Network for Sale

Wed Feb 21 20:53:44 UTC 2001

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 at 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)