In Windows Vista, a great deal of effort has gone into making it simple for network applications to take advantage of QoS capable networks. This post focuses on QoS for WiFi networks (both consumer and enterprise) and how the Vista network stack enables differentiated treatment of outgoing traffic. The WiFi Alliance has created a certification for Wireless Multimedia, or WMM, which identifies four access classes (WMM_AC from lowest to highest priority): background, best-effort, video, and voice. In abbreviated form, these classes are BG, BE, VI, and VO. If both the wireless station NIC and access point (AP) support WMM, it is possible to gain differentiated treatment for traffic sent. The good news is that many retail and enterprise APs support this feature, either out of the box, or in the most recent firmware available from the vendor. As for the wireless station adapter, the NIC driver must be WMM capable.

The WMM specification clearly states that traffic must be assigned to these four aforementioned WMM_AC (to receive differentiated treatment) based on either the MSDU 802.1Q UserPriority tag or the DSCP mark in the IP header of a packet. Importantly, from a Windows implementation perspective, the task of assigning outgoing traffic to the appropriate access class is carried out by the wireless NIC driver on the sending station. As such, this driver must be WMM capable. Like wireless APs, the good news is many 802.11g and 802.11a/b/g (and pre-n MIMO) wireless NICs support this feature, either out of the box, or in the most recent firmware available from the vendor.

Now that you have some background, the purpose of this post is to provide details on how (1) vendors writing Native WiFi (NWF) NIC drivers ascertain which access class to assign outgoing traffic to (create WMM capable drivers), and (2) how network sockets-based applications can gain differentiated treatment for traffic sent over the network.

1.    In Windows Vista, the net buffer list (NBL) available to NDIS-6 drivers exposes a new field, WMMInfo, in the NDIS_NET_BUFFER_LIST_8021Q_INFO structure. A NWF driver need only examine the WMMInfo field to ascertain the correct WMM_AC. When sockets-based applications call QoS APIs or an enterprise QoS policy is enabled (see section 2 below), a QoS flow is created and maintained by the network packet scheduler (Pacer.sys). If 802.1Q UserPriority and/or DSCP are applied to this flow, Pacer.sys will automatically populate WMMInfo correctly. This means that the NIC driver does not have to incur a per-packet performance hit (an improvement over WinXP) from manually parsing each packet to determine the proper WMM_AC.

 

2.    Windows Vista provides a simple set of APIs for adding QoS to sockets-based applications. These functions can be found in qos2.h. I’ll post a detailed description about Qos2 APIs shortly. Policy-Based QoS is also available, which enables IT administrators to specify Group Policies that indicate which applications/users/groups/etc should receive differentiated treatment from QoS capable routers and WiFi APs. Policy-based QoS can be used to easily enable and manage QoS on enterprise WiFi networks.

 

I am interested to hear any feedback or questions about the improved support for WMM in Windows Vista.

- Gabe Frost