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