Zusammenfassung

  • Der Eifel-Erkennungsalgorithmus aus RFC 3522 speichert den Zeitstempel der ersten, die Recovery auslösenden Neuübertragung. Ein älterer Echo-Wert im ersten zulässigen ACK zeigt, dass die ursprüngliche Sendung bestätigt wurde und die Recovery unnötig war.
  • Diese Feststellung rekonstruiert weder Staukontrollfenster noch Slow-Start-Schwelle, RTO oder Anwendungserfolg. Belastbare Nachweise müssen Auslöser, Messwert, Mehrdeutigkeitsausgänge, gespeicherten Vorzustand, Reaktion und beobachtetes Ergebnis auseinanderhalten.

Automatisierte Regelkreise müssen handeln, bevor ihre Beweislage vollständig ist. Ein Timer läuft ab oder die Zahl doppelter ACKs erreicht ihren Grenzwert. TCP sendet erneut und reduziert sein Arbeitsfenster. Der spätere ACK kann zeigen, dass die ursprüngliche Annahme falsch war; er kann die bereits erfolgten Schreibvorgänge nicht ungeschehen machen.

RFC 3522 erschien im April 2003 mit dem Status Experimental, nicht als Internet Standard. Die Spezifikation nutzt TCP Timestamps gegen retransmission ambiguity. Eine ACK-Nummer besagt, welche Bytes angekommen sind, nicht aber, ob das Original oder seine Wiederholung die Bestätigung ausgelöst hat. Ein zurückgespiegelter Zeitstempel kann diese Historie unterscheiden.

Die Zuständigkeit ist eng gezogen. Der Schritt (RESP) tut ausdrücklich nichts. Erkennung liefert eine Aussage über die Vergangenheit; Reaktion verändert die Gegenwart. Wer beides als ein Ergebnis meldet, unterschlägt den Übergang.

Der erste zulässige ACK ist ein nachträglicher Zeuge

Beim Eintritt in eine Recovery-Episode setzt der Sender SpuriousRecovery auf false. In RetransmitTS speichert er den Timestamp Value der Timeout-Neuübertragung oder der fast retransmit, die den Vorgang gestartet hat. Spätere Wiederholungen dürfen diesen Wert nicht überschreiben.

Dann wartet er auf den ersten zulässigen ACK, der zuvor unbestätigte Daten abdeckt. Ist dessen Timestamp Echo Reply strikt kleiner als RetransmitTS, muss der ACK auf eine ältere Originalsendung reagieren. Nach den weiteren Vorsichtsprüfungen darf der Sender die Recovery als spurious einstufen.

Das erste Ereignis ist wichtig. Nach einem falschen Timeout können verspätete Original-ACKs eine go-back-N-artige Kette weiterer Neuübertragungen anstoßen. Frühe Erkennung begrenzt den Schaden, solange die Kette noch läuft.

Sie bleibt rückblickend. Auslöser, Fensteränderung und erste Kopie liegen zeitlich vor dem Zeugen. Ein Audit muss diese Reihenfolge erhalten und darf das spätere Urteil nicht an die Stelle des tatsächlichen Verlaufs setzen.

Gleiche Oberfläche, verschiedene Ursachen

Ein plötzlicher Laufzeitanstieg kann den RTO vor dem ACK ablaufen lassen. Paketumordnung kann genügend doppelte ACKs erzeugen. Doppelte Daten oder Bestätigungen können dasselbe sichtbare Muster hervorrufen.

Der ältere Echo-Wert beantwortet nur, ob die konkrete Recovery nötig war. Er beweist weder Umordnung noch einen Funkwechsel, misst keine Überlastung und ordnet die Ursache keiner Netzdomäne zu.

Auch die Folgen unterscheiden sich. Eine falsche fast retransmit erzeugt oft eine nutzlose Kopie und halbiert das Fenster. Ein falscher Timeout kann Slow Start auslösen und weitere Kopien produzieren, sobald verzögerte Bestätigungen der Originale eintreffen.

RFC 3522 trennt zudem den fast timeout ab. Ging das Segment tatsächlich verloren und war nur der Timer schneller als der Duplicate-ACK-Pfad, war die Recovery berechtigt. Ein Rennen zwischen Auslösern ist kein Beweis für einen Fehlalarm.

