DSCP and CoS

Hello!
There is the question about QoS marking...
I use Tcmon to mark set the value of DSCP fiels as well as CoS field, but when i inspect the captured packets with Ethereal i do see that DSCP value is set and CoS is not!
What can be the problem?
Thanks
[313 byte] By [Sofi_Eva] at [2008-1-7]
# 1

Make note that the DSCP RFC supersedes TOS. CoS bits are only relevant in legacy TOS environments. DSCP is classless and does not provide any distinction or use for CoS. There are; however, certain code points referred to as "class selector codepoints" which preserve backward compatitiblity with legacy TOS presidence and class bits. For more information on using these particular code points, refer to RFC 2474 section 4.2.2.1. All this said, Windows has a focus on DSCP, not legacy TOS. The specific DSCP you are specifying with Traffic Control APIs is probably not conformant to the backward compatible class selector codepoint.

-- Gabe Frost [MSFT]

GabeFrost at 2007-10-2 > top of Msdn Tech,Windows Networking Development,Network Quality of Service (QoS/qWAVE)...
# 2

CoS is a level 2 (Ethernet) tagging, whereas DSCP and TOS are level 3 (IP) tagging. You're right about the fact that DSCP obsoletes TOS, but TOS has nothing to do with CoS. And as far as I know, CoS is not legacy at all.

Mr Frost, I think you're mistaking CoS with the legacy IP precedence, which RFC 791 defined as a 0 to 7 value, written in the 3 firt bits of the TOS octet of the IP header. Actually, CoS is also a 0 to 7 value, hence your mistake I think.

EtienneMiret at 2007-10-2 > top of Msdn Tech,Windows Networking Development,Network Quality of Service (QoS/qWAVE)...
# 3

I hadn't realized you were actually referring to IEEE 802.1p specification. This is also commonly referred to as 802.1Q UserPriority (very distinct from VlanId). The ability to detect the layer-2 tag in outgoing frames has been a hot topic on this forum recently, so a colleague and I are in the process of co-authoring a blog post and tool which can be used to validate these tags. Stay tuned, and check http://blogs.msdn.com/wndp for this post.

In short, the reason you cannot see the layer-2 tag via NetMon or WireShark is because of where the stack inserts the tag. The network sniffer tools are filter drivers within NDIS, which sit above the actual miniport driver which adds the tag. When a user-mode QoS API creates a flow that specifies an 802.1p tag should be added, the tag value is stored in an out-of-band structure passed down the stack. Unlike DSCP, which is written during IP header construction, the miniport driver is responsible for adding the 802.1p tag based on the value in the out-of-band structure. Because the tag is not yet written to the packet, network sniffer filter drivers do not see it.

Again, look for the blog post and filter driver sample for validating 802.1p tags soon.

Best,

Gabe Frost [MSFT]

GabeFrost at 2007-10-2 > top of Msdn Tech,Windows Networking Development,Network Quality of Service (QoS/qWAVE)...