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)