Résumé

  • Le RFC 6298 calcule le délai de retransmission à partir du temps aller-retour lissé et de sa variation, tout en refusant les échantillons ambigus après retransmission.
  • La première attente peut commencer à une seconde ; un SYN perdu rétablit trois secondes pour les données, puis chaque expiration double le délai avant une nouvelle tentative.

Le silence constitue une preuve faible. Le segment peut être perdu, l’ACK peut être perdu, ou l’un des deux peut simplement être lent. Retransmettre trop tôt crée un doublon et charge un chemin peut-être congestionné. Attendre trop longtemps laisse une perte réelle sans réparation. Le RTO choisit entre ces erreurs sans prétendre connaître l’événement.

L’estimation contient le temps et l’incertitude

Avant toute mesure, le RFC fixe de préférence RTO à une seconde, tout en autorisant une valeur plus prudente. Avec le premier échantillon R, il pose SRTT = R, RTTVAR = R/2, puis RTO = SRTT + max(G, 4*RTTVAR), où G est la granularité de l’horloge.

Pour les mesures suivantes, RTTVAR est mis à jour avant SRTT et utilise l’ancienne valeur de SRTT. Beta vaut un quart, alpha un huitième et K vaut quatre. L’ordre mesure l’écart du nouvel échantillon par rapport à l’estimation précédente. Le RTO reste le temps lissé augmenté du plus grand terme entre G et quatre fois la variation.

Un résultat inférieur à une seconde devrait être arrondi à une seconde. Un plafond n’est permis que s’il atteint au moins 60 secondes. Une mise en œuvre peut être plus conservatrice, jamais retransmettre plus agressivement que l’algorithme.

Tout ACK n’instruit pas l’horloge

L’algorithme de Karn est obligatoire. Après une retransmission, l’ACK peut correspondre au premier envoi ou au second ; il ne doit pas devenir un échantillon RTT, sauf si l’option TCP Timestamps lève l’ambiguïté. Sans horodatages, il faut normalement au moins un échantillon par RTT. Avec eux, plusieurs deviennent possibles sans annuler les règles de l’estimateur.

Ce rôle diffère de PAWS : ici, l’horodatage identifie la transmission acquittée, il ne rejette pas des numéros de séquence rebouclés.

Un temporisateur pour les données les plus anciennes

Lorsque de nouvelles données partent et qu’aucun temporisateur ne tourne, TCP le démarre avec le RTO courant. Un ACK couvrant tout l’encours l’arrête. Un ACK qui confirme de nouvelles données tandis qu’il en reste relance le temporisateur au RTO courant.

À l’expiration, TCP retransmet le plus ancien segment non acquitté, double RTO et redémarre avec cette valeur. Le recul exponentiel rend chaque silence répété plus coûteux à interpréter comme une perte. Une mesure RTT propre peut ensuite faire redescendre RTO ; après plusieurs reculs, l’implémentation peut effacer SRTT et RTTVAR devenus peu crédibles.

La seconde initiale comporte une exception précise. Si un SYN expire avec un RTO inférieur à trois secondes, le RTO doit revenir à trois secondes une fois la connexion établie et les données prêtes à partir. Le chemin a réfuté l’hypothèse rapide.

Le temporisateur agit, il ne diagnostique pas

Un attaquant peut retarder un paquet mesuré pour gonfler RTO ou tenter de le réduire avec du trafic forgé. Le lissage et le recul limitent la persistance, sans authentifier le délai. Une expiration reste donc une action sous incertitude, pas la preuve d’une perte déterminée.

La seule source est le RFC 6298, publié sur la voie de normalisation en juin 2011. Il définit l’algorithme et sa justification historique, pas les paramètres actuels d’un fournisseur ou d’un réseau.