[e2e] Fundamental Questions about Router Queue in High Speed IP Networks

[Ted Faber]

On Fri, Aug 24, 2001 at 12:07:15PM -0400, David P. Reed wrote:
> At 05:21 PM 8/24/2001 +0100, Vos, E.W. wrote:
> >I don't see why buffering is so wrong. Actually, a buffer should be large
> >enough to accomodate incidental bursts of traffic. Aren't the effects of
> >dropping a packet much worse than delaying one a little bit?
> 
> Not a well-formed question - some drops are essential, some are 
> costly.  Dropping a packet is how you tell TCP to back off.  Delaying the 
> dropping may lead to a larger catastrophe.  RED and ECN (and even SQ) are 
> just simulated dropping, and increasing queue size also slows TCP's back-off.

While it's true that ECN is a simulated drop from the congestion
control standpoint, it is a non-event for the retransmission system.

While it's true that increasing the router's queue size without changing REDs
parameters will just lead to larger queue utilization (with a lot of
big TCP flows), RED parameters can be changed simply.

For TCP flows using RED and ECN, loss is neither necessary nor
particularly useful.

If your router is serving bursty traffic amongst bulk TCP sources that
use ECN, adding queueing to your router and appropriately modifying
the RED parameters will really let you trade loss for delay.  There
are plenty of times that's not a good trade, but it's available in a
TCP/ECN/RED world.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20010827/5d454e44/attachment.bin