[Make-wifi-fast] Thoughts on tackling airtime fairness

[David Lang]

On Wed, 11 May 2016, Toke Høiland-Jørgensen wrote:

> Improving the access point behaviour is definitely the straight-forward
> way, and there are many obvious improvements that can result from that,
> as we've already seen in e.g. Michal's patch set. So looking at airtime
> fairness from the point of view of the access point makes sense.

As a practical matter, we are not going to be able to change the code on the 
nodes. There are just too many closed source, and never-to-be-updated devices 
out there (IoT)

So focusing on the AP is the right thing to do.

> Basically, on a high level I think there are two things that we need to
> achieve good airtime fairness: Building the right aggregates (like in
> [3]), and scheduling (like in [4]) to compensate for when we get it
> wrong or when we can't control the aggregation because the firmware
> handles it.
>
> Getting closer to the practical level, what I plan to go poke at is:
>
> (1) The ath9k aggregation building logic, to try to achieve
>  constant-time aggregate size (for a suitable time quantum). Not sure
>  how much actually needs to change here; the standard already mandates
>  that an aggregate cannot be longer than 4ms, so the code already takes
>  time into account. And not sure how this interacts with rate
>  selection.

I think the problem  is that the aggregates are created too soon, and as a 
result the rate can change drastically between the time the aggreagate is formed 
and when it is sent. I don't believe that they are really limited to 4ms in 
practice.

> (2) Adding a time-based scheduler to enforce airtime fairness. Building
>  this on FQ-CoDel seems like the sensible thing to do, to get the same
>  latency bonus for stations that only transmit occasionally. It would
>  be nice to be able to stick this in the mac80211 layer to make it
>  shared between drivers, but not sure the required timing information
>  is available at that layer.

Right now, most of the stuff is still doing packet-count based queues. On wired 
networks where the rate was constant, moving to BQL was a huge win. When the 
rate can vary so drastically, we need to be factoring rate into the picture 
somehow.

> A non-exhaustive list of issues that need to be resolved one way or
> another:
>
> - What to account to each station's airtime? My thought would be
>  retransmissions, but not time spent waiting for other stations.

Possibly, or possibly have retransmissions change the effective rate.

> - What about management, control and multicast frames? I'd say just
>  ignore it (at least for now).

I agree.

> - How to measure the results? Can we dump the information from the
>  driver (and is it accurate)? Do we need to parse aircaps? Something
>  else?

we need to be able to instrament the driver (I don't know if we can get enough 
data there or not currently)

trying to work with aircaps has the problem that what you see in the aircap 
doesn't match what either the sender or receiver sees

Take retransmissions as an example. They only happen because the receiver didn't 
see them. If you were to get an aircap off the same antenna as the receiver, you 
also wouldn't see them and therefor could not account for them. In the real 
world, you are doing the aircap from a different device, with a different 
antenna so what you see will be even more different. Now think about the normal 
case where you have two stations taking in two very different locations and one 
device to do the aircap.

If we don't have anything else, aircaps are what we have to fall back on, but we 
need to realize how much we can't see at that point.

David Lang