Zusammenfassung

  • Ein kumulatives ACK beweist, dass die Empfangsgrenze über bestimmte Bytes hinausging; nach einer Wiederholung verrät es nicht, welche Sendeinstanz die Bytes lieferte.
  • Karn schließt die mehrdeutige RTT-Probe aus, während exponentieller Backoff einen konservativen RTO erhält, bis neue Daten ohne Wiederholung bestätigt werden.
  • TCP-Timestamps können Instanzen unter engen Regeln unterscheiden, machen aber nicht jedes ACK zur gültigen Probe und den Transport nicht zum Beleg eines Anwendungsergebnisses.

Eine Antwort mit zwei möglichen Startzeiten

Ein Sender überträgt die Bytes 7000 bis 7999 und startet den Retransmission Timer. Kein ACK trifft vor Ablauf ein, deshalb verlässt derselbe Sequenzraum den Host erneut. Danach meldet ein ACK als nächstes erwartetes Byte 8000.

Vielleicht war das Original nur verspätet. Dann ergibt die Messung ab der Wiederholung eine zu kurze RTT. Vielleicht ging das Original verloren und nur die zweite Instanz traf ein. Dann enthält die Messung ab der ersten Sendung die gesamte Timeout-Wartezeit und ist zu lang.

Alle Zeitstempel können technisch exakt sein. Es fehlt dennoch die kausale Paarung. Das kumulative ACK beschreibt den Zustand eines Bytestroms, nicht die Identität des physischen Pakets, das die Zustandsänderung bewirkte.

Für andere Entscheidungen bleibt das ACK vollwertig. Der Sender kann SND.UNA vorrücken, bestätigte Daten freigeben und im Rahmen seiner Fenster weiterarbeiten. Empfangsfortschritt und Laufzeitmessung sind zwei Berechtigungen. Eine Nachricht kann die erste besitzen und die zweite verlieren.

Anpassung brauchte eine Zulassungsregel

RFC 793 verlangte bereits eine dynamisch bestimmte Wiederholungsfrist. Ein Internetwork verbindet Pfade mit verschiedenen und veränderlichen Verzögerungen. TCP sollte Round-Trip Times messen, glätten und daraus seine Wartezeit ableiten.

Der Regelkreis funktioniert jedoch nur mit bedeutungsstabilen Eingaben. Senden, ACK empfangen, Schätzung aktualisieren und den nächsten Timer stellen klingt eindeutig, solange es nur eine Sendung gab. Nach einer Wiederholung definiert der Rückkehrzeitpunkt allein kein Intervall mehr.

Eine falsche Zuordnung kann sich verstärken. War das Original langsam und wird das ACK der jüngeren Kopie zugerechnet, erscheint die RTT zu klein. Der nächste RTO läuft früher ab, erzeugt unnötige Wiederholungen und damit weitere ACKs mit zwei möglichen Ursachen. Der Zeitmesser produziert die Lage, aus der er noch aggressiveres Verhalten ableitet.

RFC 1122 bezeichnete die in RFC 793 vorgeschlagene Berechnung als unzureichend. Er machte Jacobsons und Karns Algorithmen verpflichtend. Jacobson berücksichtigt die RTT-Variation. Karn entscheidet über die Zulässigkeit einer Probe. Die Güte der Formel ersetzt nicht die Herkunft ihrer Eingabe.

Karn machte Unwissen ausführbar

Die Kernregel lautet: Von einem wiederholten Segment wird keine RTT-Probe genommen. Sobald mehrere Sendeinstanzen denselben Sequenzraum abdecken, kann ein normales ACK sie nicht auseinanderhalten. Die Auswahl des bequemsten Startzeitpunkts stellt die fehlende Kennung nicht wieder her.

TCP ignoriert das ACK deswegen nicht. Der Zustandsautomat schreitet voran, Bytes gelten als bestätigt und neue Daten dürfen folgen. Nur SRTT und RTTVAR werden aus diesem Vorgang nicht so aktualisiert, als sei seine Ursache bekannt.

Damit bleibt Unsicherheit lokal. Sie blockiert nicht den gesamten Datenfluss und wird zugleich nicht in einer Durchschnittszahl versteckt. Das ist eine allgemeine Evidenzgrenze: Eine Beobachtung kann für einen Zweck entscheidend und für einen anderen unzulässig sein.

