Résumé

  • RFC 3042 autorise l’émission de données jusque-là inédites sur chacun des deux premiers ACK dupliqués consécutifs, sous réserve des fenêtres annoncée et de congestion.
  • Cette émission peut susciter assez de retours pour atteindre le seuil préexistant de trois ACK dupliqués ; elle ne doit pas augmenter cwnd.

Dans l’exemple de petite fenêtre de RFC 3042, la difficulté n’est pas seulement un segment manquant. Il manque aussi un retour suffisant pour déclencher la règle de retransmission rapide déjà en place. Avec cwnd limité à trois segments, la perte de l’un d’eux ne laisse au plus que deux ACK dupliqués. Sans autre signal, l’émetteur peut devoir attendre l’expiration du temporisateur de retransmission.

Publié en janvier 2001 par Mark Allman, Hari Balakrishnan et Sally Floyd, le texte introduit le Limited Transmit. Si des données jamais envoyées attendent dans la file, l’émetteur DEVRAIT transmettre un nouveau segment à l’arrivée de chacun des deux premiers ACK dupliqués consécutifs. Il ne peut le faire que si la fenêtre annoncée par le récepteur l’autorise et si le total en vol reste inférieur ou égal à cwnd + 2 segments. Surtout, il NE DOIT PAS modifier cwnd pour ces deux envois.

La séparation est essentielle. Le mécanisme dépense une marge de vol strictement plafonnée afin de susciter davantage de retours ; il ne conclut pas que le réseau n’est pas congestionné et ne relève pas le budget de congestion de l’émetteur. Il ne retransmet pas non plus aussitôt le segment présumé perdu. Si les nouveaux segments et les ACK qu’ils entraînent arrivent, un autre ACK dupliqué peut porter le compte au seuil familier de trois. La retransmission relève alors de Fast Retransmit, mécanisme antérieur que RFC 3042 complète sans le remplacer.

Un ACK dupliqué reste équivoque. Il peut signaler que le récepteur a reçu des données au-delà d’un trou, mais un réordonnancement peut produire une observation semblable. Réémettre l’ancien segment dès le premier ACK réagirait à un indice plus faible. Envoyer de nouvelles données conserve plutôt le rythme des ACK et, selon l’argument de RFC 3042, résiste mieux au réordonnancement. Cela ne transforme pas l’indice en preuve de la cause physique de la perte.

Les conditions sont concrètes : nouvelles données disponibles, fenêtre du récepteur suffisante et FlightSize limité à cwnd + 2 segments. Avec SACK, l’émetteur NE DOIT PAS répondre par de nouvelles données à un ACK dupliqué dépourvu d’information SACK nouvelle ; la règle est précisée dans RFC 3042, tandis que RFC 2018 décrit l’option SACK. Si l’une des conditions échoue, ou si les données supplémentaires ou leurs ACK se perdent, le mécanisme ne garantit pas d’éviter l’expiration du temporisateur.

RFC 5681 a ensuite intégré ces deux envois préalables à la séquence consolidée de Fast Retransmit et Fast Recovery, en conservant le plafond de deux segments et l’interdiction d’augmenter cwnd. Cette évolution montre où se situe RFC 3042 dans la spécification de TCP ; elle ne démontre pas le comportement d’une pile actuelle non observée.

La portée historique de RFC 3042 est précise : remédier à un manque de retours dans un cas limité, sans redéfinir le contrôle de congestion. Le compte de trois ACK, la retransmission du segment et l’ACK cumulatif ultérieur sont des transitions différentes. Aucun de ces éléments, pris isolément, ne désigne la cause matérielle d’une perte ni ne prouve qu’une application a reçu ses données utiles.

Sources