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

[David Lang <david@lang.hm>]

On Mon, 2 Feb 2015, dpreed@reed.com wrote:

> 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.

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