IP-Pakete in Windows 7/8 mittels DSCP Flag priorisieren

Ich werde bevormundet 🙁 Windows schreibt mir vor was ich zu tun und zu lassen habe. Egal ob ich Administrator oder Bill Gates persönlich bin, Windows lässt mich manches nicht tun und das prangere ich an.

In einem meiner Projekte versuchte ich via C# eine TCP-Socketverbindung mit einer höheren Priorität auszustatten, damit diese stets Vorrang vor den restlichen Datenpaketen auf der selben Übertragungsleitung erhalten und nicht im Falle einer Überlastsituation einfach verloren gehen oder verzögert ankommen. Das IP-Header Feld Type Of Service (ToS) oder Differentiated Services Code Point (DSCP) wie es seit 1998 genannt wird, war dazu genau der richtige Hebel. Mit den korrekten Werten gefüllt, erhält ein IP-Paket auf dem Windows internen Netzwerkstack Vorrang vor anderen Paketen (wird also stets vorn in die Paketwarteschlange eingereiht) und auch Netzwerkelemente auf dem Weg zum Empfänger, lassen dieses Paket schneller passieren (natürlich nur wenn auch diese QoS unterstützen und das DSCP Feld auswerten).

Füllt man das Feld also mit dem Wert 46 (was normalerweise im VoIP Umfeld nur dem wichtigen RTP Traffic zugestanden wird), sollten meine IP-Kontrollpakete bevorzugt behandelt werden. Also nutzte ich folgende kleine Methode, um die wichtigen Flags zu setzen:

/// <summary>
/// Set socket options for the QoS parameter
/// </summary>
/// <param name="pSocket"></param>
private void SetSocketOptions(Socket pSocket)
{
	pSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.BsdUrgent, 1);
	pSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.Expedited, 1);
	pSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, 1);
	// Der Dezimalwert 184 entspricht dem DSCP Wert 46. .NEt unterstützt nur das Setzen des 8bit ToS Feldes, nicht direkt des 6Bit DSCP Feldes
	pSocket.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.TypeOfService, 184);
}

Ein Blick in die gesendeten Pakete via Wireshark offenbarte mir jedoch, dass keine meiner Änderungen übernommen wurden. Alle Felder blieben leer.

Wie sich herausstellte, untersagt Windows Programmen und auch Programmierern die Anpassung  dieser Werte und ersetzt sie mit dem jeweiligen Standardwert. Manche behaupten man könne dieses Verhalten mit zwei Einträgen in der Registry abstellen, andere sagen man müsse sein Programm mit Administratorrechten starten. Bei mir half das leider alles nichts.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"DisableUserTOSSetting"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\QoS]
"Do not use NLA"="1"

Die Lösung, wenn auch eine sehr unschöne, liegt in der Verwendung des Group Policy Editor gpedit.msc.

1. Öffne gpedit.msc
2. Navigiere zu Computerkonfiguration –> Windows Einstellungen –> Richtlinienbasierter QoS
3. Erstelle eine neue Regel, wähle einen Namen und den gewünschten DSCP Wert
4. Wähle aus für welche Anwendungen, Quell- und Zieladressen, Quell- und Zielports diese Regel gilt
5. Fertig

Nach dieser Anpassung wurden meine Kontrollpakete sofort (ohne Neustart) bevorzugt durch das Netz gesendet und konnten trotz Überlastsituation meinen Client steuern. Warum ich jedoch selbst als Programmierer diese Werte nicht im Code anpassen kann, sondern auf den Gruppenrichtlinieneditor zurückgreifen muss, wird wohl ein Microsoft’sches Rätsel bleiben.