Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing`

[dpreed@reed.com]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]


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

> On Sun, Feb 1, 2015 at 9:43 AM, <dpreed@reed.com> 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.
 
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.
 
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.
 
Anyway, degradation of WiFi services at a particular location over time is the norm I observe.
 

[-- Attachment #2: Type: text/html, Size: 3828 bytes --]