From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On
Behalf Of Suresh Ramasubramanian
Sent: Wednesday, February 14, 2007 6:25 PM
To: Marshall Eubanks
Cc: Carl Karsten; NANOG
Subject: Re: wifi for 600, alex
[snip]
2. Plan the network, number of APs based on session capacity,
signal coverage etc so that you dont have several dozen
people associating to the same AP, at the same time, when
they could easily find other APs ... I guess a laptop will
latch onto the AP that has the strongest signal first.
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!
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.
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.
I can think back to Nanogs years ago where folks tended to have junky
prism II radios which did this (type of scanning). Nanog 29 in
particular was quite rife with junky prism II user hardware. A lot of
the laptops were "sager" or something silvery-plastic-generic from far
overseas.
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.
We now see 'controller based' systems from cisco and Meru which have
implemented some of the core principals at work in larger mobile
networks. 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.
True, the CCX (cisco client extensions) support on some devices can
permit stuff like this to be shared with the clients (i.e. CCX exposes
AP loading data in the beacon frames, and can tell the client how to
limit it's TX power) in the hopes that this can be used in the 'hybrid'
AP selection logic of the station card. What stinks for us is that very
few (generally fewer than 10% at Nanog) of the clients *support* CCX.
What's even more maddening is that about 35 to 40% of the MAC addresses
associated at the last Nanog could support CCX, but it's simply not
enabled for the ssid profile! Here we have one potential solution to
some of the troubles in scaling wireless networks that depends entirely
on the user doing the right thing. Failure, all around.
This gets back to the point of #2 here, in that only "some" of the
better-logic'd client hardware will play by the rules (or even do the
right thing). In a lot of theses cases it's better to expertly control
where a client _can_ associate with a centralized authority (i.e.
controller with data from all active APs). We simply cannot depend on
the user doing the right thing, especially when the 'right thing' is
buried and obscured by software and/or hardware vendors.
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. What I've done at Nanog meetings is to watch what's going on
(recently with some application-aware netflow tracking) and continually
morph and adapt the policy map/class map on the router to set specific
DSCP bits on "p2p" or "hoggish users" traffic. These packets from the
"hog" can then be mapped in the AP (by virtue of their specific DSCP
coloring) to a CoS queue which has lower delivery priority than other
non-hoggish traffic. This way, the p2p/hog/etc bits act as a 'null fill'
and use the available space on the air, but they cannot overtake or
crowd out the queued data from higher priority applications.
You'd have to ask other Nanog meeting attendees, but I think it's fairly
safe to say that the way we treat certain SSH, dns, and tcp-initial
packets over the wireless network has yielded happy, content, and
less-lagged-n-frustrated users.
> > How was the wifi at the resent Nanog meeting?
I liked it! (heh)
> > I have heard of some success stories 2nd hand. one
'trick' was to
> > have "separate networks" which I think meant unique SSID's. but
> > like I said, 2nd hand info, so about all I can say is supposedly
> > 'something' was done.
The quick & dirty formula for Nanog wireless is as follows:
A) ssid for b/g (typically "Nanog" or "nanog-arin")
B) ssid for a-only (typically "nanoga" or "Nanog-a")
C) 1/4/8/11 channel plan for the 11b/g side, and tight groupings of
5.1/5.2 GHz and 5.7 GHz 11a. Many 11a client cards do not cleanly
scan/roam from 5.3 -> 5.7 or from 5.7 -> 5.3, so this apparent 'panacea
of 8 channels' really isn't. for each 'dwelling area' where users are
expected to sit, try to stick with 5.3 channels + reuse or 5.7 channels
+ reuse. If you have to, go ahead and mix them, but ensure that
'roaming' from this area to other areas features AP's along the way
which are in the same band, less 'hardest handoff' causes the card to
rescan both bands.
D) Ensure 1/4/8/11 channel re-use considers the "full" RF footprint. An
active, busy user at the 'edge' of an AP's coverage area might as well
be considered another AP on the same channel because the net effect is
to be another RF source which grows the footprint. Basically, the
effective "RF load" radius is twice as wide as the AP's own effective
coverage if the users transmitter power and receiver sensitivity is the
same (or nearly the same) as the AP's. This is perhaps the most subtle
and ignored part of wifi planning.
E) Help 'stupid' hardware do the right thing by ensuring an 'ideal'
channel is 'most attractive' to clients at every point in space where
capacity is the goal.
In areas where you are able to receive three AP's on channel 1, ensure
that you 'attract' the stupid hardware to a better AP that isn't
co-channel with others. A situation might be three AP's on channel 1
being heard at -72 dBm to -65 dBm by a client. You should place another
AP on channel 8 or 11 near by and ensure it's received level is
approximately 10 dB higher than the AP's on channel 1. This will tend to
attract even the dumbest of stupid hardware.
Why do you want to attract this client to another channel other than 1
so badly? Because if you are in a point in space that can receive three
AP's worth of beacons on the same channel, those three AP's can all hear
your transmissions. Every transmission your hardware makes means you've
consumed airtime on not one, not two, but three AP's at once.
An especially bad situation which you should strive to avoid is one in
which you are able to hear AP's on channel 1, 4, 8, and 11 with levels
of, say, -75 to -70 dBm. There is no clear winner here (a 5 dB
difference wouldn't be large enough in many drivers to base the decision
on it alone). In this case, ensure that co-channel AP's are heard at
least 20 db down from the strongest AP's so that users landing on
1/4/8/11 don't consume airtime from co-channel AP's and that the other
adjacent AP's transmissions fall below the threshold of 'clear channel'
assessment of the clients.
F) Use DSCP, CoS, and .11e EDCF support to allow the wireless devices to
treat different types of packets over the air appropriately. As
mentioned weeks ago by Todd and others (but apparently missed or ignored
by the thread) there's a PDF and a video up covering some of the results
of this concept.
Check it out at:
http://www.nanog.org/mtg-0610/presenter-pdfs/kapela.pdf
...and http://www.nanog.org/mtg-0610/real/delivered.ram
Perhaps this wasn't quick (little that's complicated is), but it's dirty
all the same! Try these ideas out at your next wireless event!
-Tk
you mean by that
Which brings me to the part about: