sniffwifi

Just another WordPress.com site

Archive for the ‘WMM’ 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

I Guess Apple Wireless Routers Don’t Like… Anything?

with one comment

I’ve seen a lot of inexplicable stuff in my day.  Landlords advertising Free WiFi and then telling you to use the neighbor’s.  Twitter praise from people whose employer I had just criticized in a blog post.  USC journeyman quarterback Mark Sanchez picked fifth in the entire NFL Draft.  But when I saw that my sturdy Apple Airport Extreme (single radio, dual band, two-stream 802.11n) wireless router was tagging all of my apps as Background traffic, I just couldn’t explain it.

For those who are unfamiliar with WiFi quality of service (QoS), a quick primer:

WiFi Multimedia (WMM) certified devices use QoS protocols from the 802.11e amendment.  Primarily, that means classifying APPLICATIONS (not networks, not devices) as either Voice, Video, Best Effort or Background.  What happens when a device classifies an application as Voice (highest priority)?  Whenever that device is ready to send a frame (sometimes called a packet) from that Voice application the device has to wait less time before sending.  What does less time get you?  It gets you a better chance of being the next frame to use whatever channel you are on.

The bottom line is that you want voice applications to be Voice.  If an app is Voice, there is a better chance it will work if your AP’s channel gets congested.

What you don’t want is for your voice applications to be Background.  Background is the lowest priority level.  Apps that are Background have to wait the longest possible amount of time before the device sends their frames.  That is bad.  It makes those apps vulnerable to shabbiness when your AP is on a congested channel.

So, what is my sturdy Apple Airport Extreme doing?  It is classifying EVERYTHING as Background.  TruPhone (my preferred voice app when traveling internationally), Facetime, the WWE Network and MLB At Bat were all sent using Background by my Airport Extreme.  My iPod Touch (rapidly becoming my favorite WiFi surveying device) wasn’t using Background for those apps.  It was using Best Effort.  In fact, it even used Video for some packets when I ran the Dish Anywhere app.  But look at this Wireshark capture from when I ran Facetime (sorry, I was too lazy to plug in my OmniWiFi and run WildPackets OmniPeek on my virtual machine):

That’s Background, Apple!  For a voice app!  THAT YOU MADE!  Whyyyyyyyyy?!?

Maybe it doesn’t matter that much.  Maybe it’s just my router.  (It is old enough to be single-radio, you know.)  Or maybe Apple has some cool new protocol going.  Maybe Apple’s WiFi team found out that if you have a clear channel, that the extra quiet time between frames for Background devices (seven slot times during the arbitration interframe space [AIFS] instead of three slot times for Best Effort or two for Voice & Video) results in fewer collisions.  Yes!  That’s it!  Apple figured out something none of us knew and is saving us from collisions without us even knowing it!  (Actually, no.  I switched to a crowded channel and the Airport Extreme kept on churning out Background frames for Facetime.)

The truth is I don’t know why my wireless router was classifying my voice and video apps as Background.  I know the Cisco AP in the office wasn’t.  See:

The thing that really bugs me is that I recommend the Apple Airport Extreme to people all the time.  As consumer-grade wireless routers go, I find it to be the best.  It doesn’t block wireless printing (a problem that a lot of Arris wireless modems seem to have), it doesn’t require random power cycles (a problem that every other wireless router ever seems to have) and it has good range.  I like it.
I have another Airport Extreme, a more modern one, that I’ll test when I’m back home in Los Angeles.  For now, I will just remain perplexed.  Why does Apple (at least for traffic coming from their wireless router) want my Facetime to have low priority?  I don’t get it.
***
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

Written by sniffwifi

July 31, 2014 at 11:50 pm

QoS the Packets of iPad (a poem)

leave a comment »

QoS the packets of iPadand all through the air 
not a station was Probing, not even a hair
When suddenly on to my Wireshark screen
Appeared Video, Voice and Background, it seemed
“But alas”, I exclaimed, as I looked at the MACs
This is only one tablet, not a bushel or stack
To the standard I looked, to decipher the meaning
And to you, dear reader, I offer this gleaning

