Résumé

  • RFC 6298 redémarre le temporisateur lorsqu’un ACK acquitte de nouvelles données, et non à chaque arrivée d’ACK.
  • Le temporisateur démarre lorsque des données sont envoyées, s’arrête quand toutes les données en attente sont acquittées et, à l’expiration, vise le segment non acquitté le plus ancien.

Le front d’acquittement commande l’horloge

Le temporisateur protège les données encore exposées. Lorsqu’un paquet contenant des données est envoyé et qu’aucun temporisateur ne tourne, l’émetteur démarre le délai RTO courant. Les envois suivants ne repoussent pas automatiquement cette échéance.

La règle 5.3 change la situation seulement si l’ACK reconnaît de nouvelles données. Le récepteur a alors confirmé une portion supplémentaire du flux : le premier segment encore non acquitté peut être différent, et le temporisateur repart pour un nouvel intervalle RTO.

Un ACK qui répète l’ancienne frontière ne remplit pas cette condition. On peut donc en déduire que des ACK dupliqués ne peuvent pas acheter indéfiniment de nouveaux délais pour les données non résolues. Cela ne signifie pas qu’ils sont inutiles dans TCP en général.

Quand il ne reste plus de données en attente, le temporisateur est arrêté. S’il expire, l’émetteur retransmet le premier segment non acquitté.

Ce que la norme impose réellement

RFC 6298 impose qu’un segment ne soit jamais retransmis moins d’un RTO après sa transmission précédente. La séquence démarrer-arrêter-redémarrer est présentée comme un algorithme recommandé pour gérer ce temporisateur. Le texte distingue donc une contrainte obligatoire d’une méthode recommandée.

Cette source ne permet pas de conclure sur toutes les implémentations actuelles. Elle ne traite pas ici des acquittements retardés, de l’échantillonnage RTT, de la retransmission rapide, de SACK, du contrôle de congestion ni du recul exponentiel après expiration.

Sources