Zusammenfassung

  • RFC 3742 bremst den TCP-Fensterzuwachs, sobald cwnd über max_ssthresh liegt, weil exponentieller Slow Start pro RTT Tausende Segmente hinzufügen kann.
  • Der verifizierte Erratum 236 korrigierte den Zuwachsbereich pro RTT: Im Beispiel sind 836 RTT bis 83.000 Pakete ein Mindestwert, keine exakte Dauer.

„Begrenzt“ bedeutete nicht „konstante Rate“. RFC 3742 war 2004 ein optionaler Experimental-Vorschlag für TCP-Verbindungen mit Congestion Windows von Tausenden maximalen Segmentgrößen. Bis max_ssthresh blieb es beim herkömmlichen Slow Start: ein MSS zusätzlich je eingehendem ACK. Darüber berechnete die Regel K = int(cwnd / (0.5 * max_ssthresh)) und addierte pro ACK ungefähr ein K-tel MSS. Der zusätzliche Parameter ersetzte ssthresh nicht; wurde ssthresh überschritten, endete weiterhin der Slow Start.

Die ursprüngliche Beschreibung in Abschnitt 2 klang eindeutiger als der Algorithmus. Sie sagte, der Zuwachs oberhalb von max_ssthresh liege pro RTT höchstens bei der Hälfte dieses Schwellenwerts. Die ACK-Regel mit ihrem stufenweise wechselnden K ergab jedoch einen Bereich. Der vom RFC Editor verifizierte Erratum 236 korrigierte die Invariante: Der Zuwachs beträgt höchstens max_ssthresh MSS je RTT und mindestens die Hälfte. Außerdem ersetzte er die einzelne Zeitformel durch eine Unter- und Obergrenze. Bei 100 MSS Schwellenwert und 83.000 Paketen als Ziel wurden aus den oft genannten 836 RTT „mindestens“ 836 RTT.

Das korrigiert die Beschreibung des Mechanismus, nicht den Congestion-Control-Algorithmus selbst. Der 2004 veröffentlichte RFC-Text bleibt unverändert; der Erratum ist ein eigener Datensatz und muss daneben gelesen werden. Die Korrektur erweitert die mögliche Spanne von Zuwachs und Dauer, macht aus ihren Endpunkten aber keine universell gemessenen Ergebnisse.

Die Begrenzung sollte nicht nur dem Sender helfen, sondern auch externe Effekte mindern. Ein großer Sprung während des Slow Starts konnte viele gleichzeitige Verluste, Retransmission Timeouts und den Rückfall auf ein kleines Congestion Window auslösen. Auch andere Flows am Engpass teilen sich Warteschlange und Verlustbudget. RFC 3742 nennt ein Beispiel mit 100 MSS und berichtet frühe Experimente mit einem Linux-2.4.16-Web100-Kernel. Das ist ein begrenzter historischer Befund: kein Beleg für heutige flächendeckende Nutzung, globalen Nutzen oder eine Garantie für eine bestimmte Warteschlangenlänge.

Spätere TCP-Spezifikationen nutzen andere Kontrollsignale. RFC 9438 empfiehlt für den Slow Start von CUBIC im Allgemeinen HyStart++ und führt Limited Slow-Start als experimentelle Alternative auf. RFC 9406 verwendet dagegen einen RTT-Anstieg als Hinweis zum Verlassen des Slow Starts und ergänzt eine konservative Phase, die einen verfrühten Ausstieg überprüft. Dieses Signal unterscheidet sich von RFC 3742s fensterabhängigem ACK-Zuwachs; die Verfahren sind nicht austauschbar.

Für Netzbetreiber ist der Erratum Anlass zu fragen, was eine hervorgehobene Zahl tatsächlich begrenzt. Ein Fensterzuwachs je RTT ist weder eine direkte Byte-Ratenobergrenze noch eine Warteschlangenmessung oder ein Fairnessnachweis für einen geteilten Pfad. Schwellenwert, ACK-Verhalten, Pacing, Puffer, RTT und konkurrierende Flows bestimmen die reale Wirkung. Die Korrektur macht die Unsicherheit im RFC sichtbarer, beseitigt sie aber nicht.

Quellen