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

Luca Muscariello luca.muscariello at gmail.com
Wed May 11 12:33:15 EDT 2016


What is worse is that I agree entirely.

Short time fairness is important and more important is a fairness criterion
that enables expedited forwarding for RTC.
 And for RTC
what you say is key.

However, EDCF is not going to help when you have many stations and low PHY
rates should be disabled
to get something that approaches to what you have in mind.

On Wednesday, 11 May 2016, Dave Taht <dave.taht at gmail.com> wrote:

> My own foci are going to be around trying to rip every source of
> potential latency out of the current system: be it deferred
> interrupts, bad rate control information, overlong txops, excessive
> retries, insufficient packet loss, busting the block ack window, and
> quashing stations grabbing too much airtime...
>
> and then adding back in "bandwidth" from there. We have enough
> bandwidth in wifi nowadays, just now narrow enough time slices to feed
> many stations sanely.
>
> a somewhat subtle distinction is that aiming for airtime fairness
> independently of the behaviors of real traffic is not a goal (for me).
> A system handing out 8 stations 8ms each of airtime is "fair", but
> handing out 1ms each - or just enough, for example, for my
> videoconferencing flow to handle each frame with a single txop - or
> getting a new station started faster on some web traffic - is better.
>
> Certainly there is a ton of low hanging fruit to excise, and achieving
> something closer to but we ignore multicast, channel scans, and other
> oddities to our peril.
>
> I don't, for example, think that aiming for airtime fairness over 1sec
> intervals is good, 20-50ms would be way more desirable. And so on.
> Getting a good rate control estimate by the second txop used by a
> previously idle station would be good. And so on.
>
> ...
>
> this message brought to you from the association for more coffee in the
> morning.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20160511/14aa38ae/attachment.html>


More information about the Make-wifi-fast mailing list