Leave, Leave, Leave My Rates Alone

Sometimes you have to return to the classics.  Who better than less-than-memorable pre-gangsta rapper Hi-C to take us there?

Much like the cool kids have embraced the neon colors and late-night TV comedy of the grunge decade, so too has this blog decided to embrace its past, only with a twist.  Five short years ago I  wrote a plea asking that Wi-Fi folks stop disabling high data rates on guest networks.  And they did!  (For the most part.)  Unfortunately, the pendulum has swung too far.  Now it's time to ask Wi-Fi folks to stop disabling low data rates; or, to paraphrase Hi-C: leave my rates alone.

Wi-Fi folks are always looking for ways to make wireless channels more efficient.  That is a good thing.  Wi-Fi's one limited resource is channel time, and so it is great to see more and more Wi-Fi people looking for ways to get the most amount of data across a channel in the least amount of time.

Disabling low data rates is a relatively recent trend that aims to improve Wi-Fi channel efficiency.  When low data rates are used, the same amount of data uses more channel time.  Data rates are calculated in data (usually bits; sometimes bytes) divided by time (seconds).  If the data-to-time ratio is lower (say, 13 megabits per second instead of 130 megabits per second), then the same 1,500 byte segment of data is taking ten times as much time to traverse a Wi-Fi channel.  That is inefficient and that is why it is a noble goal to eliminate low rate Wi-Fi traffic.

(All of this is ignoring physical layer overhead, which stays approximately the same no matter which data rate is used.  The physical layer overhead has to remain the same because devices don't know which rate to tune their radios to receive at until the physical layer header tells them.)

A theoretical secondary benefit to disabling low rate traffic is that it shrinks the area covered by the access point.  Since low data rates are needed for faraway devices to be able to "hear" the AP, if low rates are disabled then devices will have to roam to a new AP at shorter distances, at least according to this theory.  Since APs will be covering a smaller area, there will be less chance of APs becoming saturated with associated devices -- again, in theory.

When it comes to disabling low data rates, the theory and the reality don't match up.  AP coverage areas don't shrink (at least, not as much as they'd need to shrink in order to make the Wi-Fi better) and the channel does not get more efficient.

Disabling low rates fails to shrink AP coverage areas because devices don't associate based on data availability.  They associate based on received signal strength (RSSI).  Even if a device moves to a far flung location where receiving high rate data from the AP is impossible, the device will often stay connected.  This happens because all the device needs is one little Beacon frame to stay associated to the AP, assuming the RSSI stays above the device's roaming threshold.  Even if APs transmit Beacons at a high rate like 24 Mbps, single Beacons can be heard from far, far away.  That can cause devices to stay connected to far, far away APs, even if the device is unable to consistently send and receive data.

Disabling low rates causes the channel to become inefficient because devices will stay connected to APs at greater-than-expected distances.  When low rates are disabled, the AP has to try over and over again to send data to a faraway device, even if the device repeatedly fails to receive data successfully.  All of that failed data being transmitted by the AP wastes channel time, and makes overall Wi-Fi performance worse.

A recent lunch I had at Escuela Taqeria in Los Angeles illustrated the problem with disabling low rates.  While I was eating two delicious branzino tacos, I decided to connect to AT&T's public Wi-Fi network.  It was 3 p.m. on a weekday, so I was expecting good Wi-Fi because the restaurant was empty.  Instead, the Wi-Fi was inconsistent.  So I opened up AirMagnet because I had a suspicion that whoever configured the Wi-Fi got some bad advice and decided to disable low data rates.

First, I wanted to see if the problem was just general channel saturation.  I opened up AirMagnet, went to the Infrastructure screen and selected "Listed By SSID" instead of "AP List".

The AP only had two associated devices, just as I suspected.

Next, I wanted to see if low rates were, in fact, disabled.  In AirMagnet, once you click on an AP or device in the Infrastructure screen, the software automatically shows you only the information relevant to the clicked-upon AP or device.  So, I clicked on the "att-wifi" AP and then selected AP Detail in the lower right corner of the Infrastructure screen.  

(At this point I should point out that AirMagnet retails for $4,250 USD, but you can get the same information shown in the AP Detail area for a lot less money if you have a Mac.  AP Detail essentially shows information from AP Beacons.  WiFi Explorer also shows information from AP Beacons and it retails for $15 USD.)

As I suspected, all rates below 18 Mbps had been disabled.  That means somebody -- maybe from AT&T, maybe from Aruba Networks (Aruba showed up when I did an OUI search on the AP's MAC address) or maybe from a third-party installer -- is operating under the illusion that disabling low data rates improves Wi-Fi performance.

Also as suspected, the AP's inability to transmit data using rates below 18 Mbps was killing channel efficiency.

The AP was mostly using the 24 Mbps rate when transmitting data...

...but using that relatively high rate was causing 41.46% of the AP's transmissions to fail.

(Some context here for less experienced Wi-Fi folks: you're seeing that the AP has sent frames at rates below 18 Mbps.  Those are acknowledgments.  The 802.11 standard requires that acknowledgments be transmitted at a rate that is at or below the rate of the data that is being acknowledged.)

At this point I was nearly certain that the AT&T Wi-Fi network was seeing its performance suffer due to disabled low data rates, but not totally certain.  Sometimes heavy interference can cause a massive Retry percentage like 41%.

To confirm my theory about disabling low data rates, I had to know how efficient the Wi-Fi channel was when my device sent data.  Each Wi-Fi radio; whether an AP radio or a device radio, gets to choose which rates to use when transmitting data.

So, I clicked on my MacBook in the upper left area of AirMagnet's Infrastructure screen...

...and then I looked at the lower right corner of the Infrastructure screen to see which rates were being used by my MacBook and what the Retry percentage was:

Look at that!  My laptop was using the 12 Mbps rate to send data (those 24 Mbps frames were almost certainly acknowledgments sent in response to the AP's 24 Mbps data) and the result was a teeny-tiny  Retry percentage of 2.20%.  And it doesn't take a mathematician to figure out that a Wi-Fi channel occupied by 12 Mbps data with a 98% success rate is a lot more efficient than a channel that has 24 Mbps data and a 59% success rate.  

It's clear that AT&T/Aruba/someone should stop disabling low rates for their hotspot near Escuela Taqueria in Los Angeles, but does that mean that you should?  I say yes, but some other Wi-Fi people say no.  Chuck Lukaszewski (if you're from Wisconsin, then pronouncing that name should be easy), who is the top high-density Wi-Fi guy at Aruba Networks, said that he believes that high-density deployments work better when low rates are disabled because the efficiency gains from high-rate Beacons offset any efficiency losses from Retries.  I think that Chuck is wrong, but I still encourage people to use a protocol analyzer to check their own Wi-Fi networks.  

And if you're short on time and you just want to choose the best settings?  Then leave... leave... leave those rates alone.  You can set your SSID, do anything you choose...

***

If you like my blog, you can support it by shopping through my Amazon link.  You can also donate Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU or to my QR code:

Twitter: @Ben_SniffWiFi

ben at sniffwifi dot com