Yes, making a distinction between large and small packet sizes helps. There is a clear bifurcation in network traffic at around 300 bytes, with all kinds of packet sizes below 300, with very few packets sized in the 300-1100 byte range. webrtc and hangout traffic tends to about 1000 bytes for some reason.
As shipped in openwrt and the sqm-scripts, 300 is the default fq_codel quantum. Along the way we explored per packet fairness not just with SFQ but fiddling with the drr (and later, fq_codel) quantum, settling initially on 500 bytes and after much testing, we cut to 300 bytes. There was a variant (pfq_codel I think it was in the codebase) that attempted per packet against all small flows fairness (fiddling with the new/old queue concept) - but it did badly. I think nfq_codel still exists in cerowrt as it did quite well also (I can no longer remember what it did, but it also served more different flows within a quantum). It is kind of unclear, scheduling for higher bandwidths (100s of mbits), what the drr quantum should be. Cake is experimenting with gradually increasing the quantum as bandwidths grow. I lean towards sticking with 300 bytes until you crack a gigabit. sch_fq (targetted at 10gigE+) defaults to 2 packets (3018) which has the nice property of releasing a delayed-ack on the other side. (I had talked to john nagle a long time ago and one of the things he sighed about was that he was deeply unhappy (starting in 198x!) about the delayed ack concept, but he never explained why, and I have assumed it was the loose interaction with fq... and lets not go into stretch acks!) It had been my hope that the new/old flow distinction in fq_codel at the default packet quantum (1514) would provide a useful signal to a tcp type about the actual path RTT, but I think (now, 3 years later), that gets smoothed away. Still, the new paced stuff (which can measures the baseline RTT from the syn/synack pair) interacts nicely with the new/old distinction in fq_codel at 300 bytes. To mess up this observable portion of the universe and "easy fix", there are tcp fast open and quic. On Fri, Jun 5, 2015 at 7:46 AM, Kevin Darbyshire-Bryant <[email protected]> wrote: > Hi Chaps, > > I was speaking with Andrews & Arnold (a UK clueful ISP) about their > experiences with bufferbloat and was sent this graph: > https://support.aa.net.uk/VMG1312:_QoS > > I was surprised at how such a simple 'priority by packet size' scheme > appears to work. Clearly there's slightly more going on in that the box in > question *knows* the outbound bandwidth and doesn't let a standing queue > form...but priority by packet size? Hmm. > > Kevin > > > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat > -- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
