North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: wifi for 600, alex

  • From: Christian Kuhtz
  • Date: Thu Feb 15 14:26:44 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