From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 DCCCB21F33E for ; Mon, 2 Feb 2015 08:22:35 -0800 (PST) Received: from smtp10.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E793028043C; Mon, 2 Feb 2015 11:22:32 -0500 (EST) Received: from app13.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E7D9628040E; Mon, 2 Feb 2015 11:22:30 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app13.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 02 Feb 2015 16:22:32 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app13.wa-webapps.iad3a (Postfix) with ESMTP id D07ED380045; Mon, 2 Feb 2015 11:22:30 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 2 Feb 2015 11:22:30 -0500 (EST) Date: Mon, 2 Feb 2015 11:22:30 -0500 (EST) From: dpreed@reed.com To: "Avery Pennarun" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150202112230000000_44458" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: 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> X-Auth-ID: dpreed@reed.com Message-ID: <1422894150.85227837@apps.rackspace.com> X-Mailer: webmail/11.3.11-RC Cc: dstanley@arubanetworks.com, Andrew McGregor , Stig Thormodsrud , Jesper Dangaard Brouer , "cerowrt-devel@lists.bufferbloat.net" , Matt Mathis , Derrick Pallas , Kathy Giori , Mahesh Paolini-Subramanya , Jonathan Morton , Tim Shepard 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 16:23:04 -0000 ------=_20150202112230000000_44458 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AOn Sunday, February 1, 2015 11:21pm, "Avery Pennarun" said:=0A =0A=0A> On Sun, Feb 1, 2015 at 9:43 AM, wrot= e:=0A> > Just to clarify, managing queueing in a single access point WiFi n= etwork is=0A> > only a small part of the problem of fixing the rapidly degr= ading performance=0A> > of WiFi based systems.=0A> =0A> Can you explain wha= t you mean by "rapidly degrading?" The performance=0A> in odd situations is= certainly not inspirational, but I haven't=0A> noticed it getting worse ov= er time.=0A=0A=0AI was being specific about the words "WiFi-based systems",= and not WiFi itself. An obvious example is GoGo, whose degradation is pro= bably not specifically in the WiFi portion, but in the bidirectional buffer= bloat I can measure whenever I fly (frequently!). But I also visit many en= terprise 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 pu= blic Internet (whether wireless or not), but worse, encountering severe bad= behavior on the WiFi hop, remedied by using a wired connection. And then t= here are hotels, and trains.=0A =0AWhat's worse is that typical "sales offi= ce" connections in my past employers are often quite poor.=0A =0ANow the ca= uses of degradation are apparently multifaceted. Places that seem to be f= ine fall off a cliff, because they used to be overprovisioned relative to t= raffic load, but now are not. Of course capacity sharing should slow every= one, but the cliff adds insult to injury.=0A =0AI have observed that deploy= ing a lot of wifi stations that operate in basic 802.11b mode really does a= ffect the folks with better gear in the same channel a lot. A small packe= t 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 wro= ng) is that "cheap" devices compete equally for packet time, but consume mu= ch more than their share. My sense is that channel time should be allocate= d fairly by the most basic MAC access decision - LBT and backoff, not oppor= tunities to transmit. This would eliminate the pokey puppy problem. There = are pragmatic ways to achieve this without changing the basic MAC access de= cision, which is the firmest-of-ware.=0A =0AAnyway, degradation of WiFi ser= vices at a particular location over time is the norm I observe.=0A ------=_20150202112230000000_44458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sunday, February 1, 2= 015 11:21pm, "Avery Pennarun" <apenwarr@google.com> said:

=0A

 

=0A
=0A

> On Sun, Feb 1, 2015 at 9:43 AM, <dpreed@reed.com> wrote:> > Just to clarify, managing queueing in a single access point Wi= Fi network is
> > only a small part of the problem of fixing the= rapidly degrading performance
> > of WiFi based systems.
&= gt;
> Can you explain what you mean by "rapidly degrading?" The pe= rformance
> in odd situations is certainly not inspirational, but I= haven't
> noticed it getting worse over time.

=0AI 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 bu= fferbloat I can measure whenever I fly (frequently!).  But I also visi= t many enterprise sites for my day job, and hotels.  I do a few measur= ements when I can - almost always encountering bufferbloat (severe) on the = path to the public Internet (whether wireless or not), but worse, encounter= ing severe bad behavior on the WiFi hop, remedied by using a wired connecti= on. And then there are hotels, and trains.

=0A

 =0A

What's worse is that typical "sales office" connecti= ons in my past employers are often quite poor.

=0A

&nbs= p;

=0A

Now the causes of degradation are apparently mul= tifaceted.   Places that seem to be fine fall off a cliff, because the= y used to be overprovisioned relative to traffic load, but now are not. &nb= sp;Of course capacity sharing should slow everyone, but the cliff adds insu= lt to injury.

=0A

 

=0A

I have= observed that deploying a lot of wifi stations that operate in basic 802.1= 1b mode really does affect the folks with better gear in the same channel a= lot.   A small packet occupies a disproportionate amount of channel t= ime if transmitted at 1 Mb/sec - and my theory (this is hard to measure inf= ormally, so I could be wrong) is that "cheap" devices compete equally for p= acket time, but consume much more than their share.  My sense is that = channel time should be allocated fairly by the most basic MAC access decisi= on - LBT and backoff, not opportunities to transmit.  This would elimi= nate the pokey puppy problem. There are pragmatic ways to achieve this with= out changing the basic MAC access decision, which is the firmest-of-ware.=0A

 

=0A

Anyway, degradation o= f WiFi services at a particular location over time is the norm I observe.=0A

 

=0A
 ------=_20150202112230000000_44458--