Zusammenfassung

  • Nach dem ersten geordneten Segment darf der Empfänger kurz warten, um zwei Segmente gemeinsam zu bestätigen oder das ACK mit einer eigenen Antwort zu verbinden.
  • Zweites Segment, Timerablauf oder Verlustanzeichen beenden das Warten, bevor Bündelung zu unkontrollierter Stille wird.

Beim Beginn der Verzögerung sind die Bytes schon angenommen und die nächste erwartete Sequenznummer ist vorgerückt. Nur die Mitteilung an den Sender fehlt. Trifft ein zweites volles Segment ein, bestätigt ein kumulatives ACK beide; andernfalls gibt der Timer die Bestätigung frei.

RFC 1122 empfahl Delayed ACK, weil weniger reine ACK-Segmente Host- und Netzaufwand sparen. Gleichzeitig musste die Verzögerung unter 0,5 Sekunden bleiben, und bei vollen Segmenten sollte mindestens jedes zweite bestätigt werden. Das Terminalbeispiel zeigte eine weitere Möglichkeit: ACK, Fensteraktualisierung und Echo konnten in einem Segment zusammenkommen.

RFC 5681 stellte klar, dass die Zwei-Segment-Frequenz ein SHOULD ist und die Wartezeit 500 ms niemals überschreiten darf. Ein Zähler von 2*RMSS kann jedoch täuschen, wenn der Sender wegen der Pfad-MTU kleinere Segmente verwendet. Dann umfasst ein ACK mehr als zwei reale Segmente und wird zum Stretch ACK. Um das zu vermeiden, sollte der Empfänger unabhängig von ihrer Größe mindestens jedes zweite eintreffende Segment bestätigen.

Bei einer Lücke gilt eine andere Priorität. Daten oberhalb der Lücke sollten sofort ein Duplicate ACK auslösen. Auch auf Daten, die die Lücke ganz oder teilweise schließen, sollte der Empfänger sofort mit einem ACK reagieren. Nun trägt das ACK konkrete Verlust- und Wiederherstellungsevidenz.

RFC 2525 dokumentierte Stretch ACK als Implementierungsfehler. Da eintreffende ACKs den Kontrolltakt des Senders mitbestimmen, kann übermäßiges Bündeln Wachstum bremsen und größere Sendeschübe begünstigen.