Überlastkontrolle in Netzen: TCP, CUBIC, BBR und QUIC

Überlastung beginnt, wenn Verkehr über einen längeren Zeitraum schneller in einem Teil eines Netzes eintrifft, als dieser ihn übertragen kann. Pakete warten im Ausgangspuffer eines Routers, der Warteschlange. Der Engpass ist die Verbindung auf dem Pfad, die für diesen Verkehr die geringste Kapazität bereitstellt.

Verfolge den Überschuss

Angenommen, ein Router empfängt 12 Mbps für eine Ausgangsverbindung, die 10 Mbps senden kann. Er kann den Ausgang nicht auf die Geschwindigkeit des Eingangs beschleunigen. In jeder Sekunde bleiben 2 Megabit zurück, nach Division durch 8 also 250.000 Byte. Ein anfangs leerer Puffer mit 1.000.000 Byte füllt sich in:

Ein Paket, das sich hinter dieser Datenmenge einreiht, wartet, bis die Verbindung die Daten vor ihm übertragen hat:

Sobald der Puffer voll bleibt, überträgt der Ausgang weiterhin nur 10 Mbps. Von den eintreffenden 12 Mbps werden etwa 2 Mbps verworfen, also ein Sechstel des angebotenen Verkehrs. Diese Berechnungen gehen von gleichbleibenden Ankunfts- und Abgangsraten aus; der genaue zeitliche Ablauf einzelner Pakete führt zu kleinen Abweichungen.

Entscheide, ob sich die Warteschlange leert

Ein kurzer Verkehrsschub unterscheidet sich von anhaltender Überlast. Eine Warteschlange kann einen Schub aufnehmen und sich leeren, wenn die Ankunftsrate unter die Ausgangsrate fällt. Entspricht eine gleichbleibende Ankunftsrate genau der Ausgangsrate, bleibt eine bestehende Warteschlange erhalten: Jedes abgehende Paket wird durch ein ankommendes ersetzt. Liegt die Ankunftsrate dauerhaft über der Ausgangsrate, wächst die Warteschlange, bis der Puffer voll ist.

Tatsächlicher Verkehr trifft ungleichmäßig ein. Selbst unterhalb der vollen durchschnittlichen Auslastung führen Verkehrsschübe dazu, dass Pakete warten. Nahe der Kapazitätsgrenze bleibt wenig freie Zeit, um solche Schübe abzubauen, sodass die durchschnittliche Verzögerung stark steigt. Überlastung erhöht vor allem den Warteschlangenanteil der Paketverzögerung; Verarbeitung, Übertragung und Ausbreitung sind eigene Bestandteile.

Benenne die gemeinte Rate

Unterschiedliche Geschwindigkeiten können den Engpass sichtbar machen: Ein lokales Netz mit 1 Gbps kann eine Zugangsverbindung mit 50 Mbps speisen. Bündelung hat denselben Effekt, wenn mehrere Routereingänge einen Ausgang teilen. Ein einzelner Eingang kann wenig Verkehr führen, während seine Summe mit dem Verkehr der anderen den Ausgang überlastet.

Wähle die richtige Begrenzung

Die Flusskontrolle schützt den Puffer des Empfängers mithilfe des von ihm bekannt gegebenen Empfangsfensters. Die Überlastkontrolle schützt den Pfad zwischen den Endpunkten. Ein Empfänger kann reichlich freien Speicher haben, während ein Router auf dem Pfad Pakete verwirft.

Ein größerer Routerpuffer kann einen längeren Verkehrsschub aufnehmen, doch anhaltende Überlast füllt jeden endlichen Puffer und erhöht die Wartezeit. Eine schnellere Engpassverbindung beseitigt diesen Kapazitätsmangel. Eine andere Verbindung begrenzt dann den Pfad; sie wird nur überlastet, wenn der Verkehr die dort verfügbare Kapazität übersteigt.

Eine ausgelastete Verbindung ist nur dann nützlich, wenn ihr Verkehr zur Zustellung neuer Daten beiträgt. Überlastung verbraucht Kapazität auf eine Weise, die die Zustellung von Nutzdaten verringern kann, obwohl das Netz ausgelastet bleibt.

Erfasse die Kosten

Zuerst entsteht Warteschlangenverzögerung. Ein Videoanruf kann schwer verständlich werden, bevor Pakete verworfen werden, weil Sprache zu spät ankommt. Zuverlässigkeit allein kann diese Verzögerung nicht beheben.

Verlorene Pakete verursachen weitere Kosten: Ein zuverlässiger Sender überträgt sie erneut. Wenn eine Verbindung mit 10 Mbps gleich große Pakete überträgt und 20 % Daten wiederholen, die bereits über diese Verbindung übertragen wurden, entfallen höchstens 8 Mbps auf neue Daten:

Der Nutzdatendurchsatz der Anwendung ist geringer, wenn Header und mögliche Verluste an anderer Stelle berücksichtigt werden. Die Aktivität der Verbindung lässt den Fortschritt der Anwendung daher größer erscheinen, als er ist.

Manche Übertragungswiederholungen sind unnötig. Ein Paket kann in einer langen Warteschlange warten, wenn der Zeitgeber des Senders abläuft. Sein Ersatz gelangt dann in dasselbe stark belastete Netz. Beide Kopien können eintreffen, aber der Empfänger behält die Daten nur einmal. Die Warteschlange hat ein Verzögerungsproblem in zusätzliche angebotene Last verwandelt.

Betrachte die Verbindungen vor einem verworfenen Paket

Ein Verwerfen nahe dem Ziel kann Arbeit auf mehreren früheren Verbindungen verschwenden. Stell dir vor, ein Paket durchläuft die Verbindungen A und B, bevor es in der Warteschlange für C verworfen wird. Die Übertragungen auf A und B haben Kapazität genutzt, ohne das Paket zuzustellen. Wiederholt sich dies, bleibt auf den vorgelagerten Verbindungen weniger Kapazität für Verkehr, der sein Ziel hätte erreichen können.

Steigt die angebotene Last, steigt zunächst auch der Durchsatz. Werden jedoch genügend Pakete auf nachgelagerten Verbindungen verworfen, führt eine höhere Last dazu, dass mehr Verkehr für Arbeit aufgewendet wird, die verschwendet sein wird. Der Ende-zu-Ende-Durchsatz kann einen Höchstwert erreichen und dann fallen. Der Überlastkollaps ist der Extremfall: Die angebotene Last bleibt hoch, während der Nutzdatendurchsatz gegen null fällt.

Im Oktober 1986 fiel der Durchsatz zwischen dem Lawrence Berkeley Laboratory und der UC Berkeley von 32 kbps auf 40 bps, also um den Faktor 800. Die Arbeit von Jacobson und Karels aus dem Jahr 1988 führte eine abgestimmte Reaktion ein: Slow Start, Überlastvermeidung, eine bessere Schätzung der Umlaufzeit und exponentielles Backoff des Zeitgebers. Fenstersteuerung und sinnvoll eingestellte Zeitgeber wirken an unterschiedlichen Stellen des Rückkopplungskreises.

Finde den sinnvollen Betriebsbereich

Raj Jains Kniepunkt und Klippe beschreiben zwei Schwellen. Jenseits des Kniepunkts bringt zusätzliche Last wenig zusätzlichen Durchsatz, aber viel mehr Verzögerung. Jenseits der Klippe fällt der Durchsatz, weil Verluste und verschwendete Arbeit überwiegen. Die Überlastkontrolle strebt eine effiziente Zustellung nahe dem Kniepunkt an und hält Abstand zum Kollaps.

