Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Network for Sale

  • From: Richard A. Steenbergen
  • Date: Wed Feb 21 16:16:54 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 <>
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.