WiFi QoS Support in Windows Vista: WMM Part 4

Parts 1-3 of this series on WMM provided a bunch of details about how the Windows Vista network stack enables prioritization on WiFi networks, and how to figure out if the access point actually supports this capability. This post describes what behavior you can expect on a WMM capable wireless network. Before I start discussing scenarios, my test network setup looks like this:


  • WMM capable WLAN AP
  • Laptop-A connected via Ethernet to WLAN AP
  • Laptop-B connected via WiFi (802.11a) to WLAN AP

Best Effort (no priority)


If the WMM access category (WMM_AC) is best effort (BE), i.e. no prioritization, you can expect your applications to equally share available bandwidth. Based on my test network setup described above, I did the following experiment to confirm this:


  • (Red line) Laptop-A sending 30Mbps TCP to Laptop-B
  • (Yellow line) Laptop-B sending 30Mbps TCP to Laptop-A



The above graph is captured from Laptop-A who is sending traffic (red line) and also shortly thereafter, receiving traffic (yellow line) from Laptop-B. As you can see from this graph, I start sending traffic from Laptop-A (not competing with any other traffic) and then a few seconds later start sending from Laptop-B. When I start sending traffic from Laptop-B, both data streams share the available bandwidth as expected.




The notion of priority in a shared wireless network is based on statistically obtaining greater transmit opportunities (TXOP), arbitrated by the 802.11 media access control (MAC) layer. This means the MAC algorithm for obtaining TXOPs is more aggressive for video (VI) and voice (VO) access categories. Because it’s more aggressive, I would expect an application to achieve greater TCP throughput on VI and VO compared with no priority (BE). The graph below shows 30Mbps TCP traffic sent from Laptop-B to Laptop-A. This TCP traffic begins with no priority, and after time a DSCP value of 40 (VI) is applied. As you can see, greater throughput is achieved (the bump in the graph toward the top right). Actual throughput increase will vary by vendor implementation, but this implementation yielded about 3Mbps increase.



That was interesting, but what about VI traffic competing with BE?


  • (Red line) Laptop-A sending 30Mbps TCP to Laptop-B
  • (Yellow line) Laptop-B sending 30Mbps TCP to Laptop-A



To start, both Laptop-A and Laptop-B are sending with no priority (BE). As such, they equally share the available network bandwidth. I then apply DSCP value of 40 (VI) to traffic sent from Laptop-A. As expected, the higher priority video flow receives more TXOPs and is able to utilize more of the available bandwidth than the BE traffic from Laptop-B.




I think by now you get the idea. In short, BE traffic will get more TXOPs than BG, so the background traffic will be de-prioritized. If you were to look at a graph of BE vs. BG, it would look similar to the above graph of VI vs. BE. The best effort traffic would receive priority handling above background traffic. This scenario is useful for backup applications or background transfers (like bulk copies) that do not want to impact ongoing traffic like Internet downloads.




VO is somewhat unique in that it doesn’t gain significant throughput over VI; but rather is allowed to burst. This makes sense because voice doesn’t require large sustained throughput like video does.


Does anyone have any questions about WMM based on this series? If you want me to post about anything else on this topic, let me know.


– Gabe Frost (gfrost)

Comments (7)

  1. ShayEr says:

    Do I as a comm framework developer need to be aware of what type of transport (WiFi/LAN/WAN/etc) I have a in order apply QOS?

    Who need to be aware of that? Can I just tag my (outgoing) data in such way that I would never care about the underlying transport?

  2. wndpteam says:

    If you are using the Qos2 API on Windows Vista, then no, you *do not* have to worry about the underlying network medium. The Vista QoS subsystem will ensure the right thing is done based on your destination address and the capabilities of the network. Basically, DSCP (field in IP header) is always safe and 802.1Q (more generally r eferred to as 802.1p) is not always safe. 802.1Q has no place in WAN, only LAN (WiFi, Ethernet, etc.). For more details about DSCP and 802.1Q, check out some of the posts submitted by Mathias in the QoS subsection of this blog. What you do need to consider is whether your application scenario is adaptive (dynamically adjust to changing network conditions). If so, you can only make use of this particular Qos2 functionality in private (home) environments. Adaptive capability is not available for WAN in Vista.

    Let me know if you have any other questions.

    – Gabe

  3. ShayEr says:

    10x, Gabe.

    P.S. the networking blogs is one top 5 blogs that come out of MS (IMHO) keep on the good work!.

  4. anant says:


    I am  a little curious about the mechanism Vista uses to assign priorities to different data packet.For instance how can Vista differentiate between an audio ,a video and a text packet thats in the Q for transmission?

    Hi Anant,

    The network stack in Server 2k8 and Vista does not automatically classify network packets as voice, video, background, etc.; but rather, provides a set of APIs for application developers to mark packets they send with a layer-3 DSCP or layer-2 802.1p tag. Also, IT administrators can create policies in Group Policy that identify application traffic which the OS will automatically mark DSCP for them (applications don’t have to call QoS APIs). It is then up to the network equipment (routers/switches) to prioritize the traffic based on these markings. Let me know if that answers your question.

  5. Enrique says:


        I just discovered your post series on WMM, and they are great! I have just a doubt: Supposing the network equipments (AP, switches) do NOT support 802.1p tags, but we use them, will we see any difference in the performance between different applications in the same Vista host?

         I mean, for example, setting a policy that assigns BE to a P2P software, and VO to a VoIP software. Will we have priorization in the local TCP/IP stack, so P2P traffic doesn’t interfere with VoIP traffic, or interferes less?



    Answer is: depends on MaxOutstandingSends being defined.

    If HKLMSOFTWAREPoliciesMicrosoftWindowsPschedMaxOutstandingSends does not exist then DRR scheduling is applied after 65355 packets are pending in miniport and only applies that to the flow associated packets. In that case VO traffic would get preferential send opportunities compared to BE. However, 65535 is a huge threshold and since it only affects flow packets there is no significant differentiating effect.

    If the regkey is defined to some value (e.g. 5), then the differentiating effect is very significant. Not only is the value low enough to have an impact, but it applies to all outbound packets. Any packets that are not explicitly associated with a flow (e.g. via qwave/tc/gqos/http.sys-qos/eqos) get lowest classification. All explicitly associated flow packets will get preferential outbound treatment on the local NIC.

    — QoS Team

  6. Paolo says:

    I’m going to enable QoS WMM on the controller of my WiFi network. I also should do the same on client side which is running WinCE 5.0.

    Does Windows CE 5.0 support WiFi QoS WMM ?

    In case of, how can I do it?



  7. Charley Wen says:

    Hi Paolo,

    Thanks for your question. However, your question will need to be answered by the Windows Embedded team, which owns its own stack. Please check out its blog site: http://blogs.msdn.com/mikehall/archive/tags/Windows+CE/default.aspx