Im Internet gibt es keine zentrale Steuerung, die jedem Sender eine Rate zuweist. Jeder Sender muss auf die Rückmeldungen reagieren, die er erhält. Sendet einer weiterhin mit einer festen hohen Rate, während andere ihre Rate verringern, kann er deren Kapazität beanspruchen und die Überlast verschärfen.

Übertragungswiederholung macht einen Bytestrom zuverlässig, aber sie macht Verluste nicht kostenlos. Die Wiederherstellung verbraucht Kapazität und verzögert die Zustellung fehlender Daten; das Warten auf einen Zeitgeber für Übertragungswiederholungen kann die Verbindung viel länger zum Stillstand bringen als Fast Recovery.

Ein Sender sieht nicht jede Routerwarteschlange auf seinem Pfad direkt. Überlastkontrolle ist ein Rückkopplungsprozess: Die Zustellung wird beobachtet, die Beobachtungen werden gedeutet und die Menge oder Rate des ins Netz eintretenden Verkehrs wird angepasst.

Bestimme die Quelle der Rückmeldung

Bei der Ende-zu-Ende-Überlastkontrolle schließen Endpunkte aus Verlust oder Verzögerung auf Überlastung, ohne eine ausdrückliche Routernachricht zu erhalten. Reno nutzt Verlust. Vegas nutzt Änderungen der Umlaufzeit. BBR erstellt aus Messungen der Zustellrate und RTT ein Pfadmodell.

Bei der netzgestützten Überlastkontrolle liefert ein Router eine ausdrückliche Rückmeldung. ECN markiert ein Paket auf dem Weg zum Empfänger, der die Markierung in seiner Quittung meldet. Ältere ATM-Verfahren konnten eine ausdrücklich erlaubte Rate melden. Ein Router kann auch eine Nachricht direkt an den Sender zurückschicken, ein sogenanntes Drosselpaket. ICMP Source Quench im Internet nutzte diesen Ansatz und wurde 2012 für veraltet erklärt.

Deute Signale sorgfältig

Bei Tail-Drop-Warteschlangen tritt Verlust normalerweise auf, nachdem sich der Puffer gefüllt hat. Aktives Warteschlangenmanagement kann Pakete früher verwerfen oder markieren. Das verändert den Zeitpunkt des Signals, aber der Sender muss weiterhin reagieren.

Die kleinste beobachtete RTT ist nützlich, weil sie näherungsweise einem Pfad mit wenig Wartezeit in Warteschlangen entspricht. Eine RTT über diesem Minimum deutet auf Wartezeit hin, doch ein Endpunkt muss Messungen über einen längeren Zeitraum auswerten. Weder ein einzelner störanfälliger Messwert noch jedes verlorene Funkpaket zeigt die Ursache mit Sicherheit an.

Steuere ein Fenster oder eine Rate

Ein fensterbasierter Sender begrenzt unquittierte Daten, die unterwegs sind. Wenn Quittungen zurückkommen, wird Platz für neue Daten frei. Ein ratenbasierter Sender legt eine Zielrate fest und nutzt meist Pacing, um Pakete über die Zeit zu verteilen. Die Steuergrößen hängen zusammen:

Zum Beispiel entsprechen 100.000 Byte pro 50 ms einer Rate von 2.000.000 Byte/s oder 16 Mbps, wenn das Fenster die maßgebliche Beschränkung ist. Eine ratenbasierte Steuerung kann ebenfalls ein Fenster als obere Schranke für ausstehende Daten nutzen.

Wäge mehrere Ziele ab

Effizienz bedeutet, die verfügbare Engpasskapazität auszulasten. Fairness betrifft die Aufteilung unter konkurrierenden Datenströmen. Geringe Verzögerung setzt kurze Warteschlangen voraus; Stabilität vermeidet große, wiederholte Schwankungen; Reaktionsfähigkeit bedeutet, sich an Änderungen der Kapazität oder der Konkurrenz anzupassen. Eine Regel, die einen Pfad schnell auslastet, kann dennoch ungeeignet sein, um die Verzögerung gering zu halten oder mit anderen Algorithmen zu teilen.

Die TCP-Überlastkontrolle läuft normalerweise im Betriebssystem, die von QUIC normalerweise in einer Anwendungsbibliothek. UDP stellt keine Überlastkontrolle bereit, sodass Anwendungen, die es nutzen, selbst dafür sorgen müssen. Das Trägerprotokoll entbindet nicht von der Pflicht, auf Überlastung zu reagieren.

Das Überlastfenster, cwnd, ist eine senderseitige Begrenzung für unquittierte Daten, die unterwegs sind. Es wird in Byte gemessen, auch wenn Ablaufbeispiele häufig Segmente maximaler Größe zählen. Es ist kein TCP-Headerfeld. Der Empfänger gibt eine andere Begrenzung bekannt: das Empfangsfenster rwnd.

Wende beide Begrenzungen an

Neue Übertragungen müssen sowohl die Flusskontrolle als auch die Überlastkontrolle einhalten. Die nutzbare Begrenzung ist:

Beträgt cwnd 30.000 Byte und rwnd 18.000 Byte, ist die Begrenzung des Empfängers maßgeblich. Sind noch 12.000 Byte unquittiert unterwegs, kann der Sender weitere 6.000 Byte senden. Nach einer Verringerung des Überlastfensters können bereits gesendete Daten die neue Begrenzung übersteigen; der Sender wartet auf Quittungen, bevor er weitere Daten sendet.

Die maximale Segmentgröße, MSS, zählt Anwendungsdaten ohne Header. Von einer Ethernet-MTU mit 1.500 Byte bleiben nach Abzug von 20 Byte für den IPv4-Header und 20 Byte für den TCP-Header ohne Optionen 1.460 Byte. Standards verwenden SMSS für die MSS des Senders.

Rechne ein Fenster in eine Rate um

Ein durch sein Fenster begrenzter Sender liefert ungefähr ein Fenster pro RTT. Bei einem cwnd von 65.536 Byte und einer RTT von 50 ms:

Multipliziere mit 8, um etwa 10,5 Mbps zu erhalten. Diese Schätzung setzt außerdem genügend Anwendungsdaten, ein mindestens ebenso großes Empfangsfenster und einen Pfad voraus, der die resultierende Rate übertragen kann.

Laste den Pfad aus, ohne seine Warteschlange zu füllen

Das Bandbreiten-Verzögerungs-Produkt, BDP, ist die Engpassbandbreite mal der minimalen RTT ohne Warteschlangen. Für 100 Mbps und 40 ms:

Die Division durch 8 ergibt 500.000 Byte, also etwa 342 Segmente à 1.460 Byte. Ein BDP an unterwegs befindlichen Daten hält diesen idealisierten Engpass ohne dauerhaft gefüllte Warteschlange ausgelastet. Weniger Daten lassen Kapazität ungenutzt; überschüssige Daten warten und erhöhen die gemessene RTT. Berechnest du das BDP aus einer bereits erhöhten RTT, hältst du wartende Daten fälschlich für Daten, die der Pfad benötigt.

Die Quittungstaktung hilft, das Tempo zu halten. Wenn Pakete den Engpass verlassen, kehren Quittungen zurück und geben Platz für Ersatz frei. Im stationären Zustand helfen Abgänge daher, den Zeitpunkt neuer Ankünfte zu bestimmen. Das ist der Gedanke der Paketerhaltung hinter der Selbsttaktung von TCP.

Lege Anfangswert und Schwelle fest

