Question about propagation and queuing delays
Joe Abley
jabley at isc.org
Mon Aug 22 17:58:02 UTC 2005
On 22-Aug-2005, at 11:14, David Hagel wrote:
> This is interesting. This may sound like a naive question. But if
> queuing delays are so insignificant in comparison to other fixed delay
> components then what does it say about the usefulness of all the
> extensive techniques for queue management and congestion control
> (including TCP congestion control, RED and so forth) in the context of
> today's backbone networks? Any thoughts? What do the people out there
> in the field observe? Are all the congestion control researchers out
> of touch with reality?
Most networks I have touched that have seen fit to deploy some kind
of "quality of service" mechanism have done so in order to
deliberately degrade service in inverse proportion to what people are
prepared to spend. This is somewhat contrary to the marketing
message, since "pay us more money and we'll wreck your performance
less!" is unlikely to win awards as a slogan, but it happens
nonetheless.
Examples are DSL users who are rate-limited down to modem speeds
after their leeching budget for the month has been exhausted, and
gigabit-attached customers whose traffic is squeezed as it is carried
over expensive bits of network (e.g. bits that cross oceans). These
may be more common in regions with expensive external paths that are
used by a high proportion of traffic (e.g. small, English-speaking
countries in the Pacific rim) than it is in North America.
In North America, the usual contention I have seen in backbones is a
lack of external capacity towards particular peers; the answer there
is usually traffic engineering rather than queue management, although
I've seen WRED turned on as a short-term measure to make the helpdesk
phone ring less while more OC12s are turned up.
One last wave of the hands: just because the backbone is clear and
free, and rarely needing to queue a packet, doesn't mean that one
edge or another of a flow (or both) isn't competing with other
traffic as part of a multi-access wireless network, oversubscribed
back-haul from a DSLAM or a CATV network at 4pm in the winter when
the neighbourhood kids come back from school.
Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050822/6013ba7f/attachment.sig>
More information about the NANOG
mailing list