Friday, 4 January 2019

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


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.


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)


List of references from article & further reading: