Résumé

  • RACK combine horodatages d’envoi, ACK/SACK, RTT et fenêtre de réordonnancement pour marquer une plage perdue ; il n’observe pas une suppression physique.
  • Un DSACK ultérieur peut indiquer que la retransmission était superflue, sans identifier la cause réseau.
  • L’exploitation doit conserver les données de l’inférence et chaque copie transmise au lieu de transformer une décision de récupération en fait d’incident.

Récupérer avant de connaître toute l’histoire

RACK répond à une question pratique : les preuves de livraison plus récente et le temps écoulé suffisent-ils pour retransmettre une plage antérieure non acquittée ? L’émetteur ne peut attendre indéfiniment une certitude impossible ; il fixe une limite à l’ambiguïté.

La RFC 8985 exige deux éléments. Un segment envoyé plus tard a été livré, et l’ancien reste non livré au-delà du RTT estimé augmenté de la fenêtre de réordonnancement. Cette règle est plus informative qu’un simple chronomètre, mais demeure une inférence locale au moment de la décision.

ECMP, les reprises radio ou d’autres mécanismes peuvent changer l’ordre d’arrivée. La copie initiale peut être encore en route quand sa plage est marquée perdue. La marque signifie qu’il faut réparer la plage selon l’algorithme, pas qu’un dispositif a vu le paquet disparaître.

L’horloge de RACK fait partie de la preuve

RACK conserve le dernier horodatage de transmission de chaque segment, retransmissions comprises. Il prend comme référence le segment envoyé le plus récemment parmi ceux dont la livraison est connue et en déduit un RTT récent.

La fenêtre de réordonnancement est adaptative et bornée. Une petite valeur initiale accélère les flux courts au prix de quelques retransmissions parasites. Des indices de réordonnancement peuvent l’élargir, mais sa borne évite une attente sans fin.

TLP traite le cas où les ACK sont rares. Avant le RTO, il envoie de nouvelles données ou retransmet le segment portant le numéro de séquence le plus élevé afin de solliciter un ACK. Ce retour enrichit l’inférence de RACK ; il ne constitue pas l’observation directe d’une perte.

DSACK corrige le récit après coup

La RFC 2883 permet au récepteur de signaler une plage reçue en double. Après une retransmission, un DSACK établit seulement que des données dupliquées sont arrivées. Rapproché de l’historique de l’émetteur, il peut suggérer une retransmission superflue, sans déterminer quelle copie est arrivée, à quel moment ni pour quelle raison.

La RFC 8985 recommande alors d’agrandir la fenêtre de réordonnancement. DSACK ne désigne toutefois ni file, ni radio, ni lien, ni tunnel, ni membre ECMP responsable : il constate un doublon, pas sa cause complète.

Sources