On Wed, Feb 21, 2001 at 12:28:20PM -0800, Paul A Vixie wrote:

...

...

Oh god, I hope not. RTT has never been an accurate predictor of end-to-end performance. (Just ask anyone who bought into ping-based global server load balancing.) ASPATH length is almost as bad (as a predictor) as RTT.

well, it's the way icmp_echo is handeld in some vendor routers and sometime also the poor implementation of an IP stack on the echoing device which is a problem.

no, that is not the problem. oh i admit that ping time jitter is ~random. but even if it weren't, RTT doesn't drive performance, (bw*delay)-loss does.

Delay (in non-obscene amounts) can be overcome, loss cannot. Loss is especially bad when you are overcoming delay with a large window of packets inflight, even more so without SACK. Designing a network to please the "traceroute happy" customer will probably not make anything better by itself. Assuming your goal is to actually push packets, loss should be eliminated first before RTT becomes an issue. Lack of bandwidth is the cause, loss is the symptom. This is of course assuming that TCP thruput is your goal, which may be completely not the case. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)