Résumé

  • Un pair doit avoir annoncé le paramètre vide reset_stream_at avant de recevoir RESET_STREAM_AT. Il autorise une syntaxe de transport, pas le sens que l’application attribue aux premiers octets.
  • Reliable Size est un minimum livré, non une coupure exacte. Il ne peut qu’être réduit, et un ancien paquet arrivé en retard ne rétablit pas une promesse plus grande.
  • WebTransport impose séparément que son en-tête de session reste dans la partie fiable. C’est cette règle applicative qui rend un flux interrompu encore attribuable.

Un projet approuvé en attente d’annonce, pas encore un RFC

Marten Seemann et Kazuho Oku ont déposé la révision 11 de QUIC Stream Resets with Partial Delivery le 6 septembre 2026. Le Datatracker la classe comme Internet-Draft Standards Track du groupe QUIC. Les états courants indiquent une soumission à l’IESG, un examen IANA « OK — actions nécessaires » et une approbation dont l’annonce reste à envoyer. L’approbation de l’IESG est acquise ; l’annonce formelle, le passage éditorial et l’attribution d’un numéro RFC ne le sont pas encore. Parler déjà d’un RFC effacerait une étape réelle du processus.

La date ne constitue pas seule l’actualité. Après la téléconférence IESG du 3 septembre, la révision 11 a intégré les remarques de plusieurs évaluateurs. Le texte interdit explicitement l’emploi de la trame sans annonce du pair, qualifie Reliable Size de quantité minimale, reformule la retransmission comme celle d’une information courante, distingue mieux les contrôles de cohérence, précise le traitement des paquets réordonnés et recommande zéro après STOP_SENDING.

Ces corrections révèlent quatre détenteurs de décision. Le pair ouvre l’extension. L’émetteur déclare une terminaison et un plancher de livraison. Le protocole applicatif sait quels octets donnent son identité au flux. L’application réceptrice peut demander l’arrêt. Le mot « fiable » ne fusionne pas ces autorités.

Le pair autorise d’abord la trame

Le paramètre de transport reset_stream_at, valeur 0x1d, doit être vide. Une valeur non vide provoque TRANSPORT_PARAMETER_ERROR chez une mise en œuvre qui comprend le paramètre. La phrase ajoutée en révision 11 est sans détour : aucun endpoint ne doit envoyer RESET_STREAM_AT si le pair n’a pas annoncé cette capacité.

La présence du code dans une bibliothèque ne suffit pas. Une version antérieure du serveur, un autre produit du même fournisseur ou l’espoir qu’une trame inconnue sera tolérée ne confèrent aucun droit sur cette connexion. Le consentement est inscrit dans l’état de négociation produit par le pair. La permission est locale à cette relation et à cet instant.

La reprise 0-RTT oblige à conserver cette mémoire. Client et serveur se rappellent si le serveur avait annoncé l’extension. S’il accepte les données précoces, le serveur ne peut pas désactiver ensuite la capacité sur la connexion reprise. Il peut refuser le 0-RTT ; il ne peut accepter le contexte ancien tout en retirant silencieusement l’autorité sur laquelle le client s’est fondé.

Cette continuité ne promet pourtant aucun préfixe applicatif. Elle assure seulement que la trame est licite et compréhensible. L’association d’un flux à une session demeure une question distincte.

Un plancher mobile vers le bas

La trame de type 0x24 porte Stream ID, Application Protocol Error Code, Final Size et Reliable Size. Final Size conserve la comptabilité totale du flux. Reliable Size désigne le préfixe minimal qui doit atteindre l’application malgré la réinitialisation. Un minimum supérieur à la taille finale est impossible et entraîne FRAME_ENCODING_ERROR.

Le mot « minimal » évite une mauvaise lecture. Les données perdues sous cette limite doivent être retransmises. Au-dessus, l’émetteur devrait cesser de retransmettre, mais le récepteur peut remettre à l’application des octets déjà arrivés. La limite ne commande donc pas d’effacer ce qui est en mémoire. Elle garantit un plancher ; elle ne dessine pas un plafond.

Surtout, le plancher initial peut diminuer. Une autre trame RESET_STREAM_AT peut annoncer une valeur plus petite. Un RESET_STREAM ordinaire équivaut, pour la livraison, à Reliable Size zéro. La valeur ne peut jamais remonter. L’information correspondant au plancher courant, et les octets situés en dessous, sont retransmis jusqu’à acquittement.

L’émetteur détient ainsi une option unidirectionnelle : abandonner une partie de l’engagement, sans pouvoir la recréer plus tard. Le récepteur doit gouverner selon la plus petite valeur valide observée, non selon la promesse la plus généreuse apparue dans son journal.

Le réordonnancement ne ressuscite pas la promesse

Un émetteur peut annoncer 128 octets puis réduire le plancher à 20. Rien ne garantit que le réseau livrera les trames dans cet ordre. Si la valeur 20 arrive d’abord, puis l’ancienne valeur 128, le récepteur conserve 20. Le paquet tardif ne remonte pas l’obligation.

