From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3FA2B21F343 for ; Mon, 2 Feb 2015 10:30:00 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t12ITlpq023485; Mon, 2 Feb 2015 10:29:47 -0800 Date: Mon, 2 Feb 2015 10:29:47 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: dpreed@reed.com In-Reply-To: <1422894150.85227837@apps.rackspace.com> Message-ID: References: <1422537297.21689.15.camel@edumazet-glaptop2.roam.corp.google.com> <54CB5D08.2070906@broadcom.com> <1422623975.21689.77.camel@edumazet-glaptop2.roam.corp.google.com> <54CB8B69.1070807@broadcom.com> <1422741065.199624134@apps.rackspace.com> <1422801814.796219699@apps.rackspace.com> <1422894150.85227837@apps.rackspace.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII Cc: dstanley@arubanetworks.com, Andrew McGregor , Stig Thormodsrud , Jesper Dangaard Brouer , Derrick Pallas , Matt Mathis , "cerowrt-devel@lists.bufferbloat.net" , Jonathan Morton , Mahesh Paolini-Subramanya , Kathy Giori , Tim Shepard , Avery Pennarun Subject: Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing` X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:30:30 -0000 On Mon, 2 Feb 2015, dpreed@reed.com wrote: > On Sunday, February 1, 2015 11:21pm, "Avery Pennarun" said: > > >> On Sun, Feb 1, 2015 at 9:43 AM, wrote: >> > Just to clarify, managing queueing in a single access point WiFi network is >> > only a small part of the problem of fixing the rapidly degrading performance >> > of WiFi based systems. >> >> Can you explain what you mean by "rapidly degrading?" The performance >> in odd situations is certainly not inspirational, but I haven't >> noticed it getting worse over time. > > > I was being specific about the words "WiFi-based systems", and not WiFi > itself. An obvious example is GoGo, whose degradation is probably not > specifically in the WiFi portion, but in the bidirectional bufferbloat I can > measure whenever I fly (frequently!). But I also visit many enterprise sites > for my day job, and hotels. I do a few measurements when I can - almost > always encountering bufferbloat (severe) on the path to the public Internet > (whether wireless or not), but worse, encountering severe bad behavior on the > WiFi hop, remedied by using a wired connection. And then there are hotels, and > trains. > > What's worse is that typical "sales office" connections in my past employers > are often quite poor. Too many people deploy a couple apple Airports and think the problem is solved (my current employer did the same thing). Part of the problem is that people then think that this is the best that can be done with consumer equipment, and that the only think they can do after that is to go spend $50K+ to buy an "Enterprise" solution, that is then so complex to deploy that they may sit for 9+ months between when they arrive and when they are deployed (two employers of mine have fallen into this trap). The idea that you can actually get good service without spending a ton of money just isn't something that is out there. All the 'networking vendors' out there push the proprietary "Enterprise" solutions. At SCaLE, we had one of these vendors come in one year and deploy their $10K/AP "Enterprise" solutions, and it failed miserably (and they didn't have any info or explination as to why). Some of the best conference wifi I have seen (and here I will exclude the ones I've setup to be fair :-) have been setup with consumer grade equipment. I drool over the capabilities of some of the commercial equipment, but the expertise in setting it up is far more important than the equipment used. > Now the causes of degradation are apparently multifaceted. Places that seem > to be fine fall off a cliff, because they used to be overprovisioned relative > to traffic load, but now are not. Of course capacity sharing should slow > everyone, but the cliff adds insult to injury. The cliff is a real problem. It's not obvious to people how the various features of WiFi interact to create the cliff, and it's not something that is easy to duplicate for lab/performance/installation testing. > I have observed that deploying a lot of wifi stations that operate in basic > 802.11b mode really does affect the folks with better gear in the same channel > a lot. A small packet occupies a disproportionate amount of channel time if > transmitted at 1 Mb/sec - and my theory (this is hard to measure informally, > so I could be wrong) is that "cheap" devices compete equally for packet time, > but consume much more than their share. My sense is that channel time should > be allocated fairly by the most basic MAC access decision - LBT and backoff, > not opportunities to transmit. This would eliminate the pokey puppy problem. > There are pragmatic ways to achieve this without changing the basic MAC access > decision, which is the firmest-of-ware. It's even worse than you think, those long (time) packets sent at the slow rates are far more likely to have other things interefere with them (something that can't hear the transmission, but who's transmission will prevent the receiver from hearing it) and so they are going to get retransmitted more frequently than faster bitrate packets. > Anyway, degradation of WiFi services at a particular location over time is the > norm I observe. well, to be fair, any service that's not updated as usage grows degrades over time (including things in meatspace like bus service or freeway lanes). Some of the worst hotel network service I have seen is at higher-end hotels that implemented network service early and outsourced the job. Some of them are now updating/replacing that service and getting much better. But between updates, the service is always going to degrade under increased use. David Lang