Résumé

  • Un ACK cumulatif prouve que la frontière des octets reçus a avancé, sans identifier l’instance d’émission responsable lorsque les mêmes numéros de séquence ont été transmis deux fois.
  • Karn interdit d’utiliser ce retour comme échantillon RTT ; le recul exponentiel conserve un temporisateur prudent jusqu’à l’arrivée d’une observation non ambiguë.
  • L’option d’horodatage peut rétablir une attribution limitée, mais elle ne transforme ni tout ACK en mesure valide ni le temps de transport en preuve d’achèvement applicatif.

L’expérience dont le début est inconnu

Imaginons un segment portant une plage de mille octets. L’émetteur note l’heure de départ et arme son temporisateur. Aucun retour n’arrive avant l’échéance ; la même plage de séquence repart. Puis un ACK cumulatif annonce que le prochain octet attendu se trouve après cette plage.

Deux récits restent compatibles. Dans le premier, l’original a traversé lentement et l’ACK aurait été produit même sans la seconde émission. Dans le second, l’original s’est perdu et seule la réémission a atteint le destinataire. Mesurer depuis le second départ raccourcit abusivement le premier récit ; mesurer depuis le premier allonge abusivement le second.

Le chronomètre peut être exact à la microseconde et la mesure rester fausse. Il manque non pas une unité plus fine, mais le lien causal entre un départ particulier et le retour observé. L’ACK n’a jamais promis ce lien : il décrit une frontière dans le flux.

Cette scène sépare deux usages d’une même information. Pour libérer des octets du tampon et continuer l’échange, l’ACK est pleinement valable. Pour réviser l’estimation du trajet aller-retour, il est contaminé par une alternative que le protocole ordinaire ne tranche pas.

Le premier TCP savait adapter le délai, pas filtrer toutes ses observations

Le RFC 793 prévoyait déjà un délai de retransmission dynamique. Un interréseau rassemble des chemins très différents ; attendre toujours la même durée aurait été trop agressif sur certains et inutilement lent sur d’autres. Le texte proposait donc de lisser les temps aller-retour mesurés et d’en tirer un délai borné.

Cette boucle est séduisante : émettre, recevoir un ACK, apprendre, puis régler l’attente suivante. Mais l’apprentissage n’est sûr que si le point de départ de l’échantillon est connu. Après une retransmission, la donnée visible — un ACK à telle heure — ne suffit plus à construire l’intervalle.

Une mauvaise mise à jour peut s’autoalimenter. Si l’on associe l’ACK à la réémission alors que l’original était seulement lent, le RTT paraît trop court. Le prochain délai expire plus tôt, crée davantage de doubles émissions et donc davantage d’ACK sans origine identifiable. L’estimateur fabrique alors les conditions qui semblent confirmer son impatience.

Le RFC 1122 qualifia plus tard le calcul suggéré par le RFC 793 d’insuffisant. Il imposa deux corrections complémentaires : l’algorithme de Jacobson pour intégrer la variation du RTT, et celui de Karn pour sélectionner les mesures admissibles. L’un améliore le calcul ; l’autre protège l’entrée du calcul.

Refuser un échantillon n’est pas refuser le progrès

La règle de Karn tient en une décision : ne pas tirer de RTT d’un segment retransmis. Dès que plusieurs instances couvrent la même séquence, un ACK classique ne permet pas de choisir leur origine. Un programme ne transforme pas ce silence en preuve en prenant le timestamp qui l’arrange.

TCP ne jette pourtant pas l’ACK. Il avance SND.UNA, retire les données reconnues de la file et peut envoyer la suite selon les fenêtres de flux et de congestion. Seul l’usage métrique est refusé. La réception est établie au niveau du flux ; sa durée causale ne l’est pas.

Cette dissociation constitue le cœur historique de Karn. Les systèmes techniques échouent souvent en supposant qu’une preuve recevable pour une décision l’est pour toutes. Ici, la norme autorise l’ACK à gouverner l’état de livraison et lui interdit de gouverner l’horloge lorsque son origine est ambiguë.

Le prix est visible : au moment où le chemin semble instable, l’émetteur perd des observations fraîches. Mais ajouter un nombre douteux ne réduit pas l’incertitude. Cela la masque dans une moyenne et rend l’erreur plus difficile à diagnostiquer.

Le recul exponentiel conserve la prudence

Le RFC 1122 exige également un recul exponentiel des délais successifs. Le RFC 2988, puis le RFC 6298 qui le remplace, détaillent le contrat : conserver SRTT et RTTVAR, calculer RTO, retransmettre le premier segment non reconnu à l’échéance et doubler le délai.

Le recul protège le réseau contre une répétition de plus en plus rapide. Il porte aussi l’incertitude de mesure. Tant que le retour le plus récent ne peut être rattaché à un départ, rien n’autorise l’émetteur à faire retomber son temporisateur sur une valeur optimiste.

Le RFC 6298 prévoit le retour à un calcul normal lorsqu’un nouvel échantillon devient disponible. Après le recul, il faut généralement de nouvelles données émises puis reconnues sans retransmission. Ce n’est donc pas le simple passage du temps qui rend l’estimation propre ; c’est une nouvelle paire départ-retour dont la provenance est défendable.

La règle est asymétrique. Une implémentation peut être plus prudente que le minimum décrit, mais ne doit pas être plus agressive. Une attente excessive pénalise une connexion ; une rafale trop précoce ajoute du trafic à un chemin qui a justement cessé de fournir un retour ponctuel.

L’ACK appartient au flux, non au paquet physique

