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

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

David Lang <david@lang.hm> writes:

>> 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)

Yes, there's that too. Besides, if we assume most traffic is TCP (or has
similar ack-type feedback), we can to a large extent control what the
client does by scheduling in the downstream.

> 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.

Ah, right, hadn't thought of that. Another good reason to reduce
queueing in the lower layers I suppose...

> 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.

Yes, my thought was to just switch entirely to time-based accounting in
the scheduler. Which means that the scheduler has to have this
information available to it. Not sure whether that is practical at the
mac80211 layer (but suppose it could be done by adding appropriate
driver hooks if things are missing).

>> - 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.

Hmm, hadn't thought of that. Damn. Well, guess we'll have to trust the
driver (or make it trustworthy if we can't).

-Toke