Der Verzicht kostet Aktualität. Gerade in einer Phase mit Verlust oder Verzögerung fehlen neue RTT-Werte. Eine kontaminierte Zahl schließt die Lücke aber nicht. Sie verschiebt sie in künftige Entscheidungen und entfernt den sichtbaren Hinweis, dass die Herkunft unbekannt war.

Backoff trug die Unsicherheit weiter

RFC 1122 verlangte zusätzlich exponentiellen Backoff für aufeinanderfolgende RTOs. RFC 2988 und sein Nachfolger RFC 6298 kodifizierten SRTT, RTTVAR und RTO. Beim Ablauf wird das älteste unbestätigte Segment erneut gesendet und RTO verdoppelt.

Der Backoff schützt einen Pfad, der keine rechtzeitige Rückmeldung liefert, vor immer schnellerer Wiederholung. Zusammen mit Karn hält er außerdem die Messunsicherheit im Verhalten fest. Das mehrdeutige ACK darf den bereits vergrößerten Timer nicht sofort auf einen optimistischen Wert zurücksetzen.

Nach einer neuen gültigen RTT-Probe kann RTO wieder sinken. Üblicherweise müssen dafür neue Daten gesendet und ohne Wiederholung bestätigt werden. Nicht bloß verstrichene Zeit bereinigt die Schätzung, sondern ein neues Paar mit identifizierbarem Anfang.

RFC 6298 erlaubt konservativere Implementierungen, verbietet aber aggressivere. Zu langes Warten kostet hauptsächlich eine Verbindung Zeit. Zu frühes Wiederholen fügt einem gemeinsam genutzten Pfad Last hinzu, während dessen fehlende Rückmeldung gerade Vorsicht verlangt.

Das Dokument von 2011 senkte zugleich den allgemeinen anfänglichen RTO von drei auf eine Sekunde und definierte eine Rückkehr zu drei Sekunden nach Verlust eines SYN oder dessen ACK. Parameter können mit neuer Evidenz revidiert werden; die kausale Zulassungsregel hängt nicht an einem festen Sekundenwert.

ACKs führen Buch über Bytes, nicht über Datagramme

Die Mehrdeutigkeit folgt aus der TCP-Abstraktion. Sequenznummern bezeichnen Positionen im Bytestrom. Eine Wiederholung kann denselben Bereich mit anderer Segmentierung senden. Empfänger dürfen ACKs verzögern, mehrere Ankünfte zusammen bestätigen und Duplikate entfernen.

Das kumulative ACK nennt das nächste erwartete Byte. Es gibt keine unveränderliche Paket-ID zurück. Eine vollständige Zuordnungsbuchhaltung beim Empfänger hätte zusätzlichen Zustand und eine größere gemeinsame Semantik verlangt.

TCP wählte einen kleineren Vertrag. Der Empfänger berichtet die Stromgrenze. Der Sender kennt seine eigenen Wiederholungen und prüft, ob eine Zeitprobe eindeutig ist. Entscheidungsbefugnis und lokale Information liegen so am selben Ort.

Auch Paketmitschnitte dürfen diese Grenze nicht verdecken. Ein ACK direkt nach einer Wiederholung kann vom verspäteten Original ausgelöst worden sein. Zeitliche Nachbarschaft liefert eine Hypothese, keinen Protokollbeweis. Ohne korrekt ausgehandelte Zusatzinformation bleiben mehrere Ursachen möglich.

Das ACK beweist ebenso wenig, dass der entfernte Prozess las, ein Datensatz dauerhaft geschrieben oder eine Transaktion abgeschlossen wurde. Der Transport besitzt seine Sequenzgrenze. Ein Anwendungsergebnis braucht einen Beleg des Systems, das dieses Ergebnis besitzt.

Timestamps ergänzten eine begrenzte Instanzkennung

RFC 6298 nennt die Ausnahme: Wenn die TCP-Timestamp-Option die Instanzmehrdeutigkeit entfernt, darf auch nach einer Wiederholung gemessen werden. RFC 7323 beschreibt TSval in Segmenten und TSecr in zurückkehrenden Segmenten.

Wird der Wert der tatsächlich empfangenen Instanz zurückgegeben, kann der Sender die Antwort mit einer bestimmten Sendeuhr verbinden. Die fehlende Kennung stammt dann aus der Option, nicht aus einer nachträglichen Erweiterung der ACK-Bedeutung.

