Résumé

  • PADDING est une trame d’un seul octet, sans contenu ni valeur sémantique ; elle augmente la taille mais ne transporte ni données applicatives, ni STREAM, ni CRYPTO.
  • Un paquet composé uniquement de PADDING est en vol et consomme la fenêtre de congestion sans provoquer les accusés de réception qui l’ouvrent ; RFC 9000 indique que l’émetteur SHOULD ajouter périodiquement d’autres trames ack-eliciting.
  • Le client MUST porter à au moins 1200 octets chaque datagramme UDP qui transporte Initial ; le serveur MUST faire de même pour un datagramme qui transporte un paquet Initial ack-eliciting. Aucune de ces règles ne prouve un progrès.

Un opérateur voit un datagramme UDP de 1200 octets et coche « Initial utile ». Puis les octets en vol augmentent et le tableau de bord annonce une progression. Cette conclusion mélange des registres distincts : longueur du datagramme UDP ; frontières et type des paquets QUIC ; nombre d’octets PADDING ; présence d’une trame qui déclenche un accusé ; octets en vol ; utilisation de la fenêtre de congestion ; accusé de réception ; état de la négociation ; résultat applicatif.

Une trame QUIC PADDING est de type 0x00 et ne contient que son octet d’identification. Elle n’a ni contenu ni valeur sémantique. Elle peut agrandir un paquet, atteindre la taille minimale d’un Initial et réduire certaines informations visibles par l’analyse du trafic. Elle ne transporte aucune donnée d’application, STREAM ou CRYPTO, aucun reçu, résultat ou signal d’achèvement. Son volume ne prouve donc ni traitement utile par le pair, ni progression de la négociation, ni livraison applicative.

Un datagramme peut contenir un Initial avec PADDING et d’autres trames, ou plusieurs paquets QUIC réunis. Sa longueur seule ne permet pas d’identifier les octets qui ont fait avancer la négociation. Il faut, sur un point d’extrémité autorisé, examiner les frontières de paquets et les trames protégées. Un paquet contenant PADDING peut aussi contenir une trame ack-eliciting et être acquitté. L’ACK fournit alors une preuve limitée du traitement du paquet ; il ne transforme pas PADDING en contenu de négociation ou d’application.

RFC 9000 exclut ACK, PADDING et CONNECTION_CLOSE du contenu qui déclenche un accusé. PADDING seul ne provoque donc pas l’envoi d’un ACK par le récepteur. Un paquet contenant PADDING reste néanmoins en vol pour le contrôle de congestion. Un paquet composé seulement de PADDING consomme la fenêtre sans produire les accusés qui l’ouvrent ; l’émetteur SHOULD donc ajouter périodiquement d’autres trames ack-eliciting. La hausse des octets en vol ne vaut pas preuve de progrès utile.

La règle des 1200 octets est précise. Le client MUST étendre chaque datagramme UDP qui porte un paquet Initial à au moins 1200 octets, par PADDING ou par réunion de paquets. Le serveur MUST faire de même pour un datagramme qui porte un paquet Initial ack-eliciting. Cette règle teste le support d’une MTU raisonnable du chemin ; l’expansion côté client réduit aussi l’amplification disponible avant validation de l’adresse. Elle n’exige pas 1200 octets de contenu de négociation et tout Initial n’utilise pas PADDING.

Avant validation de l’adresse, toutes les charges UDP attribuables à la connexion entrent dans le compte trois fois du serveur, y compris les octets PADDING. L’absence de sémantique ne supprime pas le coût. PADDING peut modifier certaines longueurs observables, sans garantir la confidentialité ni masquer le temps, la direction, le nombre de paquets ou toutes les longueurs. La conservation d’une preuve respectueuse de la vie privée et ce registre sont des recommandations éditoriales, non des exigences QUIC.