Das Anfangsfenster von RFC 5681 reicht je nach SMSS von zwei bis vier Segmenten: vier bis einschließlich 1.095 Byte, drei bis einschließlich 2.190 Byte und darüber zwei. RFC 6928 erlaubt ein Anfangsfenster von bis zu zehn Segmenten. Ein Ablaufbeispiel, das bei einem Segment beginnt, ist eine nützliche Darstellung zum Lernen und keine Aussage, dass alle neuen Verbindungen dort beginnen.

ssthresh, die Slow-Start-Schwelle, bestimmt den Wachstumsmodus. Darunter nutzt TCP Slow Start, darüber Überlastvermeidung. Bei Gleichheit erlaubt RFC 5681 beide Möglichkeiten. Eine hohe Anfangsschwelle ermöglicht einem neuen Sender, die Kapazität durch Slow Start zu erkunden.

TCP muss zunächst erkunden, wie viel Verkehr der Pfad übertragen kann. Slow Start vergrößert das Fenster von einem kleinen Anfangswert aus schnell. Sobald die Slow-Start-Schwelle erreicht ist, erkundet die Überlastvermeidung die Kapazität vorsichtiger.

Zähle Quittungen im Slow Start

RFC 5681 erhöht cwnd für jede Quittung neuer Daten um bis zu eine SMSS:

wobei N die Anzahl der neu quittierten Bytes ist. Bei einer Quittung pro vollem Segment und genügend Daten zum Füllen jedes Fensters schafft jedes gesendete Segment in der nächsten Runde Platz für zwei: einen Ersatz und ein Segment aus dem vergrößerten Fenster.

Ausgehend von 1 MSS lauten die Werte pro Runde 1, 2, 4, 8, 16, 32 und 64 MSS. Nach sechs RTTs sind 64 MSS erreicht. Bei 100 ms pro RTT sind das 0,6 s. Der Name bezeichnet einen sichereren Beginn als das sofortige Senden eines ganzen Empfangsfensters; das Wachstum selbst ist exponentiell.

Verzögerte Quittungen verändern die Rechnung. Sendet der Empfänger für jeweils zwei volle Segmente eine Quittung, ergibt die einfache Regel pro Quittung etwa das 1,5-Fache pro RTT. Appropriate Byte Counting, beschrieben in RFC 3465, nutzt neu quittierte Bytes, um die Abhängigkeit von der Häufigkeit der Quittungen zu beheben.

Wechsle den Wachstumsmodus

Wähle für ein Ablaufbeispiel mit einem anfänglichen cwnd von 1 MSS und ssthresh von 8 MSS bei Gleichheit die Überlastvermeidung. Der Ablauf lautet:

Die ersten drei Änderungen verdoppeln das Fenster. Spätere Änderungen addieren eine MSS pro RTT. Verlust kann beide Phasen unterbrechen. Implementierungen mit HyStart++ (RFC 9406) können Slow Start außerdem vorzeitig verlassen, wenn die Verzögerung steigt.

Erkläre die additive Erhöhung

Eine übliche Regel pro Quittung während der Überlastvermeidung lautet:

Bei 10 MSS fügt eine Quittung etwa 0,1 MSS hinzu. Im Verlauf der Runde treffen etwa zehn Quittungen ein, sodass die gesamte Erhöhung etwa eine MSS beträgt. Der Zuwachs pro Quittung wird mit wachsendem cwnd kleiner, sodass die Erhöhung pro Runde ungefähr konstant bleibt.

Dieser Unterschied ist auf einem großen Pfad bedeutsam. Von 16 auf 32 MSS dauert es im idealen Slow Start eine RTT, in der Überlastvermeidung aber sechzehn RTTs. Das langsamere Wachstum verringert eine plötzliche Überschreitung der Kapazität, sobald der Sender über eine brauchbare Schätzung verfügt.

Erkenne einen Neustart

Slow Start ist nicht auf den Beginn einer Verbindung beschränkt. Der Ablauf des Wiederholungszeitlimits setzt cwnd auf ein Segment zurück. Auch eine Ruhephase, die länger als das Wiederholungszeitlimit dauert, erfordert einen Neustart mit höchstens dem Anfangsfenster, weil die frühere Quittungstaktung und Kapazitätsschätzung möglicherweise nicht mehr zum Pfad passen.

Die Überlastvermeidung hält cwnd nicht auf einem festen sicheren Wert. Sie erhöht das Fenster weiter, bis eine Überlastrückmeldung eintrifft. Auf einem Pfad mit Tail Drop führt dieses fortgesetzte Erkunden tendenziell zu einer dauerhaft gefüllten Warteschlange, bevor ein Verlust dem Sender signalisiert, seine Rate zu verringern.

TCP kann aus einem Zeitgeber oder aus Duplikatquittungen auf ein fehlendes Segment schließen. Der Unterschied ist wichtig: Eine Zeitüberschreitung liefert weniger Hinweise darauf, dass das Netz weiterhin Verkehr zustellt, als drei Duplikatquittungen.

Lege die neue Schwelle fest

Reno verwendet die tatsächlich ausstehende Datenmenge, FlightSize, um Folgendes festzulegen:

FlightSize liegt bei einer voll ausgelasteten Übertragung oft nahe bei cwnd. Beide Werte müssen aber nicht gleich sein, wenn die Anwendung wenig Daten sendet. Die untere Schranke verhindert, dass die Schwelle unter zwei Segmente fällt.

Nach einer Zeitüberschreitung überträgt der Sender erneut, setzt cwnd auf eine SMSS und beginnt Slow Start erneut. Wiederholte Zeitüberschreitungen für dieselben Daten verdoppeln das Wiederholungszeitlimit. Dieses exponentielle Backoff verhindert, dass ein anhaltender Fehler einen ebenso anhaltenden Strom von Wiederholungsversuchen erzeugt.

Stelle die Übertragung vor Ablauf des Zeitgebers wieder her

Drei Duplikatquittungen zeigen, dass drei spätere Segmente hinter einer Lücke angekommen sind. Sie bedeuten nicht, dass drei Segmente verloren gingen. Ein oder zwei Duplikate können durch eine andere Reihenfolge beim Eintreffen entstehen. Daher wartet TCP auf das dritte, bevor Fast Retransmit das fehlende Segment sendet.

Reno beginnt dann Fast Recovery. Angenommen, FlightSize beträgt 12 MSS. Die neue Schwelle beträgt 6 MSS und Reno setzt vorübergehend:

Die drei zusätzlichen Segmente berücksichtigen Pakete, die nachweislich das Netz verlassen haben. Jede weitere Duplikatquittung bläht cwnd um eine MSS auf und ermöglicht weiteres Senden, wenn das Fenster es erlaubt. Sobald eine Quittung die kumulative Quittung voranschiebt, setzt Reno cwnd wieder auf 6 MSS und setzt die Überlastvermeidung fort.

Bei einem Anfangsfenster von 1 MSS und ssthresh von 8 MSS wächst cwnd vor dem Verlust über 1, 2, 4, 8, 9, 10, 11, 12 MSS. Reno fährt schließlich mit 6, 7, 8, 9 fort. Tahoe beginnt erneut mit 1, 2, 4, erreicht die neue Schwelle von 6 und fährt dann mit 7, 8 fort.

Behebe mehrere Lücken in einem Fenster

Das klassische Reno verlässt Fast Recovery bei der ersten Quittung neuer Daten. Deckt diese Quittung nur einen Teil der ursprünglich unterwegs befindlichen Daten ab, bleibt eine weitere Lücke. Reno kann erneut verringern oder eine Zeitüberschreitung erfahren.

