<html><head></head><body>Modern APs use more agressive channel access parameters than clients. They can also control the parameters the clients use.<br>
<br>
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.<br>
<br>
Simon<br><br><div class="gmail_quote">On August 30, 2014 12:20:48 AM PDT, Jonathan Morton <chromatix99@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><br />On 24 Aug, 2014, at 11:24 am, David Lang wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> 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.<br /></blockquote> <br /> If your use case is web browsing or streaming video yes. If it's gaming or other interactive use, much less so.<br /></blockquote><br />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.<br /><br
/>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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br /> - Jonathan Morton<br /><br /><hr /><br />Bloat mailing list<br />Bloat@lists.bufferbloat.net<br /><a href="https://lists.bufferbloat.net/listinfo/bloat">https://lists.bufferbloat.net/listinfo/bloat</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>