What was Microsoft smoking when building their QoS stack?

QoS is somewhat of a confusing area. The most common method of marking packets at Layer 3 (IP) is with a DSCP tag. This method replaces the earlier Type Of Service (TOS) tag, and uses the same space in the IP header.

Whilst DSCP has a far greater range of values than TOS, there are some that are commonly used in most implementations. DSCP values also overlap with TOS values.  There is a table showing the relationship between DSCP and TOS here. This is all likely to lead to confusion in implementation.  

Whenever talking about this stuff, there is one very common area of confusion. Numbers. That is, whenever a number is given, is it in Decimal, Hex, or a “type” number. It can also be given as a full byte (non-offset) value – -effecting it further. The DSCP table linked above helps show the different ways a single value can be represented.

eg. 34 = 0x22 = AF41

Be VERY sure you know what they are using in any document you read. The vendors switch between the values in their own documents with remarable dexterity and no explanation.

So – back to Microsoft’s weirdness.

VOIP traffic is generally tagged as “EF” (Express Forward), one of the highest priority values. Microsoft chooses however to use DSCP marking of “CS5”. That would make sense if they where tagging using TOS, as that matches the common practice for TOS values. BUT, their own documents state they are using DiffServ which is based on DSCP markings. DSCP recommends EF for voice, not CS5.

In short, it looks like they have mixed up the older TOS standard with the newer Diffserv standard, and gotten confused along the way. This causes problems with the mappings not classifying correctly if you are using vendor managed L2 prioritisation such as Telstra’s IPWAN DCOS services on their MPLS networks.

This behaviour is consistent across:

LCS 2005
OCS 2008 R2
Server 2003
XP
Vista
W7

The only take away I can get is that Microsoft does not recommend the use of QoS in general, and offers that OCS using RTAudio codecs does not require or recommend the use of QoS due to the protocols in use. I have found however that on services that suffer from congestion, it helps improve the quality of the service.

LCS / XP – Defaults
Video – DSCP 0x18 – 011000 (24) – CS3
Voice – DSCP 0x28 – 101000 (40) – CS5

XP – “Conforming Packets”

Reference

DSCP and Live Mtg
http://nwsmith.blogspot.com/2009/08/dscp-qos-microsoft-office-live-meeting.html

MS QOE Doc
http://www.microsoft.com/downloads/en/details.aspx?familyid=05625af1-3444-4e67-9557-3fd5af9ae8d1&displaylang=en