[Bloat] pie aqm finally landed in Linux

Greg White g.white at CableLabs.com
Tue Jan 21 18:55:56 EST 2014


We're allowing target to be configurable, but providing a default value of
10ms.  In the DOCSIS CM implementation of PIE we don't track historic data
rates via an estimation window, instead we utilize the state of the token
bucket rate shaper to predict the rate transitions from the known peak
rate (power boost) to the known sustained rate.  This is both a) much
simpler and b) much more accurate.

The 3.1 spec and the 3.0 ECO do include AQM requirements for the CMTS side
as well. I agree though that reductions in buffer sizes would seem to be a
quick fix in advance of AQM implementations.

FYI, we've made some additional enhancements to the PIE algorithm for
DOCSIS since publication of the D3.1 spec.  An update is forthcoming.


On 1/20/14, 8:46 AM, "Dave Taht" <dave.taht at gmail.com> wrote:

>Hat off to vijay and the pie folk at cisco who shepherded the code
>through 5 releases to get it upstream!
>PIE is now mandated in DOCSIS3.1 cablemodems and the ECO for DOCSIS
>3.0 went out a while ago.
>I think the mandate differs from the Linux implementation. I don't
>know the size of the recomended cablelabs target nor the size of the
>estimation window (?)).
>So that will improve going-upstream buffering problems dramatically.
>The linux implementation supports ECN, the DOCSIS standard does not.
>The ECN work in pie has some minor problems that fq_codel doesn't
>have, we hope to discuss at ietf...
>I will fold the v5 implementation of pie into cerowrt in the next release
>see what happens.
>The biggest problem remaining in cable is fixing excessive downstream
>buffering. Surely something can be done to remove the 1.6 seconds of
>buffering I observed yesterday (at some level without needing to AQM?
>Some workaround that operators can use?). Some benchmarks I ran last
>night (not against pie):
>I sure hope the gpon, lte, and wifi folk are paying attention.
>Dave Täht
>Fixing bufferbloat with cerowrt:
>Bloat mailing list
>Bloat at lists.bufferbloat.net

More information about the Bloat mailing list