Zusammenfassung

  • RFC 3465 schlug Appropriate Byte Counting vor: Das TCP-Fenster sollte nach zuvor unbestätigten Bytes wachsen, die ein ACK neu abdeckt, statt jeder ACK-Nachricht einen festen Zuwachs zu geben.
  • Auch Byte-Belege blieben begrenzt. L deckelte den Zuwachs je ACK im Slow Start, durfte zwei SMSS nie überschreiten und musste nach einem RTO auf ein SMSS fallen, weil ein kumulatives ACK ältere Fortschritte enthalten konnte.

Die Zahl der Quittungen war kein Fortschrittsmaß

Traditionell bot jedes eingehende ACK eine Gelegenheit, cwnd zu vergrößern. Das funktionierte als Näherung, wenn jedes Segment bestätigt wurde und kein ACK verloren ging. Verzögerte ACKs erzeugten für dieselben Bytes weniger Gelegenheiten. ACK Division ließ einen Empfänger dagegen ein Segment in mehreren kleinen Schritten bestätigen und so mehrere Gelegenheiten aus derselben Lieferung gewinnen.

Der im Februar 2003 als Experimental veröffentlichte RFC 3465 wechselte die Rechnung. Klartext, RFC-Editor-Eintrag, Datatracker, Historie, Referenzen, spätere Verweise und Errata bilden den öffentlichen Bestand. Der Vorschlag änderte die Logik aus RFC 2581, der später durch den Standards-Track-RFC 5681 ersetzt wurde.

Nach RFC 1122 konnten verzögerte ACKs ungefähr zwei volle Segmente bestätigen. Eine nach Nachrichten zählende Implementierung wuchs dadurch nur etwa halb so schnell. Ein verlorenes ACK löschte ebenfalls eine Gelegenheit, obwohl das folgende kumulative ACK dieselben angekommenen Bytes belegte.

ACK Division nutzte die Gegenrichtung. Bestätigte der Empfänger nacheinander kleine Bereiche eines Segments, konnte ein fester Zuwachs pro Nachricht mehrfaches Sendeguthaben erzeugen. ABC ließ die vielen Teilnachrichten nur die tatsächlich neue Gesamtmenge einzahlen.

Der Sender führte ein Byte-Konto

In Congestion Avoidance sammelte bytes_acked nur zuvor unbestätigte Bytes. Erreichte das Konto das aktuelle cwnd, zog der Sender diese Fenstermenge ab und erhöhte cwnd um ein SMSS. Das Ziel von ungefähr einem Segment je RTT blieb bestehen, unabhängig von der Anzahl der ACKs.

Im Slow Start durfte das Fenster um die neu bestätigten Bytes eines ACK wachsen, höchstens jedoch um L. Mit L=1*SMSS war ABC nicht aggressiver als die alte Regel und wurde in dieser Form empfohlen. L=2*SMSS war für Versuche erlaubt, um ein ACK für zwei Segmente auszugleichen; höhere Werte waren verboten.

Die Grenze hielt große kumulative oder Stretch-ACKs davon ab, beliebige Leitungsbursts freizugeben. Zwei SMSS konnten dennoch Mikrobursts vergrößern und Slow Start näher an eine Verdopplung je RTT bringen. Die begrenzten Simulationen im RFC zeigten teilweise mehr Verluste und begründeten weitere Versuche, nicht allgemeine Einführung oder bewiesene Fairness. Der Text empfahl SACK aus RFC 2018. RFC 2861 behandelte das verwandte Ansammeln ungenutzten Fensterguthabens.

Nach dem RTO kam alte Geschichte mit

War ein frühes Segment verloren, während spätere bereits beim Empfänger lagen, konnte die erneute Übertragung der Lücke ein kumulatives ACK über mehrere Segmente auslösen. Für den Bestätigungsstand des Senders waren alle Bytes neu. Im aktuellen RTT hatte aber womöglich nur die Wiederholung das Netz verlassen.

Deshalb verlangte RFC 3465 im Slow-Start-Recovery nach RTO L=1*SMSS. RFC 2988 und sein späterer Nachfolger RFC 6298 liefern den Timer-Kontext. Das ACK war gültig; seine zeitliche Aussage war nur breiter als die frische Kapazitätsprobe.

Benachbarte Verfahren hatten andere Zuständigkeiten. Limited Transmit in RFC 3042 erlaubte begrenzt neue Daten vor dem dritten Duplicate ACK, definierte aber kein ABC-Konto. RFC 3449 untersuchte asymmetrische Wege, ACK-Filterung und Rekonstruktion, nicht die Guthabeneinheit beim Sender. Der Katalog RFC 2525 zeigt mögliche Implementierungsfehler, aber keine ABC-Verbreitung.

Heng Lus spätere Realitätsebenen trennen beobachtetes ACK, neue Bytes, zugelassenes Guthaben und gesendete Pakete. Der Vorrang laufenden Codes lenkt auf Akkumulator, Grenze, Recovery-Zustand und Burst. Das sind spätere redaktionelle Instrumente, keine private Absicht des RFC-Autors.

RFC 3465 machte die Rechnung widerstandsfähiger, ohne jedes bestätigte Byte zu frischer Kapazität zu erklären. Quittungen ließen sich teilen oder bündeln; der zugrunde liegende Fortschritt sollte sein Gewicht behalten.

Quellen