Zusammenfassung

  • RFC 3517 überführte kumulative ACKs und SACK-Blöcke in ein Sender-Scoreboard; SetPipe() schätzte daraus Oktette, die noch als unterwegs gelten sollten.
  • Manche Retransmissionskopien wurden doppelt gezählt, weil der Sender nicht wusste, welche Kopie das Netz verlassen hatte. cwnd - pipe erlaubte einen Sendeschritt, nicht die Behauptung exakter Pfadkenntnis.

Bei mehreren Verlusten zeigt das kumulative ACK nur die lückenlose linke Kante. Oberhalb davon kann der Empfänger Inseln besitzen. RFC 2018 ließ ihn diese Bereiche mit SACK melden und ersparte dem Sender blinde Wiederholungen.

Die Meldung blieb jedoch beratend. Der Empfänger durfte bereits gemeldete Daten verwerfen. Deshalb musste der Sender sie im Retransmissionspuffer behalten, bis das kumulative ACK darüber hinausging. SACK bewies einen berichteten Zustand, keine dauerhafte Verwahrung.

RFC 3517 baute daraus ein lokales Recovery-Modell. HighACK, HighData, HighRxt und RecoveryPoint grenzten den Zustand ein. Update() pflegte das Scoreboard. IsLost() leitete Verlust aus einer Schwelle höherer, getrennter SACK-Bereiche ab. Die Regel sah weder Verlustort noch Ursache.

SetPipe() durchlief den Sequenzraum. Nicht SACKte und noch nicht als verloren bewertete Oktette erhöhten pipe, weil sie als im Netz angenommen wurden. Retransmittierte Oktette bis HighRxt kamen hinzu. Der Standard nannte das Ergebnis eine Schätzung.

Die Doppelzählung machte die Grenze sichtbar. Wurde vor einer Verlustklassifikation erneut gesendet, wusste der Sender nicht, ob Original, Kopie oder beide noch unterwegs waren. Beide als verschwunden anzunehmen konnte pipe unterschätzen und zu viel weiteren Verkehr freigeben. Konservatives Zählen hielt die Unsicherheit fest.

Beim Recovery-Eintritt wurde RecoveryPoint auf HighData gesetzt, das Staukontrollfenster reduziert, der erste vermutete Verlust retransmittiert und SetPipe() ausgeführt. Nachfolgende ACKs aktualisierten die Rechnung. Erst wenn cwnd - pipe mindestens ein SMSS frei ließ, wählte NextSeg() den nächsten Bereich.

Diese Differenz war eine lokale Genehmigung. Das Erhöhen von pipe nach einem Sendeschritt bewies weder eine konkrete Warteschlange noch Verbleib, Empfang oder Anwendungsverarbeitung. Ein kumulatives ACK jenseits von RecoveryPoint beendete lediglich die Recovery-Phase.

RFC 3042 nutzte frühe Duplicate ACKs für Limited Transmit. RFC 2883 ließ D-SACK Duplikate melden. RFC 5681 gab den Congestion-Control-Rahmen, RFC 6582 beschrieb NewReno. Alle verbesserten Senderentscheidungen, ohne den Pfad physisch zu zählen.

Der RTO blieb Rückfallgrenze. Nach einem Timeout musste alte SACK-Information wegen möglichen Renegings ignoriert werden. Selbst ein detailreiches Scoreboard war kein dauerhafter Empfängerspiegel.

RFC 6675 ersetzte RFC 3517 und präzisierte Schwellen, Eintritt und Rescue Retransmission. pipe blieb dennoch eine Schätzung. RFC 6937 führte PRR mit einer anderen Taktung ein. Recovery-Buchhaltung ist damit erkennbar eine Steuerungspolitik.

RFC 9293 bildet heute die TCP-Basis; IANA registriert SACK-Permitted und SACK. Eine Codenummer beweist weder Aushandlung noch Verlust oder Zustellung. Das bleibende Erbe von RFC 3517 ist kontrolliertes Handeln ohne vorgetäuschte Vollsicht.

Quellen