Résumé

  • ACK Delay décrit l’attente volontaire entre la réception du plus grand paquet acquitté et l’envoi de l’ACK.
  • latest_rtt est d’abord calculée localement, avant toute correction par ACK Delay.
  • Le décodage et la correction dépendent de ack_delay_exponent, de la phase de handshake, de max_ack_delay et de min_rtt.

La tentation est forte : mesurer le temps entre l’envoi et l’arrivée d’un ACK, soustraire ACK Delay, puis publier le résultat comme latence réseau. Cette opération donne une colonne nette dans un tableau de bord, mais elle dépasse ce que le protocole permet d’affirmer. ACK Delay est une déclaration du récepteur sur l’attente intentionnelle qu’il a contrôlée. Ce n’est ni le temps de propagation, ni la file d’attente réseau, ni une latence aller simple, ni la somme des délais sur l’hôte.

La portée du champ est précise. Le récepteur décrit l’intervalle entre la réception du paquet portant le plus grand numéro de paquet acquitté et l’émission de l’ACK. Le champ ne vaut pas pour tous les paquets présents dans les plages ACK. Il n’englobe pas non plus les retards que le point terminal ne contrôle pas, par exemple un paquet immobilisé dans le système avant son traitement QUIC. Une attente liée à l’indisponibilité des clés peut être incluse selon les règles du protocole, sans devenir pour autant un chronomètre universel du traitement hôte.

L’émetteur forme d’abord latest_rtt à partir de son heure d’envoi du plus grand paquet nouvellement acquitté qui déclenche un ACK et de l’heure locale d’arrivée de cet ACK. L’échantillon brut conserve donc tout l’intervalle observé. ACK Delay intervient ensuite dans le calcul de smoothed_rtt et rttvar. Sa valeur codée n’est exploitable qu’avec ack_delay_exponent et les paramètres de transport pertinents. La valeur par défaut de l’exposant est 3; max_ack_delay est exprimé en millisecondes, avec une valeur par défaut de 25 ms, mais ces valeurs ne remplacent pas le contexte négocié.

min_rtt obéit à une autre règle. Elle repose uniquement sur les observations locales et n’est pas diminuée par ACK Delay annoncé par le pair. Elle sert de plancher contre un rapport erroné; elle ne mesure ni le réseau seul ni un trajet à sens unique. Après confirmation du handshake, l’émetteur retient la plus petite des valeurs entre ACK Delay décodé et max_ack_delay du pair, sans laisser l’échantillon corrigé descendre sous min_rtt. Avant cette confirmation, max_ack_delay ne sert pas de plafond : des attentes plus longues peuvent notamment tenir à la disponibilité des clés.

Un dépassement n’a pas de cause unique démontrée. Après le handshake, l’algorithme traite le surplus au-delà de max_ack_delay comme faisant effectivement partie du délai de chemin, mais l’observation ne permet pas de choisir entre ordonnanceur du pair, perte d’ACK précédents et récepteur non conforme. Le fait que le paquet soit protégé authentifie le champ, pas sa véracité. Et aucun échantillon ne prouve le traitement applicatif, la réponse du service, l’achèvement durable ou un résultat métier.

La bonne pratique consiste à conserver un registre : chemin et connexion, espace de numéros, paquet concerné et heure d’envoi, arrivée et traitement de l’ACK, latest_rtt brut, champ ACK Delay, valeur décodée, ack_delay_exponent, max_ack_delay du pair, état du handshake, min_rtt, plafond et plancher appliqués, échantillon corrigé, smoothed_rtt, rttvar et PTO. Il faut aussi séparer plages ACK, disponibilité des clés, traitement local, perte d’ACK antérieurs et mesure applicative. Une correction d’estimateur ne doit pas être rebaptisée mesure physique.