La révision 10 disait d’ignorer la trame qui augmentait Reliable Size. Cette formulation pouvait conduire à ignorer aussi une modification illicite du code d’erreur ou de Final Size. La révision 11 demande d’ignorer l’augmentation elle-même tout en contrôlant les autres champs. Le code d’erreur reste identique entre trames de reset ; Final Size reste identique entre ces trames et un STREAM avec FIN. Les écarts produisent respectivement STREAM_STATE_ERROR ou FINAL_SIZE_ERROR.

Une trame n’est donc pas une assertion indivisible. Sa valeur de plancher peut être périmée tandis que ses autres éléments constituent encore des preuves à vérifier. Le parseur qui jette tout le paquet sous l’étiquette « ancien » masque des contradictions d’état importantes.

L’application doit désigner son préfixe irréductible

Le projet QUIC permet explicitement au protocole applicatif de fixer un seuil que Reliable Size ne peut franchir. Ce choix est nécessaire parce que le transport connaît les offsets, pas leur fonction. Il ignore si les premiers octets contiennent un identifiant de session, une souscription, une catégorie d’objet ou un simple contenu facultatif.

WebTransport over HTTP/3 en fournit le cas le plus net. Sa révision 16 exige qu’une réinitialisation de flux de données utilise RESET_STREAM_AT avec une Reliable Size couvrant au moins l’en-tête WebTransport. L’identifiant contenu dans cet en-tête rattache le flux à sa session. S’il disparaît, l’application peut constater une interruption sans savoir à quelle session attribuer l’erreur ou les ressources.

Le projet Media over QUIC Transport emploie un degré différent. Pour un flux de sous-groupe, la Reliable Size devrait inclure l’en-tête afin que l’abonné reconnaisse la souscription et compte le flux réinitialisé dans PUBLISH_DONE. Le texte avertit qu’une taille inadéquate peut laisser l’état de souscription attendre son délai d’expiration.

Le MUST de WebTransport et le SHOULD de MoQ ne sont pas interchangeables. Ils traduisent des arbitrages applicatifs propres. Le transport rend possible un plancher décroissant ; chaque protocole doit préciser le coût de la perte d’identité et les circonstances où l’abandon demeure acceptable.

STOP_SENDING ouvre une voie de retrait

Avec STOP_SENDING, l’application réceptrice indique qu’elle ne veut plus de données sur le flux. La révision 11 recommande alors, si la réponse utilise malgré tout RESET_STREAM_AT, une Reliable Size nulle. Continuer à réémettre un préfixe positif pour une application qui a retiré son intérêt consommerait congestion, crédit de flux et mémoire sans bénéficiaire actif.

Cette sortie confirme que la première Reliable Size n’est pas une obligation éternelle. Elle offre un retour défini vers le comportement d’un reset ordinaire. Une application peut néanmoins interdire ce retrait lorsqu’un intermédiaire a encore besoin d’un en-tête pour acheminer une erreur ou solder une relation. Elle doit alors justifier la persistance, définir qui en paie le coût et expliquer comment elle respecte la demande d’arrêt.

Le caractère fiable d’un mécanisme ne lui donne pas autorité sur la volonté du récepteur. Il faut nommer le bénéficiaire de l’obligation et l’événement qui la termine.

Le mot reset ne libère pas immédiatement les ressources

Final Size reste soumis au contrôle de flux du stream et de la connexion. Faute de crédit, l’émetteur peut devoir attendre avant même d’envoyer RESET_STREAM_AT. Dépasser les limites du récepteur entraîne FLOW_CONTROL_ERROR. La trame sollicite un acquittement ; son information et les octets fiables perdus doivent être renvoyés.

L’état terminal peut donc demander plusieurs allers-retours. Le côté émetteur n’atteint Data Recvd qu’après acquittement du plus petit plancher courant et des données correspondantes. Le côté récepteur attend leur réception. Les considérations de sécurité maintiennent la surveillance des engagements de ressources et de l’épuisement jusqu’à cette fin réelle.

Le suivi opérationnel doit refléter ce coût : capacité négociée, première et plus petite Reliable Size, Final Size, octets retransmis, blocage par contrôle de flux, moment de STOP_SENDING, délai de fin et état conservé jusqu’au timeout. Compter seulement les trames envoyées donnerait une image administrative, pas le comportement du système.

Limites de l’analyse

Les sources établissent le texte, son histoire et les motifs des évaluateurs. Elles ne constituent ni recensement de déploiement, ni benchmark, ni test d’interopérabilité. Aucun navigateur, CDN, relais, service média ou stack QUIC n’a été testé. L’état IANA annonce des actions ; nous ne prétendons pas que chaque inscription demandée est déjà définitive.

Les révisions citées de WebTransport et de MoQ sont elles-mêmes provisoires. Leur langage montre comment une application peut borner l’extension, sans garantir la rédaction finale. Le document QUIC peut encore évoluer dans la chaîne de publication.

La conclusion qui résiste est institutionnelle et technique : permission de parser, minimum courant, préfixe indispensable et volonté d’arrêter sont des décisions séparées. Les implémentations doivent les conserver comme états observables plutôt que les compresser dans une case « reset fiable ».

Sources