[Cake] cake byte limits too high by 10x

[Jonathan Morton]

> On 24 May, 2015, at 08:14, Dave Taht <dave.taht at gmail.com> wrote:
> 
> at 100Mbit we had 5 megabytes of max queuing. I don't think this was
> jonathon's intent, as the default if no rate was specified was 1Mbyte.
> 
> … On the other hand codel does not
> react fast enough to major bursts without engaging the out of
> bufferspace cake_drop which is pretty darn cpu intensive.

The 1-megabyte default is not intended to reflect the highest possible link rate.  Frankly, if you’re triggering cake_drop() without involving truly unresponsive flows, then the buffer limit is too small - you need to give Codel the time it needs to come up to speed.  I definitely should make cake_drop() more efficient, but that’s not the problem here.

I consider it *far* less important to control the short-term length of individual queues, compared to the latency observed by competing latency-sensitive traffic.

And I also think that ECN and packet-drops are too crude a tool to control queue length to the extent you want.  Hence ELR - but that’s still in the future.  (How much funding do you think we can get for that?)

> On the
> gripping hand there becomes no right outer limit for a wildly variable
> 802.11ac wifi queue, with speeds from one to 1.5Gbit, but I sure would
> like a cake-mq that handled the existing queues right with less
> memory.

Something that I haven’t had time to implement yet is a dual-mode FQ, performing both flow isolation and host isolation.  That seems like a step towards what wifi needs, as well as more directly addressing the case where swarms and sensitive traffic are running on different endpoints, without Diffserv assistance.

However, the overall design I have in mind for a wifi-aware qdisc is a little bit inside-out compared to cake.  Cake goes:

shaper -> priority -> flows -> signalling -> queues

…or, with host isolation added:

shaper -> priority -> hosts -> flows -> signalling -> queues

What wifi needs is a bit different:

(hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows -> signalling -> queues

Of course, since the priority layer is buried three+ layers deep, it’s obviously not going to use hardware 802.11e support.

 - Jonathan Morton