Zusammenfassung

  • Die kumulative TCP-Bestätigung kommt an einer Lücke zum Stehen. SACK erlaubte dem Empfänger, später eingetroffene zusammenhängende Bytebereiche zusätzlich zu melden.
  • Nach RFC 2018 durfte der Empfänger bereits gemeldete Daten wieder verwerfen. Der Sender musste seine Kopie bis zur kumulativen Bestätigung behalten.

In einer Registratur treffen die Seiten eins, zwei und vier ein. Der amtliche Stempel reicht nur bis Seite zwei: Die dritte fehlt. Daneben steht handschriftlich, dass Seite vier auf dem Tisch liegt. Wer den Tisch später räumt, kann sie dennoch fortwerfen. TCP brauchte genau diese Unterscheidung zwischen einem fortschreitenden Stempel und einer Momentaufnahme vom Schreibtisch.

RFC 1072 aus dem Jahr 1988 schilderte das Problem auf Verbindungen mit viel Bandbreite und langer Verzögerung. Ein fehlendes Segment hielt die kumulative Bestätigung auf. Aus ihrer Zahl erfuhr der Sender kaum, welche späteren Segmente schon beim Empfänger lagen. Weiteres Abwarten kostete Umlaufzeit; blindes Nachsenden konnte vorhandene Daten nochmals transportieren. Eine selektive Rückmeldung sollte die Inseln hinter der Lücke zeigen. RFC 1072 war ein experimenteller Vorschlag, noch nicht die spätere SACK-Festlegung.

Im Oktober 1996 beschrieb RFC 2018 die SACK-Option. Zunächst musste die Gegenseite im anfänglichen SYN SACK-Permitted angekündigt haben. Die übliche Bestätigungsnummer blieb im TCP-Header und bezeichnete weiterhin die lückenlose Folge. SACK-Blöcke nannten die Grenzen empfangener Bereiche jenseits davon. Stempel und Randnotiz konnten nun in derselben Antwort stehen, ohne dieselbe Aussage zu treffen.

Der Platz für Randnotizen war knapp. TCP-Optionen konnten bei vielen getrennten Bereichen nicht alles aufzählen. RFC 2018 verlangte im ersten SACK-Block gewöhnlich den Bereich mit jenem Segment, das die Bestätigung ausgelöst hatte; eine Ausnahme galt, wenn dieses Segment die kumulative Zahl weiterbewegte. Weitere unterschiedliche Bereiche sollten folgen, soweit Platz war. Kürzlich gemeldete Blöcke erneut zu nennen, gab einer verlorenen ACK-Nachricht eine zweite Chance. Der Sender erhielt einen nützlichen, aber unvollständigen Lagebericht.

Abschnitt 8 setzte dem Bild vom sicheren Archiv ein Ende. Der Empfänger durfte außerhalb der Reihenfolge gespeicherte Daten verwerfen, obwohl er sie zuvor mit SACK gemeldet hatte, etwa wegen knappen Pufferspeichers. Die Spezifikation nennt das reneging. In späteren Optionen durfte er verworfene alte Bereiche nicht weiter als vorhanden ausgeben. Die Sonderregel für den ersten Block meldete die neueste Ankunft sogar dann, wenn der Empfänger sie gleich wegwerfen wollte. Eine Meldung belegte eine Ankunft und einen augenblicklichen Speicherzustand, keine dauerhafte Verwahrung.

Der Sender bekam deshalb eine klare Pflicht: Bytes erst löschen, wenn die kumulative Bestätigung sie erfasst. SACK half ihm zu entscheiden, welche Lücke zuerst repariert werden sollte und welche Bereiche vorläufig nicht nochmals über die Leitung mussten. Doch die wiederholbare Originalkopie blieb bei ihm. Räumte die Gegenseite ihre Warteschlange, konnte nur diese Kopie den Ausfall beheben.

RFC 2883 vom Juli 2000 verwendete dieselbe Option für einen weiteren Zweck. D-SACK meldete doppelt eingetroffene Daten. Weder die Bedeutung der kumulativen Zahl noch der Zeitpunkt für ACKs änderte sich. Ein Duplikat konnte in genau einer ACK-Nachricht auftauchen; ging diese verloren, verschwand auch die Nachricht darüber. Selbst der ausführlichere Empfangszettel hatte einen Transportweg.

SACK ersparte dem TCP-Sender einen Teil des Ratens bei beschädigten Folgen. Seine vielleicht wichtigste Regel war jedoch altmodisch: Mit der Bleistiftnotiz lässt sich die nächste Lieferung planen. Das Original wird erst entsorgt, wenn der amtliche Stempel aufgeholt hat.