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 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@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/bloat -- Sent from my Android device with K-9 Mail. Please excuse my brevity.