On 03/04/2015 04:42 AM, David Lang wrote:
The question is how much of a burst should the buffer be able to
handle? Right now buffers routinely hold 10+ seconds worth of traffic
(and Dave T showed the airline system buffering 10+ MINUTES of traffic)
The problem is that if you buffer too much, you break the TCP link
speed probing, and if you buffer even more you end up with the sender
genrating a new packet to deliver while you still are buffering the
old one.
Buffers need to hold less than one second worth of traffic, and
emperical testing is showing that much less is desirable (Others can
post more exact numbers, but I belive that somewhere between 1/100 of
a second and 1/10 of a second is a reasonable range)
I'd suggest that buffers are there to hold unexpected bursts of traffic
above the steady state maximum. This can happen for several reason:
1) due to the sender sending an unexpected wodge, either at startup or
due to a bug, or
2) after a period of non-transmission, due to something in the pipe
slowing us down momentarily.
Either case of (1) should be throttled, so bugs and
super-fat-start-eats-the-network can be avoided (;-))
Case of (2) need to be buffered, in an amount that handles either the
average/expected burstyness of the link, or handles the predictable
burst when one stream on the link slows down and then catches up.
Let's say the link varies by +/- 1 packet/second: we should have
buffering for 2, probably for 3 and definitely not for any bigger sigma.
--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
[email protected] | -- Mark Twain
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
