Re: [Make-wifi-fast] [RFC] mac80211: Add airtime fairness accounting

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2017-10-06 at 13:52 +0200, Toke Høiland-Jørgensen wrote:
>> This adds accounting of each station's airtime usage to mac80211. On
>> the RX side, airtime is calculated from the packet length and
>> duration.
>
> I think you should probably try to get something here from the driver?
> Doing the calculations is really awkward, because you have to take
> into account aggregation, etc.

Well, calculating the duration from the rate and size is what ath9k is
currently doing, and that has all the information available to do so (I
did verify that the airtime was almost identical on the TX and RX side
for the same traffic). But yeah, I guess that is not necessarily the
case for all drivers? Maybe having a field that the driver can fill in
is better (that also has the nice property that a driver that doesn't
supply any airtime information won't get the scheduling; which is
probably desirable).

> However, I'm not even sure that you _want_ to use RX airtime at all? I
> guess this is a fairly fundamental philosophical question, but there's
> no way to feed back "you're sending too much" to a station, so if it
> starts consuming a lot of airtime with (what we see as) RX, and we
> throttle sending to it, then I'm not sure that will have much effect?
> Maybe with TCP, but not really with anything else.

You're right that it does nothing for one-way UDP, of course. But not a
lot of traffic is actually one-way (most is either TCP or something like
Quic that also has a feedback loop). So in most of our tests we saw a
pretty nice effect from TCP back-pressure.

> You also can't really know what AC this was on, and it doesn't make all
> that much sense?
>
> Then again, I'm not even sure yet why you care about the AC at all?
> Should fairness really be something that's within an AC?

No, ideally it shouldn't. This is mostly an artifact of how ath9k
schedules TXQs independently for each AC. This means that if (say) three
stations are back-logged on the BE queue, and one of those also has the
occasional packet on the VO queue, if the deficit is shared between all
levels, every time a VO packet arrives that station effectively gets its
deficit reset to zero, meaning it will get too much airtime.

Having a separate deficit for each AC level is a crude workaround for
this, which is what we went with for the initial version in ath9k; and
this patch is just a straight-forward port of that. But I guess this is
a good opportunity to figure out how to solve this properly; I'll think
about how to do that (ideas welcome!)...

-Toke