NewReno (RFC 6582) bleibt bei einer solchen Teilquittung in Fast Recovery und überträgt das nächste fehlende Segment erneut. Es verlässt die Phase, wenn alle bei Beginn der Wiederherstellung ausstehenden Daten quittiert sind. SACK meldet empfangene Blöcke ausdrücklich; eine SACK-basierte Wiederherstellung kann mehrere Lücken innerhalb einer Umlaufzeit erkennen und beheben.

Ein Überlastungsereignis sollte normalerweise eine Verringerung verursachen, auch wenn mehrere Pakete verloren gehen. NewReno und die SACK-basierte Wiederherstellung handhaben dies zuverlässiger als das klassische Reno. CUBIC verwendet für gewöhnliche Überlastsignale einen anderen Verringerungsfaktor und behält 70 % bei, beginnt nach einer Zeitüberschreitung aber ebenfalls erneut bei einem Segment.

Das klassische Reno erhöht sein Fenster wiederholt und verringert es nach einer Überlastung. Der entstehende Sägezahnverlauf liefert eine nützliche Schätzung für den stationären Zustand, wenn die RTT ungefähr konstant ist, Fast Retransmit Verluste erkennt und keine Zeitüberschreitungen oder Slow-Start-Phasen auftreten.

Bilde den Durchschnitt des Fensters

Das Spitzenfenster betrage W Segmente. Eine Halbierung ergibt einen Bereich von W/2 bis W, dessen Durchschnitt 0,75 W beträgt. Multipliziere mit der MSS, um Byte pro Umlaufzeit zu erhalten, und dividiere dann durch die RTT:

Bei W von 24 Segmenten, einer MSS von 1.460 Byte und einer RTT von 80 ms beträgt die Spitzenrate 3,504 Mbps. Der Durchschnitt liegt bei etwa 2,63 Mbps. Denk daran, dass ein Fenster in Segmenten einen Faktor für die Segmentgröße benötigt; bei einem Fenster, das bereits in Byte angegeben ist, entfällt dieser Faktor.

Stelle den Zusammenhang zwischen Durchsatz und Verlust her

Die Mathis-Näherung beschreibt dasselbe Reno-ähnliche Verhalten mithilfe des Verlustanteils L:

Steht die MSS in Byte und die RTT in Sekunden, wird T in Byte/s angegeben. Bei einer MSS von 1.460 Byte, einer RTT von 0,1 s und einem Verlustanteil von 0,0001 beträgt der Nenner 0,001 s. Das Ergebnis sind 1.781.200 Byte/s, nach Multiplikation mit 8 also etwa 14,25 Mbps.

Bei festem Verlustanteil halbiert eine Verdopplung der RTT den Durchsatz. Bei fester RTT muss der Verlustanteil auf ein Viertel fallen, um den Durchsatz zu verdoppeln, weil der Nenner die Quadratwurzel des Verlustanteils enthält. Ein Verlustanteil von 0,0001 bedeutet 0,01 %, nicht 0,0001 %.

Erkenne das Problem bei hohen Übertragungsraten

Ein Pfad mit 10 Gbps und einer RTT ohne Warteschlangen von 100 ms benötigt zur Auslastung 1 Milliarde Bit oder 125.000.000 Byte an unterwegs befindlichen Daten. Bei Segmenten mit 1.500 Byte ergibt das etwa 83.333 Segmente. Nach einer Halbierung dieses Fensters müssen etwa 41.667 Segmente wieder hinzugewonnen werden. Reno fügt eines pro RTT hinzu, sodass das etwa 4.167 s dauert, fast 70 Minuten.

Der Wert von 83.333 Segmenten ist das Fenster, das benötigt wird, um zu einem bestimmten Zeitpunkt mit 10 Gbps zu senden. Ein Reno-Sägezahn mit durchschnittlich 10 Gbps bräuchte eine höhere Spitze, weil sein durchschnittliches Fenster nur drei Viertel seines Spitzenwerts beträgt. Die Verlustanteilsformel schätzt, dass für einen dauerhaften Durchschnitt von 10 Gbps bei dieser MSS und RTT ungefähr ein Segment unter 4,7 Milliarden verloren gehen darf.

Prüfe weitere Begrenzungen

Eine Überlastkontrolle kann nicht schneller zustellen, als der Engpass es erlaubt, und ein kleines Empfangsfenster kann vor cwnd zur Begrenzung werden. Verwende die kleinste zutreffende Schranke. Zeitüberschreitungen senken die Rate unter den Wert des einfachen Modells, und die Übertragung eines kleinen Objekts kann vollständig im Slow Start enden. Ihre Abschlusszeit hängt stark von den Anfangsrunden und dem Anfangsfenster ab, sodass die Formel für langlebige Übertragungen sie schlecht beschreibt.

Eine schnellere Zugangsverbindung hilft daher nur, wenn sie eine wirksame Begrenzung beseitigt. Eine lange RTT, Verlust oder ein kleines Fenster können eine einzelne Verbindung weit unter der Kapazität der ausgebauten Verbindung halten.

Wenn K aktive Datenströme jeweils mehr Kapazität benötigen, als ein Engpass ihnen geben kann, beträgt ein gleicher Anteil pro Datenstrom R/K, wobei R die verfügbare Rate ist. Effizienz fragt danach, ob ihre Raten zusammen R ergeben. Fairness fragt danach, wie gleichmäßig sie die Kapazität aufteilen.

Trage zwei Raten in ein Diagramm ein

In einem Chiu-Jain-Diagramm entsprechen die waagerechte und die senkrechte Koordinate den Raten der beiden Datenströme. Die Effizienzgerade lautet:

Die Fairnessgerade ist die Diagonale, auf der die Raten gleich sind. Ihr Schnittpunkt steht für die faire Aufteilung bei voller Auslastung. Auf einer Verbindung mit 10 Mbps sind das 5 Mbps pro Datenstrom. Punkte unterhalb der Effizienzgeraden lassen Kapazität ungenutzt; Punkte oberhalb bieten mehr Verkehr an, als die Verbindung übertragen kann.

Unterscheide die beiden Anpassungen

Die additive Erhöhung addiert zu jeder Rate denselben Betrag. Ausgehend von 8 und 1 Mbps ergeben sich durch Addition von jeweils 0,5 Mbps die Raten 8,5 und 1,5 Mbps. Die Differenz bleibt 7 Mbps, aber der kleinere Datenstrom gewinnt im Verhältnis zu seiner Ausgangsrate mehr hinzu. Im Diagramm bewegt sich der Punkt parallel zur Gleichheitsdiagonalen.

Die multiplikative Verringerung multipliziert beide Raten mit demselben Faktor. Die Halbierung von 9 und 2 Mbps ergibt 4,5 und 1 Mbps. Ihr Verhältnis bleibt unverändert, während die absolute Differenz von 7 auf 3,5 Mbps fällt. Der Punkt bewegt sich zum Ursprung hin und die Überlast wird schnell abgebaut.

Dies sind unterschiedliche Arten der Verbesserung: Eine gleiche Addition verbessert das relative Verhältnis; eine proportionale Verringerung verkleinert den absoluten Abstand. Die Wiederholung beider Schritte verhindert, dass der Abstand beim erneuten Erkunden der Kapazität wieder wächst.

Verfolge mehrere Zyklen

Beginne bei 8 und 1 Mbps auf der Verbindung mit 10 Mbps. Addiere pro Schritt und Datenstrom 0,5 Mbps und verringere die Raten erst, nachdem ihre Summe die Kapazität übersteigt. Nach zwei Erhöhungen betragen die Raten 9 und 2, zusammen 11. Die Halbierung ergibt 4,5 und 1.

