Résumé

  • RACK ne déclare un ancien segment perdu que si un segment envoyé plus tard a été livré et si l’ancien reste sans acquittement au-delà d’un RTT estimé augmenté d’une fenêtre de réordonnancement.
  • TLP envoie au plus une sonde contrôlée avant le délai RTO pour provoquer un ACK. Cette sonde crée une observation ; RACK qualifie la perte et le contrôle de congestion garde le pouvoir d’autoriser l’émission de récupération.

Le procès fragile des trois témoins

La retransmission rapide de TCP repose historiquement sur un indice commode : trois acquittements dupliqués suggèrent qu’un paquet antérieur manque. Cette convention a rendu de grands services, mais elle dépend d’un trafic suffisant derrière le trou. Une réponse courte, une application momentanément inactive ou une perte au bout d’une fenêtre ne produit parfois jamais les trois signaux. Le flux attend alors le délai de retransmission, dont la prudence est précisément conçue pour les cas où les indices plus fins manquent.

SACK a enrichi le dossier. RFC 2018 permet au récepteur d’indiquer les plages d’octets reçues hors de l’acquittement cumulatif. RFC 6675 exploite ce tableau pour une récupération fondée sur SACK. Son critère principal reste cependant exprimé par un nombre de séquences discontinues ou d’octets livrés au-dessus d’un trou. Le réordonnancement, les ACK étirés ou la duplication peuvent rendre ce compte trop lent ou trop affirmatif. Un nombre dans l’espace des séquences ne mesure pas la durée pendant laquelle un envoi a été exposé au chemin.

RFC 8985 déplace donc le raisonnement vers l’axe du temps. Ses quatre auteurs sont Yuchung Cheng, Neal Cardwell, Nandita Dukkipati et Priyaranjan Jha. L’IETF a fait entrer le texte dans son Standards Track en février 2021 : il s’agit d’un résultat collectif. Les profils officiels de Cardwell auprès de l’IETF et de Google Research relient bien son nom à ce travail et à la recherche sur les réseaux ; ils n’autorisent ni le récit du génie solitaire ni l’idée qu’il gouvernerait aujourd’hui toutes les implémentations.

L’événement qui ouvre le dossier

RACK conserve l’heure de la transmission la plus récente de chaque segment en attente, y compris après retransmission. Lorsqu’un ACK ou un SACK atteste la livraison de données parties plus tard qu’un segment toujours en suspens, le sender dispose enfin d’un point de comparaison : le chemin vient de livrer un envoi postérieur. Il mémorise la transmission livrée la plus récente et le moment où elle a été acquittée.

Ce fait ne suffit pas à condamner l’ancien segment S. Deux conditions doivent coexister : une donnée envoyée après S a été livrée, puis S est resté sans acquittement pendant au moins le RTT estimé plus une fenêtre de réordonnancement. RFC 8985 raisonne comme si chaque segment possédait un temporisateur, sans imposer cette réalisation matérielle. Un système peut calculer la prochaine échéance à partir de l’ensemble des segments en vol.

La précision de l’horloge devient alors une donnée fonctionnelle. Le texte demande de conserver une heure par segment avec une granularité plus fine que le quart du RTT minimal. Il évoque un coût de quatre ou huit octets par segment selon la représentation ; c’est une estimation dans le cadre du RFC, pas une loi universelle de consommation mémoire.

Surtout, l’acquittement reste une preuve étroite. Il certifie la réception d’une plage TCP, pas la santé du chemin, la cause du retard, l’identité d’un intermédiaire ou la consommation des octets par l’application. RACK ne localise pas la congestion. Il décide seulement que l’ordre observé et le temps écoulé suffisent désormais à traiter S comme perdu pour les besoins du transport.

Une tolérance chiffrée au désordre

Le réseau peut réordonner sans perdre. La fenêtre de réordonnancement évite donc de confondre immédiatement arrivée tardive et disparition. Selon les conditions du RFC, elle commence à zéro ou à une petite fraction du RTT minimal. Un DSACK révélant qu’une retransmission était inutile fournit une preuve de réordonnancement plus profond ; l’émetteur peut alors élargir sa tolérance. Le texte recommande cette adaptation et borne la fenêtre au RTT lissé.

Ce réglage ne supprime pas l’incertitude, il en fixe le prix. Une fenêtre courte accélère la réparation d’une vraie perte mais augmente les retransmissions parasites. Une fenêtre large ménage les chemins désordonnés au prix d’une attente supplémentaire. La formule « fondé sur le temps » ne signifie donc pas « certain ». Elle signifie que le délai accordé à une autre explication est explicite, mesurable et borné.

