Die TCP-Staukontrolle nimmt auch nach mehr als 35 Jahre ihrer ersten Veröffentlichung einen wichtigen Teil der TCP/IP-Funktionen ein. Aus diesem Grund ist jetzt ein guter Zeitpunkt diese Funktion zu würdigen, die für den Erfolg des Internets verantwortlich ist.
Natürlich gibt es inzwischen viele Theorien darüber, warum TCP/IP erfolgreicher war als viele seiner seine Zeitgenossen , wie CLNP oder TP4. Wahrscheinlich gab es viele Faktoren, die zum Erfolg der Internet-Protokolle beigetragen haben. Aber ich halte die Staukontrolle für einen der Schlüsselfaktoren, die es dem Internet ermöglichten, sich von einem moderaten zu einem globalen Maßstab zu entwickeln. Außerdem ist es eine interessante Studie darüber, wie sich die in den 1970er Jahren getroffenen architektonischen Entscheidungen im Laufe der folgenden Jahrzehnte bewährt haben.
Verteiltes Ressourcenmanagement
In einem von David Clarks veröffentlichen Aufsatz mit dem Titel „The Design Philosophy of the DARPA Internet Protocols“ (http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf) wird als eines der Ziele für den Protokollentwurf folgendes festgelegt: „Die Internet-Architektur muss eine verteilte Verwaltung der Ressourcen ermöglichen!“ Dieses Ziel hat verschiedene Auswirkungen. Die Art und Weise wie Jacobson und Karels (siehe auch https://ee.lbl.gov/papers/congavoid.pdf) die Staukontrolle in TCP erstmals implementierten, ist ein gutes Beispiel dafür, wie dieses Prinzip beherzigt wurde.
Ihr Ansatz berücksichtigt auch ein weiteres Ziel des Internet: die Anpassung an viele verschiedene Arten von Netzen. Zusammengenommen schließen diese Prinzipien so gut wie jede Art von netzbasierter Zugangskontrolle aus, was in scharfem Kontrast zu Netzen wie ATM steht, die davon ausgingen, dass ein Endsystem eine Anfrage an das Netz stellt, bevor Daten fließen können.
Ein Teil der Philosophie der „Anpassung an viele Netzwerktypen“ besteht darin, dass man nicht davon ausgehen kann, dass alle Netze über eine Zugangskontrolle verfügen. In Verbindung mit der verteilten Verwaltung von Ressourcen führt dies dazu, dass die Überlastungskontrolle von den Endsystemen übernommen werden muss, was genau das ist, was Jacobson und Karels mit ihren ersten Änderungen an TCP erreicht haben.
Dadurch wurden Millionen von Endsystemen dazu gebracht, die Bandbreite von meist schmalbandigen Verbindungen auf faire Art und Weise gemeinsam zu nutzen.
Die Geschichte der TCP-Überlastungskontrolle ist lang genug, um ein ganzes Buch zu füllen. Jedoch die Arbeiten, die von 1986 bis 1998 in Berkeley zu diesem Thema geleistet wurden, wirft einen langen Schatten voraus. Hierbei zählt das Papier von Jacobsons (https://dl.acm.org/doi/10.1145/52324.52356) von 1988 zu den am häufigsten zitierten Netzwerkpapieren aller Zeiten.
Slow-Start, AIMD (Additive Increase, Multiplicative Decrease) sowie die Abschätzung der Round-Trip-Time (RTT) und die Verwendung von Paketverlusten als Überlastungssignal waren bereits allesamt in diesem Papier enthalten und legten den Grundstein für die folgenden Jahrzehnte der Forschung zum Thema Staukontrolle. Ein Grund für den Einfluss dieses Papiers liegt meiner Meinung nach darin, dass es eine solide Grundlage schuf und gleichzeitig viel Raum für künftige Verbesserungen ließ – wie wir an den anhaltenden Verbesserung der Staukontrolle heute sehen.
Das Stauproblem ist grundsätzlich schwierig in den Griff zu bekommen: Wir versuchen, Millionen von Endsystemen, die keinen direkten Kontakt zueinander haben, dazu zu bringen, die Bandbreite von Engpassverbindungen auf einigermaßen faire Weise gemeinsam zu nutzen, indem wir nur die Informationen nutzen, die wir durch das Senden von Paketen in das Netz und die Beobachtung, wann und ob sie ihr Ziel erreichen, gewinnen können.
Einer der größten Fortschritte nach 1988 war wohl die Erkenntnis von Brakmo und Peterson, dass nicht nur Paketverluste, sondern auch zunehmende Verzögerungen ein Zeichen für Überlastung sind. Dies war die Grundlage für das bekannte TCP-Vegas-Paper (https://dl.acm.org/doi/10.1145/190809.190317) von 1994, und die Idee, die Verzögerung statt nur die Verlust zu Messung von Staus im Netzwerk verwenden, war damals ziemlich umstritten.
Das Vegas-Papier leitete jedoch einen neuen Trend in der Staukontrollforschung ein und inspirierte viele andere Bemühungen, die Verzögerung als Frühindikator für einen Stau zu berücksichtigen, bevor ein Verlust auftritt. Datacenter-TCP (DCTCP) (siehe https://dl.acm.org/doi/10.1145/1851275.1851192) und Googles BBR (Bottleneck Bandwidth and Round-Trip-Propagation) sind zwei Beispiele dafür.
Ein Grund dafür, dass ich den Algorithmen zur Staukontrolle bei der Erklärung des Erfolgs des Internets Anerkennung zolle, ist, dass der Weg zum Scheitern des Internets 1986 deutlich zu sehen war. Jacobson beschreibt einige der frühen Zusammenbrüche des Internets aufgrund eines Staus, bei denen der Durchsatz um drei Größenordnungen einbrach.
Als ich 1995 zu Bay Networks kam, hörten wir immer noch Kundenberichte über katastrophale Überlastungsepisoden. Im selben Jahr prophezeite Bob Metcalfe, Erfinder des Ethernet, dass das Internet zusammenbrechen würde, da der Internetzugang der Consumer und das Aufkommen des Internets zu einem rapiden Anstieg des Datenverkehrs führten. Das hat sich jedoch nicht bewahrheitet.
Inzwischen hat sich die Staukontrolle weiterentwickelt. Das QUIC-Protokoll beispielsweise bietet sowohl bessere Mechanismen zur Erkennung von Staus als auch die Möglichkeit, mit mehreren Algorithmen zur Staukontrolle zu experimentieren. Außerdem wurde die Staukontrolle teilweise in die Anwendungsschicht verlagert, z. B: Dynamisches adaptives Streaming über HTTP.
Ein interessanter Nebeneffekt der Überlastungsepisoden der 1980er und 1990er Jahre war, dass wir beobachteten, dass kleine Puffer manchmal die Ursache für Überlastungen waren. In einer Arbeit von Villamizar und Song (siehe https://dl.acm.org/doi/10.1145/205511.205520) wurde gezeigt, dass die TCP-Leistung abnahm, wenn die Puffermenge geringer war als das durchschnittliche Produkt aus Verzögerung und Bandbreite der Datenströme.
Leider galt dieses Ergebnis nur für eine sehr kleine Anzahl von Datenströmen (wie in der Arbeit eingeräumt wurde), aber es wurde weithin als unumstößliche Regel interpretiert, die die nächsten Jahre der Router-Entwicklung beeinflusste.
Dies These wurde schließlich durch die Arbeit von Appenzeller (https://dl.acm.org/doi/10.1145/1015467.1015499) zur Puffergröße im Jahr 2004 widerlegt. Zuvor musste dieses Missverständnis jedoch zum bedauerliche Phänomen des Bufferbloats – den übermäßige Puffergrößen führen. Diese führten zu massiven Verzögerungen in der Warteschlange in Millionen von Low-End-Routern. Der Selbsttest (https://www.waveform.com/tools/bufferbloat ) für Bufferbloat für die Heimnetzwerk gibt einen Hinweis auf diese Probleme.
Wir werden zwar nicht genau herausfinden, was das Internet zum Erfolg führte und andere Protokollsuiten auf der Strecke blieben, aber wir wissen, dass das Internet ein mögliches Scheitern vermieden hat, weil die Staukontrolle rechtzeitig eingeführt wurde.
Im Jahr 1986 war es relativ einfach, mit neuen Ideen zu experimentieren, indem man den Code in einigen Endsystemen optimierte und dann als effektive Lösung auf eine große Anzahl von Systemen ausweitete. Innerhalb des Netzes musste sich nichts ändern. Es war sicherlich hilfreich, dass die Anzahl der Betriebssysteme, die geändert werden mussten, klein genug war, um eine weit verbreitete Anwendung der ursprünglichen BSD-basierten Algorithmen von Jacobson und Karels zu erreichen.
Etwas wie den perfekten Lösungsansatz zur Staukontrolle wird es auch in Zukunft nicht geben, weshalb auch 35 Jahre nach Jacobson immer wieder neue Arbeiten zu diesem Thema veröffentlicht werden. Aber die Architektur des Internets hat ein Umfeld geschaffen, in dem wirksame Lösungen getestet und eingesetzt werden können, um eine verteilte Verwaltung gemeinsam genutzter Ressourcen zu erreichen.
Meiner Meinung nach ist das ein großartiges Zeugnis für die Qualität dieser Architektur.
Von Matthias Hein, Consultant, Autor, Redakteur