Fünf weitere Erhöhungen führen zu 7 und 3,5, zusammen 10,5. Die Halbierung ergibt 3,5 und 1,75. Die Abstände betrugen 7; 3,5 und 1,75 Mbps. Eine weitere gleichzeitige Halbierung führt zu einem nächsten Abstand von 0,875 Mbps. Die Datenströme nähern sich gleichen Anteilen, während ihre Summe weiterhin um die verfügbare Kapazität schwankt.

Vergleiche andere Anpassungsregeln

Diese Konvergenz setzt gleiche RTTs, zeitgleiche Überlastrückmeldungen, übereinstimmende Reaktionen und Datenströme voraus, die lange genug aktiv bleiben. Renos additiver Schritt beträgt etwa eine MSS pro RTT und sein Verringerungsfaktor eine Hälfte. Andere positive additive Schritte und Verringerungsfaktoren zwischen null und eins führen zum selben grundlegenden Konvergenzargument. Reale Datenströme müssen nicht alle Annahmen erfüllen, sodass ein zu einem bestimmten Zeitpunkt ungleiches Wertepaar für sich genommen kein Versagen von AIMD zeigt.

Gleiche Anteile sind ein nützlicher Bezugspunkt, aber reale Datenströme können sich in Bedarf, RTT, Anzahl der Verbindungen und Überlastkontrolle unterscheiden. Eine Aussage über Fairness braucht eine klare Antwort auf „Fair zwischen welchen Datenströmen?“

Berechne den Jain-Fairnessindex

Für nicht negative Datenstromraten mit einer Summe ungleich null lautet der Jain-Fairnessindex:

Die Raten 8 und 2 Mbps ergeben eine Summe von 10 und eine Quadratsumme von 68. Der Index beträgt daher etwa 0,735. Gleiche Raten ergeben 1. Erhält einer von n Datenströmen alles, beträgt der Index 1/n.

Der Index misst Gleichheit, nicht Auslastung. Zwei Datenströme mit jeweils 1 Mbps und zwei mit jeweils 5 Mbps haben beide einen Index von 1, obwohl sie unterschiedliche Anteile einer Verbindung mit 10 Mbps nutzen. Prüfe die Gesamtrate getrennt davon.

Berücksichtige begrenzten Bedarf

Max-Min-Fairness gibt Datenströmen mit geringem Bedarf, was sie benötigen, und teilt dann die verbleibende Kapazität unter den Datenströmen auf, die noch mehr möchten. Auf einer Verbindung mit 12 Mbps benötigen drei Datenströme 2, 8 und 10 Mbps. Der anfängliche gleiche Anteil beträgt 4 Mbps. Der erste benötigt nur 2, sodass 10 Mbps für die anderen beiden bleiben. Die Aufteilung beträgt daher 2, 5 und 5 Mbps.

Eine der größeren Raten zu erhöhen würde erfordern, die Rate eines Datenstroms zu verringern, dessen Rate bereits gleich groß oder kleiner ist. Diese Eigenschaft definiert Max-Min-Fairness. Ihre ungleiche Aufteilung kann angemessen sein, auch wenn Jains Gleichheitsmaß unter 1 fällt.

Erkenne Vorteile einzelner Datenströme

Reno wächst einmal pro RTT. Bei gleichem Verlustanteil ist sein ungefährer Durchsatz umgekehrt proportional zur RTT: Ein Datenstrom mit 20 ms kann etwa die vierfache Rate eines Datenstroms mit 80 ms erreichen. Gleicher Zugang zum Engpass beseitigt diesen zeitlichen Vorteil nicht.

Die Aufteilung erfolgt außerdem pro Verbindung. Bei neun bestehenden Verbindungen könnte eine Anwendung, die eine weitere hinzufügt, etwa ein Zehntel der Verbindungskapazität erhalten. Fügt sie stattdessen elf vergleichbare Verbindungen hinzu, beträgt ihr Anteil elf Zwanzigstel oder 55 %. HTTP/2 und HTTP/3 übertragen viele Anfragen über eine Verbindung, während HTTP/1.1-Clients häufig mehrere Verbindungen öffnen.

Eine UDP-Anwendung mit fester Rate kann weitersenden, während TCP-Datenströme ihre Rate verringern. UDP selbst stellt keine Überlastkontrolle bereit; RFC 8085 fordert Anwendungen auf, eine geeignete Überlastkontrolle zu ergänzen. Ein TCP-freundlicher Datenstrom nutzt unter denselben Bedingungen nicht mehr Bandbreite, als vergleichbarer TCP-Verkehr nutzen würde. TFRC nutzt die TCP-Durchsatzgleichung, um eine gleichmäßigere Rate zu unterstützen.

Berücksichtige Warteschlange und Algorithmus

Eine FIFO-Warteschlange setzt keine gleichen Anteile pro Datenstrom durch. Das Ergebnis hängt vom Verhalten der Sender ab. Fair Queuing, einschließlich des Schedulings pro Datenstrom in FQ-CoDel, gibt Datenströmen separate Warteschlangen und Möglichkeiten zur Bedienung.

Das Wachstum von CUBIC und Reno unterscheidet sich auf Pfaden mit großem BDP. Auch die Aufteilung zwischen BBR und CUBIC hängt von der Version und der Puffergröße ab; frühe BBR-Versionen konnten bei kleinen Puffern aggressiv sein. Keine einzelne Gleichheitsberechnung belegt, dass unterschiedliche Überlastkontrollen auf jedem Pfad gleichmäßig nebeneinander arbeiten.

Eine Tail-Drop-Warteschlange nimmt Pakete an, bis ihr Puffer voll ist, und verwirft dann neu eintreffende Pakete. Verlustbasierte Sender erhöhen ihre Rate weiter, bis sie ein Überlastsignal erhalten. Bei einem großen Tail-Drop-Puffer kann dieses Signal erst eintreffen, nachdem sich eine lange Warteschlange gebildet hat.

Berechne die im Puffer verborgene Verzögerung

Ein Puffer mit 2.000.000 Byte vor einer Ausgangsverbindung mit 20 Mbps fasst 16 Millionen Bit. Ist er voll, wartet ein Paket hinter diesen Daten:

Ein Upload kann daher den Durchsatz hoch halten und zugleich einen Anruf auf derselben Ausgangsverbindung um fast eine Sekunde verzögern. Bufferbloat bezeichnet eine anhaltend erhöhte Verzögerung durch große Puffer und das Verkehrsverhalten, das diese gefüllt hält.

Pufferung hat dennoch einen Zweck: Kurze Verkehrsschübe brauchen einen Platz zum Warten. Im einfachen Modell mit einem einzelnen Reno-Datenstrom kann ein Puffer von etwa einem BDP die Verbindung unmittelbar nach einer Fensterhalbierung auslasten. Ein wesentlich größerer Puffer erhöht die Wartezeit, ohne die Übertragungsrate der Verbindung zu steigern.

Signalisiere Überlastung vor dem Überlauf

Aktives Warteschlangenmanagement, AQM, verwirft oder markiert Pakete frühzeitig, um Sendern zu signalisieren, dass sie ihre Last verringern sollen. Ein tatsächlicher Überlauf ist nicht mehr die einzige Möglichkeit, Überlastung anzuzeigen. RFC 7567 empfiehlt einen breiten Einsatz von AQM.

Random Early Detection, RED, beobachtet einen gleitenden Durchschnitt der Warteschlangenlänge. Unterhalb einer unteren Schwelle signalisiert RED nichts. Zwischen zwei Schwellen verwirft oder markiert es mit steigender Wahrscheinlichkeit. Oberhalb der oberen Schwelle signalisiert es bei jedem eintreffenden Paket. Die Mittelwertbildung verhindert, dass ein einzelner kurzer Verkehrsschub wie anhaltende Überlast aussieht. Es ist jedoch schwierig, Schwellen zu wählen, die bei unterschiedlichen Geschwindigkeiten und Lasten funktionieren.

