[83693] in North American Network Operators' Group
Re: Question about propagation and queuing delays
daemon@ATHENA.MIT.EDU (Andre Oppermann)
Mon Aug 22 12:40:59 2005
Date: Mon, 22 Aug 2005 18:40:30 +0200
From: Andre Oppermann <nanog-list@nrg4u.com>
To: Tony Finch <dot@dotat.at>
Cc: Petri Helenius <pete@he.iki.fi>,
David Hagel <david.hagel@gmail.com>,
"Robert E. Seastrom" <rs@seastrom.com>,
Richard A Steenbergen <ras@e-gerbil.net>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.60.0508221717430.32180@hermes-1.csi.cam.ac.uk>
Errors-To: owner-nanog@merit.edu
Tony Finch wrote:
> On Mon, 22 Aug 2005, Petri Helenius wrote:
>>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?
>>
>>Co-operative congestion control is like many other things where you're better
>>off without it if most of "somebody else" is using it. TCP does not give you
>>optimal performance but tries to make sure everybody gets along.
>
> TCP performs much better if queueing delays are short, because that
> means it gets feedback from packet drops more promptly, and its RTT
> measurements are more accurate so the retransmission timeout doesn't get
> artificially inflated.
A combination of WRED and friends doing tail- and head-drop would seem
to be ideal for this.
OTOH you rather want some queueing delays instead of packet drops if
your RTT is high. Recovering from packet loss at >100ms is far slower
than having 10ms added to the RTT.
--
Andre
