Zusammenfassung

  • RFC 9959 erlaubt einem Sender, genutzte Pfadkapazität, minimale RTT, eine Remote-Endpoint-Identität und eine Lifetime aus einer Verbindung zu speichern und in einer späteren Verbindung vorsichtig einzusetzen.
  • Der Datensatz ist historische Evidenz, keine heutige Kapazität: Die neue Verbindung startet normal, reserviert den Zustand einmalig, erkundet den Pfad und darf höchstens auf die Hälfte des alten Fensters springen, gepaced nach der aktuellen RTT.
  • Verlust, ECN oder Pfadänderung führen in Safe Retreat: Der ungültige Datensatz wird gelöscht, das Fenster stark reduziert und unvalidierte Arbeit abgebaut, damit konkurrierende Flows ihren Anteil zurückgewinnen.

Der kritische Moment kommt nicht beim erfolgreichen Sprung, sondern beim ersten Verlust danach. Ein Sender hat auf Grundlage einer früheren Verbindung schneller gesendet, als Slow Start es zu diesem Zeitpunkt erlaubt hätte. Seine Pakete könnten andere aus dem Puffer gedrängt haben. Eine normale, langsame Korrektur würde den Irrtum weiter wirken lassen.

Genau deshalb heißt die letzte Phase nicht bloß Recovery, sondern Safe Retreat.

RFC 9959, im Mai 2026 als IETF Standards Track veröffentlicht, definiert Careful Resume für die Wiederverwendung von Congestion-Control-Parametern zwischen Verbindungen. Das Verfahren soll lange Hoch-BDP-Pfade schneller auslasten. Seine eigentliche Leistung besteht aber darin, historische Information als widerrufbare Hypothese zu behandeln: beobachten, befristen, einmalig reservieren, erkunden, begrenzt springen, mit Gegenwartsdaten validieren und bei Widerspruch zurückweichen.

Das gespeicherte Fenster ist eine Messung mit Datum

Eine etablierte Verbindung kann die tatsächlich in einer RTT genutzte Kapazität als saved_cwnd und die damals minimale RTT als saved_rtt speichern. Dazu kommen saved_remote_endpoint und Lifetime. Pro Remote Endpoint darf höchstens ein Satz bestehen; eine spätere Beobachtung soll ihn aktualisieren oder ersetzen. Eine Messung unter vier Initial Windows kann den Aufwand nicht rechtfertigen.

saved_cwnd bedeutet nicht Leitungsrate, gebuchte Bandbreite, freie Gegenwartskapazität oder gerechten Anteil. Es bedeutet, dass ein bestimmter Flow unter früheren Routing- und Lastbedingungen dieses Volumen erfolgreich nutzte.

RFC 2914 macht deutlich, warum diese Semantik eine Stabilitätsfrage ist. Congestion Control begrenzt die Externalität eines Senders am gemeinsamen Engpass. Der beschleunigte Dienst erhält den Zeitgewinn; fremde Flows tragen Queueing, Verlust und Starvation, wenn seine Erinnerung falsch ist.

Der Datensatz ist deshalb austauschbar, löschbar und vergänglich. Mehrere erfolgreiche Verbindungen häufen kein Kapazitätsguthaben an.

Eine Endpoint-ID ist kein Pfadbeweis

Der Remote Endpoint ist implementierungsabhängig. Er umfasst eine sendende Schnittstelle und ein Ziel, etwa eine Unicast- oder Anycast-Adresse, und kann DSCP enthalten. Mehr Merkmale verbessern die Trennung, vermindern aber Wiederverwendung.

Auch ein detaillierter Schlüssel zertifiziert keinen physischen Pfad. Anycast kann eine andere Serverfarm wählen, ECMP eine andere Route, NAT, Tunnel oder Mobilität einen anderen Engpass. Unveränderte Topologie schützt nicht vor neuen konkurrierenden Flows.

Reconnaissance kombiniert den Schlüssel mit aktuellen Signalen. Ein lokaler Pfadwechsel, abgelaufene Lifetime oder bereits reservierter Datensatz beendet Careful Resume. Liegt die aktuelle minimale RTT bei höchstens der Hälfte der gespeicherten, könnte ein halbes altes Fenster über die kürzere RTT eine höhere Rate erzeugen als beobachtet. Mehr als die zehnfache RTT gilt ebenfalls als Pfadänderung.

Ähnliche RTT beweist keine identische Queue. Die Prüfung entfernt grobe Widersprüche; sie erteilt noch keine Kapazitätsfreigabe.

Der schnelle Start beginnt langsam

Die neue Verbindung beginnt mit normaler Congestion Control. RFC 5681 liefert das klassische TCP-Verhalten; RFC 6928 den modernen Initial-Window-Kontext. saved_cwnd wird nicht in den ersten Flug kopiert.

In Reconnaissance führen Verlust, ECN-CE, geänderte Identität, Ablauf, unpassende RTT oder parallele Nutzung zum normalen Verfahren zurück. Erst wenn sämtliche Initialdaten ohne gemeldeten Stau bestätigt sind, darf Unvalidated beginnen.

Die Grenze lautet:

jump_cwnd ≤ Min(max_jump, saved_cwnd / 2)

Die Hälfte ist ein Maximum, keine Zusage. max_jump kann kleiner sein. Alle unvalidierten Pakete müssen nach der aktuellen RTT gepaced werden. PipeSize startet mit dem bereits genutzten Flight und wächst nur um neu bestätigte Daten.

Der Zustand bleibt kurz: Ein vollständig gesendeter unvalidierter Flug, der ACK des ersten unvalidierten Pakets oder mehr als eine RTT führen zur Validierung. Nutzt die Anwendung den Sprung nicht, bleibt der ungenutzte Teil nicht als Erlaubnis bestehen.

