Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

On Mon, May 18, 2015 at 8:54 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 18 May, 2015, at 18:27, Simon Barber <simon@superduper.net> wrote:
>>
>> Apparently a significant chunk of bittorrent traffic and Windows updates use these techniques to deprioritise their traffic. Widespread adoption of AQM will remove their ability to avoid impacting the network at peak times. Use of DSCP could be one way to mitigate this problem with AQM, and this merits further study.
>
> I’m working on a comprehensive algorithm (including AQM, FQ and Diffserv support and a shaper in one neat package) which does address this problem, or at least provides a platform for doing so.  Some information here:
>
>         http://www.bufferbloat.net/projects/codel/wiki/Cake

This is partially an outgrowth of some of the ideas and problems I
attempted to discuss at ietf90.

https://www.ietf.org/proceedings/90/slides/slides-90-aqm-6.pdf

Since then various other working groups (like dart) attempted to
answer some of the same questions.

I am pretty convinced (now) that inbound policing on cpe can be
improved to better "fool" dumb upstream rate limiters (like those in
cmtses), but haven't got around to doing the work (it's called
"bobbie"). The biggest problem we have with applying a shaper + fq/aqm
algorithm to inbound traffic on an already be-ing dumbly rate limited
link is that a burst can backup in the upstream cmts and stay backed
up - a rate differential of 90 to 100 takes a long time for an aqm to
bring under control. Analysis of "smoothness" might also help.

When the ratios are 10 or 1000s to 1 and there is only one bottleneck
link, we do better.

> This is working code, albeit still under development.  I’m actively dogfooding it, and I’m not the only one doing so.

Pushing it into openwrt soon, we hope. As it stands cake is a win
across the board on cpu cost and fairness, it does saner things with
ecn, and so on...

We have discussed a few more advanced ideas that are not currently in
cake on the cake mailing list, including better coupling between
flows, more rapid response to overload, etc.

> The Diffserv layer provides a four-class system by default, corresponding in principle with the 802.1p classes - background, best-effort, video and voice.  It does not inherit the naive mapping from DSCPs to those classes, though - only CS1 (001000) is mapped to the background class.

I see a ton of traffic remarked to CS1 from comcast. Others may be more lucky.

Since dart I have basically come to the conclusion we need at least
one new diffserv priority class for scavaging traffic.

> An important part of the Diffserv support in Cake is that the enhanced priority given to the video and voice classes applies only up to given shares of the overall bandwidth.  If traffic in those classes exceeds that allocated share, deprioritisation occurs.  This ensures that improperly marked traffic cannot starve the link, and attempts to incentivise correct marking.
>
>  - Jonathan Morton
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67