Delay, die unterschätzte Größe

Kommentieren Drucken

Kennen Sie das? Die Performance im Weitverkehrsnetz lässt zu wünschen übrig. Mitarbeiter Ihrer Außenstellen beklagen lange Wartezeiten beim Zugriff auf Anwendungen und Dateien. Kein Problem: schnell eine höhere Bandbreite beim Provider beauftragt – doch nichts verbessert sich. So ähnlich erging es einem unserer Kunden. Zur Kopplung zweier Rechenzentren an entfernten Standorten wurde eine schnelle Datenleitung angemietet. Gigabit Ethernet sollte das Kopieren von Daten in erträglicher Zeit ermöglichen. Doch erste Tests zeigten: Mehr als ca. 200 MBit/s waren nicht zu schaffen.

Um sich die Vorgänge auf der Datenleitung zu verdeutlichen, stelle man sich einen einfachen Kommunikationsvorgang in Form eines „Ping-Pong“ vor.

Der Sender überträgt eine Nachricht und erwartet darauf eine Quittung. Erst nach erfolgreicher Bestätigung kann er die nächste Nachricht schicken. Die Gigabit-Datenleitung unseres Kunden hatte eine Antwortzeit von 10 Millisekunden, wie sich über den bekannten Befehl „Ping“ leicht ermitteln ließ. Somit kann der Sender in unserem Beispiel alle 10 Millisekunden eine Nachricht verschicken, d.h. maximal 100 Nachrichten pro Sekunde. Nehmen Sie jetzt an, eine Nachricht habe die Länge von 32 KByte, ein typischer Wert bei Dateizugriffen unter Windows XP. Dann lassen sich maximal 100 mal 32 KByte in einer Sekunde übertragen. Das entspricht 25 MBit/s oder 2,5% der Leitungskapazität aus unserem Beispiel.

Den Erfindern des heute allgemein verwendeten Transmission Control Protocol (TCP) war dieser Zusammenhang bewusst. Daher haben sie einen Mechanismus erfunden, der das Warten des Senders auf eine Quittung vermeidet. Der TCP-Sender darf nämlich eine bestimmte Anzahl von Datenbytes senden, ohne auf eine Quittung warten zu müssen. Diese Anzahl wird „Window“, zu Deutsch Fenster genannt. Um ohne Unterbrechung senden zu können, muss das Window mindestens so groß sein wie die Antwortzeit multipliziert mit der Bitrate der Leitung. In unserem Beispiel beträgt dieses Produkt – auch Bandwidth Delay Product oder BDP genannt – 1 GBit/s mal 0,01 s. Das entspricht einem Window von 1,25 MByte! Anders ausgedrückt, frühestens nachdem der Sender 1,25 MByte am Stück gesendet hat, kann er das erste Quittungspaket vom Empfänger erwarten.

So weit, so gut. Braucht man also beim TCP-Sender „nur“ die entsprechende Fenstergröße (Window Size) einzustellen und alle Probleme sind behoben? Weit gefehlt. Denn erstens muss auch der Empfänger das unterstützen, d.h. genügend Empfangspuffer bereithalten. Und zweitens rechnet sich der TCP-Sender die tatsächlich verwendete Window Size selbst aus. Das Verfahren basiert auf der Anzahl der erfolgreich bestätigten Pakete. Ziel ist es nämlich, die Window-Size gerade so groß werden zu lassen, dass Überlast vermieden wird („Congestion Avoidance“). Mit anderen Worten, sobald der Sender feststellt, dass Pakete verloren gingen, verwendet er eine kleinere Window Size. Er vergrößert sie zwar anschließend mit jedem erfolgreich quittierten Paket wieder, jedoch langsamer als vor dem Paketverlust. In der Praxis führt das dazu, dass die meisten TCP-Sender niemals eine wirklich große Window Size erreichen. Die Gigabit-Verbindung wird nicht ausgelastet.

Dieser Zusammenhang sollte Ihnen bewusst sein, bevor sie eine schnelle und teure Datenleitung in Betrieb nehmen – etwa um zwei Rechenzentren zu koppeln. Und bedenken Sie, mit jedem Geschwindigkeitssprung (10GE, 40GE, usf.) verschärft sich das Problem. Außerdem müssen die Warteschlangen der Netzkomponenten in der Lage sein, die großen TCP-Windows aufzunehmen. Der Einsatz von QoS ist hier bekanntlich kontraproduktiv, da QoS die Warteschlangen prinzipiell verkleinert (vgl. mein „Standpunkt“ vom März 2011).

Hilfe kommt aus zwei verschiedenen Richtungen. Erstens berücksichtigen aktuelle TCP-Stacks das Problem großer BDPs. Ein Beispiel ist das mit Windows Vista/7 bzw. Server 2008 eingeführte „Compound TCP“ (CTCP), aber auch das in der Linux-Welt bekannte „Westwood+“.

Zweitens adressieren die so genannten WAN Optimization Controller (WPC) dieses Thema. Durch das Generieren „lokaler“ Quittungen, die sehr schnell an den TCP-Sender zurückgehen, kann dieser sein Window schneller vergrößern. Aber Achtung! In der Praxis gibt es immer wieder Kompatibilitätsprobleme mit WOC; es gibt eben kein Optimierungsverfahren, das mit allen möglichen TCP-Implementierungen und Anwendungen gleichermaßen gut umgehen kann.

Was bleibt, ist die Erkenntnis, dass Sie jeden Einzelfall genau betrachten müssen. Woran liegt es, dass in Ihrer speziellen Umgebung bestimmte Anwendungen gut laufen und andere nicht? Ist die Ursache wirklich eine zu kleine TCP Window Size? Welche Parameter der TCP-Stacks und Anwendungen lassen sich überhaupt verstellen? Welche Seiteneffekte hat der Einsatz von WOC? Wie sehen entsprechende Testszenarien aus? Die Performance-Optimierung im Zusammenhang mit großem BDP ist eine Herausforderung!

zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.