Résumé

  • PTO déclenche une ou deux sondes qui sollicitent un ACK et augmente le backoff.
  • Il ne déclare pas à lui seul la perte d’un paquet et ne prouve ni congestion ni ACK manquant.
  • Le temporisateur, l’espace de numéros de paquets, la sonde, les ACK ultérieurs et la déclaration de perte sont des faits distincts.

Dans QUIC, l’erreur commence lorsqu’un tableau de bord rassemble plusieurs événements sous une même étiquette. Une expiration PTO est d’abord l’événement d’un temporisateur dans un espace de numéros de paquets précis. Elle signifie que des paquets sollicitant un ACK n’ont pas produit le progrès attendu pendant la période calculée, ou qu’un serveur peut devoir sonder avant la validation de l’adresse du client. La réponse consiste à rechercher ce progrès : l’endpoint envoie au moins une sonde et peut en envoyer jusqu’à deux, sous forme de datagrammes de taille complète qui sollicitent un ACK, puis augmente le backoff.

Rien dans cette séquence ne désigne un paquet perdu.

Le PTO est géré séparément dans chaque espace de numéros de paquets. Initial, Handshake et Application Data ne forment donc pas une seule file. Le calcul ordinaire est smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay. Dans Initial et Handshake, le terme max_ack_delay est fixé à zéro. Le PTO d’Application Data n’est pas armé avant la confirmation du handshake. L’envoi ou la réception d’ACK pour des paquets sollicitant un ACK peut relancer le temporisateur, tout comme l’abandon des clés Initial ou Handshake. Après expiration, la période suivante double ; les périodes consécutives augmentent exponentiellement dans les différents espaces de numéros de paquets, jusqu’à la limite distincte de l’idle timeout.

La priorité de détection est essentielle. Un time-threshold loss-detection timer passe avant le PTO, qui ne doit donc pas être armé lorsqu’un tel temporisateur est établi. Des plages d’ACK ultérieures peuvent ensuite permettre une déclaration de perte par packet threshold ou time threshold selon RFC 9002. Cette déclaration produit une preuve différente. Marquer tous les paquets non confirmés comme perdus au moment de l’expiration revient à anticiper cette preuve.

Le mot « retransmission » brouille aussi le mécanisme. Les nouvelles données doivent être utilisées lorsqu’elles existent. Sinon, une information déjà envoyée peut être portée par une nouvelle trame et un nouveau paquet. En l’absence de données, PING ou une autre trame sollicitant un ACK convient. RFC 9000 précise que les paquets QUIC perdus ne sont pas renvoyés tels quels : l’information à réparer est portée de nouveau dans de nouvelles trames et de nouveaux paquets. Renvoyer une information n’est donc pas rejouer le même paquet ; PING et PADDING ne contiennent aucune information retransmissible.

Avant validation de l’adresse, les sondes du serveur consomment l’anti-amplification limit. Si le budget ne permet plus d’émettre, le serveur ne doit pas armer son PTO avant qu’un nouveau datagramme du client n’augmente ce budget. Le client peut néanmoins devoir sonder pour débloquer le serveur. Ce budget ne démontre ni perte de paquet ni perte d’ACK.

RFC 9002 autorise une stratégie d’implémentation consistant à déclarer perdu le reste des paquets en vol au lieu d’envoyer une sonde. C’est un choix explicite, pas la sémantique du PTO, et il peut provoquer une réduction inutilement agressive du débit du contrôleur de congestion. Une expiration ne prouve pas davantage que la congestion est en cause, que le récepteur a traité des données applicatives, qu’un service a répondu ou qu’une opération métier est terminée.