QoS über Flusskontrolle

Es ist der klassische Fall. Eine Firma mit PC-Nutzern und Servern hat eine Internetanbindung, die von allen Anwendern parallel genutzt werden kann. je häufiger aber VoIP, Video und andere "multimediale" Elemente genutzt werden, desto eher beschweren sich Mitarbeiter über Aussetzer, Hänger bis hin zur Arbeitsunfähigkeit. Diese Seite beschreibt die Optionen, auch ohne QoS die eingehende Bandbreite zu steuern. Wenn eine Firma z.B. Dienstleistungen über das Internet erbringt, z.B. Fernsteuerungen von Kunden mit Teamviewer und Co, dann ist ein unkontrollierter Mega-Download sehr störend.

Das Problem

Solange die Bandbreite hoch genug und die Belastung immer nur kurzfristig ist, reicht notfalls sogar ein einfacher Router, der die Client per NAT in das Internet lässt. QoS im Internet ist sowieso ein Fremdwort und lange Websurfen und Mails sind eher punktuelle Spitzen, die sich irgendwie schon ausgeglichen haben. Sobald aber VoIP und Video dazu kommt oder per Fernwartung über Internet gearbeitet wird, muss eine Steuerung eingesetzt werden um zumindest die Kontinuität zu verbessern. Auch der Up- oder Download von großen Dateien, was z.B. bei Migrationen von Exchange nach Office 365, der Übertragung von VMs nach Azure, Backups in die Cloud oder auch einfach nur ein Download eines ISO-Images zur Installation (Exchange 2016CU4 ist ein 5 GB ISO-File) stören oder machen eine Anbindung unbrauchbar. Das folgende Bild soll das Dilemma etwas verdeutlichen:

 

Der PC (Knoten A1) lädt z.B. eine große Daten von einem WebServer im Internet herunter. In den meisten Fällen ist die Anbindung an das Internet das Teilstück mit der geringsten Bandbreite. Auch wenn Sie vielleicht 100MBit o.ä. haben, dürften die Transferleistungen im Internet und die Anbindung des Servers in einem Datacenter immer besser sein. Der Client A1 dürfte also die gesamte Bandbreite nutzen, wenn er sich die Leitung nicht teilen muss.

Wenn nun ein anderer Client, z.B. das Telefon A2 mit einer anderen Gegenstelle im Internet (Endgeräte Z2) eine eigene Verbindung aufbaut, dann nutzen auch diese Pakete die gleiche Anbindung. Von A2 nach Z2 wird vermutlich ein Engpass zu vermuten sein aber beim Empfang von Z2 nach A2 stauen sich die Pakete beim Router des Provider und einige UDP-Pakete dürften wohl verworfen werden. In der Regel haben Sie als Kunde aber keinen Zugriff auf den Router des Providers und können damit weder die "Paket Drop Rate" sehen noch über eine Priorisierung bestimmen.

Aber auch wenn es das auf dem Bild angedeutete Ventil im Rückweg nicht gibt, so sind sie dennoch nicht hilflos einem "Sauger" ausgeliefert. So können Sie auf der Senderichtung Richtung Internet schon einmal den Durchsatz pro Client, pro Dienst, pro Connection o.ä. beschränken. Die Flexibilität hängt hier natürlich von der eingesetzten Software ein. Aber solche ein Drosselventil von ihnen Richtung Internet hat auch Auswirkungen auf den eingehenden Verkehr.

Flow-Control

Der Hebel dazu ist die Flusskontrolle, welche bei TCP-Verbindungen enthalten ist. TCP wird von den meisten modernen Protokollen genutzt, die Daten unveränderlich, verlustfrei und gesichert übertragen wollen. Diese Funktion ist erforderlich, das die Router zwischen Netzwerken nur einen beschränkten Speicher haben und nicht überflutet werden sollten. Die älteren Semester erinnern sich vielleicht noch an die Leitungen RTS/CTS oder die XON/XOFF-Bytes bei seriellen Verbindungen. Schauen wir und ein einfaches Netzwerk-Beispiel an:

Das Internet ist ein richtig umfangreicher Verbund vieler Netzwerkknoten und auf dem Weg zwischen zwei Systemen gibt es sehr unterschiedliche verfügbare Bandbreiten. Relevant ist nicht die maximale Geschwindigkeit der Leitung sondern die im Moment verfügbare Bandbreite. Das kann sehr veränderlich sein und schon so ist erklärbar, dass die Geschwindigkeit des "Lokalen Link" nicht allein die Übertragung steuert. Auch wenn in dem Beispiel der Client mit einem kleinen HTTP-GET eine Datei anfordern kann und der Webserver rechts diese dann mit maximaler Geschwindigkeit auf den Weg bringt, so gibt es immer Zwischenstationen, die die Daten zwar schnell annehmen aber nicht genauso schnell wieder weiterreichen können. Router puffern einige Pakete aber dieser Bereich ist beschränkt. Es wäre auch ungeschickt dem Sender alle Daten abzunehmen und diese dann lange zu puffern. Es läuft also auf eine Flusskontrolle hinaus.

