From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B3C3E21F380 for ; Sun, 31 Aug 2014 13:46:41 -0700 (PDT) Received: from 72-160-19-81.dyn.centurytel.net ([72.160.19.81] helo=[192.168.2.5]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XOC18-0001t0-4C; Sun, 31 Aug 2014 21:46:36 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> <4C1661D0-32C6-48E7-BAE6-60C98D7B2D69@ifi.uio.no> <8651E326-171F-472F-9456-920A9E43367D@gmail.com> <4265A8B2-10DA-455A-BA61-41907752365D@gmail.com> <5DEDBF8E-EA25-4CEC-B235-1F0122CAB228@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----9H7AB6U9YKBMD15CWSE8AD9Y2ODR2W" Content-Transfer-Encoding: 8bit From: Simon Barber Date: Sun, 31 Aug 2014 13:46:19 -0700 To: Jonathan Morton ,David Lang Message-ID: <9ab693a9-d24d-4175-a561-c8e320064486@email.android.com> X-Spam-Score: -2.9 (--) Cc: bloat Mainlinglist Subject: Re: [Bloat] sigcomm wifi X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 20:46:42 -0000 ------9H7AB6U9YKBMD15CWSE8AD9Y2ODR2W Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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. ------9H7AB6U9YKBMD15CWSE8AD9Y2ODR2W Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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@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@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------9H7AB6U9YKBMD15CWSE8AD9Y2ODR2W--