Miss die Wartezeit direkt

CoDel, Controlled Delay, misst die Verweilzeit eines Pakets, also seine Zeit in der Warteschlange. Der Standardzielwert beträgt 5 ms und das Intervall 100 ms. Bleibt selbst die kleinste beobachtete Verweilzeit ein Intervall lang über dem Zielwert, liegt eine dauerhaft gefüllte Warteschlange vor. CoDel verwirft oder ECN-markiert dann Pakete und erhöht die Häufigkeit der Signale, solange die erhöhte Verzögerung anhält.

Das Minimum über ein Intervall ist entscheidend. Ein Verkehrsschub kann kurzzeitig eine hohe Verzögerung verursachen und kurz darauf abgebaut sein; eine Warteschlange, deren Verzögerung nie klein wird, erfordert ein Eingreifen. Dank der Verzögerungsmessung funktionieren die Standardeinstellungen von CoDel bei einem breiten Spektrum von Übertragungsraten.

FQ-CoDel kombiniert separate Warteschlangen pro Datenstrom mit CoDel. Durch die Trennung der Datenströme führt eine große Übertragung weniger leicht dazu, dass jedes kleine interaktive Paket hinter ihrem Rückstau warten muss.

Frühzeitige Signale können auch die globale Synchronisation verringern, bei der viele Datenströme gleichzeitig Pakete verlieren, gemeinsam ihre Rate halbieren und die Verbindung vorübergehend unterausgelastet lassen. Zufällig verteilte frühe Signale verteilen die Reaktionen über die Zeit. Bei ECN-fähigem Verkehr kann ein AQM seine Warnung durch eine Markierung senden und das Paket trotzdem zustellen.

Die explizite Überlastbenachrichtigung, ECN, ermöglicht einem Router, ein Paket zuzustellen und vor entstehender Überlastung zu warnen. Die Markierung verändert das Verhalten des Senders, ohne fehlende Daten zu erzeugen, die erneut übertragen werden müssen.

Lies den IP-Codepunkt

Das ECN-Feld besteht aus zwei Bits im IPv4-Type-of-Service-Byte beziehungsweise in der IPv6-Traffic-Class.

Beim klassischen TCP-Handshake nach RFC 3168 setzt das SYN des Clients ECE und CWR. Das SYN-ACK eines zustimmenden Servers setzt ECE. Nach der Aushandlung markiert klassisches TCP Datenpakete mit ECT(0).

Verfolge den Rückkopplungskreis

Ein AQM, das ein ECN-fähiges Paket als Überlastwarnung verwerfen würde, kann dessen Codepunkt auf CE ändern und es weiterleiten. Ein Not-ECT-Paket kann diese Warnung nicht tragen und wird verworfen, wenn das AQM ein Signal geben muss. Ein vollständig gefüllter Puffer verwirft weiterhin Pakete, auch ECN-fähige.

Der Empfänger meldet CE zurück, indem er in seinen Quittungen ECE, ECN-Echo, setzt. Er setzt ECE weiter, bis er vom Sender CWR, Congestion Window Reduced, erhält. Diese Flags melden und bestätigen die Rückmeldung; ihr Vorhandensein bedeutet nicht, dass Daten verloren gingen.

Beginne für klassisches ECN nach Reno-Art mit einem cwnd von 20 MSS. Nach Eingang von ECE verringert der Sender cwnd auf 10 MSS und setzt CWR im nächsten Segment mit neuen Daten. Der Empfänger beendet die Rückmeldung, sobald CWR eintrifft. Wiederholte Rückmeldungen aus demselben Fenster erfordern keine wiederholten Halbierungen. Die Warnung kehrt auf dem Quittungspfad zurück, sodass die Reaktion einer Rückmeldeverzögerung unterliegt.

ECN legt das Signal fest; der Überlastkontrollalgorithmus bestimmt die Verringerungsregel. Reno halbiert, während CUBIC bei einem ECN-Ereignis normalerweise 70 % beibehält. Beide Endpunkte und ein markierender Engpass müssen ECN unterstützen, damit dieser Kreis funktioniert.

Nutze den Anteil der Markierungen

DCTCP, Data Center TCP, nutzt häufige Markierungen in einer kontrollierten Umgebung. Es schätzt den Anteil markierter Bytes mit einem geglätteten Wert Alpha:

wobei M der kürzlich markierte Anteil ist. Manche Implementierungen verwenden für g den Wert 1/16. Das Fenster wird wie folgt verringert:

Bei einem Alpha von 0,2 wird aus einem Fenster von 100 der Wert 90; bei einem Alpha von 1 halbiert es sich. DCTCP benötigt eine passende Markierung und Rückmeldung. Werden DCTCP und klassisches TCP in einer gewöhnlichen Warteschlange gemischt, können unfaire Anteile entstehen.

L4S, die experimentelle Architektur in RFC 9330 bis 9332, überträgt eine verwandte skalierbare Reaktion auf Internetpfade. ECT(1) kennzeichnet skalierbaren Verkehr, und ein gekoppeltes AQM mit zwei Warteschlangen trennt ihn vom klassischen Verkehr und koordiniert zugleich deren Behandlung. Häufige Markierungen schon bei geringer Warteschlangenbildung zielen auf eine Warteschlangenverzögerung von etwa einer Millisekunde. ECT(1) allein garantiert diese Verzögerung nicht: Die Überlastkontrolle und das Verhalten des Engpasses vervollständigen den Entwurf.

CUBIC behebt Renos langsames Wachstum auf schnellen Pfaden über große Entfernungen. Sein Fenster folgt der seit einer überlastungsbedingten Verringerung verstrichenen Zeit und reagiert damit anders als bei einer festen Erhöhung um ein Segment pro RTT. RFC 9438 spezifiziert CUBIC; es ist die Standardeinstellung in wichtigen TCP-Implementierungen von Linux, Windows und Apple.

Merke dir den letzten Überlastungspunkt

Bei einem gewöhnlichen Verlust oder einem ECN-Überlastungsereignis speichert CUBIC sein Fenster als Wmax. Bei einem vollständig genutzten Fenster behält es mit dem Verringerungsfaktor 0,7 70 % der unterwegs befindlichen Datenmenge bei. Reno würde die Hälfte behalten. Der Ablauf des Wiederholungszeitlimits ist anders: CUBIC kehrt wie Reno zu einem Fenster von einem Segment und Slow Start zurück und legt seine Schwelle dabei mit dem CUBIC-Verringerungsfaktor fest.

Für die grundlegende kubische Phase nach einer Verringerung lautet das Zielfenster in Segmenten:

Die Zeit t wird in Sekunden angegeben. Beträgt das verringerte Fenster 0,7 Wmax, ist die Rückkehrzeit zum alten Spitzenwert:

Vollziehe die Kurve nach

Bei einem Wmax von 100 Segmenten beträgt das verringerte Fenster 70. Der Wert unter der Kubikwurzel ist 75, sodass K etwa 4,22 s beträgt. Nach einer Sekunde liegt die Kurve bei etwa 86,7 Segmenten, nach zwei Sekunden bei 95,6 und nach drei Sekunden bei 99,3. Sie erreicht 100 bei K.