Une décision RACK auditable devrait conserver l’heure du dernier envoi du segment suspect, celle du segment ultérieur livré, l’ACK ou le SACK décisif, le RTT estimé, la fenêtre active et le DSACK qui l’a éventuellement modifiée. Le seul compteur « pertes RACK » publie le verdict en détruisant les prémisses.

La sonde qui rompt le silence de queue

TLP, l’autre mécanisme de RFC 8985, traite précisément le moment où les preuves se raréfient. Le délai de sonde est généralement calculé autour de deux RTT lissés, sous réserve des règles portant sur l’ACK retardé et le RTO. Il exige une mesure récente du RTT et n’autorise qu’une seule sonde en attente.

À l’échéance, l’émetteur privilégie de nouvelles données si elles existent et si la fenêtre de congestion les permet. Sinon, il retransmet le segment en attente dont le numéro de séquence est le plus élevé. Le but est d’obtenir un ACK capable d’éclairer l’état de la queue. Une sonde peut momentanément dépasser d’un paquet une fenêtre de congestion pleine, mais cette dépense reste comptabilisée et doit être résorbée au prochain acquittement.

La sonde ne prouve pas que la première copie s’est perdue. C’est une question instrumentée : la réponse peut fournir à RACK la livraison ultérieure nécessaire, ou montrer que les données d’origine étaient arrivées tandis que le retour d’ACK était silencieux. Si la sonde se perd aussi, le RTO demeure le filet ultime. TLP recueille une observation ; il ne prononce pas le jugement.

Trois autorités qui ne doivent pas fusionner

Même lorsque RACK classe un segment comme perdu, il n’obtient pas le droit de l’émettre immédiatement. RFC 8985 exige d’attendre l’autorisation de l’algorithme de contrôle de congestion. RFC 5681 fournit les obligations classiques, tandis que RFC 6937 recommande Proportional Rate Reduction pour doser les envois pendant la récupération.

La distinction est protectrice. Un meilleur capteur doit réduire l’incertitude, non accorder une exemption aux règles de débit. Si chaque résultat RACK déclenchait une salve sans contrôle, un progrès de détection se transformerait en actionneur agressif. L’architecture sépare donc trois mandats : TLP sollicite, RACK infère, le contrôle de congestion dépense.

Le RTO défini par RFC 6298 reste présent. Il garantit le progrès lorsque les observations plus rapides échouent et applique son propre recul prudent. SACK décrit les blocs reçus ; RACK évalue la perte dans le temps ; TLP provoque un retour à la queue ; le contrôleur encadre la récupération ; le RTO couvre le silence résiduel. Le progrès tient à cet empilement, pas au remplacement d’une minuterie par une autre.

Ni certificat de réseau, ni oracle de causalité

La finesse temporelle peut donner une illusion de connaissance. Pourtant, la livraison d’un paquet ultérieur ne certifie ni un chemin sain, ni l’absence de middlebox, ni la cause d’une anomalie. Une même observation peut résulter d’une perte radio, d’une congestion, d’un changement de route ou d’un réordonnancement licite. RACK fournit une conclusion exploitable par TCP, pas une expertise forensique du réseau.

La section sécurité hérite des préoccupations connues de SACK. Elle note une résistance plus précise à l’ACK splitting : acquitter un octet supplémentaire ne fait pas avancer l’heure de la transmission livrée la plus récente, contrairement à certains mécanismes dominés par le nombre d’ACK. Cette propriété limite une tactique ; elle n’authentifie pas le retour et ne rend pas tous les ACK dignes de confiance.

RFC 9002 reprend une logique de seuil temporel pour QUIC et cite RACK-TLP parmi ses antécédents. La filiation ne rend pas les deux systèmes identiques : espaces de numéros de paquets, règles d’acquittement et interface avec la congestion diffèrent. Comparer les idées est légitime ; transférer automatiquement les paramètres ou l’autorité ne l’est pas.

Le chiffre historique et ses limites

En 2013, l’article « Reducing Web Latency: the Virtue of Gentle Aggression », cosigné par Cardwell, étudiait un échantillon de trafic frontal de Google. Dans ce cadre précis, 77 % des pertes observées étaient réparées par le RTO plutôt que par la récupération rapide. La combinaison expérimentée y améliorait la latence moyenne de 23 % et le 99e centile de 47 %.

Ces résultats expliquent l’attention portée aux fins de transferts courts. Ils ne décrivent pas l’Internet de 2026, ne recensent aucun déploiement actuel et ne constituent pas une garantie du RFC final. Leur enseignement durable est plus sobre : quand les échanges sont courts, attendre une longue suite de paquets postérieurs laisse de nombreuses pertes au temporisateur le plus grossier.

Sources