Was ist Laminar?
Laminar ist ein neues Framework für die TCP-Überlastungssteuerung, das von der reinen Überlastungssteuerung die Gesamtmenge der Daten bestimmt, die während jeder RTT gesendet wird. Damit wird die Übertragungsplanung getrennt, die genau bestimmt, wann Daten gesendet werden.
Der Standardalgorithmus für die Planung von Übertragungen ist eine strikte Implementierung des Van-Jacobson-Prinzips zur Paketerhaltung [Jacobson88]. Beim Empfänger ankommende Daten führen zu Bestätigungen, die den Sender wiederum dazu veranlassen, eine äquivalente Datenmenge zurück in das Netzwerk zu übertragen. Die primäre Statusvariable ist implizit in die Datenmenge und Bestätigungen implizit, die im Netzwerk zirkulieren. Dieser Status wird durch einen verbesserten tcp_packets_in_flight()-Schätzer (auch total_pipe genannt) beobachtet. „total_pipe“ basiert auf „pipe“ wie in RFC 3517 beschrieben, enthält aber auch die Datenmenge, die von der aktuellen Bestätigung und ausstehenden Übertragungen gemeldet wird, die die Überlastungskontrolle durchlaufen haben, aber auf andere Ereignisse wie TSO warten.
Die neue Variable CCwin ist die primäre Variable für den Status der Überlastungssteuerung. Die Algorithmen zur Überlastungssteuerung passen den CCwin so an, dass die Überlastung auf dem Pfad insgesamt reguliert wird. Obwohl CCwin „cwnd“ ähnelt, wird „cwnd“ von mehreren Algorithmen (z. B. Burst-Unterdrückung) mit unterschiedlichen und manchmal widersprüchlichen Zielen überlastet und verwendet.
Wenn sich „total_pipe“ von CCwin unterscheidet, passt der Algorithmus für die Übertragungsplanung leicht die Anzahl der Segmente an, die als Antwort auf jede Bestätigung gesendet werden. Langsamer Start und proportionale Rate Reduktion (PRR) (ein Ersatz für die Raten-Halbierung) sind beide in den Übertragungsplanungsalgorithmus eingebettet.
Der Hauptvorteil des Laminar-Frameworks besteht darin, dass durch die Partitionierung der Überlastungssteuerung und der Übertragungsplanung in separate Subsysteme wesentlich einfachere Designbeschränkungen unterliegen, was die Entwicklung vieler neuer Algorithmen erleichtert, die mit der vorherigen Organisation des Codes nicht realisierbar sind.
Das Laminar-Framework verändert die zugrunde liegende Designphilosophie der TCP-Überlastungskontrolle und kann weitreichende Auswirkungen haben, die über den Patch selbst hinausgehen. Dieser Patch soll Nutzern die Möglichkeit geben, mit dem Code zu experimentieren und sie zu kommentieren. Außerdem sollen sie auf besondere Fälle hinweisen, die möglicherweise übersehen wurden. Darüber hinaus ist der Patch unvollständig, da noch eine Reihe von Algorithmen fehlen, insbesondere: andere Überlastungskontrollalgorithmen als CUBIC und Reno, cwnd-Validierung, Zielmesswerte usw. Es wäre wirklich toll, wenn einige dieser anderen Algorithmen refaktoriert werden könnten.
Das Laminar-Framework und seine Beweggründe werden im Internetentwurf draft-mathis-tcpm-tcp-laminar ausführlicher beschrieben.
Bitte senden Sie Kommentare und Vorschläge an mattmathis@google.com.
Dieses Projekt ist Teil der Bemühungen von Google, das Web schneller zu machen durch Protokollverbesserungen.
Implementierungshinweise
Laminar wird hauptsächlich in drei Funktionen implementiert (tcp_input.c):
Tcp_cong_avoid() und tcp_mult_decr() führen die AIMD-Überlastungssteuerung mithilfe der CCwin-Statusvariablen durch. Mit Ausnahme des Rückgängig-Vorgangs sind nur diese beiden Funktionen die einzigen Orte, an denen CCwin geändert wird. Beide Funktionen rufen Überlastungsmodul-spezifische Handler auf.
Tcp_laminar_schedule() bestimmt, wie viele Daten als Antwort auf jede Bestätigung gesendet werden. Es implementiert die Paketerhaltung von Van Jacobson, die leicht nach oben oder unten angepasst wird, um tcp_packets_in_flight() mit CCwin zu konvergieren.
Wir haben wichtige Änderungen am Schätzer „tcp_packets_in_flight()“ vorgenommen, damit er bei den meisten Protokollereignissen invariant ist. Anwendung hält Anwendung an, die Anpassungen in tcp_laminar_schedule() und tatsächliche Paketverluste ändern tcp_packets_in_flight() wie erforderlich. ACK-Verarbeitung, TSO und die meisten anderen Ereignisse nicht. Beachten Sie, dass sich bei Verlusten die tatsächliche Anzahl der Pakete im Flug sofort ändert, sich aber erst im Schätzer tcp_packets_in_flight() widergespiegelt wird, bis die Maschine für die erneute Übertragung sie als verloren markiert und „lost_out“ erhöht.
Patch abrufen
Dieser Patch richtet sich gegen Dave Miller und kann problemlos auf 3.5-rc2 angewendet werden.
Hinweis: Die Überlastungssteuerungsmodule, die sonst Reno und CUBIC nicht aktualisiert haben, wurden nicht aktualisiert und können auch nicht kompiliert werden. Wenn in Ihrer Konfiguration weitere Module zur Überlastungssteuerung wie z. B. Vegas, skalierbare, Hochgeschwindigkeitsmodule usw. erstellt werden, müssen diese zuerst deaktiviert werden.