Re: [aqm] [Bulk] Re: the cisco pie patent and IETF IPR filing

[David Collier-Brown <[e-mail]>]

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
[e-mail]           |                      -- Mark Twain