Der Absender kann nur Daten senden, wenn er vom Empfänger auch eine Freigabe dazu bekommt. Dazu handeln Absender und Empfänger im Rahmen des TCP-Handshake z.B. eine Windowsize aus. Damit weiß der Absender, wie viele Pakete er auf die Reise schicken darf, ehe er auf eine Bestätigung des Ziels warten muss. An dieser Stelle kann nun auch eine Steuerungsfunktion bei einer Firma eingreifen und eben diese Rückmeldungen so anpassen oder verzögern, dass der Absender seine Sendeleistung auf das gewünschte Maß drosselt.

Kommt allerdings UDP statt TCP zum Einsatz, was bei VoIP mit Audio/Video eher der Regelfall ist, dann gibt es hier keine TCP-Flusskontrolle. Der Absender kann quasi mit seiner "Kabelgeschwindigkeit" die Pakete auf die Leitung setzen. Der Router zum nächsten langsameren Teilstück kann aber nur begrenzt Pakete puffern und muss daher Pakete verwerfen. Daher ist UDP ohne eigene Kontrolle wirklich ein "verlustbehaftetes Protokoll". beim Einsatz von VoIP kommt daher ein Rückkanal in Form von RTCP  (Real Time Control Protocol) zum Einsatz, welches aber mehr Daten liefert, als ein einfacher TCP-ACK. Der Sender kann anhand der Daten im RTCP-Protokoll abschätzen, ob ein Codec-Wechsel oder andere Auflösung ratsam ist. Eine UDP-Verbindung zeichnet sich schon dadurch aus, dass die Datenrate "vorhersehbar" ist.

Beispiel Sophos UTM

Mein Testfeld fokussiert sich auf Gateways und VoIP-Telefone, Headsets, so dass ich mir hier auf ein paar Ausschnitte einer Sophus UTM9 beschränke, mit der Bandbreiten kontrolliert werden können. Alle Dialoge befinden sich unter "Interfaces and Routing" und dann "Quality of Service (QoS). Auf der ersten Karteikarte "Status" habe ich für jedes Interface hinterlegt, wie viel Bandbreite insgesamt vorhanden ist und die Limitierung aktiviert.

 

Das reicht aber noch nicht. Ehe ich aber dann Limit anwenden kann, muss ich erst einmal die Datenströme klassifizieren. Wie sie hier im Ausschnitt sehen, habe ich RDP-Verkehr aber auch Teamviewer und natürlich VoIP definiert.

Die Klassifizierungen kann ich später verwenden. Für viele Firmen wird aber auch eine ganz einfache Konfiguration erst einmal Besserung bringen. Auf "Download Throttling" habe ich hier zwei Begrenzungen aktiv. Die erste steuert, dass der WSUS-Server nicht mehr als 2Mbit absolut verwendet. Damit ist hier schon mal "Ruhe". Die zweite Regel begrenzt, dass es ein generelles Limit von 5MBit pro Quelle/Ziel gibt. Auch dies verhindert schon einmal, dass ein Anwender die komplette Bandbreite nutzt.

In dem meisten Fällen ist diese einfache Konfiguration schon ein Gewinn. Wer es feiner haben will, kann natürlich auf der Karteikarte "Bandwidth Pools" auch Mindestbandbreiten garantieren.

Hier bekommt Teamviewer 1 MBit und Voice kann mit 250Kbit rechnen. Natürlich sollten Sie dann auch mittels CAC z.B. den Weg über Edge entsprechend beschränken.

Sophos UTM: Turbocharge your bandwidth
https://www.youtube.com/watch?v=00FT8OGK6sk

Zusammenfassung

Auch wenn man auf den ersten Blick meinen könnte, dass Bandbreiten-Limits immer nur in die Senderichtung erzwungen werden können, gibt es mit dem passenden Produkt durchaus Wege, auch die Gegenrichtung indirekt zu steuern. Wenn ihr Router/Firewall nämlich den aktuellen Bandbreitenbedarf einer Anwendung oder Verbindung messen und mit Sollwerten vergleichen kann und basierend darauf dann den Rückkanal beeinflusst, dann ist sehr wohl eine künstliche Verlangsamung einer Verbindung möglich. So kann die bestehende Bandbreite dann etwas fairer verteilt werden und bestimmte kritische Dienste können weiterhin genutzt werden ohne die weniger wichtigen Dienste zu stark einzuschränken.

Die Feinabstimmung ist aber nicht mal eben möglich. Sie müssen das entsprechende Produkt kennen, die verschiedenen Datenverkehre erfassen und klassifizieren, und zu allerletzt natürlich bestimmen, welche Bandbreiten Sie zuweisen bzw. limitieren. Aber es durchaus möglich, auch über qualitativ ungesicherte Verbindungen zumindest auf der ersten Teilstrecke die verfügbare Bandbreite zu managen. Was dann aber tiefer im Internet passiert, ist nicht mehr kontrollierbar.

Weitere Links