wifi for 600, alex

Thu Feb 15 19:19:38 UTC 2007

On Feb 15, 2007, at 10:57 AM, Anton Kapela wrote:
> Speaking from experiences at Nanog and abroad, this has proven  
> difficult
> (more like impossible) to achieve to the degree of success engineers
> would expect. In an ideal world, client hardware makers would all
> implement sane, rational, and scalable 'scanning' processes in their
> products. However, we find this to be one market where the hardware is
> far from ideal and there's little market pressure to change or improve
> it. On many occasions I've detected client hardware which simply picks
> the first 'good' response from an AP on a particular SSID to associate
> with, and doesn't consider anything it detects afterward! If the first
> "Good" response came from an AP on channel 4, it went there!

That is exactly how nearly all devices today function; the exceptions  
are small.  There's a bit more needed to truly establish what is a  
good association and what isn't, from performance characteristics to  
functionality.

There are things underway that can mitigate some of this, neighbor  
lists for example.

> Also incredibly annoying and troubling are cards that implement 'near
> continuous' scanning once or say twice per second or cards that are
> programmed to do so whenever 'signal quality' falls below a static
> threshold. A mobile station would likely see very clean hand-over
> between AP's and I'm sure the resulting user experience would be  
> great.

There's actually a lot more to clean hand-overs between AP.  For  
starters, you need to know what's around, find them(!) (i.e.,  
channel), and reestablish any security associations and take care of  
IP mobility (at least at scale).

> However, this behavior is horrible when there are 200 stations all
> within radio distance of each other...  you've just created a storm of
> ~400 frames/sec across _all_ channels, 1 on up! Remember, the scan
> sequence is fast - dwell time on each channel listing for a
> probe_response is on the other of a few milliseconds. If a card  
> emits 22
> frames per second across 11 channels, that 2 frames/sec per channel
> becomes a deafening roar of worthless frames. It's obvious that the CA
> part of CSMA/CA doesn't scale to 200 stations when we consider these
> sorts of issues.

High density and the relatively high rate of AP can cause the same  
from beacons, for example.  There's a tradeoff between mobility and  
density of beacons, too: you need to hear a sufficient number of them  
to make decisions in the current model.

> In my selfish, ideal world, a "wifi" network would behave more like a
> CDMA system does. Unfortunately, wifi devices were not designed with
> these goals in mind. If they had, the hardware would be horribly
> expensive, no critical mass of users would have adopted the  
> technology,
> and it wouldn't be ubiquitous or cheap today. The good news is that
> because it's gotten ubiquitous and popular, companies have added-in  
> some
> of the missing niceties to aid in scaling the deployments.

Hmm. I think it would be good to frame which parts of a "CDMA  
system" (whatever that actually refers to ;-) you mean by that

> We now see 'controller based' systems from cisco and Meru which have
> implemented some of the core principals at work in larger mobile
> networks.

And which have similar scaling challenges with small cell sizes and  
mobility.  In fact, you could argue the model is particularly  
challenged in that case.

> One of the important features gained with this centralized
> controller concept is coordinated, directed association from AP to AP.
> The controller can know the short-scale and long-scale loading of each
> AP, the success/failure of delivering frames to each associated  
> client,
> and a wealth of other useful tidbits. Armed with these clues, a
> centralized device would prove useful by directing specifically active
> stations to lesser loaded (but still RF-ideal) APs.

So goes the theory at small scale, yes.  And I would contend that "RF- 
ideal" is something you will only find inside of an RF tent.

>> 3. Keep an eye on the conference network stats, netflow etc
>> so that "bandwidth hogs" get routed elsewhere, isolate
>> infected laptops (happens all the time, to people who
>> routinely login to production routers with 'enable' -
>> telneting to them sometimes ..), block p2p ports anyway (yea,
>> at netops meetings too, you'll be surprised at how many
>> people seem to think free fat pipes are a great way to update
>> their collection of pr0n videos),
>
> I would add that DSCP & CoS maps on the AP's can be used to great  
> effect
> here.

I don't I agree.  Having QoS mechanisms in a cooperative, unlicensed  
frequency has its limitations, rather than anything amounting to  
scheduled access.  And scheduled access in WiFi is of limited  
availability in chipsets today, not to mention incompatible with non- 
scheduled access.

Best regards,
Christian