Zusammenfassung

  • Eine Duplikatmeldung kann zeigen, dass eine bestimmte Wiederholung unnötig war; sie belegt nicht, dass alle Segmente im selben Fenster verlustfrei ankamen.
  • RFC 3708 lässt den Schluss auf eine mögliche Rücknahme von Congestion-Control-Änderungen erst zu, wenn jede Wiederholung im vorherigen Fenster bestätigt und als Duplikat markiert wurde und keine Abbruchbedingung gegriffen hat.

Der aufschlussreiche Fall ist beinahe eine Falle. Der Sender überträgt die Segmente N und N+1 erneut. Nur N ging verloren; N+1 kam lediglich verspätet. Meldet der Empfänger N+1 als Duplikat, erfährt der Sender: Diese Wiederholung von N+1 war unnötig. Er erfährt nicht, dass das Netz nichts verloren hat. N bleibt ein echtes Verlustsignal. Würde er den Congestion-Zustand für das ganze Fenster zurücksetzen, löschte er weiterhin relevante Evidenz.

Diese Unterscheidung bildet den Kern von RFC 3708, einem im Februar 2004 veröffentlichten Experimental-Memo. Es beschreibt vorsichtige Verfahren für Duplikatmeldungen: TCPs Duplicate Selective Acknowledgement (DSACK) und SCTPs Meldungen doppelter Transmission Sequence Numbers (TSN). Das Dokument trennt zwei Einsatzzwecke. Ein Stack kann Meldungen für Buchführung oder Beobachtung zählen. Wer Änderungen der Überlastungssteuerung zurücknehmen will, braucht den strengeren Disambiguierungsalgorithmus.

Zuerst prüft der Algorithmus, ob der gemeldete Sequenzbereich oder TSN erneut übertragen wurde. Bei mehr als einer Wiederholung im selben Fenster endet die Verarbeitung; der frühere Congestion-Zustand wird nicht wiederhergestellt. Hat der Sender die Einheit nie wiederholt, kann die Meldung auf eine Netzduplizierung hindeuten. Dann soll der Algorithmus für den Rest der Verbindung nicht mehr verwendet werden: Spätere Duplikate wären schwerer den unnötigen Wiederholungen des Senders zuzuordnen.

Selbst eine passende Meldung für eine Wiederholung reicht nicht. Der Sender prüft sämtliche wiederholten Segmente oder Chunks des vorherigen Datenfensters. Erst wenn alle bestätigt und als Duplikate markiert sind, schließt RFC 3708, dass alle Wiederholungen unnötig waren und das Fenster keinen Verlust enthielt. Bleibt eine Wiederholung unmarkiert, erlaubt die Meldung keine Schlussfolgerung. Eine weitere Sicherung greift bei leerem TCP-SACK-Scoreboard und einem DSACK, dessen linke Grenze bei SND.UNA liegt. Das passt zu einem vollständig verlorenen ACK-Fenster; in diesem Fall bleibt eine reduzierte Senderate die vorsichtige Wahl.

Das Verfahren braucht zusätzlichen Zustand: Neben den üblichen SACK-Wiederherstellungsdaten verfolgt die Implementierung, welche Sequenznummern oder TSNs bereits als Duplikate bestätigt wurden. Das ermöglicht eine eng begrenzte Schlussfolgerung, aber keine Gewissheit über die Ehrlichkeit des Empfängers oder alle Ereignisse auf dem Pfad. Der Sicherheitsteil von RFC 3708 warnt, dass ein Empfänger bei echtem Verlust umsortiert eingetroffene Daten fälschlich als Duplikate markieren und so eine riskante Änderung des Congestion-Zustands auslösen könnte.

RFC 2883 legt fest, wie Empfänger Duplikate in TCP-D-SACK-Blöcken codieren, nicht aber die Reaktion des Senders. RFC 3522 nutzt andere Evidenz: Eifel kann eine unnötige Wiederholung mithilfe von TCP-Zeitstempeln schneller erkennen, verlangt dafür aber die Timestamp-Option in jedem Paket. RFC 3708 ist langsamer und trennt dafür zwei Fragen: War eine einzelne Wiederholung überflüssig? Reicht die Evidenz aus, das gesamte Fenster als verlustfrei zu werten? Welche Aktion nach der Erkennung folgt, legt das Memo nicht fest.

Quellen: RFC 3708, Status von RFC 3708, RFC 2883, RFC 3517, RFC 3522, RFC 2960, RFC 4960.