The standard in question is dot11e

and the goal of its authors was to keep the air free
from clutter like YouTube and Facebook or Twitter
that might cause your voice conference to lag and/or jitter
But remember, dear sniffers, we’re still talking WiFi
A world where each access point, smartphone and MiFi
makes its own way to the channel or not
deciding on rates, QoS and the lot

So take heed if your WiFI must work for those apps
that users just love but treat admins like saps
a smartphone may say, “this packet is Voice”
but the AP may reply, “Best Effort; no choice”
And thus if your tool is a management GUI
You could end up wondering why WiFi is pooey
But a sniffer will show — be it angst or delight —
Whether your gear plays nice or girds for a fight

***

(iPhone: ‘This is a Video app.”)

 (AP: “You’ll get Best Effort and like it.”)

If you like my blog, you can support it by shopping through my Amazon link.  Same Amazon store and prices, but I get a kickback.  Thank you.

Written by sniffwifi

January 23, 2014 at 9:26 pm

Now It’s AirMagnet’s Turn to Show Us QoS

with one comment

In my last (real) post, I detailed how I used WildPackets OmniPeek to solve an iPhone 5 QoS problem.  But what about AirMagnet WiFi Analyzer?  I am a fan of both of those fine WiFi sniffers, so I figure it’s a good idea to show you how QoS can be analyzed with Fluke Networks’ signature WiFi protocol analyzer.

WildPackets OmniPeek is more of a hardcore protocol analyzer than AirMagnet WiFi Analyzer is.  If you’re going to be doing the type of sniffing I detailed in the last blog post, you will have an easier go of it with WildPackets’ product.  But AirMagnet is popular and both tools are expensive.  So if you happen to be a gal (or guy) who needs to troubleshoot WiFi voice or video and you have AirMagnet, this brief tutorial should help.

To begin analyzing QoS, one must first capture on the VoFi devices channel.  In my case I associated my iPhone 5 to a network with the SSID of “R&T”.  Then I looked at the Start screen in AirMagnet:

The “R&T” access point was on channel 44.

Once you know the channel that your VoFi device is on, then next step is to start capturing and viewing frames in the Decodes screen of AirMagnet.  It is at this point that I should note that the wise Keith Parsons once told me, “If you’re looking at the decodes in AirMagnet, then you’re in the wrong place.”  And that is true, usually.  But in the specific case of needing to find out which WMM QoS categories are being used by your VoIP app, then the Decodes screen is the right place to be.

I navigated to the Decodes screen in order to view captured frames.  I selected channel 44 as my capture channel and then I applied a capture filter for my iPhone, as shown here:

Once I had my filtered capture running, my step was to generate some voice traffic so that I could test QoS.  I used Truphone, which is a WiFi-based calling app.

After capturing VoFi frames, WMM QoS categories can be seen by opening a data frame and viewing the 802.11 header.  The 802.11 header has a field called “QoS Control”, and inside that field the TID (traffic identifier) will indicate which WMM access category is being used.  For Truphone, the category was Best Effort:

AirMagnet makes it a little bit more difficult to see the WWM QoS Category than other WiFi sniffers do.  For one thing in AirMagnet a capture must be stopped before frame decodes may be viewed.  For another the TID subfield is not summarized.  When the TID value is zero that means Best Effort, which is simple to remember.  The other categories are a bit more odd.  Voice is 5 or 6.  Video is 3 or 4.  Background is 1 or 2.  Seeing the raw bits of the TID field like in the AirMagnet capture above is fine for people who have memorized those numbers.  WildPackets OmniPeek and Wireshark decipher the number and tell you the category, which makes things easier for people who spend less time focusing on WiFi.  Like in this example below, it would’ve been nice if AirMagnet made it clearer that the frame I was looking at it Voice instead of forcing me to remember that 0110 in binary is 6:

In summation, the process for figuring out whether WiFi-based QoS will help your applications is rather straightforward.  Capture on the channel.  Run the app.  View the headers.  And if you do that it can really help you predict whether your VoFi apps will work well on a crowded channel.

Written by sniffwifi

November 21, 2013 at 12:39 am