4.2. Génération des Accusés de Réception

L'algorithme d'ACK retardé spécifié dans [RFC1122] DEVRAIT (SHOULD) être utilisé par un récepteur TCP. Lors de l'utilisation des ACK retardés, un récepteur TCP NE DOIT PAS (MUST NOT) retarder excessivement les accusés de réception. Plus précisément, un ACK DEVRAIT (SHOULD) être généré pour au moins chaque second segment de taille complète, et DOIT (MUST) être généré dans les 500 ms suivant l'arrivée du premier paquet non acquitté.

L'exigence selon laquelle un ACK « DEVRAIT (SHOULD) » être généré pour au moins chaque second segment de taille complète est énoncée dans [RFC1122] à un endroit comme un SHOULD et à un autre comme un MUST. Nous indiquons ici sans ambiguïté qu'il s'agit d'un SHOULD. Nous soulignons également qu'il s'agit d'un SHOULD, ce qui signifie qu'un implémenteur ne devrait s'écarter de cette exigence qu'après un examen attentif de ses implications. Voir la discussion de la « violation de Stretch ACK » dans [RFC2525] et les références qui y figurent pour une discussion des problèmes de performance possibles liés à la génération d'ACK moins fréquemment qu'à chaque second segment de taille complète.

Dans certains cas, l'émetteur et le récepteur peuvent ne pas être d'accord sur ce qui constitue un segment de taille complète. Une implémentation est réputée satisfaire à cette exigence si elle envoie au moins un accusé de réception chaque fois qu'elle reçoit 2RMSS octets de nouvelles données de l'émetteur, où RMSS est la taille maximale de segment indiquée par le récepteur à l'émetteur (ou la valeur par défaut de 536 octets, selon [RFC1122], si le récepteur ne spécifie pas d'option MSS lors de l'établissement de la connexion). L'émetteur peut être contraint d'utiliser une taille de segment inférieure à RMSS en raison de l'unité de transmission maximale (MTU), de l'algorithme de découverte du MTU de chemin ou d'autres facteurs. Par exemple, considérons le cas où le récepteur annonce une RMSS de X octets mais où l'émetteur finit par utiliser une taille de segment de Y octets (Y < X) en raison de la découverte du MTU de chemin (ou de la taille de MTU de l'émetteur). Le récepteur générera des stretch ACK s'il attend l'arrivée de 2X octets avant qu'un ACK ne soit envoyé. De toute évidence, cela prendra plus de 2 segments de taille Y octets. Par conséquent, bien qu'aucun algorithme spécifique ne soit défini, il est souhaitable que les récepteurs tentent d'empêcher cette situation, par exemple en acquittant au moins chaque second segment, quelle que soit sa taille. Enfin, nous répétons qu'un ACK NE DOIT PAS (MUST NOT) être retardé de plus de 500 ms en attendant l'arrivée d'un second segment de taille complète.

Les segments de données hors séquence DEVRAIENT (SHOULD) être acquittés immédiatement, afin d'accélérer la récupération de perte. Pour déclencher l'algorithme de retransmission rapide, le récepteur DEVRAIT (SHOULD) envoyer immédiatement un ACK duplicata lorsqu'il reçoit un segment de données au-dessus d'un trou dans l'espace de séquence. Pour fournir un retour aux émetteurs qui récupèrent de pertes, le récepteur DEVRAIT (SHOULD) envoyer immédiatement un ACK lorsqu'il reçoit un segment de données qui comble tout ou partie d'un trou dans l'espace de séquence.

Un récepteur TCP NE DOIT PAS (MUST NOT) générer plus d'un ACK pour chaque segment entrant, sauf pour mettre à jour la fenêtre offerte lorsque l'application réceptrice consomme de nouvelles données (voir [RFC813] et page 42 de [RFC793]).