[Cake] cake byte limits too high by 10x

[Jonathan Morton]

> > What wifi needs is a bit different:
> >
> > (hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows ->
signalling -> queues

> Yep.

> I don't see a huge need for "shaping" on wifi. I do see a huge need - as
a starting point - an airtime fair per station queue that is aggregation
aware, and slightly higher up, something that is aware of the overall
workload on the AP.

Which is basically what I'm thinking of. "Airtime fair" is also known as
"proportional fair". You need to know the data rate to each station for
that.

But knowing the data rate via minstrel, and the average expected time
between transit opportunities to each station (which could probably be
calculated rather than measured), would allow inferring certain things that
I currently do using the shaper in cake, such as the appropriate size for
the aggregate, and the amount of bandwidth that we can allow priority in.
The only reason I can't reliably do that in cake with the shaper disabled
is because I can't sense the hardware link rate, which is exactly what
minstrel is in charge of.

Incidentally, I suspect that aggregates of equal temporal length are
valuable for multi station MIMO.

It's also pretty obvious that selective link layer acks need to be acted
on, and aggregates reformed for each transmit opportunity, whether a retry
or not. I'm very disappointed to hear that those things often aren't
already done, but it's probably a consequence of leaving that functionality
to the hardware vendors so far. It's even possible that the current mess of
binary blobs is a consequence of the weak support for aggregation in the
kernel.

Probably not so much raw code (which autocorrected to coffee TWICE) can be
reused from cake, not least due to simply operating at a different layer of
the stack, but I think a lot of the conceptual advances can.

- Jonathan Morton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20150529/98e89596/attachment-0002.html>