In Validating reagiert der normale Controller auf ACKs. Bis das letzte unvalidierte Paket staufrei bestätigt ist, kann Verlust den gesamten Versuch widerrufen.

Ein Cache-Eintrag darf nur einmal senden

Ein Satz gespeicherter Parameter darf nur von einer Verbindung verwendet werden. Innerhalb eines Prozesses genügt möglicherweise eine atomare Tabelle. Ein verteilter Dienst muss die Regel über Worker, Hosts, Retries, Failover und Partitionen durchsetzen.

Ein saved_cwnd von 200 erlaubt einer Verbindung höchstens 100, vorbehaltlich max_jump. Fünf unabhängige Leser erzeugen nicht fünf sichere Entscheidungen, sondern eine aggregierte Last von 500. Replikation für Verfügbarkeit darf keine Sendebefugnis replizieren.

RFC 9040 beschreibt die zeitliche Teilung von TCP-Control-Block-Information zwischen Verbindungen. Es zeigt Nutzen und Scope von Caches, wählt aber weder die RFC-9959-Lifetime noch eine verteilte Sperre. Ohne sichere Koordination bleibt normale Congestion Control.

Safe Retreat löscht die falsche Annahme

Nach Verlust, ECN-CE oder Pfadänderung entfernt Safe Retreat zuerst die gespeicherten Parameter. Spätere Verbindungen dürfen denselben Fehler nicht wiederholen. CWND sinkt auf höchstens PipeSize / 2; Recovery arbeitet mit diesem kleineren Fenster; während unvalidierte Pakete abfließen, darf CWND nicht wachsen. Beim Austritt liegt ssthresh höchstens bei PipeSize × Beta, standardmäßig mit Beta 0,5.

RFC 9937 definiert Proportional Rate Reduction für die schrittweise Annäherung an ein vom Controller gesetztes Ziel. RFC 9959 erklärt PRR hier für ungeeignet, wenn der historische Sprung erheblichen Overshoot ausgelöst haben kann. RFC 9438 beschreibt CUBIC und dessen übliches Beta 0,7; die spezielle Retreat-Pflicht bleibt bestehen.

Rate-basierte Controller wie BBR können eine äquivalente Bottleneck-Bandwidth-Beobachtung speichern. Auch sie müssen nach einem fehlgeschlagenen Versuch Raum abgeben. Persistent Congestion oder TCP-RTO beendet Careful Resume. Späte ACKs korrigieren Buchhaltung, nicht die frühere Entscheidung.

Lifetime verteilt Unsicherheit

RFC 9959 legt keine universelle Dauer fest. Dynamische Pfade sprechen für Minuten; stabile, wenig geteilte Pfade können Stunden rechtfertigen. Je mehr Sender einen Engpass teilen, desto größer das Risiko wiederholter Überlast und desto kürzer sollte die Lifetime sein. Konfigurationsänderungen brauchen einen Flush.

Längere Lifetime erhöht Cache-Treffer und das Alterungsfenster. Breitere Keys erhöhen Wiederverwendung und falsche Gleichsetzung. Größeres max_jump erhöht Best-Case-Gewinn und Fehlerkosten. Der Dienst sieht seine Completion Time, nicht automatisch die Warteschlange anderer.

RFC 7661 verwaltet ein nicht validiertes CWND innerhalb einer anwendungsbegrenzten laufenden Verbindung und empfiehlt höchstens fünf Minuten NVP. RFC 9959 lässt eine neue Verbindung auf die Erinnerung einer alten zugreifen. Beide begrenzen ungenutzte Autorität, aber auf verschiedenen Zeitachsen.

RFC 4782 bildet den Kontrast: Quick-Start bat Router um Zustimmung zu einer Rate. Careful Resume erhält keine Reservierung und keine Pfadgenehmigung. Der Endpoint vermutet und prüft.

Empfänger und Anwendung begrenzen weiterhin

Der Empfänger kann einen Schnittstellenwechsel, Hardwaregrenzen, einen kurzen Transfer oder künftigen Kapazitätsbedarf kennen. RFC 9959 lässt Transportmechanismen eine Präferenz für Aktivierung oder Hemmung ausdrücken, definiert aber kein universelles Signal.

CWND ist nur eine Schranke. Das TCP-Empfangsfenster aus RFC 9293, QUIC-Flow-Control und Anti-Amplification aus RFC 9000, oder fehlende Anwendungsdaten können vorher begrenzen. Eine QUIC-Verbindung kann bei Migration ihre Identität behalten, aber nicht den Congestion-Zustand des alten Pfades.

RFC 9002 liefert QUIC-IW, Pacing, Verlust und Persistent Congestion. RFC 8085 erweitert die Stauverantwortung auf UDP-Anwendungen und -Transporte. Erinnerung ist keine Ausnahme vom gemeinsamen Schutz.

Nur die ausgeführte Kette ist prüfbar

Heng Lus Running-Code-Primat verlangt Cache-Key, Alter, alte/aktuelle RTT, Lifetime, Einmal-Lease, Initialflug, Sprung, Pacing, PipeSize, ACK/Verlust/ECN, Übergänge, Löschung und Endfenster. Ein Feature-Flag beweist nichts davon.

Sein Prinzip von minimaler Anfangsspezifikation und lokaler Zukunftsentscheidung passt zur Trennung: Der RFC setzt Sicherheitsinvarianten; der Betreiber wählt Remote Endpoint, Lifetime, max_jump, Cache, Empfängersignal und Scope und trägt die Haftung.

Die Realitätsebenen trennen gespeicherten Eintrag, scheinbar ähnlichen Pfad, unvalidierten Zustand, bestätigte Lieferung und Nutzen ohne Fremdschaden. Keine Ebene beweist automatisch die nächste.