[Bloat] Remarkably simple bloat managing use by a UK ISP

[Dave Taht]

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
<kevin at darbyshire-bryant.me.uk> 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
> Bloat at lists.bufferbloat.net
> 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