Netzwerk Performance: Explicit Congestion Notification
Wenn Netzwerkgeräte um Hilfe rufen.
Wir sprechen sehr oft über Engpässe im Netzwerk, den Mechanismen welche versuchen diese Engpässe zu vermeiden schenken wir leider nur sehr wenig Aufmerksamkeit. Das wollen wir heute ändern.
Der Hauptmechanismus zur Handhabung von Netzengpässen ist ein Packet Drop. Ja, die überlasteten Geräte lassen, scheinbar willkürlich, Pakete fallen, um Zeit (und Bandbreite) zu gewinnen. Dabei vertrauen sie darauf, dass die Protokolle den Paketverlust verwalten.
Was bewirkt das bei den Anwendungen, welche den Paketverlust erleiden?
Es gibt zwei Nebeneffekte, die sich auf die Übertragungsleistung auswirken:
- Das Protokoll/die Anwendung muss erkennen, dass ein Paketverlust vorliegt. Damit dies geschieht, muss eine bestimmte Zeit vergehen (RTO Retransmission Time Out). Auf Windows Betriebssystemen ist das RTO auf 3 Sekunden eingestellt.
- Im TCP-Protokoll wird, im Fall einer erneuten Versendung, die Transmissionsrate halbiert und in kleinen Schritten wieder erhöht (slow-start)
Ein Paketverlust kann also einen Stillstand von einige Sekunden, beispielsweise bei der Übertragung einer kleinen Webseite, herbeiführen. Dies wirkt sich natürlich negativ auf das Benutzererlebnis aus.
Gibt es einen Mechanismus der Überlastungen verwaltet ohne, dass sich dies drastisch auf den Throughput auszuwirken?
Im EMC und TeraOptics haben 2001 ECN – Explicit Congestion Notification (ECN RFC 3168) vorgeschlagen. ECN ist ein Mechanismus, welcher es Netzwerkgeräten ermöglicht, der Quelle eine drohende Überlast zu signalisieren. Wodurch diese die Datenrate reduziert.
Die Netzwerkgeräte bitten also um Hilfe indem sie, bildlich gesprochen, eine Flagge hissen auf der steht „Sagt dem Absender, er soll die Pakete langsamer verschicken, Danke!“.
Wenn alles gut geht, wird die Datenrate verringert und der Status der Geräte ist nicht mehr kritisch: ohne Einbruch des Throughputs und ohne RTO Wartezeiten.
Ganz bewusst schreibe ich “wenn alles gut geht“, es können sich nämlich folgende Situationen ergeben, welche dazu führen, dass der Mechanismus nicht funktioniert:
- Das Betriebssystem des Clients, des Servers oder der Netzwerkgeräte unterstützt ECN nicht.
- Die Pakete mit den Hilfeanfragen oder jene, welche um eine verlangsamte Rate bitten, werden von anderen Geräten verworfen.
NetEye Real User Experience ist in der Lage die Pakete mit ECN-Flag zu erkennen. Um ECN für die Netzwerk-Geräte zu aktivieren reicht es die Queuing-Mechanismen wie RED, WRED, GRED, ALTO (je nach Vendor) zu konfigurieren.
Die Information zum Congestion-Stauts eines Netzwerk-Gerätes ist insofern hilfreich, da er uns hilft die Ursache eines Performanceproblems so schnell wie möglich aufzudecken.
Wie Sie im oben stehenden Beispiel sehen können, haben wir Anfragen zwischen zwei IPs im lokalen Netzwerk vorliegen, welche fallengelassene Pakete erlitten (siehe Feld “Retransmissions”). Es ist sehr wahrscheinlich, dass die Ursache dafür ein Netzwerk-Gerät ist, welches bereits einen Engpass signalisiert hat (siehe Feld “Congestion”). Wir kennen zwar die Identität des betroffenen Geräts noch nicht, um diese herauszufinden reicht es jedoch der Route der Pakete zu folgen und die Statistiken der Geräte zu überprüfen, welche sich entlang dieser Route befinden.
Durch die Integration mit NeDi können wir die Switche/Router erkennen, welche mit dem Client bzw. Server verbunden sind, um die Netzwerkgeräte weiter zu analysieren.
Tipp: Sie fragen sich sicher ab wann es sich denn überhaupt auszahlt den Congestions mehr Aufmerksamkeit zu schenken, es kann ja mal vorkommen, dass Engpässe auftreten. Meine Empfehlung ist hier die Entwicklung der Congestions zu beobachten. Häufen sie sich, sollten Sie der Ursache auf den Grund gehen und die Paket-Routen genauer verfolgen. So werden Sie in der Lage sein auftretende Engpässe zu identifizieren, bevor sich diese negativ auf die gefühlte Applikationsperformance der User auswirken und diese sich letztendlich dann darüber beschweren.
Zusatz
Damit der Recovery-Mechanismus (also die Verringerung der Transmissionsrate) funktioniert, ist es notwendig, dass auch die Clients und Server ECN aktiviert haben. Generell, unterstützen alle neueren Betriebssysteme ECN, in einigen ist der Mechanismus jedoch standardmäßig deaktiviert und muss daher aktiviert werden.
Microsoft Windows
Ab Windows Server 2012 ist ECN standardmäßig aktiviert. In den vorhergehenden Non Server Versionen ist es standardmäßig deaktiviert, kann jedoch mit netsh interface tcp set global ecncapability=enabled aktiviert werden.
Linux
Ab Kernel 2.4.20 wird ECN wie unten beschrieben unterstützt. Die Konfiguration erfolgt über das sysctl Interface indem die Parameter /proc/sys/net/ipv4/tcp_ecn eingestellt werden.
0 – deaktiviere ECN und aktiviere und akzeptiere es nicht
1 – aktiviere ECN wenn es von eingehenden Übertragung angefragt wird und frage ECN an für ausgehende Übertragungsversuche
2 – (default) aktiviere ECN wenn es von eingehenden Übertragungen angefragt wird, frage es aber für ausgehende Übertragungen nicht an.
Mac OS X
Ab Version 10.5 wird ECN unterstützt, ist standardmäßig jedoch deaktiviert. Die Aktivierung erfolgt indem man diese Variabeln setzt sysctl net.inet.tcp.ecn_negotiate_in
Ab Version 10.11 ist ECN standardmäßig aktiviert
iOS
Ab Version 9 ist ECN standardmäßig aktiviert
Luca Di Stefano
Author
