<div dir="ltr">Toke,<div><br></div><div>I'd suggest to add this in you list of references:</div><div><br></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px">Godfrey Tan and John Guttag, Time-based fairness improves performance in multi-rate WLANs. In Proc of </span><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px">USENIX 2004</span><br></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px"><a href="https://www.usenix.org/legacy/publications/library/proceedings/usenix04/tech/general/full_papers/tan/tan.pdf">https://www.usenix.org/legacy/publications/library/proceedings/usenix04/tech/general/full_papers/tan/tan.pdf</a></span></font><br></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px">It's worth having a look to the APware project for freeBSD and Godfrey Tan PhD thesis at MIT.</span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px"><a href="http://nms.csail.mit.edu/projects/apware/">http://nms.csail.mit.edu/projects/apware/</a></span></font><br></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px"><br></span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px">this work predates 802.11n and aggregation.</span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px"><br></span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px">Ten years ago I played with SFQ and madwifi for 802.11g</span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px">to get max-min time fairness (and so proportional rate fairness) with excellent results.  The hacking I made was based on</span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px">using time quanta instead of bytes. Which required me to</span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px">get the current PHY rates (AP to all STAtions) and dynamically compute/update </span></font><span style="font-size:16px;color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif">SFQ time quanta.</span></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px"><br></span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px">It's surprising that 802.11 standard never considered time fairness in the EDCF. A reason might be the time fairness might be enforced using the PCF.</span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px"><br></span></font></div><div><font color="#000000" face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:16px">IMO, It's a very good topic.</span></font></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px">Thanks for bringing this up.</span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px">Luca</span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 2:19 PM, Toke Høiland-Jørgensen <span dir="ltr"><<a href="mailto:toke@toke.dk" target="_blank">toke@toke.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So one of the components of tackling WiFi performance in Linux is (I<br>
believe) achieving airtime fairness (which turns out to be equivalent to<br>
proportional throughput fairness [1]). This is my attempt to summarise<br>
some thoughts on how to achieve this. I am by no means claiming these<br>
thoughts are necessarily (all) original, a lot of it has been floating<br>
around for a while; I'm simply trying to separate out airtime fairness<br>
as a separate issue that can be tackled orthogonally from the other<br>
parts of the stack (and that hopefully will be complementary). Feedback<br>
welcome, obviously :)<br>
<br>
<br>
In the literature, there are basically three approaches to achieving<br>
airtime fairness: Varying the MAC protocol timing parameters (e.g. TXOP<br>
duration or CWmin; see e.g. [2] for an over-engineered "optimal" way of<br>
doing this), varying the size of the aggregate (see [3]) and scheduling<br>
at the access point (see [4]). The two former approaches are distributed<br>
in nature (i.e. each node adjusts its behaviour in a way that will<br>
result in aggregate airtime fairness for the whole network) while the<br>
latter is access point-centric.<br>
<br>
Improving the access point behaviour is definitely the straight-forward<br>
way, and there are many obvious improvements that can result from that,<br>
as we've already seen in e.g. Michal's patch set. So looking at airtime<br>
fairness from the point of view of the access point makes sense.<br>
<br>
Basically, on a high level I think there are two things that we need to<br>
achieve good airtime fairness: Building the right aggregates (like in<br>
[3]), and scheduling (like in [4]) to compensate for when we get it<br>
wrong or when we can't control the aggregation because the firmware<br>
handles it.<br>
<br>
Now, of course the academic publications tend to be some way from<br>
something that can be implemented in practice; I simply refer to them<br>
here as concepts worth pursuing, and to shape thought. And, well,<br>
because I happen to be in academia myself ;)<br>
<br>
<br>
Getting closer to the practical level, what I plan to go poke at is:<br>
<br>
(1) The ath9k aggregation building logic, to try to achieve<br>
  constant-time aggregate size (for a suitable time quantum). Not sure<br>
  how much actually needs to change here; the standard already mandates<br>
  that an aggregate cannot be longer than 4ms, so the code already takes<br>
  time into account. And not sure how this interacts with rate<br>
  selection.<br>
<br>
(2) Adding a time-based scheduler to enforce airtime fairness. Building<br>
  this on FQ-CoDel seems like the sensible thing to do, to get the same<br>
  latency bonus for stations that only transmit occasionally. It would<br>
  be nice to be able to stick this in the mac80211 layer to make it<br>
  shared between drivers, but not sure the required timing information<br>
  is available at that layer.<br>
<br>
<br>
A non-exhaustive list of issues that need to be resolved one way or<br>
another:<br>
<br>
- What to account to each station's airtime? My thought would be<br>
  retransmissions, but not time spent waiting for other stations.<br>
<br>
- What about management, control and multicast frames? I'd say just<br>
  ignore it (at least for now).<br>
<br>
- How to measure the results? Can we dump the information from the<br>
  driver (and is it accurate)? Do we need to parse aircaps? Something<br>
  else?<br>
<br>
<br>
Hope this all makes sense. Comments very welcome! :)<br>
<br>
-Toke<br>
<br>
<br>
[1] Li Bin Jiang and Soung Chang Liew, "Proportional fairness in<br>
wireless LANs and ad hoc networks"<br>
<a href="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1424745&isnumber=30730" rel="noreferrer" target="_blank">http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1424745&isnumber=30730</a><br>
<br>
[2] P. Lin, W. I. Chou and T. Lin, "Achieving airtime fairness of<br>
delay-sensitive applications in multirate IEEE 802.11 wireless LANs,"<br>
<a href="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6011749&isnumber=6011722" rel="noreferrer" target="_blank">http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6011749&isnumber=6011722</a><br>
<br>
[3] Minho Kim, Eun-Chan Park, and Chong-Ho Choi, “Adaptive Two-Level<br>
Frame Aggregation for Fairness and Efficiency in IEEE 802.11n Wireless LANs,”<br>
<a href="http://www.hindawi.com/journals/misy/2015/548109/" rel="noreferrer" target="_blank">http://www.hindawi.com/journals/misy/2015/548109/</a><br>
<br>
[4] Li Bin Jiang and Soung Chang Liew, "Proportional fairness in<br>
wireless LANs and ad hoc networks,"<br>
<a href="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1424745&isnumber=30730" rel="noreferrer" target="_blank">http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1424745&isnumber=30730</a><br>
_______________________________________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
</blockquote></div><br></div>