On Mon, May 18, 2015 at 8:54 AM, Jonathan Morton <[email protected]> wrote: > >> On 18 May, 2015, at 18:27, Simon Barber <[email protected]> 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 > [email protected] > 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 _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
