WiFi QoS Support in Windows Vista: WMM part 2

My previous post on WiFi QoS (WMM) discussed the four access classes (BG, BE, VI, and VO) available for traffic differentiation. I also highlighted that packets containing either a layer-2 802.1p tag or layer-3 DSCP mark (i.e. packets associated with a QoS flow) will be added to the correct WMM access class by a Native WiFi (NWF) driver that supports WMM based on the WMMInfo field in the NDIS_NET_BUFFER_LIST_8021Q_INFO structure. However, I did not mention which 802.1p or DSCP values correspond to the four WMM access classes and therefore cause WMMInfo to be populated by Pacer.sys correctly. Before I can answer this, I need to provide a little more, you guessed it, background.

As Mathias described in his post about 802.1p, there are eight values (0-7) representing traffic classes from background to network control. Mathias also highlighted in his post about DSCP that there are 64 possible values for this field in the IP header. You may be thinking, that things don't align here, and you're right. Because WMM only has four possible traffic classes, and it relies on 802.1p and DSCP to indicate what traffic class to use, there needs to be some major consolidation. The following table lists the four WMM traffic classes and which 802.1p and DSCP values correspond:

802.1p DSCP WMM_AC
1 16 BG
2 8 BG
0 0 BE
3 24 BE
4 32 VI
5 40 VI
6 48 VO
7 56 VO

The Qos2 API removes the need to choose the correct 802.1p and/or DSCP values and instead provides a simple enum for available traffic classes:

typedef enum _QOS_TRAFFIC_TYPE {

The four traffic types that correspond to WMM_ACs are shown in red. By way of example, if a Qos2 application specified QOSTrafficTypeAudioVideo for QOS_TRAFFIC_TYPE, outgoing packets for this QoS flow would be marked with a DSCP value of 40 and may have an 802.1p tag with value 5. If you're wondering why I used the word "may" for an 802.1p tag, read my post on the necessity for end-to-end QoS experiments.

Let me know what you think.

- Gabe Frost