Gleichheit ist keine positive Evidenz

Der Basistest verlangt „kleiner“, nicht „kleiner oder gleich“. Bei grober Timestamp-Uhr oder sehr kurzem Abstand können Original und Neuübertragung denselben Wert tragen. Dann erklärt der RFC die Recovery konservativ nicht für spurious.

Damit geht möglicherweise eine Optimierung verloren, doch ein ununterscheidbares Signal wird nicht zur Gewissheit hochgestuft. Der Vergleichsoperator ist Teil der Beweisnorm.

Der Beleg sollte beide Rohwerte, die Granularität der Uhr, den Operator und den durchlaufenen Zweig enthalten. „Eifel geprüft“ verrät nicht, ob das Resultat positiv, negativ oder unentscheidbar war.

Der Verlust aller ACKs sieht gefährlich ähnlich aus

Das älteste ausstehende Segment kann den Empfänger erreichen, während sämtliche ACKs des Flights auf dem Rückweg verloren gehen. Der Sender muss seinen Timer ablaufen lassen. Die Kopie ist aus Sicht der bereits gelieferten Bytes überflüssig, doch der Timeout war unvermeidbar; eine Fenstersenkung kann auf Stau im ACK-Pfad angemessen reagieren.

Trifft das Duplikat ein, kann ein Empfänger nach den historischen Timestamp-Regeln den Marker des letzten geordneten Originals zurückgeben. Er ist kleiner als der Marker der Wiederholung und sieht genau wie der positive Eifel-Fall aus.

Schritt 5 berücksichtigt DSACK-Fähigkeit und die Frage, ob der ACK alle offenen Daten umfasst. Im kritischen Fall beendet er den Ablauf, statt einen Rollback nahezulegen. Der Algorithmus ist deshalb mehr als echo < retransmit; auch konservative Abbrüche sind Ergebnisse.

Wer nur den abschließenden Wahrheitswert speichert, verliert die Begründung für eine erlaubte oder verweigerte Reaktion.

Ein Empfänger kann überzeugende Beweise erfinden

Der Empfänger kontrolliert den Echo-Wert und könnte einen alten Timestamp vortäuschen. Eine notwendige Neuübertragung sähe dann unnötig aus. RFC 3522 beschreibt dafür eine sichere Variante: Der Sender speichert die Timestamps ausstehender Originale und akzeptiert nur die exakte Übereinstimmung mit dem zugehörigen Originalwert.

Die stärkere Bindung kostet Zustand. Sie ist empfindlicher gegenüber ACK-Verlust und -Umordnung, weil sie auf die konkrete Bestätigung des Originals angewiesen ist. Eine grobe Uhr erleichtert außerdem das Erraten fehlender Werte.

Sicherheit folgt nicht aus dem Etikett „Timestamps aktiv“. Sie hängt davon ab, was der Sender bewahrt, wie fein der Marker ist, was der Empfänger wissen kann und wie fehlende Evidenz behandelt wird.

Eine Diagnose kann nicht gespeicherten Zustand nicht rekonstruieren

Im RFC bedeutet (RESP), nichts zu tun. Genannt werden mögliche Ziele — Staukontrollzustand wiederherstellen, unnötige go-back-N-Übertragungen stoppen, Duplicate-ACK-Schwellen oder RTT-Schätzer anpassen —, doch sie liegen außerhalb des Erkennungsalgorithmus.

RFC 4015 spezifiziert später die Eifel-Reaktion. Die Trennung ist notwendig, weil Wiederherstellung Vorbereitung verlangt. Wer ein früheres Congestion Window oder ssthresh zurücksetzen will, muss dessen Wert vorher gesichert haben. Aus der Diagnose „spurious“ lässt sich ein überschriebener Zahlenwert nicht ableiten.

Auch die Reichweite des Rollbacks braucht eine Grenze. Eine bestimmte Kopie kann überflüssig gewesen sein, während ein anderes Segment desselben Flights wirklich fehlte. Die DSACK-Erörterung in RFC 3708 beschreibt diesen Mischfall. Der Freispruch einer Neuübertragung entkräftet nicht jede Stauinformation der Episode.

