I’ve been fiddling with QoS and OCS for the past few days and have some insights to share.
First important point is that OCS will support QoS via DSCP marking. But it is not enabled by default on any OCS servers or clients, but can be enabled. Microsoft has some pretty useful info on how to make that work. Straight from TechNet on the MS philosophy of QoS:
Although Office Communicator Server 2007 has been designed to work without any QoS framework, it is possible to configure the media stack to mark the IP traffic conveying the real time audio and video IP traffic according to well established classes of services.
The marking may be enabled or disabled by means of registry keys. If enabled, the marking of the IP packets is done by the QoS Packet Scheduler service. The resulting marked packets can subsequently be recognized by network entities (end systems and routers) to manage the media traffic according to the QoS priorities.
And the correct registry entry (a DWORD) is as follows:
That’s actually the "main" one to change. If you do that, your voice traffic gets marked with a DSCP value of 40 and video gets marked as 28.
QoS with Cisco Switches and Routers
In my experience, most QoS policies (especially Cisco) prefer to treat voice as Expedited Forwarding traffic – the highest level of DSCP QoS – a value of 46 . And for video, it normally should be marked as "assured forwarding -31" – a value of 26. )
Cisco networks that are already set up to prioritize IP telephony traffic will be looking for these markings, not the MS / OCS defaults. It’s possible to use other values (like the MS defaults) but I’m pretty sure that EF / AF is the way to go in most cases.
So to make that happen – you can use Group Policy – or just manually set the registry entries like this:
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsPschedDiffservByteMappingConformingServiceTypeControlledLoad = 26 (Decimal)
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsPschedDiffservByteMappingConformingServiceTypeGuaranteed = 46 (Decimal)
It’s probably a good idea to set the following as well:
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsPschedDiffservByteMappingNonConformingServiceTypeControlledLoad = 26 (Decimal)
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsPschedDiffservByteMappingNonConformingServiceTypeGuaranteed = 46 (Decimal
When you do this, you can run a network capture in wireshark and see that the voice packets are being marked properly:
As well as the video packets:
Case closed. Welllll… not totally: my 64-bit clients, for some reason, were not actually marking the packets properly.
64-bits and QoS with MOC
I’ve been running Vista for a long time (I appear to be one of tens of people who actually really love Vista & haven’t moved to W7 yet) and I’ve never been able to make the QoS policies work on it. All packets were showing up with 0×00 in the DSCP field. A co-worker and I finally had reached the end of our patience and decided to get to the bottom of the mystery. We both had the same problems, he on W7, me on Vista. Nothing worked… until it dawned on me: we were both running 64-bit OS. That seemed like a likely cause, but I wasn’t sure exactly why.
My co-worker, Aaron, suggested that we try making the above registry entries in the "HKEY_LOCAL_MACHINESOFTWAREWow6432Node". Brilliant! MOC is a 32-bit app, even on a 64-bit machine. So I created all the correct entries:
HKEY_LOCAL_MACHINESOFTWAREWoW6432NodePoliciesMicrosoftWindowsPschedDiffservByteMappingConformingServiceTypeControlledLoad = 26 (Decimal)
HKEY_LOCAL_MACHINESOFTWARE WoW6432NodePoliciesMicrosoftWindowsPschedDiffservByteMappingConformingServiceTypeGuaranteed = 46 (Decimal)
And then, just like that, Vista 64-bit was marking packets. I tested audio and video; to my delight QoS was working properly.
QoS on OCS Servers
Getting QoS deployed and configured on the OCS servers is a different matter – although it’s similar in concept to making it work on OCS clients. I’ll save that for a later date.