Why Are You Slowing Down My WiFi, Apple? To Make Things Better?
I defend Apple a lot. When Network World wrongly accused the original iPhone of flooding Duke University's network, I defended Apple. (It was later found to be a Cisco problem.) When a health care provider I was doing some work for blamed SIP-enabled iPhones for a VoIP problem, I eventually found out that the APs were to blame. (The APs were failing to respond to WiFi frames tagged as "Background" QoS.) Time and time again networking folks blame device makers like Apple, and time and time again the problem ends up being the network.
There are times, however, when it really is Apple's fault. When the network is operating just fine. This is one of those times. The problem is that I just don't know why.
802.11n (HT) and 802.11ac (VHT) networks operate in co-existence with first generation (802.11a/b/g, that is) WiFi a lot. When that happens, the HT or VHT access point operates in mixed mode.
There are all sorts of ramifications when a WiFi network operates in mixed mode, but one of the bigger ones (a ramification that usually results in a throughput loss between 25% and 40%) is the protection mechanism. When the the AP operates in mixed mode, it transmits data using the protection mechanism and it uses Beacon and Probe Response frames to tell WiFi devices to use the protection mechanism. An AP or device using the protection mechanism will precede its data frame transmissions with the transmission of a non-data carrying frame called a request to send (RTS) or a clear to send (CTS). The RTS and CTS frames are always sent at a data rate that the legacy devices can understand. For example, a WiFi network with a mix of 802.11a and 802.11ac devices would see 802.11a (24 Mbps, typically) RTS and/or CTS frames sent in advance of data that would be sent using VHT rates (up to 1,300 Mbps with today's gear).
An important note in all of this is that if there is no mixed mode, then there doesn't need to be any protection mechanism. If you've got a bunch of HT devices all associated to an HT AP, then there shouldn't be any RTS or CTS frames slowing down the data.
Rough & Tumble Films (a movie production company whose owners I'm friends with and who have a little country noir called "We Gotta Get Out Of This Place" airing on the Starz network later this year) has a WiFi network with an HT AP and all HT (or VHT) devices. (See the Probe Request frame below showing the "R&T" network indicating that all devices are HT-capable.)
The R&T WiFi network should see HT data frames going across the WiFi channel without any RTS and/or CTS frames slowing it down. That is not, however, what shows up in my WildPackets OmniPeek capture. (See that the highlighted data frames below are sent at HT rates of 243 Mbps and 300 Mbps, but they are surrounded by RTS and CTS frames sent at 24 Mbps.)
What gives, I wondered? Are the Probe Response frames coming from the AP giving me bad information? Are devices acting up? My initial capture was done on data going to and from my laptop (MacBook Air using dual-band, two-stream 802.11n), so I wanted to add my phone to the network to see if anything was different.
When I added my phone (iPhone 5 using dual-band, single-stream 802.11n), the same behavior occurred. More 24 Mbps RTS and CTS frames were surrounding my HT (this time 135 Mbps or 150 Mbps) data.
I noticed a trend when investigating all of this protection mechanism traffic on my friends' non-mixed mode WiFi. I noticed that the RTS frames were only being sent by my devices. The APs were never sending an RTS frame. Beyond that, I noticed that when the AP was the transmitter of a data frame, neither an RTS or a CTS preceded that data frame. In short, I noticed that the AP was not using the protection mechanism, which my laptop and phone were.
I know, then, that Apple devices (both iOS and OS X) slow down the channels they are using by acting like it's mixed mode even when it's not. What I don't know is, Why? Did Apple make a mistake? Is there some HT or VHT protocol that I am unaware of that causes devices to use the protection mechanism even when APs don't? Or is Apple doing this on purpose because someone at Apple thinks that their devices function better when the protection mechanism is always on?
After seeing Apple devices voluntarily engage in the protection mechanism, it made me think back to a question that I received while doing a Reddit AMA last year. A person asked about RTS/CTS being used to manage network traffic and getting devices to cooperate. The person from Reddit mentioned that he (sorry ladies, but when his Reddit handle is "ShadowHawk109" and he posts about beer, WiFi and William Shatner, it's got to be a guy) did work in academia, so I just assumed that he didn't know what he was talking about. Maybe he was on to something. Maybe Apple believes that their devices will have a more consistent data connection over WiFi if RTS/CTS frames are being used all the time, and so they've enabled it in their devices. Maybe Apple doesn't care that much if their devices cause the maximum available throughput to be lower on the channel.
Whatever the reason may be that Apple devices have been programmed to use RTS/CTS frames, WiFi professionals are going to have to deal with the impact. It could mean that our throughput tests mean even less and that our ability to support high density deployments has been expanded.
There are times, however, when it really is Apple's fault. When the network is operating just fine. This is one of those times. The problem is that I just don't know why.
802.11n (HT) and 802.11ac (VHT) networks operate in co-existence with first generation (802.11a/b/g, that is) WiFi a lot. When that happens, the HT or VHT access point operates in mixed mode.
There are all sorts of ramifications when a WiFi network operates in mixed mode, but one of the bigger ones (a ramification that usually results in a throughput loss between 25% and 40%) is the protection mechanism. When the the AP operates in mixed mode, it transmits data using the protection mechanism and it uses Beacon and Probe Response frames to tell WiFi devices to use the protection mechanism. An AP or device using the protection mechanism will precede its data frame transmissions with the transmission of a non-data carrying frame called a request to send (RTS) or a clear to send (CTS). The RTS and CTS frames are always sent at a data rate that the legacy devices can understand. For example, a WiFi network with a mix of 802.11a and 802.11ac devices would see 802.11a (24 Mbps, typically) RTS and/or CTS frames sent in advance of data that would be sent using VHT rates (up to 1,300 Mbps with today's gear).
An important note in all of this is that if there is no mixed mode, then there doesn't need to be any protection mechanism. If you've got a bunch of HT devices all associated to an HT AP, then there shouldn't be any RTS or CTS frames slowing down the data.
Rough & Tumble Films (a movie production company whose owners I'm friends with and who have a little country noir called "We Gotta Get Out Of This Place" airing on the Starz network later this year) has a WiFi network with an HT AP and all HT (or VHT) devices. (See the Probe Request frame below showing the "R&T" network indicating that all devices are HT-capable.)
The R&T WiFi network should see HT data frames going across the WiFi channel without any RTS and/or CTS frames slowing it down. That is not, however, what shows up in my WildPackets OmniPeek capture. (See that the highlighted data frames below are sent at HT rates of 243 Mbps and 300 Mbps, but they are surrounded by RTS and CTS frames sent at 24 Mbps.)
What gives, I wondered? Are the Probe Response frames coming from the AP giving me bad information? Are devices acting up? My initial capture was done on data going to and from my laptop (MacBook Air using dual-band, two-stream 802.11n), so I wanted to add my phone to the network to see if anything was different.
When I added my phone (iPhone 5 using dual-band, single-stream 802.11n), the same behavior occurred. More 24 Mbps RTS and CTS frames were surrounding my HT (this time 135 Mbps or 150 Mbps) data.
I noticed a trend when investigating all of this protection mechanism traffic on my friends' non-mixed mode WiFi. I noticed that the RTS frames were only being sent by my devices. The APs were never sending an RTS frame. Beyond that, I noticed that when the AP was the transmitter of a data frame, neither an RTS or a CTS preceded that data frame. In short, I noticed that the AP was not using the protection mechanism, which my laptop and phone were.
I know, then, that Apple devices (both iOS and OS X) slow down the channels they are using by acting like it's mixed mode even when it's not. What I don't know is, Why? Did Apple make a mistake? Is there some HT or VHT protocol that I am unaware of that causes devices to use the protection mechanism even when APs don't? Or is Apple doing this on purpose because someone at Apple thinks that their devices function better when the protection mechanism is always on?
After seeing Apple devices voluntarily engage in the protection mechanism, it made me think back to a question that I received while doing a Reddit AMA last year. A person asked about RTS/CTS being used to manage network traffic and getting devices to cooperate. The person from Reddit mentioned that he (sorry ladies, but when his Reddit handle is "ShadowHawk109" and he posts about beer, WiFi and William Shatner, it's got to be a guy) did work in academia, so I just assumed that he didn't know what he was talking about. Maybe he was on to something. Maybe Apple believes that their devices will have a more consistent data connection over WiFi if RTS/CTS frames are being used all the time, and so they've enabled it in their devices. Maybe Apple doesn't care that much if their devices cause the maximum available throughput to be lower on the channel.
Whatever the reason may be that Apple devices have been programmed to use RTS/CTS frames, WiFi professionals are going to have to deal with the impact. It could mean that our throughput tests mean even less and that our ability to support high density deployments has been expanded.
***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU
Ben,
ReplyDeleteNot necessarily that RTS/CTS always slows down the overall performance.
RTS/CTS are good for reliability; especially in 11ac environment.
Infact, with 11ac, RTS-CTS protection along with AMPDU over AMSDU performs better than without RTS for all the tests that I have been doing.
Its not bad at all to do RTS-CTS anymore;
The penalty are actually very less for the extra reliability.
RTS/CTS diminishes throughput capacity. As stated in the article, if the counterweight is an improvement in consistency, then that's good.
ReplyDeleteInteresting article Ben! I have been investigating lots of RTS/CTS on my WLAN for some time and was actually hoping to garner your opinion, but couldn't find a contact-me e-mail address. I think it might be the same thing, but I'm not familiar enough with packet traces to be sure. (yet!).
ReplyDeleteben at sniffwifi dot com
ReplyDeleteSome information about phone locators you could find here
ReplyDeleteThank you a lot for providing individuals with a very spectacular possibility to read critical reviews from this site.
ReplyDeleteData Science Training in Bangalore