[Bloat] sigcomm wifi

[Simon Barber]

Modern APs use more agressive channel access parameters than clients. They can also control the parameters the clients use.

One major issue is that to remove bloat in a wireless environment and keep access fair and delays low you really want to integrate the AQM and the packet scheduling, while tracking airtime usage. I very much doubt any equipment is doing this.

Simon

On August 30, 2014 12:20:48 AM PDT, Jonathan Morton <chromatix99 at gmail.com> wrote:
>
>On 24 Aug, 2014, at 11:24 am, David Lang wrote:
>
>>> The conditions are probably different in each direction.  The AP is
>more likely to be sending large packets (DNS response, HTTP payload)
>while the client is more likely to send small packets (DNS request, TCP
>SYN, HTTP GET). The AP is also likely to want to aggregate a TCP
>SYN/ACK with another packet.
>> 
>> If your use case is web browsing or streaming video yes. If it's
>gaming or other interactive use, much less so.
>
>That's fair enough.  But the conditions in both directions are *still*
>different, to the point where I am wary of attempting to simulate
>multiple wireless clients using a single piece of hardware.
>
>The big problem is that clients have the sheer weight of numbers behind
>them when negotiating for the channel, and are therefore quite capable
>of starving the AP if there are enough of them.  This results in
>congestion collapse, as the clients aggressively demand updates on
>where the responses to their requests have got to, while the poor AP
>can't get a packet in edgewise to answer them.  It doesn't matter, for
>that purpose, whether the packets are bigger in one direction than the
>other - the per-transmission overhead in modern wifi is big enough to
>swamp that effect.
>
>For the sake of amusement, I'm going to call this the "airport
>problem".  Imagine a harassed airline desk clerk, besieged by hundreds
>of irate passengers who have just been sat on the tarmac for three
>hours.
>
>I don't think this is a new problem with wireless networks, either - it
>should happen on bus Ethernet, too.  That's probably a large factor
>behind the comprehensive shift away from bus and hub Ethernet to
>switched Ethernet on most corporate LANs, which have a habit of
>acquiring large numbers of clients.
>
>Fortunately, modern wifi also comes with a mechanism that could,
>theoretically, be used to combat this problem.  An AP with a lot to
>send could ignore clients' RTS, and respond with an RTS of its own
>instead of a CTS.  This would allow it to get its greater volume of
>packets, data and/or TCP ACKs through, satisfying the requests and
>hopefully pacifying the crowd.  But I have no idea at present whether
>that technique is actually in use.
>
> - Jonathan Morton
>
>_______________________________________________
>Bloat mailing list
>Bloat at lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20140831/48febf3b/attachment-0003.html>