From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 DA64A21F5EA for ; Sat, 23 Aug 2014 19:29:35 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so10647385lbi.25 for ; Sat, 23 Aug 2014 19:29:33 -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=q5e20o4t6aEIyTYZBTTUkPW3+vFgYg76NZlePkX9itY=; b=G4kx3J/+qJgBYUO+PcG3Xg5hASWn2y1G8rhfpB+XaMtW6cbybCR2a6yBultuTAU7bl L6+b2/A440mF7cp8jA3/RclQAwd5w0lQlhfuJ3MpoqHx/9QGFQ4L3Lgqbah0eecNziib 818P60krrZhpQjy//VUlrBam9Ft4cqJUMOsgjIAxvYbAHty4w10LBi2ewF9jft23l9I5 v/mMIKWTwDgOE+GA2pbLU18ZhuGD816JM27AGr4cxBtmhYxRSWQGl/pM+W8ARuUScIUG S9QteVU6Ml63IaL4pP47KgSsu9veqmgKvjYSSKHFpzO7O00UZDLYS/uM6gB4sloDlgrO ShHw== X-Received: by 10.152.27.134 with SMTP id t6mr12995852lag.56.1408847373199; Sat, 23 Aug 2014 19:29:33 -0700 (PDT) Received: from bass.home.chromatix.fi (178-55-89-211.bb.dnainternet.fi. [178.55.89.211]) by mx.google.com with ESMTPSA id kv3sm54998646lbc.37.2014.08.23.19.29.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Aug 2014 19:29:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Sun, 24 Aug 2014 05:29:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4265A8B2-10DA-455A-BA61-41907752365D@gmail.com> 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> 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: Sun, 24 Aug 2014 02:29:36 -0000 On 24 Aug, 2014, at 4:33 am, David Lang wrote: > On Sun, 24 Aug 2014, Jonathan Morton wrote: >=20 >> My general impression is that 802.11ac makes a serious effort to = improve matters in heavily-congested, many-clients scenarios, which was = where earlier variants had the most trouble. If you're planning to set = up or go to a major conference, the best easy thing you can do is get = 'ac' equipment all round - if nothing else, it's guaranteed to support = the 5GHz band. Of course, we're not just considering the easy = solutions. >=20 > If ac had reasonable drivers available I would agree, but when you are = limited to factory firmware, it's not good. Hmm. What are the current limitations, compared to 'n' equipment? >> Wider bandwidth channels can be used to shorten the time taken for = each transmission. However, this effect is not linear, because the = RTS/CTS handshake and preamble are fixed overheads (since they must be = transmitted at a low speed to ensure that all clients can hear them), = taking the same length of time regardless of any other enhancements. = This implies that in seriously geographically-congested scenarios, 20MHz = channels (and lots of APs to use them all) are still the most efficient. = MIMO can still be used to beneficial effect in these situations. >=20 > Another good reason for sticking to 20MHz channels is that it gives = you more channels available, so you can deploy more APs without them = interfering with each other's footprints. This can significantly reduce = the distance between the mobile user and the closest AP. No, that is *the* good reason. If you don't have a lot of APs, you = might as well use 40MHz or 80MHz channels to increase the throughput per = AP. >> Multi-target MIMO allows an AP to transmit to several clients = simultaneously, without requiring the client to support MIMO themselves. = This requires the AP's antennas and radios to be dynamically = reconfigured for beamforming - giving each client a clear version of its = own signal and a null for the other signals - which is a tricky = procedure. APs that do implement this well are highly valuable in = congested situations. >=20 > how many different targets can such APs handle? if it's only a small = number, I'm not sure it helps much. The diagram I saw on Cisco's website demonstrated the process for three = clients, so I assume that's their present target. I think four targets = is plausible at the high end, once implementations mature, though the = standard permits 8-way in theory. The RF hardware requirements are = similar to 'n'-style single-target MIMO. > Also, is this a transmit-only feature? or can it help decipher = multiple mobile devices transmitting at the same time? I think it *could* be used for receive as well. The AP could hear = several RTS packets, configure itself for multiple receive, then send = CTS in multiple, in order to signal that. The trick is with hearing the = multiple RTSes, I think. >> Single-target MIMO allows higher bandwidth between one client at a = time and the AP. Both the AP and the client must support MIMO for this = to work. There are physical constraints which limit the ability for = handheld devices to support MIMO. In general, this form of MIMO = improves throughput in the home, but is not very useful in congested = situations. High individual throughput is not what's needed in a = crowded arena; rather, reliable if slow individual throughput, = reasonable latency, and high aggregate throughput. >=20 > well, if the higher bandwidth to an individual user ended up reducing = the airtime that user takes up, it could help. but I suspect that the = devices that do this couldn't keep track of a few dozen endpoints. I think multi-target MIMO is more useful than single-target MIMO for the = congested case. It certainly helps that the client doesn't need to = explicitly support MIMO for it to work. > This needs to be tweakable. In low-congestion, high throughput = situations, you want to do a lot of aggregation, in high-congestion = situations, you want to limit this. Yes, that makes sense. The higher the latency, beyond some threshold, = the more likely that spurious retransmits (TCP or UDP) will occur, = making the congestion worse and crippling goodput. So latency trumps = throughput in the congested case. However, I think there is a sliding scale on this. With the modern = modulation schemes (and especially with wide channels), the handshake = and preamble really are a lot of overhead. If you have the chance to = triple your throughput for a 20% increase in channel occupation, you = need a *really* good reason not to take it. >> There should be enough buffering to allow effective aggregation, but = as little as possible on top of that. I don't know how much aggregation = can be done, but I assume that there is a limit, and that it's not = especially high in terms of full-length packets. After all, tying up = the channel for long periods of time is unfair to other clients - a = typical latency/throughput tradeoff. >=20 > Aggregation is not necessarily worth pursuing. >=20 >> Equally clearly, in a heavily congested scenario the AP benefits from = having a lot of buffer divided among a large number of clients, but each = client should have only a small buffer. >=20 > the key thing is how long the data sits in the buffer. If it sits too = long, it doesn't matter that it's the only packet for this client, it = still is too much buffering. Even if it's a Fair Queue, so *every* client has only a single packet = waiting? >> Modern wifi variants use packet aggregation to improve efficiency. = This only works when there are multiple packets to send at a time from = one place to a specific other place - which is more likely when the link = is congested. In the event of a retry, it makes sense to aggregate = newly buffered packets with the original ones, to reduce the number of = negotiation and retry cycles. >=20 > up to a point. It could easily be that the right thing to do is NOT to = aggregate the new packets because it will make it far more likely that = they will all fail (ac mitigates this in theory, but until there is = really driver support, the practice is questionable) =46rom what I read, I got the impression that 'ac' *forbids* the use of = the fragile aggregation schemes. Are the drivers really so awful that = they are noncompliant? and from Steinar... >> Yep... I remember a neat paper from colleagues at Trento University = that piggybacked TCP's ACKs on link layer ACKs, thereby avoiding the = collisions between TCP's ACKs and other data packets - really nice. Not = sure if it wasn't just simulations, though. >=20 > that's a neat hack, but I don't see it working, except when one end of = the wireless link is also the endpoint of the TCP connection (and then = only for acks from that device) >=20 > so in a typical wifi environment, it would be one less transmission = from the laptop, no change to the AP. >=20 > But even with that, doesn't TCP try to piggyback the ack on the next = packet of data anyway? so unless it's a purely one-way dataflow, this = still wouldn't help. Once established, a HTTP session looks exactly like that. I also see no = reason in theory why a TCP ack couldn't be piggybacked on the *next* = available link ack, which would relax the latency requirements = considerably. If that were implemented and deployed successfully, it would mean that = the majority of RTS/CTS handshakes initiated by clients would be to send = DNS queries, TCP handshakes and HTTP request headers, all of which are = actually important. It would, I think, typically reduce contention by a = large margin. - Jonathan Morton