Résumé

  • QUIC DATAGRAM transporte un datagramme applicatif de façon non fiable et conserve sa frontière, sans retransmission ni ordre relatif entre datagrammes.
  • max_datagram_frame_size indique une volonté directionnelle de recevoir, non une capacité disponible ni une promesse de livraison.
  • L’ACK d’un paquet atteste un traitement par le transport, pas une confirmation applicative ou commerciale.

La distinction décisive porte sur les couches. Un appel local réussi peut signifier que l’implémentation a accepté une donnée; il ne dit pas nécessairement qu’un paquet a été transmis, qu’il a atteint le pair, que celui-ci a pu conserver le contenu ou que son application l’a traité. QUIC DATAGRAM est conçu pour conserver une frontière de message tout en abandonnant les garanties associées aux flux. Un frame transporte un datagramme applicatif. Il ne crée ni offsets de flux, ni livraison ordonnée des octets, ni retransmission après détection d’une perte. Les messages DATAGRAM ne sont pas ordonnés les uns par rapport aux autres.

Il faut aussi distinguer le frame QUIC DATAGRAM du datagramme UDP qui transporte un paquet QUIC. Le frame se trouve dans un paquet QUIC, et ce paquet peut lui-même être contenu dans un datagramme UDP. Ces objets ne fournissent pas les mêmes faits. La présence du frame dans un paquet n’est pas la réception du message par l’application.

La négociation est directionnelle. La valeur par défaut de max_datagram_frame_size est zéro. Une valeur non nulle annonce la volonté du pair de recevoir des frames conformes dans une direction donnée, sous les conditions applicables de négociation, y compris celles qui concernent le 0-RTT conservé. L’émetteur ne doit pas dépasser la valeur annoncée. Cette valeur ne garantit ni mémoire disponible, ni capacité applicative, ni traitement ultérieur. La taille réellement utilisable peut être inférieure à cause de max_udp_payload_size et du MTU du chemin.

L’extension ne fragmente pas les frames DATAGRAM; le protocole applicatif doit donc gérer une limite plus basse.

Les frames DATAGRAM n’ont pas de QUIC stream ID. Les identifiants de flux logiques, la signification des octets, l’expiration, la déduplication, une éventuelle règle d’ordre, la politique de nouvelle tentative et le signal d’achèvement relèvent du protocole applicatif. Le transport ne peut pas savoir si deux messages représentent la même opération métier.

Après soumission, QUIC construit un nouveau frame et cherche à l’envoyer dans le premier paquet disponible, sous réserve du contrôle de congestion et du pacing. Si l’envoi n’est pas encore permis, l’implémentation doit conserver le frame jusqu’à ce qu’il le soit ou le supprimer avant transmission. Une expiration définie par l’application peut également provoquer cette suppression. Le retour d’une API locale doit donc être nommé selon son contrat réel, jamais transformé automatiquement en preuve de transmission, de réception distante ou d’achèvement.

À la réception, le frame devrait être remis immédiatement à l’application seulement si le pair peut le traiter et en conserver le contenu en mémoire. DATAGRAM ne fournit pas de contrôle de flux explicite et ses données ne consomment pas les limites de flux ordinaires. Le fait de ne pas être bloqué par un crédit de flux ne prouve donc pas une capacité de réception. Le pair peut supprimer un frame qu’il ne peut pas traiter.

Les frames DATAGRAM sollicitent un ACK. Le paquet porteur peut être acquitté, mais le frame n’est pas retransmis après détection de perte. Un ACK retardé reste possible dans les bornes ordinaires; des paquets de sonde peuvent chercher une réponse plus rapide. Un réordonnancement peut inverser une croyance provisoire de perte. L’ACK prouve le traitement par la couche transport du paquet, pas le traitement réussi par l’application distante. Seul un signal applicatif peut établir cette étape, puis éventuellement la conservation durable ou la fin de l’opération.