The Windows WMM User Priority Issue - A Fix?

-
There is a known issue with Windows clients when it comes to marking applications for QoS over wireless. In short, even if a Windows client application is configured to use DSCP 46 (EF), for example to mark voice traffic, it will translate this over the air to to use a layer 2 UP value of 5, rather than 6. This means that it will end up in the Video WMM queue rather than the Voice queue that we’d like. This has an impact on traffic prioritization over the air and could have a negative impact on our high priority traffic. This has been an issue that people have just “lived with” for quite a while, but I suspect there is a solution to this issue. I’m “putting this out there” for feedback as I can’t find any information about others using this technique. I’d like feedback from my peers to understand if the approach is viable or anyone else has used/tried it

Background

Generally in my articles, I like to provide plenty of background information about a topic to encourage others to research and learn. But, in this instance, I’ll get straight to the point as there is too much ground to cover. If you’d like to know more about this topic, then please have a look at the following references:

The issue is shown on slide 47 of the presentation from Cisco Live referenced above:


As you can see, Microsoft translate the 3 most significant bits of the DCSP value in to a UP value of 5, which means that packets that are correctly marked with DCSP for EF end up in the WMM video queue, rather than the voice queue. The slide below (also borrowed from the same presentation) demonstrates the point (hopefully my friends at Cisco will excuse this liberty I'm taking with their content):



This means that both voice and video traffic (marked with DSCP 46 and 34 respectively) end up in the same WMM queue over the air from the client to an access point. Ideally, we want traffic marked with DSCP 46 to end up in the WMM voice queue and traffic marked with DSCP 34 to end up in the WMM video queue. But, this doesn’t happen by default when assigning QoS marking via the group policy editor

QoS Marking Tests


Application Marking With Group Policy Editor


The traditional method of marking applications with QoS is to use the Windows group policy editor. I 'll run through a basic example to show the process and result. However, note that the settings shown are definitely not what you would use in production. I’ll mark all Skype traffic from my laptop to send with DSCP value 46. In the real world, voice, video signalling etc. would be marked individually, so don't take this as a config to use in the real world.

I’ll then make a test voice call and capture a data frame that contains a Skype packet. I’ll also use an open SSID so that we can see both layer 2 & layer 3 decodes.

Here is the policy in the Group Policy Editor, showing the QoS policy:


Here is the resulting Skype packet showing the layer 2 priority 5 marking, together with the layer 3 DSCP marked (as expected) with EF. As mentioned previously, note that the layer 2 marking is using UP 5, so will be using the video WMM queue over the air, rather than the voice WMM queue we’d like to use:



Application Marking With Powershell


Ok, now to get to point of this blog article…

If we repeat the previous exercise, but this time set the QoS policy via Powershell, we can actually specify the layer 2 QoS marking that we actually want (i.e. set it to 6).

This is achieved by using the command “New-NetQosPolicy” in a Powershell console on your Windows laptop. Note that you need to run the command in a Powershell console opened as an administrator.


Note that we have now removed our original QoS Policy applied via the  Group Policy Editor (see screenshot above)

Here is the syntax required, together with a screenshot of the command being applied in Powershell:

New-NetQosPolicy -Name "Skype" -AppPathNameMatchCondition "Skype.exe" -DSCPAction 46 -PriorityValue8021Action 6



One point to note here is that when applying policy by this method, it is not shown in the policy configuration of the Group Policy Editor.The only way to check the applied QoS policy is to the use the “Get-NetQosPolicy” in a Powershell console on the Windows machine.

Now, if we look at the Skype packets from my laptop during a test call, we see that layer 3 is still marked with EF, as expected, but layer 2 is now marked with UP 6. This means that our traffic will use the correct WMM queue (i.e. the voice queue) over the air.



Using the correct WMM queue will ensure that our voice traffic can leverage the additional advantage in ECDA that this provides, which could be quite important on a busy wireless network carrying a mix of voice, video & data.

Questions


OK, this seems to be a reasonable approach to technically achieve the desired outcome for improved QoS marking over the air for Microsoft Windows clients. However, I don’t see anyone recommending this approach…

So, my questions are:

  • Is this a valid approach? 
  • Has anyone else used this approach? 
  • What are the pitfalls of this approach (if any)? 
  • Are there any flaws in my logic here? It seem strange that I don't find any information anywhere about this

Just a couple of caveats:

  • I’ve only tried this on my personal WIndows 10 machine that runs Win 10 Pro 
  • I’ve no idea if this approach would be scalable or supportable in a large Enterprise environment
  • I’m not a Windows or AD “Expert”

Please...let me know your thoughts (comments section at the bottom of this blog page, or track me down on Twitter - @wifinigel)

References


List of references from article & further reading:



Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more