How it works:
Troubleshooting it using packet sniffers: (e.g. Microsoft Network Monitor or Wireshark)
May not be supported in all cases, depending on factors
This page about testing it using a packet sniffer has the line “you’ll need an OS and NIC that support marking DSCP/ToS bits on the local and remote ends, use of a protocol analyzer, and the trusty ping command” which also suggests that not all NICs support DSCP, including virtual NICs.
Which OS / NICs are supported?
Policy based QOS is the ONLY way to configure this. Applications can no longer tag the packets themselves, Microsoft took that option away. From what I understand, the machine MUST be domain joined. The NIC must be able to see the domain (i.e. detected as “Domain” by NLA). I believe it should work by setting the local policy though. But if there is a conflicting domain policy, that will win.
Policies / Windows Settings / Policy-Based QOS / QoS Policies
Policy Name: RDP TCP 3389 DSCP Value: 20 Throttle Rate (Kbps): Not Specified Policy Conditions: Protocol: TCP Application: Any Source IP: 192.168.10.0/24 Destination IP: 192.168.12.0/24 Source Port: 3389 Destination Port: Any
Still true for Windows 7 / 8, and assuming 2012 too. See here:
QoS Policy settings under Windows 7/8 can be edited using the Group Policy Editor (gpedit.msc): Computer Configuration → Windows Settings → Policy-based QoS
In order to define DiffServ (DSCP) values, according to Microsoft the machine needs to have joined a domain, and interfaces have to see the domain controller. To overcome this limitation, so that you can tag DSCP values even for adapters that do not have access to a domain, use the following hidden registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\QoS (you may have to create the QoS key)
“Do not use NLA”=“1” (REG_SZ string value, not DWORD, not present by default, recommended: 1 if you plan to edit DSCP values via gpedit.msc)