Der Detektor darf das Ereignis klassifizieren, das seine Evidenz abdeckt. Er erhält dadurch keine Vollmacht über alle Variablen des umfassenderen Regelkreises.

Späterer Erfolg löscht den Eingriff nicht

Nach der Erkennung kann ein Responder neue Daten freigeben, eine RTO-Schätzung ändern oder ein gespeichertes Fenster einsetzen. Jede Änderung braucht einen eigenen Beleg: Zustand vor dem Trigger, Zustand danach, Detektor-Ausgabe, Reaktionsregel, wiederhergestellte Felder und nachfolgende Anpassungen.

Anschließend muss das Netz den Byte-Strom weiterhin zustellen. Ein vergrößertes Fenster beweist weder das Ende der Umordnung noch stabile Kapazität oder eine abgeschlossene Anwendungstransaktion. Spätere Arbeiten wie TCP Roadmap, RACK-TLP und CUBIC bewahren die Trennung zwischen der Erkennung falscher Verlustsignale und einer sicheren Antwort auf ein veränderliches Netz.

Der letzte Nachweis richtet sich nach dem Versprechen. Für Byte-Lieferung sind bestätigte Bereiche maßgeblich, für Latenz ein gemessenes Intervall, für eine Transaktion ein authentischer Anwendungsbeleg. Ein Timestamp-Echo kann diese Bedeutungen nicht übernehmen.

Ein Beleg für reversible Verlustbehandlung

Erfassen Sie Aushandlung und Taktung der Timestamps, Byte-Bereich und Marker des Originals, Verlustauslöser, Duplicate-ACK-Zahl oder Timerzustand sowie sämtliche Staukontrollwerte vor dem Trigger.

Binden Sie die erste Neuübertragung an ihr unveränderliches RetransmitTS. Bewahren Sie ersten zulässigen ACK, bestätigten Bereich, Timestamp Echo Reply, DSACK-Blöcke und die genaue Entscheidung aus Schritt 5. Vermerken Sie Basis- oder Sicherheitsvariante.

Für die Reaktion gehören Algorithmus und Version, gespeicherte und wiederhergestellte Variablen, bewusst beibehaltene Werte und Begründung in die Kette. Korrelieren Sie späteren echten Verlust, Umordnung, Neuübertragung und Timeränderung. Schließen Sie mit beobachteter Lieferung und Anwendungsergebnis.

Ein aggregierter Zähler für spurious retransmissions zeigt Trends, kann aber einen strittigen Rollback nicht rekonstruieren. Der Ereignisbeleg muss Neustart, Telemetrie-Sampling und Versionswechsel überstehen.

Evidenzgrenze

Dieser Artikel identifiziert keine TCP-Implementierung, kein Betriebssystem, keinen Anbieter, Betreiber, Zugangsnetzpfad, Empfänger, Nutzer, Flow, Vorfall oder Einsatz. Er behauptet keine aktuelle Einführung, Timestamp-Nutzung, Umordnung, Verlustrate, Leistung, Batteriewirkung, Sicherheit oder Geschäftswirkung.

RFC 3522 wird als Experimental-Dokument vom April 2003 behandelt, nicht als Internet Standard. RFC 4015, RFC 5681, RFC 5682, RFC 6298 und RFC 7323 behalten eigenen Status und Umfang. RFC 9438, RFC 8985 und RFC 9002 dienen als spätere Vergleiche, nicht als Nachweis einer RFC-3522-Implementierung.

Heng Lus Texte über Autorität und laufenden Code sind offengelegte redaktionelle Perspektiven. Sie helfen, formales Signal, Betriebszustand und beobachtetes Ergebnis zu trennen; sie sind keine Quelle für IETF-Absichten.

Die enge Aussage genügt: Ein ACK kann die Diagnose ändern, ohne den Zustand zu ändern. Ein wiederhergestelltes Ergebnis darf erst gemeldet werden, wenn eine getrennte Reaktion stattgefunden hat und ihre Wirkung beobachtet wurde.

Quellen