Zusammenfassung

  • RACK erklärt eine ältere Übertragung erst dann für verloren, wenn später gesendete Daten bestätigt sind und die ältere Übertragung über eine geschätzte RTT plus begrenztes Umsortierungsfenster hinaus unbestätigt bleibt.
  • TLP sendet vor dem RTO höchstens eine kontrollierte Sonde, um neue Rückmeldung anzustoßen. Die Sonde ist eine Frage, kein Verlustbeweis; RACK erkennt, die Staukontrolle genehmigt die Wiederherstellung.

Drei Zeugen, die am Ende nicht erscheinen

Der klassische Fast Retransmit liest drei Duplikat-ACKs als Hinweis auf eine frühere Lücke. Das funktioniert, solange hinter der Lücke genügend Pakete ankommen, um den Empfänger wiederholt antworten zu lassen. Eine kurze Webantwort, ein anwendungsbegrenzter Strom oder ein Verlust am Fensterende hat diesen Nachlauf womöglich nicht. Der Sender wartet dann auf den Retransmission Timeout, der als verlässliche Rückfallebene absichtlich vorsichtig ist.

Selective Acknowledgment verbessert die Beschreibung des Empfangenen. RFC 2018 lässt den Empfänger Bytebereiche jenseits der kumulativen ACK-Grenze melden. RFC 6675 nutzt dieses SACK-Scoreboard für die Wiederherstellung, doch sein zentraler Schwellenwert zählt weiterhin diskontinuierliche SACK-Sequenzen oder Bytes oberhalb einer Lücke. Umsortierung, Duplikate und gebündelte ACKs können die Zählung verzerren. Eine Zahl im Sequenzraum misst nicht, wie lange eine bestimmte Sendung dem Pfad ausgesetzt war.

Recent ACKnowledgment, kurz RACK, verlegt die Folgerung auf die Sendezeit. RFC 8985 wurde von Yuchung Cheng, Neal Cardwell, Nandita Dukkipati und Priyaranjan Jha gemeinsam verfasst und im Februar 2021 als IETF-Standards-Track-Dokument veröffentlicht. Cardwells offizielle IETF- und Google-Research-Profile belegen Identität, Netzwerkforschung und Bezug zum Dokument. Sie belegen weder eine Einzelerfindung noch heutige Kontrolle über jede Implementierung.

Die spätere Zustellung eröffnet nur das Verfahren

RACK speichert für jedes ausstehende Segment den Zeitpunkt seiner jüngsten Übertragung, auch nach einer erneuten Sendung. Bestätigt ein ACK oder SACK Daten, die nach einem weiterhin unbestätigten Segment S gesendet wurden, steht die erste Prämisse fest: Der Pfad hat etwas zugestellt, das S zeitlich folgte.

S ist damit noch nicht verloren. Es muss zusätzlich mindestens die geschätzte RTT zuzüglich eines Umsortierungsfensters unbestätigt geblieben sein. Der RFC beschreibt dafür konzeptionelle Zeitgeber pro Segment, verlangt aber keine physische Timerflut. Eine Implementierung kann aus allen ausstehenden Daten den nächsten Ablaufzeitpunkt bestimmen und nur diesen verfolgen.

Die Zeitauflösung wird Teil der Funktionsfähigkeit. RFC 8985 fordert, die jüngste Übertragung jedes Segments feiner als ein Viertel der minimalen RTT zu erfassen. Vier oder acht zusätzliche Oktette pro Segment werden je nach Zeitdarstellung geschätzt. Das ist eine Implementierungseinordnung des RFC, keine universelle Speicherrechnung.

Ein ACK beweist lediglich, dass ein TCP-Bytebereich den Empfänger erreicht hat. Es erklärt nicht, warum S fehlt, lokalisiert keinen Stau, zertifiziert weder Pfad noch Gegenstelle und sagt nichts über die Verarbeitung in der Anwendung. Legitime Umsortierung, Funkverlust, Pfadwechsel und Stau können beim Sender ähnlich aussehen. RACK liefert eine handlungsfähige Transportfolgerung, keine Kausaldiagnose.

Unordnung erhält ein begrenztes Zeitbudget

Pakete können vertauscht ankommen, ohne verloren zu sein. Deshalb ergänzt RACK die RTT-Schwelle um ein Umsortierungsfenster. Unter den im RFC beschriebenen Bedingungen beginnt es bei null oder einem kleinen Anteil der minimalen RTT. Zeigt ein Duplicate SACK, dass eine Wiederholung unnötig war, erhält der Sender Belege für tiefere Umsortierung und kann das Fenster vergrößern. DSACK-basierte Anpassung wird empfohlen; die geglättete RTT soll die Obergrenze bilden.

Ein enges Fenster repariert echten Verlust früher, sendet aber ein nur verspätetes Original eher doppelt. Ein weites Fenster vermeidet Fehlentscheidungen, verlängert jedoch eine wirkliche Lücke. „Zeitbasiert“ bedeutet daher nicht „gewiss“. Die Restunsicherheit bekommt eine sichtbare, messbare und begrenzte Wartezeit.

