Re: [Bloat] sigcomm wifi

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1650 bytes --]

On Thu, 21 Aug 2014, Steinar H. Gunderson wrote:

> On Wed, Aug 20, 2014 at 06:05:57PM -0400, Jim Gettys wrote:
>> The reason why 802.11 works ok at IETF and NANOG is that:
>>   o) they use Cisco enterprise AP's, which are not badly over buffered.  I
>> don't have data on which enterprise AP's are overbuffered.
>
> Note that there's a lot more to this kind of solution than “not badly
> overbuffered”. In particular, you have automated systems for channel
> assignment, for biasing people onto 5 GHz (which has 10x the number of
> nonoverlapping channels) and for forcing people to be load-balanced between
> the different APs. All of this helps in high-density.

is there actually anything for this in the 802.11 protocol? or is this just the 
controller noticing that this MAC address has shown up on 5GHz in the past so it 
opts to not respond to requests to associate with a 2.4GHz AP?

Social Enginnering works well for this without a need to technical tricks 
(Scale-slow on 2.4, Scale on 5)

> A lot of what's problematic in crowded areas is actually control traffic,
> not data traffic, especially since it is sent on the lowest basic rate.
> (So, well, one thing you do is to set 11Mbit or whatever as the lowest basic
> rate instead of 1Mbit...)

Yep, if the rate of control traffic could be set to be faster it would help a 
lot. When you transmit slower, it greatly magnifies the chances of something 
else coming up on the air and clobbering you so your lengthy broadcast is 
worthless.

But I thought that Dave Taht had been experimenting with this in cerowrt and 
found it didn't actually work well in the real world.

David Lang