Setting Data Rates - Just (Don't) Do It.

A common conundrum for enterprise WLAN administrators is guest access. You often want or need to provide it, but you want to make sure the guest WiFi has a minimal effect on the internal network. One way that people try to limit guest access is by specifying low speeds, but that is a bad idea that usually causes the internal WiFi to be worse off than it should be.

I was doing some work at a hotel in the Chicagoland area recently when I came upon another example of bad guest WiFi. Bad guest WiFi is quite common, but this one was avoidable. I've seen bad guest WiFi because of under-covered areas and because of over-covered areas. I've seen some guest WLANs with  over-saturation of stations and others with under-saturation of broadband.

As with any WiFi design, there is a little bit of art in the science. You have to look at numbers like signal-to-noise ratio and users-per-channel but in the spaces where desired numbers collide, the owner of the WLAN has to make good choices in allocating the resources that are available.

One of the obvious choices admins often make is to limit the bandwidth available to guest users. 'Tis a noble idea, but it must be done the right way. Appliances that limit the wired bandwidth of guest users do the job, at least to some degree. (I'll save my treatise on my distaste for bandwidth limits for another time.) Unfortunately, most WiFi controllers and APs lack true a bandwidth limiting function.

What controllers and APs often do have is the ability to limit data rates. You can dictate that users associated to the guest SSID are limited to either an exact data rate -- such as the 18 Mbps that I saw at the hotel near Chicago -- or a maximum data rate. In theory this may sound smart, but in reality it is a bad idea because you are limiting data rates, not throughput.

Data rates are the speed of one frame across one data link. If you are using WiFi, that means the speed of one frame from your AP to your laptop. The frames that are being sent are also part of a shared channel. That means that when the AP is sending a frame to your laptop, it can't be sending a frame to anyone else's laptop.

Throughput is a measurement of the total amount of data divided by the total amount of time it took to send or receive that data. It is the real, usable speed that your applications have available when you are on a WiFi network.

Your throughput is affected by your data rate, but it is also affected by the data rate of everyone else who is on the same channel. If you are receiving frames at 216 Mbps (as I was when I began writing this piece), that's great. Your laptop will be taking very little time to receive frames and the other stations on the channel will be very happy that your laptop takes up so little channel time. If someone else on my channel is forced to receive frames at 18 Mbps because they are on a guest SSID, my laptop's throughput will be compromised because I'll be staying quiet for more time than I need to while that guest user receives their slow frames.

Manipulating data rates can have other negative effects besides just slowing down the channel. For most WLAN controllers and APs, setting a specific rate limits the speed of frames transmitted by APs, but not transmitted by stations. Here's a look at a Beacon frame transmitted by my Linksys WRT160N 2.4 GHz 802.11n wireless router:

The rate information (Supported Rates and Extended Supported Rates) is identical to the rate information that was showing up in the Beacon frames at the hotel I was staying at outside of Chicago. Notice how there is no indication that only a 18 Mbps rate will be used by the AP. Stations are receiving Beacon frames that show all rates between 1 Mbps and 54 Mbps as supported. The end result of this is high Retry percentages because stations remain associated to the AP when they are transmitting all the way down to 1 Mbps (where frames can be demodulated at a great distance), but the AP keeps its rates at 18 Mbps (where frames can be demodulated only at a lesser distance) no matter what.

Hopefully I've made a convincing argument against specifying low rates for guest access, but there is one other rate-related topic that I want to touch on. It is the topic of disabling low rates in an attempt to enhance roaming quality.

I bring up this last topic because I was teaching a class a while back and one of the students told me that he was told that disabling 1, 2 and 5.5 Mbps was recommended to enhance roaming. The theory is that when a station reaches the lowest rate above the disabled rates (6 Mbps, in this case), the station will know to being the reassociation process, thus avoiding the problem of having stations associated to APs where the signal quality is so poor that only the lowest of the low rates are available.

I am torn on this subject. On one hand, I would assume that whoever told him to disable those low rates had tested the WLAN using the production clients and found that they roamed better with those rates disabled. I am believe that if you test something and it improves performance you should use it, so in that way I like it. On the other hand, this makes little sense to me. In my experience stations tend to begin the reassociation process based on having a low signal strength or signal-to-noise ratio (SNR), not necessarily a low data rate. If a station is receiving frames at a signal level that is above its roaming threshold, then the possibility exists that the station would remain associated to the AP but be unable to demodulate frames because the low rates that could be demodulated have been disabled. The end result of that would be high Retry percentages, and I have seen many WLANs with low rates disabled and high Retry percentages.

Now, I do want to make clear that if you are working with only 802.11g/n stations, then disabling *all* 802.11b data rates (1, 2, 5.5 and 11 Mbps) is advisable in many cases. What I am skeptical of is the idea of disabling *some* 802.11b data rates and leaving others enabled because some 802.11b stations are present on the network.

As always, I'm interested in other peoples' experience. If you have specified data rates or disabled low rates and found improved performance, please do share with us in the comments section. But my experience has been that doing those things is counter-productive, so my general recommendation is to just leave the data rates alone when configuring your WLAN.


  1. Great article Ben. I recently took one of your Wifi classes in November. I work at a hospital in Maine and we have a Cisco Unified Wireless Network. It has been suggested to us and we have implemented this to disable the low data rates like 1 and 2 Mbps. The reasoning for this was due to our Vocera deployment and there multicast data. It was my understanding that the multicast traffic was sent out the lowest allowed data rate, the lower data rates of 1 and 2 would not be good for that muliticast voice traffic. What are your thoughts on that? John B.
    (if you still have my email from that class in November shoot me off an email) Thanks

  2. Hi Ben, I am curious about something.
    Maybe you can help me.
    I am sniffing 802.11n APs using Wireshark on a MacBook.
    How can i see the wireless rates provided by the 802.11n APs, eg: 130 Mbps in the Wireshark capture ?

    As i could see in your capture, the supporte rates info is like you were capturing a 802.11g AP because the highest supported rate was 54 Mbps.

    Am i right ?

    Can you help me please.


  3. Hi Ben,
    If a wifi network has 2 SSID's one for corporate and one for guest access. Both SSID's are on the same AP on 2.4GHz band and on channel 6 broadcasting. If the guest SSID is connected to its own ISP on the backend does this problem you explained in your blog still exist? Will it affect the user that is connected to the corporation SSID through the same AP. I would assume it does because it does not change the fact that its the same AP.

    Thank You,


Post a Comment

Popular posts from this blog

Spectrum Deception

What's New (and Missing) in the WiFi for iPhone 6

Free Sniffing in Windows! (Kind Of)