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

[David Lang]

I actually have hopes that it will help in the (fairly common) case of multiple 
stations streaming video from the Internet at the same time. If the AP -> 
endpoint traffic can send to multiple stations in the same txop, it can greatly 
reduce the amount of airtime needed.

unfortunantly, from what I hear, the factory AP firmware breaks down if there 
are more than about a dozen stations connected, just as it becomes the most 
valuable.

But to make it work, we can't have two layers of buffering, we need the firmware 
to be able to grab several aggregates worth of data from different queues, and 
some of the data grabbed may be an 'unfair' share for that source, but it should 
still be grabbed because there is nothing else that could be sent at the same 
time, so the transmission is effectively free.

but to do that sort of thing, we really need to be operating close to the 
hardware, not with some firmware buffers between us.

David Lang

On Thu, 12 May 2016, Luca Muscariello wrote:

> I share your skepticism about beam forming. It depends of course on the kind
> of usage you make of wifi. If it's to cover a city in a small cell
> optimized deployment
> I don't think beam forming is going to help. When cell traffic is high only
> TDMA can help.
>
> If you use beam forming to reach non mobile users and traffic is not to
> high it's going to
> give best performance.
>
> Both are valuable use cases with economic incentives behind.
> The first one is more difficult and time fairness is gonna help a lot there
> as the average cell throughput is gonna be a lot better.
>
>
>
> On Wed, May 11, 2016 at 8:13 PM, Dave Taht <dave.taht at gmail.com> wrote:
>
>> On Wed, May 11, 2016 at 9:41 AM, Dave Taht <dave.taht at gmail.com> wrote:
>>> On Wed, May 11, 2016 at 9:09 AM, Luca Muscariello
>>> <luca.muscariello at gmail.com> wrote:
>>>> Correct, but in between that time and now a lot has been done in
>> different
>>>> areas but not much on this point.
>>>> The fact that some part of the industry is looking at LTE-U is also
>> because
>>>> 802.11 standard is not good enough.
>>>
>>> What do you think of LTE-LAA?
>>>
>>> I do think very strongly that actual usage of 802.11 can be made
>>> vastly more efficient, that we can use up a great deal of the mac
>>> currently being left unused, and schedule txops way more efficiently -
>>> and that I'd love to test with michal's patch set against the LTE-U
>>> tests cablelabs, etc which did
>>>
>>> 100 stations before (stock):
>>>
>>> http://blog.cerowrt.org/flent/drr/10tothe5.svg
>>>
>>> after
>>>
>>> http://blog.cerowrt.org/flent/drr/newcode.svg
>>
>> Seeing "only" 250ms worth of delay for 100 stations here was what
>> kicked off a prior thread, my understanding of a theoretical base
>> number here would be about 70ms. (?)
>>
>
> I miss many details about these tests. And probably I missed the thread...
> Can you give me pointers?
>
>
>
>>
>> ...
>>
>> Adding in mu-mimo to the picture makes my head hurt. My understanding
>> of how mu-mimo is supposed to work is you have to have accumulated
>> 2-3ms worth of packets for the number of stations you are going to
>> schedule before it's worthwhile at all.
>>
>> The stations are going to typically be limited to 1 antenna (most
>> laptops have 2), I think. So a 4 antenna system *could* send to 4
>> stations if all have traffic pending... at a cost of a (proposed, I
>> don't agree with it) 500 usec sounding phase every 10ms. My take on
>> that is you should only sound when you actually have some potential to
>> share that many flows to that many stations, sounding being more of an
>> aspect of rate control, also.
>>
>> Having only 2 stations that you can mu-mimo to seems like a lose generally.
>>
>> Based on normal traffic behaviors the stations that could be sent to
>> varies, and gang scheduling with lots of stations would require even
>> more soundings...
>>
>> ...
>>
>> I don't have a lot of hope for mu-mimo, although what I kind of expect
>> is the work done here will end up marketed as due to that feature in
>> the wave2 stuff...
>>
>