Dropping legacy 802.11 support from your infrastructure, Part 1.

If you’ve upgraded to 802.11n (or even 11g for that matter) but are still supporting 802.11b and the original 802.11 for coverage reasons or because you just haven’t had a chance to turn it off, now might be a good time to give it the axe. Many people are forced to keep legacy 802.11 enabled because they have to support old legacy clients (in some sad cases, brand new legacy clients) or because their AP deployment is so thin that even an 11g 6mbps data rate somehow doesn’t provide coverage. If you’re in a position where you can stop supporting legacy data rates, it’s likely going to improve your overall wireless network.

If you’ve  deployed an 802.11n based network or an 802.11g based network, I’m sure you’ve heard countless times from reading articles or from consultants saying things like “legacy support for 11b is going to make it slower”  and “the protection mechanism is going to make you slow down to 11b speeds”.  The first statement is true, the second isn’t entirely true.  If your 802.11g client is connected at 54Mbit/sec and a legacy client associates, it’s not as if your client changes its data rate to a lower data rate and coding mechanism from OFDM to CCK.  The protection mechanism itself just adds enough overhead that you slow down considerably as if you were nearly at legacy speeds, but not quite.

The point is, it’s nice to have some actual data behind “slower” and see the actual impact, especially as everyone is moving toward 802.11n.  While the ideal scenario for 11n (I did not say most affordable) is to move to 5ghz, it’s not in the cards for everyone. You do get the ability to use 40-mhz wide channels, reduce noise from neighboring APs due to more rapid attenuation, a larger channel selection, and you get to avoid some of the more common interference sources like Microwave ovens, Bluetooth, cheap security cameras, etc.  If you are China, you won’t be able to use 40-mhz channels in 5ghz, as there are only currently 5 20mhz non-overlapping channels available and doing a channel plan with only 2 sets of bonded channels would cause considerable channel overlap and be more difficult to plan than 2.4ghz with 3 channels already is today.

A busy highway analogy is typically effective in explaining 802.11 issues to people who may not care to be experts in 802.11. While the analogy isn’t perfect when you get into the real details, it does get a basic point across.

If you consider 802.11 based wireless to be a single lane highway, with an off-ramp about every 50 feet, an on-ramp in-between every off-ramp and no legal passing zones, you’d be ready to envision legacy .11 and .11n trying to work together.  On this highway, try to picture that you have mopeds (legacy .11), sedans (.11g) and exotic sport cars (.11n) entering the highway and exiting the highway (packets in the air) at every ramp. If it was only the sports cars coming in at 300mph and exiting at 300mph, we’re only slowed down by the fact that there is some merging and a quick head nod from the drivers as they cut each other off. Even though you still have to share the lane, you are still moving pretty fast.  As soon as a moped gets on the highway going 11mph, the sports cars slow to a crawl, and since everyone follows the law, nobody passes the moped.  Getting to your off-ramp will now take a lot longer. Overall the average speed of the sports cars would still be higher than the mopeds due to faster time on the ramp (We’ll use that to cover all the technical bits we’re leaving out about protocol differences, headers, preambles, and the plethora of other differences in the protocols),  but it’s still a lot slower for all the sports cards and sedans.

When you have legacy 802.11 and 802.11b enabled on your network, even if you had -70 (good) coverage, you may still have clients that roam poorly and hang on to the lower data rates, even brand new clients that support 11n may hang on to the lower rates. Testing a single 11b client connected at 1mbps running iperf with an average throughput of 0.39Mbit/sec causes an 11n client connected at 144Mbit/sec to go from an average throughput of 86.2Mbit/sec to 19Mbit/sec when the legacy client uses CTS to Self, or 6.3Mbit/sec when the client uses RTS/CTS. That’s a loss of 95% of your average throughput on the 11n client. That might make you want to outlaw mopeds on the highway. (Ok, that’s already been done, but like I said, the analogy isn’t perfect)

You must consider where your clients connect from within your cell, what their roaming aggressiveness is, and what conditions may cause them to “hang” on older access points. The data rate the client selects is determined by signal quality. The 802.11 standard has a minimum sensitivity that devices must have, and many exceed it. If you have quality access points and quality clients that support lower receive sensitivities, your clients will be able to hold higher data rates are further distances. Here is an example to give you an idea.  In this picture the red dot is 11n client near the AP at about -60 RSSI, and the green dot being a client at the very edge of the cell using the lowest supported data rate, at about -88 RSSI. We’ll just assume we’ve found a magical land that has no noise present.

In part 2 of this blog post we go over the test results and throughput to backup the numbers that we mentioned here.