On Wed, 4 Mar 2015, KK wrote:
Date: Wed, 04 Mar 2015 01:01:19 -0800
From: KK <[email protected]>
To: Vishal Misra <[email protected]>, Dave Taht <[email protected]>
Cc: "[email protected]" <[email protected]>, bloat <[email protected]>
Subject: Re: [aqm] the cisco pie patent and IETF IPR filing
I think a combination of PI/PIE/fq_codel with ECN would enable us
a) be less dependent of the physical amount of buffering that is
implemented on the intermediate devices
b) allow us to use buffering for what it is meant to do - ride out
transient variations in traffic, at points where there is a mismatch in
available capacity
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)
c) allow us to support different types of links, including wireless lossy
links
If a retry is fast and has a very high probability of succeding, then it may be
worth holding it and doing a link-level retry. But the existing mess that is
wifi is hardly a good example of this being the right thing to do in a congested
environment.
David Lang
d) as we wrote in the ECN RFC, allow even short-lived transfers to not
suffer
Thanks,
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
