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
