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