Blogs

How losing voice QoS markings on the wired made my WiFi voice call stink downstream!

By gstefanick posted May 13, 2015 06:19 PM

  

Last week I had the privilege of speaking at Interop Las Vegas 2015. My topic was one that is very near and dear to my heart, Designing Today’s WiFi Network For Tomorrow’s Applications.

 

I shared my real world experience managing a large WiFi network in healthcare. Covering a range of topics from design to troubleshooting.  A shared a few slides on wireless QoS and the importance of wired side QoS for downstream over the air priority. A topic often misunderstood or simply overlooked. 

 

This blog post assumes you the reader have a basic understanding of wireless QoS. 

 

Real world example #1: QoS properly marked both upstream and downstream

 

In this example we have two wireless voice over IP phones on a call with each other. The frame on the left #3057 is headed upstream to the access point. The frame on the right #3059 is headed downstream from the access point to the wireless phone. 

 

qos1.png

 

If you’re wondering what happen to frame #3058, it was the ACK for frame #3057. 

 

How we know the frames are marked correctly is by looking at the QoS information field. We can see the value of 6 is marked on both frames. This is an indication that both frames were dropped into the voice bucket and by doing so received the smallest contention window. 

 

Real world example #2: QoS properly marked upstream but not properly marked downstream 

 

In this example we have a wireless voice over IP phone on a call with a wired voice over IP phone. The frame on the left #14985 is headed upstream from the wireless ip phone. The frame on the right #14987 is headed downstream over the access point. 

 

qos2.png

 

If you're wondering what happen to frame #14986, it was the ACK for frame #14985.

 

Looking at the QoS information field from both frames we can see the downstream frame is marked with a value of zero. While the upstream frame is marked with a value of 6. This is an indication the upstream frame received a shorter contention window while the downstream voice frame received a much higher contention window. 

 

This is a perfect example of QoS not properly configured on a wired network. The wired IP phone is marking packets with EF46, however since trust was not properly configured on the wired network these markings were lost as the packets crossed layer 2 and 3 boundaries.  When the packet arrived at the access point with zero markings it simply did what it was suppose to do and dropped the frame into the best effort queue. The downstream voice frame which is sensitive to network latency is now sitting in queue waiting to be triggered behind data frames with an IFS of AIFS 3 and cW of 15-1023. Not with voice priority of IFS of AIFS 2 and cW of voice 3-7 like it should have.

 

In this example we noticed snap, crackle, pop and the occasional missed word from time to time. After QoS was configured correctly on the wired network these issues went away. This is one the few times correcting QoS on the wired I could notice a difference immediately. 

 

The next time you hear we have big pipes we don't need wired QoS. The lack of wired QoS can impact your wireless QoS downstream ! 

4 comments
1 view

Comments

Jun 03, 2015 04:00 PM

Like Andrew suggests, I use DSCP 48 to get the correct mapping over the air from Windows to the AP.

May 19, 2015 07:54 PM

@Andrew,

Thanks for the link to your Lync blog.  From what I understood from your blog, the Microsoft Lync Voice over Wifi est still a work in progress, as the marking of DSCP into AC=Voice requires some extra Win7 config by the Admin in the QOS policy right? to force DSCP46 into AC=Voice.

At where I work, when doing Lync voice over wifi, I do not see the DSCP46 translated into AC=Voice for traffic from the laptop (intel6300) to the AP, more ever the traffic from the AP to the laptop, I won't tell you what AC it is mapped to, but not a good AC mapping.

What I found is the Lync certification for Voice is not as "intense" like the Spectralink phone certification, the Lync cert. does not go deep into the wifi, I have more "respect" for Spectralink phone cert. and the newer Wifi-Alliance Voice-Enterprise spec.

 

Chi-Thanh @zerodegrekelvin

 

 

May 19, 2015 10:48 AM

George,

Fantastic post! Many wired network engineers dismiss the need for QoS on a high-speed LAN because they perceive there is no congestion like there is on a WAN. Unfortunately, they fail to realize that Wi-Fi is shared access and airtime does get congested. Proper end to end QoS is essential.

 

As to zerodegrekelvin's question regarding Lync, I wrote an entire blog post on the quirks of Microsoft QoS and how it maps from layer 3 DSCP to layer 2 CoS / WMM, thus affecting Lync traffic. See here:

http://www.revolutionwifi.net/revolutionwifi/2011/09/microsoft-lync-qos.html

 

Cheers,

Andrew von Nagy

@revolutionwifi

May 19, 2015 12:00 AM

Hi George, did you trace Lync voice call over wireless? let say a voice call with usb-headset from a laptop via wifi.  I notice some VoIP over wifi app do not map proper IP Diffserv into wifi AC=voice in Windows.