Unterhalb des alten Spitzenwerts ist das Wachstum zunächst schnell und verlangsamt sich dann. Dieser konkave Bereich nähert sich vorsichtig einem Punkt, an dem zuvor Überlastung auftrat. Nahe der Spitze liegt ein relativ flaches Plateau. Darüber beschleunigt sich das Wachstum im konvexen Bereich, um möglicherweise neu verfügbare Kapazität zu erkunden. Nach sieben Sekunden erreicht die Beispielkurve etwa 108,6 Segmente.

Erkläre den RTT-Vorteil und seine Grenze

Reno benötigt 50 RTTs, um von 50 wieder auf 100 Segmente zu steigen: 5 s bei einer RTT von 100 ms und 10 s bei einer RTT von 200 ms. Die Rückkehrzeit der kubischen Kurve hängt vom gespeicherten Spitzenwert und der verstrichenen Zeit ab, sodass ihre Rückkehr nach 4,22 s nicht direkt von der Anzahl der Quittungen abhängt.

CUBIC berechnet außerdem eine Reno-freundliche Schätzung. Sie verwendet eine entsprechende AIMD-Erhöhung von etwa 0,53 Segmenten pro RTT bei einem Verringerungsfaktor von 0,7. CUBIC nutzt diese Schätzung, wenn sie über dem kubischen Zielwert liegt. Pfade mit kurzer RTT können sich daher früher erholen, als es die rein kubische Rückkehrzeit vorsieht. Zeitbasiertes Wachstum verringert eine wichtige Ursache der Bevorzugung bestimmter RTTs; es macht nicht jede tatsächliche Aufteilung RTT-unabhängig.

Passe den gespeicherten Spitzenwert an

Tritt Überlastung unterhalb des vorherigen Spitzenwerts erneut auf, senkt die schnelle Konvergenz von CUBIC den gespeicherten Wert Wmax. Ein neues Ereignis bei 90 Segmenten nach einer vorherigen Spitze von 100 ergibt:

Das unmittelbar verringerte Fenster beträgt 63 Segmente. Der gespeicherte Spitzenwert und das neue aktuelle Fenster haben unterschiedliche Aufgaben: Der eine gestaltet das zukünftige Wachstum, während das andere das aktuelle Senden begrenzt.

CUBIC bleibt verlustbasiert, mit ECN als alternativem Signal. Auf einem Pfad mit Tail Drop kann es eine dauerhaft gefüllte Warteschlange aufbauen. Schnellere Wiederherstellung und eine geringere gewöhnliche Verringerung verbessern die Nutzung von Pfaden mit großem BDP, aber keines von beiden garantiert für sich eine geringe Warteschlangenverzögerung.

Verlust ist nicht das einzige Zeichen eines überlasteten Pfades. Verzögerung kann wartende Daten anzeigen, während Zustellmessungen die verfügbare Bandbreite des Pfades schätzen lassen. Vegas und BBR nutzen diese Beobachtungen auf unterschiedliche Weise.

Schätze die wartenden Daten bei Vegas

Vegas vergleicht eine erwartete Rate auf Basis der minimalen Basis-RTT mit der tatsächlichen Rate auf Basis der gemessenen RTT. Ihre Differenz, multipliziert mit der Basis-RTT, schätzt die wartenden Daten des Datenstroms.

Bei einem cwnd von 50 Segmenten, einer Basis-RTT von 40 ms und einer gemessenen RTT von 50 ms beträgt die erwartete Zustellrate 1.250 Segmente/s und die tatsächliche 1.000 Segmente/s. Die Schätzung für die Warteschlange lautet:

Vegas wächst unterhalb einer unteren Schwelle und schrumpft oberhalb einer oberen Schwelle. Füllt verlustbasierter Verkehr die gemeinsam genutzte Warteschlange immer weiter, erkennt Vegas wiederholt Verzögerung und verringert seine Rate. Dadurch kann ihm ein kleiner Anteil bleiben.

Erstelle das zweiteilige Modell von BBR

BBR, Bottleneck Bandwidth and Round-trip propagation time, schätzt die Engpassbandbreite anhand der zuletzt gemessenen maximalen Zustellraten und die minimale RTT über ein Zeitfenster von 10 s. Ihr Produkt schätzt das BDP. Das ideale Ziel ist eine ausgelastete Verbindung mit etwa einem BDP an unterwegs befindlichen Daten und wenigen wartenden Daten.

Eine Bandbreitenschätzung von 50 Mbps und eine minimale RTT von 30 ms ergeben 1,5 Millionen Bit oder 187.500 Byte pro BDP. Ein typischer Überlastfensterfaktor von 2 begrenzt ausstehende Daten auf etwa 375.000 Byte. Die Pacing-Rate ist eine separate Steuergröße: Pacing-Faktor mal geschätzte Bandbreite. Eine Obergrenze erlaubt unterwegs befindliche Daten; sie verlangt nicht, dass der Sender mit der doppelten Bandbreite sendet.

Verfolge die Zustände von BBR Version 3

Der Wachstumstest von Startup prüft, ob die Zustellrate drei Runden lang um weniger als 25 % wächst. ProbeRTT wird höchstens etwa alle 5 s eingeplant. Auf dem Beispielpfad strebt ProbeBW in Up 62,5 Mbps und in Down 45 Mbps an. Diese Einzelheiten von Version 3 sind im BBR-Internet-Draft spezifiziert, nicht in einem veröffentlichten BBR-RFC.

Vergleiche Rückmeldungen und Vor- und Nachteile

Reno und CUBIC wachsen, bis Verlust oder ECN Überlastung signalisiert. BBR steuert das Pacing anhand eines Bandbreiten- und RTT-Modells. In Startup und ProbeBW Up baut es absichtlich kurzzeitig eine Warteschlange auf. „Modellbasiert“ bedeutet daher nicht „baut nie eine Warteschlange auf“.

BBR Version 1 ignorierte Verluste weitgehend. Version 3 nutzt starke Verluste von etwa 2 % in einer Runde, um das Überschreiten der Kapazität zu begrenzen und das Zusammenwirken mit anderen zu verbessern. Es kann auf langen Pfaden mit zufälligen Verlusten einen höheren Durchsatz halten, aber nicht vollständig erkennen, warum ein Paket verloren ging. Seine konkrete ECN-Reaktion bleibt im Entwurf offen; jede Verbindung, die ECN-Unterstützung angibt, muss auf CE als Überlastung reagieren. Puffergröße, RTT, Version und konkurrierende Algorithmen bleiben für die Fairness relevant.

Ein Protokoll verkrustet, wenn eingesetzte Geräte so stark von seiner bestehenden Form abhängen, dass Änderungen schwer einzuführen sind. Middleboxes untersuchen TCP-Header und können unbekannte Optionen oder Flags zurückweisen. Bei kernelbasierten Implementierungen wird neues Verhalten zudem durch Aktualisierungen des Betriebssystems verbreitet, häufig langsam.

Erkenne die Kosten, die QUIC adressiert

TCP hat sich durch SACK, ECN, Fensterskalierung und neue Überlastkontrollen weiterentwickelt. Dennoch ist seine Struktur für den Webverkehr weiterhin relevant. Eine herkömmliche neue TCP-Verbindung mit TLS benötigt den TCP-Handshake vor dem TLS-Handshake. Ihr einziger geordneter Bytestrom bedeutet außerdem, dass ein fehlendes Segment die Zustellung späterer Bytes blockiert, einschließlich der Daten für unabhängige Anfragen. Das ist Head-of-Line-Blocking auf Transportebene.

Adressen und Ports einer Verbindung können ein weiteres Hindernis schaffen, wenn ein Gerät zwischen Netzen wechselt. QUIC, standardisiert in RFC 9000, verändert diese Teile des Transportentwurfs und überträgt seine Pakete dabei über UDP. HTTP/3 läuft über QUIC.