L’ambiguïté ne vient pas d’un champ oublié par hasard. TCP numérote des octets. L’accusé cumulatif annonce le prochain octet attendu. Les réémissions peuvent redécouper la même plage, les ACK peuvent être retardés ou regrouper plusieurs segments, et le récepteur peut éliminer les doublons.

Exiger que chaque ACK attribue le mérite à un objet réseau précis aurait modifié l’abstraction et déplacé davantage d’état vers le récepteur. Le protocole a préféré une signification commune plus petite. Le destinataire annonce la progression du flux ; l’émetteur, qui connaît ses propres retransmissions, décide si la scène permet une mesure.

Cette frontière doit rester visible dans les outils. Une capture peut placer graphiquement un ACK juste après une retransmission. La proximité ne prouve pas que cette copie l’a provoqué. Sans option d’horodatage correctement négociée et interprétée, l’analyste dispose d’une chronologie, pas d’une attribution.

De même, un ACK dupliqué ou cumulatif n’est pas une déclaration sur le délai applicatif. L’écho réseau, la consommation par le processus distant et la persistance d’une opération sont des faits différents, détenus par des couches différentes.

Les timestamps réintroduisent une identité limitée

Le RFC 6298 énonce une exception : un échantillon peut être pris après retransmission si l’option Timestamp supprime l’ambiguïté d’instance. Le RFC 7323 décrit TSval dans les segments et TSecr dans les retours.

Lorsqu’un ACK renvoie la valeur correspondant à l’instance reçue, l’émetteur peut comparer son horloge actuelle à ce marqueur précis. La causalité qui manquait au simple numéro d’ACK devient disponible dans le contexte de la connexion. Karn n’a plus besoin d’écarter indistinctement toute la période de retransmission.

La présence de l’option ne suffit toutefois pas à valider chaque soustraction. Le RFC 7323 distingue la transmission d’un timestamp de son emploi pour RTO. Une valeur retournée ne doit alimenter la moyenne que si le segment fait avancer le bord gauche de la fenêtre d’émission. Les ACK retardés, les trous de séquence, le réordonnancement et le choix du TSval à renvoyer imposent leurs propres règles.

La fréquence pose aussi une question de mémoire. Les coefficients de l’estimateur du RFC 6298 ont été conçus autour d’un historique d’environ un échantillon par RTT. Si chaque paquet fournit une mesure, appliquer les mêmes poids peut oublier trop vite l’état récent du chemin. Résoudre l’identité ne résout pas automatiquement la politique d’échantillonnage.

Enfin, ces valeurs ne sont pas des heures civiles certifiées. Elles servent à mesurer un écart local à l’aide d’un écho. Elles n’authentifient ni la machine distante, ni l’application, ni la réussite d’une transaction.

Le TCP moderne conserve cette discipline

Le RFC 9293, spécification de base actuelle de TCP, exige toujours le calcul du RFC 6298, y compris Karn. Il maintient aussi le recul exponentiel parmi les mécanismes fondamentaux nécessaires à la stabilité.

La règle a survécu parce qu’elle ne dépend pas d’une vitesse de lien ou d’une taille de fenêtre. Elle dépend d’une limite sémantique : deux instances de la même séquence et un ACK cumulatif ne forment pas une paire temporelle unique.

Les mécanismes modernes peuvent ajouter des signaux, réduire la durée sans mesure ou détecter certaines retransmissions parasites. Aucun progrès ne change le principe d’admissibilité. Une estimation ne devient pas exacte parce que le logiciel en a besoin immédiatement.

La structure des RFC montre aussi une répartition saine. Le TCP de base renvoie au document spécialisé pour le temporisateur. Le document du temporisateur se coordonne avec le contrôle de congestion sans confondre RTO et fenêtre de congestion. L’option Timestamp fournit un indice supplémentaire sans acquérir l’autorité sur la réussite applicative.

Une absence de nombre peut être un résultat de qualité

Les tableaux de bord préfèrent des séries continues. Les interfaces aiment réduire chaque connexion à un RTT courant. Cette préférence crée une tentation : lorsqu’un échantillon manque, reprendre le dernier, choisir le départ le plus proche ou accepter la valeur qui rend la courbe plausible.

Karn propose une discipline plus honnête. Marquer l’intervalle comme non mesurable, conserver le délai reculé et attendre un échange propre. L’absence devient une donnée sur la provenance plutôt qu’un défaut à masquer.

Cette distinction soutient aussi l’audit. Un opérateur doit pouvoir expliquer pourquoi une valeur a modifié SRTT : segment non retransmis, ACK avançant, ou timestamp admissible. Si la télémétrie ne garde que le nombre final, elle perd le moyen de distinguer un changement de chemin d’une attribution inventée.

Leçon plus générale : la validité se définit par usage. L’ACK peut terminer une attente de livraison sans terminer une enquête de causalité. Une option peut lever une ambiguïté sans certifier le monde extérieur. Un standard est robuste lorsqu’il indique non seulement les calculs possibles, mais les observations qu’il faut refuser.

Sources et limites de preuve

Le RFC 793 fournit le contexte du temporisateur adaptatif. Le RFC 1122 consigne l’insuffisance du calcul initial et rend obligatoires Karn, Jacobson et le recul exponentiel. Les RFC 2988 et 6298 fixent la mécanique de RTO et l’exclusion des mesures ambiguës. Le RFC 7323 encadre la désambiguïsation par timestamps. Le RFC 9293 maintient le contrat dans TCP moderne.

Ces textes normalisent des comportements ; ils ne recensent pas les piles déployées ni la fréquence des options et des retransmissions actuelles. Ils ne permettent pas d’attribuer tout timeout à la congestion, de conclure à une attaque ou d’élever un RTT transport en preuve de résultat applicatif.