Ein vorhandener Timestamp macht dennoch nicht jede Subtraktion gültig. RFC 7323 trennt das Übertragen der Werte von ihrer Verwendung für RTO. Nur eine Rückkehr, die den linken Rand des Sendefensters verschiebt, soll den Durchschnitt aktualisieren. Delayed ACKs, Sequenzlücken, Umordnung und die Auswahl des zurückgegebenen TSval beeinflussen die Probe.

Viele Messwerte erfordern eine weitere Entscheidung. Die Gewichtung in RFC 6298 nahm ungefähr eine Probe pro RTT an. Werden bei jedem Paket dieselben Koeffizienten angewandt, kann der Schätzer seine Pfadhistorie zu schnell verlieren und bei Schwankungen über mehrere RTTs falsche Wiederholungen fördern.

TSval ist außerdem keine beglaubigte Weltzeit. Eine ungefähr proportional fortschreitende lokale Uhr und ein Echo genügen für die Differenz. Die Option bestätigt weder Identität noch zivile Synchronisation oder Anwendungserfolg.

Modernes TCP behielt die negative Pflicht

RFC 9293, die heutige TCP-Basisspezifikation, verlangt weiterhin die Berechnung nach RFC 6298 einschließlich Karn. Exponentieller RTO-Backoff bleibt Teil des grundlegenden Stabilitätsverhaltens.

Die Regel überdauerte, weil ihr Grund nicht von Bandbreite oder Fenstergröße abhängt. Zwei Übertragungen desselben Sequenzraums und ein kumulatives ACK ergeben kein eindeutiges Zeitintervall.

Neuere Verlustmechanismen können zusätzliche Signale nutzen und Zeiten ohne Probe verkürzen. Sie machen einen weiterhin unbekannten Startpunkt nicht wahr. Der Wunsch nach einer aktuellen Anzeige ist kein Beleg dafür, dass eine neue Messung existiert.

Auch die Spezifikationsstruktur wahrt Zuständigkeiten. Basis-TCP verweist für den Timer auf ein Fach-RFC. RTO steht mit Congestion Control in Beziehung, ist aber nicht das Congestion Window. Timestamp liefert Instanzinformation, übernimmt jedoch kein Urteil über die Anwendung.

Eine Lücke kann die ehrlichste Messung sein

Dashboards bevorzugen lückenlose Linien. Bibliotheken möchten einen einzigen aktuellen RTT-Wert. Fehlt eine zulässige Probe, liegt es nahe, den alten Wert fortzuschreiben oder die zeitlich nächste Sendung auszuwählen.

Karn definiert einen besseren Zustand: In dieser Wiederholungsphase ist eine gewöhnliche RTT nicht messbar. Die Lücke beschreibt Evidenzqualität. Wird sie mit einer Zahl gefüllt, verschwindet die Tatsache der zwei möglichen Ursachen.

Prüfbare Telemetrie bewahrt Originalzeit, Wiederholungsnummer, RTO vor und nach Backoff, ACK-Fortschritt, Timestamp-Aushandlung, verwendetes TSecr und die erste spätere saubere Probe. Nur ein Endmittelwert kann Pfadwechsel und erfundene Zuordnung nicht unterscheiden.

Das Design verbindet drei Schritte: den gültigen Fortschritt akzeptieren, die unzulässige Zeitzuordnung ablehnen und Unsicherheit durch Backoff erhalten. Protokollstärke besteht nicht darin, jeder sparsamen Nachricht mehr Bedeutung abzuringen. Sie besteht auch darin, unbeantwortete Fragen als Zustand zu bewahren.

Quellen und Evidenzgrenzen

RFC 793 liefert den frühen adaptiven Timer. RFC 1122 dokumentiert die Unzulänglichkeit und fordert Karn, Jacobson sowie Backoff. RFC 2988 und RFC 6298 kodifizieren RTO und Probenausschluss. RFC 7323 begrenzt die Timestamp-Disambiguierung. RFC 9293 erhält die Pflicht in modernem TCP.

Diese Quellen sind Spezifikationen, keine Erhebung heutiger Stacks, Optionen oder Wiederholungsraten. Sie ordnen nicht jedes Timeout Congestion oder Angriff zu, setzen RTO nicht mit dem Congestion Window gleich und machen Transport-RTT nicht zum Beleg eines Anwendungsergebnisses.