Kombiniere die Handshakes

QUIC integriert TLS 1.3 in seinen Transport-Handshake. Bei einem einfachen Austausch mit 80 ms RTT, vernachlässigbarer Verarbeitung und ohne Verlust sendet eine neue TCP-Verbindung mit TLS 1.3 die Anfrage nach zwei RTTs und erhält die ersten Antwortbytes nach drei: 240 ms. Eine neue QUIC-Verbindung kann sie nach zwei RTTs erhalten: 160 ms.

Eine wiederaufgenommene QUIC-Verbindung kann frühe Anwendungsdaten bereits beim ersten Paketversand senden; dies heißt 0-RTT. Die erste Antwort kann dann nach einer RTT eintreffen, in diesem Beispiel nach 80 ms. Frühe Daten können erneut abgespielt werden, weshalb Anwendungen sie auf Aktionen beschränken, deren Wiederholung unbedenklich ist. Der Begriff 0-RTT beschreibt, wann das Senden beginnen kann, und keine sofortige Antwort.

Trenne Datenströme, aber nicht alle gemeinsamen Begrenzungen

QUIC überträgt unabhängige geordnete Byteströme. Enthält ein Paket Daten für Bild 1, blockiert sein Verlust nicht die Zustellung bereits empfangener Daten für die Bilder 2 und 3 in separaten Datenströmen. Ein Paket, das mehrere Datenströme überträgt, kann jeden davon betreffen. Alle Datenströme teilen sich weiterhin die Überlastkontrolle der Verbindung, sodass Verlust ihre insgesamt verfügbare Rate verringern kann.

QUIC stellt auf UDP-Basis eine zuverlässige Zustellung innerhalb der Datenströme bereit. Es bietet außerdem Flusskontrolle sowohl pro Datenstrom als auch pro Verbindung. UDP ist das Trägerprotokoll und kein Ersatz für diese Transportfunktionen.

Schütze veränderbare Einzelheiten

QUIC verschlüsselt Paketnutzlasten einschließlich aller Transport-Frames. Der Headerschutz deckt Paketnummern und einige Bits des ersten Bytes ab. Felder, die für Routing und Aushandlung benötigt werden, etwa Verbindungs-IDs und die Version, bleiben sichtbar. Das Verbergen veränderbarer Transportdetails gibt Middleboxes weniger Verhalten vor, von dem sie abhängig werden können.

Verbindungs-IDs identifizieren eine Verbindung unabhängig von den aktuellen IP-Adressen und Ports. Mithilfe der Pfadvalidierung kann eine Verbindung migrieren, wenn ein Mobiltelefon vom WLAN zum Mobilfunkzugang wechselt, ohne eine vollständig neue Verbindung zu beginnen.

QUIC ist gewöhnlich eine Bibliothek im Benutzerraum. Eine Anwendungsaktualisierung kann daher eine Verbesserung des Transportprotokolls bereitstellen, ohne auf Änderungen in jedem Betriebssystemkern zu warten. Diese Flexibilität überträgt der Anwendung zugleich die Verantwortung für korrekte Verlusterkennung, Sicherheit, Flusskontrolle und Überlastkontrolle.

QUIC verbessert, was ein Sender aus Quittungen erfahren kann, muss aber weiterhin eine Überlastung des Pfades vermeiden. RFC 9002 definiert die Verlusterkennung und eine standardmäßige Überlastkontrolle ähnlich NewReno. Implementierungen können andere geeignete Algorithmen verwenden, darunter CUBIC oder BBR.

Identifiziere jede Übertragung

Paketnummern steigen und wiederholen sich innerhalb eines Paketnummernraums nie. Erneut gesendete Daten werden in Frames innerhalb eines neuen Pakets mit neuer Nummer übertragen. Eine Quittung kann daher die Übertragung identifizieren, die angekommen ist. So wird die bei TCP bestehende Mehrdeutigkeit zwischen einem ursprünglichen Segment und seiner Übertragungswiederholung vermieden.

ACK-Frames melden empfangene Bereiche und die Quittungsverzögerung des Empfängers. Nach dem Handshake nutzt der Sender eine validierte und begrenzte Quittungsverzögerung, um RTT-Schätzungen anzupassen; er zieht nicht blind eine beliebige Verzögerung des Empfängers von jedem Messwert ab.

QUIC erklärt ein Paket für verloren, wenn ein Paket mit einer um mindestens drei höheren Paketnummer quittiert wurde, oder anhand seines Zeitschwellenwerts, sobald ein späteres Paket quittiert wurde. Der empfohlene Zeitschwellenwert beträgt das 9/8-Fache des größeren Werts aus der letzten und der geglätteten RTT. Ein Probe Timeout, PTO, sendet Testpakete, die Quittungen auslösen. Der Ablauf des PTO allein lässt cwnd nicht auf das Mindestfenster fallen.

Lege Fenstergrenzen in Byte fest

Für die maximale Datagrammgröße d lautet das Anfangsfenster nach RFC 9002:

Bei einem d von 1.200 Byte beträgt das Ergebnis 12.000 Byte. Bei einem d von 1.500 Byte sind es 14.720 Byte. Das minimale Überlastfenster beträgt zwei Datagramme maximaler Größe, sodass die Mindestwerte für diese Pfade jeweils 2.400 und 3.000 Byte betragen.

In der standardmäßigen Überlastkontrolle halbiert ein Verlust oder ein neues CE-Überlastsignal cwnd, begrenzt durch das Mindestfenster, und setzt ssthresh auf das verringerte Fenster. Eine Wiederherstellungsphase verhindert eine weitere Verringerung bei weiteren Verlusten von Paketen, die vor Beginn der Phase gesendet wurden. Die Quittung eines während der Wiederherstellung gesendeten Pakets beendet die Phase. Der Sender setzt dann das normale Wachstum fort.

Erkenne anhaltende Ausfälle

Anhaltende Überlastung ist ein stärkerer Hinweis als der einmalige Ablauf eines Zeitgebers. Sie setzt eine ausreichend lange Folge verlorener quittierungsauslösender Pakete voraus, ohne dass ein dazwischenliegendes Paket quittiert wurde, sowie einen vorherigen RTT-Messwert. Ihr Zeitschwellenwert lautet:

Bei 100 ms geglätteter RTT, 10 ms Schwankung, 25 ms maximaler Quittungsverzögerung und vernachlässigbarer Zeitgeberauflösung beträgt der Schwellenwert 495 ms. Das maßgebliche Verlustintervall muss diesen Wert überschreiten. Die Überlastkontrolle senkt cwnd dann auf zwei Datagramme, ihr Mindestfenster.

Halte Rückmeldung und zeitliche Steuerung nutzbar

QUIC-Quittungen können kumulative ECT(0)-, ECT(1)- und CE-Zähler melden. Nach der Validierung der ECN-Funktion auf dem Pfad behandelt der Sender einen erneuten Anstieg des CE-Zählers als Überlastungsereignis, ohne dass ein Paket verworfen werden muss.

Pacing verteilt Übertragungen über die Zeit. Ein vorgeschlagener Ansatz ist eine Rate von etwa dem 1,25-Fachen von cwnd dividiert durch die geglättete RTT; Begrenzungen von Verkehrsschüben können denselben Zweck erfüllen. Das Senden eines ganzen Fensters auf einmal erzeugt einen Verkehrsschub, selbst wenn die durchschnittliche Rate akzeptabel ist. Die Bereitstellung im Benutzerraum erleichtert die Auslieferung neuer Überlastkontrollen, aber jeder Protokollstapel muss die Bandbreite weiterhin verantwortungsvoll teilen.