4.2. Erzeugung von Bestätigungen

Der in [RFC1122] spezifizierte verzögerte ACK-Algorithmus SOLLTE (SHOULD) von einem TCP-Empfänger verwendet werden. Bei Verwendung verzögerter Bestätigungen DARF (MUST NOT) ein TCP-Empfänger Bestätigungen nicht übermäßig verzögern. Insbesondere SOLLTE (SHOULD) eine Bestätigung für mindestens jedes zweite vollständige Segment erzeugt werden, und eine Bestätigung MUSS (MUST) innerhalb von 500 ms nach Ankunft des ersten unbestätigten Pakets erzeugt werden.

Die Anforderung, dass eine Bestätigung „SOLLTE (SHOULD)" für mindestens jedes zweite vollständige Segment erzeugt werden soll, ist in [RFC1122] an einer Stelle als SHOULD und an einer anderen als MUST aufgeführt. Hier stellen wir eindeutig fest, dass es sich um ein SHOULD handelt. Wir betonen außerdem, dass dies ein SHOULD ist, was bedeutet, dass ein Implementierer von dieser Anforderung tatsächlich erst nach sorgfältiger Abwägung der Auswirkungen abweichen sollte. Siehe die Erörterung der „Stretch-Ack-Verletzung" in [RFC2525] und die dortigen Verweise für eine Erörterung der möglichen Leistungsprobleme bei der Erzeugung von Bestätigungen seltener als für jedes zweite vollständige Segment.

In manchen Fällen sind sich Sender und Empfänger möglicherweise nicht darüber einig, was ein vollständiges Segment ausmacht. Eine Implementierung gilt als konform mit dieser Anforderung, wenn sie mindestens eine Bestätigung sendet, jedes Mal wenn sie 2RMSS Bytes neuer Daten vom Sender empfängt, wobei RMSS die maximale Segmentgröße ist, die der Empfänger dem Sender angibt (oder der Standardwert von 536 Bytes gemäß [RFC1122], wenn der Empfänger während des Verbindungsaufbaus keine MSS-Option angibt). Der Sender kann gezwungen sein, eine Segmentgröße kleiner als RMSS zu verwenden, und zwar aufgrund der maximalen Übertragungseinheit (MTU), des Pfad-MTU-Erkennungsalgorithmus oder anderer Faktoren. Betrachten Sie zum Beispiel den Fall, dass der Empfänger eine RMSS von X Bytes ankündigt, der Sender aber aufgrund der Pfad-MTU-Erkennung (oder der MTU-Größe des Senders) letztlich eine Segmentgröße von Y Bytes (Y < X) verwendet. Der Empfänger erzeugt Stretch-ACKs, wenn er auf die Ankunft von 2X Bytes wartet, bevor eine Bestätigung gesendet wird. Offensichtlich dauert dies mehr als 2 Segmente der Größe Y Bytes. Obwohl also kein spezifischer Algorithmus definiert ist, ist es wünschenswert, dass Empfänger versuchen, diese Situation zu vermeiden, indem sie beispielsweise mindestens jedes zweite Segment bestätigen, unabhängig von seiner Größe. Abschließend wiederholen wir, dass eine Bestätigung DARF (MUST NOT) nicht länger als 500 ms verzögert werden darf, während auf die Ankunft eines zweiten vollständigen Segments gewartet wird.

Datensegmente außer der Reihe SOLLTEN (SHOULD) sofort bestätigt werden, um die Verlusterholung zu beschleunigen. Um den Algorithmus der schnellen Übertragungswiederholung auszulösen, SOLLTE (SHOULD) der Empfänger sofort eine doppelte Bestätigung senden, wenn er ein Datensegment oberhalb einer Lücke im Sequenzraum empfängt. Um Sendern, die sich von Verlusten erholen, Rückmeldung zu geben, SOLLTE (SHOULD) der Empfänger sofort eine Bestätigung senden, wenn er ein Datensegment empfängt, das eine Lücke im Sequenzraum ganz oder teilweise füllt.

Ein TCP-Empfänger DARF NICHT (MUST NOT) mehr als eine Bestätigung für jedes eingehende Segment erzeugen, außer um das angebotene Fenster zu aktualisieren, wenn die empfangende Anwendung neue Daten verbraucht (siehe [RFC813] und Seite 42 von [RFC793]).