Eine prüfbare Entscheidung enthält den letzten Sendezeitpunkt des verdächtigen Segments, den Sendezeitpunkt des später zugestellten Segments, das entscheidende ACK oder SACK, die RTT-Schätzung, das aktive Fenster und die DSACK-Evidenz für Änderungen. Ein Gesamtzähler namens RACK bewahrt das Urteil und verwirft seine Gründe.

Eine Sonde für den stillen Ausklang

Tail Loss Probe richtet sich auf den Bereich, in dem spätere Daten und damit ACK-Anstöße knapp werden. Der Probe Timeout liegt typischerweise ungefähr bei der doppelten geglätteten RTT, unter Berücksichtigung der RFC-Regeln zu Delayed ACK und RTO. TLP braucht eine frische RTT-Messung; mehr als eine ausstehende Sonde ist unzulässig.

Beim Ablauf sendet der Sender neue Daten, sofern sie verfügbar und durch das Congestion Window erlaubt sind. Andernfalls wiederholt er das ausstehende Segment mit der höchsten Sequenznummer. Beide Varianten sollen ein ACK hervorrufen, das den Zustand am Ende sichtbar macht. Eine Sonde darf ein volles Staufenster vorübergehend um ein Paket überschreiten, bleibt aber als Datenmenge verbucht und muss mit dem nächsten ACK verrechnet werden.

Die Sonde beweist keinen Verlust des Originals. Ihre Antwort kann die spätere Zustellung liefern, die RACK benötigt, oder zeigen, dass die Ursprungsdaten längst ankamen und nur die ACK-Dynamik ruhte. Geht auch die Sonde verloren, bleibt der RTO als letzte Sicherung. TLP erzeugt Beobachtbarkeit; RACK bewertet sie.

Ein Urteil ist noch keine Sendeerlaubnis

Auch ein von RACK verlorengegebenes Segment darf nicht beliebig retransmittiert werden. RFC 8985 verlangt, auf die Freigabe durch den Congestion-Control-Algorithmus zu warten. RFC 5681 beschreibt die klassischen Pflichten, RFC 6937 empfiehlt Proportional Rate Reduction für die Dosierung während der Erholung.

Diese Trennung verhindert, dass ein schnellerer Sensor zum aggressiveren Aktor wird. RACK erklärt die Beweislage für ausreichend; die Staukontrolle entscheidet, welche Reparaturlast das Netz aufnehmen darf. Selbst die eine Sonde über einem vollen Fenster ist eng begrenzt, ausdrücklich benannt und nicht aus der Buchhaltung gelöscht.

Auch der RTO nach RFC 6298 bleibt bestehen. Er wahrt Fortschritt, wenn feinere Signale keinen Schluss zulassen, und übernimmt den vorsichtigen Backoff. SACK beschreibt empfangene Bereiche, RACK bewertet Verlust in der Zeit, TLP erbittet Rückmeldung am Ende, die Staukontrolle regelt die Erholung und RTO fängt das verbleibende Schweigen auf.

Was auch eine genaue Uhr nicht beglaubigt

Eine spätere Zustellung bescheinigt nicht die Gesundheit des Pfades. Sie authentifiziert keine Gegenstelle, nennt keinen Stauort und beweist keinen Anwendungserfolg. Auch eine korrekte Verlustentscheidung bleibt eine Transportaussage aus senderseitig sichtbaren Signalen.

RFC 8985 übernimmt die bekannten SACK-Sicherheitsfragen und nennt einen engeren Vorteil gegen ACK Splitting: Die Bestätigung eines zusätzlichen Bytes verschiebt nicht den Sendezeitpunkt der jüngsten von RACK betrachteten Zustellung. Das begrenzt eine bestimmte Taktik, ist aber weder ACK-Authentisierung noch allgemeine Vertrauensgarantie.

RFC 9002 verwendet Zeitschwellen für die QUIC-Verlusterkennung und nennt RACK-TLP in seiner Entwicklungslinie. QUIC besitzt jedoch eigene Paketnummernräume, ACK-Regeln und Schnittstellen zur Staukontrolle. Verwandte Ideen machen Zustände, Konstanten und Befugnisse nicht identisch.

Eine historische Messung mit engem Geltungsbereich

Die Arbeit „Reducing Web Latency: the Virtue of Gentle Aggression“ von 2013, an der Cardwell mitwirkte, untersuchte eine Stichprobe von Google-Frontend-Verkehr. In dieser begrenzten Umgebung wurden 77 Prozent der beobachteten Verluste durch RTO statt Fast Recovery repariert. Die getestete Mechanismenkombination senkte die mittlere Latenz um 23 Prozent und die Latenz am 99. Perzentil um 47 Prozent.

Die Zahlen erklären, warum das stille Ende kurzer Transaktionen interessant war. Sie sind keine heutige Internetmessung, keine Aussage über Googles aktuellen Betrieb und kein Leistungsversprechen von RFC 8985. Belastbar bleibt die engere Einsicht: Kurzen Strömen gehen die späteren Pakete als Beweiserzeuger oft aus, bevor ihnen die Wartezeit ausgeht.

Quellen