Zusammenfassung

  • Ein kumulatives ACK bestätigt eine zusammenhängende Folge, zeigt bei mehreren Verlusten aber nicht, welche Inseln hinter der ersten Lücke angekommen sind.
  • RFC 2018 ließ den Empfänger nicht zusammenhängende Bytebereiche melden, behielt diese Angaben jedoch als beratende Evidenz und das kumulative ACK als endgültige Bestätigung.
  • RFC 3517 und RFC 6675 formten daraus eine konservative Wiederherstellung mit Scoreboard, Schätzung der noch fliegenden Daten und einer eng begrenzten Rettungsübertragung.

Geht das zweite Segment einer Folge verloren und treffen die späteren Segmente ein, kennt der Empfänger den größten Teil des Ergebnisses. Das normale ACK bleibt trotzdem vor der Lücke stehen. Seine Wiederholung signalisiert eine Störung, beschreibt aber nicht die heilen Bereiche dahinter. Der Sender kann jede weitere Lücke erst nach einer Rundlaufzeit entdecken oder vorsorglich Daten wiederholen, die längst gespeichert sind.

RFC 2018 gab TCP im Oktober 1996 eine zweite Sprache für diesen Zustand. Eine frühere Form stand bereits in RFC 1072, wurde aber unter anderem wegen Meinungsverschiedenheiten über das Zusammenspiel mit Window Scaling nicht breit eingesetzt. Die neue Fassung trennte Erlaubnis und Meldung. SACK-Permitted wird im SYN angeboten; danach dürfen SACK-Blöcke die linken und rechten Grenzen zusammenhängender empfangener Sequenzbereiche nennen.

Das kumulative ACK behielt seine starke Aussage: Alles vor der Grenze ist angekommen. SACK-Blöcke beschreiben nur Inseln dahinter. Sie schieben die Grenze nicht weiter und sind keine endgültige Quittung. Unter Speicherdruck darf ein Empfänger bereits gemeldete Daten verwerfen. Der Sender muss deshalb seine Kopie behalten, bis das gewöhnliche ACK über die betreffenden Bytes hinausgeht.

Auch die Karte ist begrenzt. Für TCP-Optionen stehen 40 Bytes zur Verfügung. Höchstens vier SACK-Blöcke passen hinein, gewöhnlich drei, wenn Zeitstempel ebenfalls Platz beanspruchen. RFC 2018 setzt den neuesten Block an die erste Stelle und empfiehlt die Wiederholung jüngerer Blöcke. So bleibt die Information aktuell und überlebt eher verlorene Rückweg-ACKs. Vollständig ist sie dennoch nie; sie ist eine Auswahl aus dem Empfängerzustand.

Die Spezifikation von 1996 beschrieb das Signal, nicht jede Reaktion des Senders. Sie verlangte ausdrücklich, die Regeln der Staukontrolle zu erhalten. RFC 3517 lieferte im April 2003 einen konservativen Ablauf. Der Sender führt ein Scoreboard kumulativ und selektiv bestätigter Bereiche, stuft Lücken als verloren ein, schätzt mit Pipe die noch im Netz befindlichen Bytes und wählt die nächste Übertragung innerhalb des Congestion Window.

Diese Arbeitsteilung hält Beobachtung und Entscheidung auseinander. Der Empfänger berichtet über seine Warteschlange. Der Sender interpretiert, speichert und trägt die Folgen eines Irrtums. Mehrere Verluste lassen sich in einer Erholungsphase bearbeiten, doch SACK hebt weder die Fensterreduktion noch die Vorsicht gegenüber Umordnung auf.

Im August 2012 löste RFC 6675 RFC 3517 ab. Die Revision bezog neue SACK-Information in die Definition doppelter ACKs ein, verbesserte die Verlusterkennung bei Segmenten unterhalb der maximalen Segmentgröße und führte RescueRxt ein. Droht bei einem Verlust am Fensterende ohne neue Daten die ACK-Uhr stehenzubleiben, ist pro Erholungsphase eine optimistische Rettungsübertragung erlaubt. Sie bleibt auf ein Segment bis zur maximalen Sendergröße beschränkt.

Die SACK-Geschichte handelt daher nicht von kostenloser Geschwindigkeit, sondern von begrenztem Vertrauen. Der Empfänger kennt seinen aktuellen Puffer, verspricht aber keine ewige Aufbewahrung. Der Sender kontrolliert die Reparatur, sieht den Pfad jedoch nur durch verzögerte Berichte. Der Header komprimiert den Zustand, und ein Timeout kann frühere Annahmen entwerten.

Die bleibende Leistung bestand darin, aus einer Bestätigungsgrenze eine Teilkarte zu machen, ohne daraus einen Befehl zu formen. Der Sender kann unnötige Wiederholungen vermeiden, bleibt aber für Rate, Kopie und Schlussfolgerung verantwortlich. So gewann TCP Präzision, ohne die Kosten privaten Optimismus ungebremst auf den gemeinsam genutzten Pfad abzuwälzen.

Quellen