sniffwifi

Just another WordPress.com site

Archive for the ‘RTS/CTS’ Category

A Voice Of Reason On Voice Over WiFi

leave a comment »

Voice over WiFi is scary.  Retries, packet errors (due to lots of Retries) and high latency (usually due to packet errors that happen because of lots of Retries) will murder a WiFi network’s ability to handle Voice and leave your users screaming (not actually screaming) like they were cast in a horror movie (or, at the very least annoyed like a character from Office Space).  But there’s one thing that sometimes scares people, but really shouldn’t: Voice Arbitration.  It’s not going to kill your WiFi voice calls.  In fact, it will almost certainly help.

Arbitration is a process defined in the 802.11 standard.  Every device (client/station and AP) goes through it.

The simplest way I can describe 802.11 Arbitration is like so:

If your AP or station has heard a quiet channel for 37 microseconds (0.000037 seconds), then your AP or station transmits a frame (what most people call a packet, but I call a frame).

If your AP or station has been hearing a busy channel for the past 37 microseconds, then it enters Arbitration. Arbitration is the process by which APs and stations go through a series of procedures in order to avoid devices sending at the same time (and, thus, causing a collision).

The big worry some people have is that Voice will mess up Arbitration.  That it will make it MORE likely that collisions will happen.  The Voice QoS category (as originally defined in the 802.11e amendment) reduces the amount of randomness in Arbitration.  For ordinary (called Best Effort in 802.11e), APs and stations choose a random value between 0 and 15 (on their first try; retries choose from exponentially larger random pools of values).  Voice applications (at least, applications that get tagged as voice by the AP or station) choose values between 0 and 3.  The problem comes when two devices (APs or stations or one of each) choose the same random value during Arbitration.  If that happens, then both devices try to transmit at the same time and most likely a collision occurs.  Two devices choosing the same number between 0 and 15 could happen, but maybe not all that often.  Two devices choosing the same number between 0 and 3 would be far more likely.

The flaw in this thinking is that devices have to be in Arbitration at the EXACT same moment for the 802.11e Voice category to become a problem.  Most likely, they won’t be.

Even though voice applications seem like they’re always running, they’re really not.  Each voice packet only uses about 300 microseconds* (assuming a 39 Mbps data rate — because smartphones don’t support MIMO — and the use of RTS/CTS) or 150 microseconds (if RTS/CTS is not used) of channel time.  And a modern voice application is going to have at most about 90 packets go over the wireless channel per second (combined send and receive).  That’s not a whole lot of channel time.  If we take the example of an iPhone on a typical WLAN — where RTS/CTS is used when the iPhone sends, but not used when the AP sends — that’s only 20,250 total microseconds being used.  20,250 microseconds is 20.25 ms.  Or 0.02025 seconds.  In other words, each phone is only using about 2% of the available channel time when a call is active.

If all of these numbers are too much, here is a visualization of how often a typical voice app is actually using the wireless channel:

The red and blue mean that the channel is occupied, while the empty boxes mean that the channel is unused**.

 Look at all of that open space.  And remember that open space is not the only way that collisions are avoided.  Collisions are avoided if:

-A phone becomes ready to send data while the channel is clear.
-A phone becomes ready to send data while another phone or AP is already sending data (assuming the devices can hear each others’ transmissions).

The only way a collision can occur due to an Arbitration match is if two or more devices begin attempting to send data at the exact same time.  For applications that use as little channel time as voice, that’s just not very likely to happen.

I have found the 802.11e Voice category to not cause problems in high density/congested environments.  In fact, I’ve found it to help.  When voice applications use the 802.11e/WMM Best Effort category instead of the Voice category, an extra 63 microseconds*** gets added to the packet transmission process.  That’s about a 20% jump in used channel time for devices that do use RTS/CTS and a whopping 40% jump for devices that don’t. That means more channel time per packet.  Using more channel time per packet is an actual problem, because it leads to the real reason that collisions tend to happen.  Collisions most often occur because one device is in the middle of sending and another device can’t hear it.  More channel time being used by each packet is most likely going to exacerbate the problem of collisions, not minimize it.

***

*All time calculations include 28 microseconds for a Voice AIFS, 18 microseconds for the Random Backoff (that’s two slot times), 10 microseconds per SIFS, 50 microseconds for non-HT physical layer headers (used by RTS, CTS and Block Ack frames) and 40 microseconds for HT physical layer headers (used by Data frames).

**That little graph has 10,000 boxes, meaning that each box could represent 100 microseconds.  The red dots are a visualization of how much channel time is being used when the iPhone sends (300 microsecs, including RTS/CTS) and the blue dots are a visualizations of the AP sending (since 150 microsecs would mean 1.5 boxes, I just represented half of the AP’s packets with two boxes and half with one box). 

***63 microseconds is calculated by adding an extra 9 microseconds to the AIFS (the Best Effort AIFS is 37 microseconds) and by adding six extra 9 microsecond slot times for the Random Backoff.

***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Advertisements

Written by sniffwifi

February 24, 2015 at 10:31 pm

Why Are You Slowing Down My WiFi, Apple? To Make Things Better?

with 4 comments

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.

***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

Written by sniffwifi

May 30, 2014 at 12:00 am