From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B3B9721F75C for ; Sat, 30 Aug 2014 00:20:56 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gl10so3787612lab.10 for ; Sat, 30 Aug 2014 00:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I5jGAlCdmB5IbIEWJgjH2RCeXc8ep9mhzXDgtz6fdd4=; b=cYOIN774rzei5PFhqHDI1mkj0fNwvGx1yz7Q1LXnmtgFw0Vj47ezq+4ACxh0hLL/S/ 6mlCve52i5Mn1eP7GzDjPzRJG7ns9IdoW8nHXLpp6pfFQP+rQxam0iX+gt/5jHfTGNPc sSerBCh0qIQ9PR8lFxMt7vA+DUM1oeU4c6d/eF3s0i13TjOATmT+z/1bn+7/Ia8a8H0p A9n8e0v/zxB66Z4V9WLE8pQNUQ7KNrC4+XZ771CNunAYapkpOgfAXT9oiNeuGnVBbC04 ALa8Y2+XmoPAJoxQgkLtPlCVn7txOrEGxn/akzE4wSXPLIBuMbccsDOkCmjlZcCKdQkw ryfw== X-Received: by 10.152.5.9 with SMTP id o9mr318360lao.95.1409383253963; Sat, 30 Aug 2014 00:20:53 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-224-93.bb.dnainternet.fi. [188.67.224.93]) by mx.google.com with ESMTPSA id 9sm3370967lbq.33.2014.08.30.00.20.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 00:20:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Sat, 30 Aug 2014 10:20:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: David Lang X-Mailer: Apple Mail (2.1085) 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: Sat, 30 Aug 2014 07:20:57 -0000 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. >=20 > 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