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

Comments

  1. Hi Ben, you were missing 16% of the Beacons sent by the AP already at your measuring position. Which points me to my thought that you should have had another AP close by that would have served your better. I think it is a combination of clients taking something more for roaming decisions than pure RSSI. What about Beacons missed? Retries? ... Just blind disable low data rates will lead you nowhere i totally agree, but if you have a real ESSID use case then the Data-Rate disabled should correlate to an SNR at the cell boundary. Just using full Tx power of an AP and then try to improve throughput or reduce airtime with screwing up the data-rates will lead you nowhere.

    ReplyDelete
    Replies
    1. Having a second AP may have helped, but not always. Devices roam based on RSSI but de-modulate successfully based on SNR. Whoever told you that missed Beacons or Retries affects roaming either hasn't studied device behavior or was lying.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. [edited for clarity and after a second look into those AirMagnet screens.]

    I have a few questions.

    1. If 18mbps was the lowest basic rate and there were 50%+ retries @24mbps - why did no one shift back to 18mbps?

    2. I understand how AP could send ACKs below supported rate, but how in the world could your Mac send frames at 12Mbps if AP did not support that rate? I don't know AirMagnet that well, but to me 100% of those frames would've been discarded by AP and contributed to that high retransmit number.

    3. When AirMagned says "No CTS/RTS" on the AP - is it for the current beacon frame? What about prolonged capture? Could that have been a hidden node type of issues?

    4. What about neighbouring APs?

    Overall, analyzing this issue via just a few AirMagnet screens doesn't seem possible. A tool like EyePA would've done a better job here, showing stats and frame distribution.

    In general, disabling low rates requires more APs and better channel planning, which wasn't done (but when done right, enables prpductive use of overlapping channels in HD/open space, provided you know what you're doing).


    Thus, with the data presented, it seems more like a typical "following best pracices w/o really understanding them" deployment, rather than an inherent deficiency of disabling the low rates approach.

    ReplyDelete
    Replies
    1. 1: This AP most likely had 24 Mbps as the lowest Basic rate and 18 Mbps as the lowest supported rate.

      2. Devices send data at whatever rate they want to send data at, regardless of what rates the AP says it supports.

      3. RTS/CTS in the "AP Info" area of AirMagnet is just a guess. There is no RTS/CTS field in the Beacon.

      4. No neighboring APs here.

      Eye P.A. is OK for getting a general overview, but I'm less into pie charts and I prefer a live capture.

      Disabling low rates is a bad idea whether the "channel planning" is excellent, good, fair or poor. The bottom line is that devices control roaming, modern devices roam based on RSSI, devices choose their own rates when transmitting and de-modulation requires high SNR, not RSSI. Those facts are inescapable.

      Delete
  4. Also, looking at that screen, how come your Mac's supposed ACKs @24 actually are more bytes than "data" @12?

    Thanks.

    ReplyDelete
    Replies
    1. Ok, I realized that you'r Mac's screen shows Tx _bytes_, but retry _frames_. Would love to see Tx Frames as well, as those 2% retried frames could have contributed to a lot more bytes.

      Sorry for making a mess of your comment feed. The absense of Edit button and small size od phone screen clearly don not help ;)

      Delete
    2. The application I was running on my Mac generated more downlink data than uplink data, hence the large amount of Acks being transmitted by my Mac. And I agree that it would be nice if AirMagnet showed statistics in Bytes (and Time, for that matter) in addition to Frames.

      Delete

Post a Comment

Popular posts from this blog

Five Facts About 6 GHz Wi-Fi

Chips, Glorious Wi-Fi 6E Chips!

Go To Sleep, Go To Sleep, Go To Sleep Little iPhone