[Cake] Cake on OpenWRT community builds and my observations

[Dave Taht]

On Tue, Dec 8, 2015 at 3:02 AM, Frits Riep <riep at riepnet.com> wrote:
> First of all, I would like to thank all of the contributors for their hard
> work and good progress in the challenge of combating bufferbloat!

we appreciate the appreciation.

> Most IT professionals and users still have no idea of issue or the potential
> fixes, and so awareness in the larger community is still a major issue.

Sigh. fix it for two friends, ask them to fix it for two friends, and
we'll get there.

I keep hoping someday soon I'll see
http://www.dslreports.com/speedtest/results/bufferbloat?up=1
have more stuff move up and closer to the green line....

> I had in the past used Cerowrt builds and other openwrt builds with fq_codel
> and also have been very happy with the results.

> I'd like to provide some feedback on my experiences with Cake so far.  I
> just updated my TP-Link Archer C7 to an OpenWRT image which was pre built
> with sqm-scripts and I was very pleasantly surprised to find that it
> supported Cake, and I set it up and tested using queue discipline as "cake"
> and queue setup script "layer_cake.qos"  I have been following the progress
> over time in the bufferbloat email lists, but was not aware that I could
> access a build supporting cake without doing my own build and I was not
> really knowledgeable enough to take that on.
>
> I've so far been extremely pleased with the results of my initial testing,
> and even when I set the bandwidth limit at very low speeds (like 1 Mbs up
> and down), applications like Netflix worked perfectly, pings were great, and
> dslreports.com/speedtest, report A+ on bufferbloat.

My own query these days is how does it compare to htb + fq_codel?

I am having trouble seeing any performance difference at all on the
hardware I have
under test.

> As I read about the qos part, I am wondering however is it only IP Layer-3
> DSCP which goes into the queue management system or is Layer-2 traffic like
> 802.1p traffic also being managed?

No layer 2 stuff is handled. Sometimes that's impossible, it's not
preserved when
packets are routed. When things are bridged, it's often bypassing major
portions of the stack.

Now, if a wired to p2p wireless bridge existed that
was sane to hack on, carrying some of that 802.1p traffic would help.

my take generally has been on - if you must deal with 802.1p, re-mark
the dscp value so it can survive transit across multiple links (and even then,
it won't).

>
> It would be great to manage that as well if it is not because there are many
> applications where there is bufferbloat which could be managed by OpenWRT.

Managing bufferbloat is almost entirely independent  of QoS markings.
Controlling
queue length and fair queuing are vastly more effective.

> For example, there are wireless links between buildings, situations where
> priority packets are not marked.  Voip phones often are set by default to
> prioritize voice packets via 802.1p.

Sure. But it doesn't matter anywhere near as much as fq or queue length.

the biggest problem linux wifi has currently is huge driver queues,
that no amount of reprioritization
can get through.

>
> Please let me know your thoughts on this.

There are so many issues with wireless that it's hard to start. For
starters, cake is the wrong thing for wireless. it (like fq_codel)
would work ok if we had less buffering in general, but only on p2p
links, and it would still behave badly with multicast and with
interference.

Fixing p2mp (e.g. Access points) is harder.

I go into how we plan to try to tackle wireless issues here:
https://www.youtube.com/watch?v=Rb-UnHDw02o

I really should do a diagram of what people think happens when qos
markings are used, vs what is actually happening, and nail it to the
wall, like Luther.

Gospel 'roun here is short queues with fq, first.

Some of the algorithms and ideas in cake might get reused. Certainly
the development experience
and tests we've developed will.