Résumé

  • Le projet MASQUE révisé le 30 septembre impose d'abandonner une trame qui ne tient pas dans la capacité disponible d'un QUIC DATAGRAM, sans la faire passer à la place dans une capsule DATAGRAM. Une autre obligation de perte s'applique si la trame décapsulée dépasse les limites de l'interface de sortie, du réseau de destination ou du récepteur.
  • La version 14 conservait la séquence de contrôle de trame, ou FCS, dans le contenu envoyé. La version 15 s'arrête juste avant ce champ : les interfaces réseau usuelles le retirent à l'entrée et le régénèrent à la sortie. Il s'agit toujours d'un Internet-Draft en évaluation, non d'une norme RFC publiée ni d'un constat de panne.

Le piège apparaît quand on confond deux tableaux de bord. Le premier affiche une session HTTP établie ; le second devrait montrer si les trames qu'elle reçoit peuvent effectivement franchir les limites de taille. On peut avoir le premier au vert et le second en défaut. La nouvelle rédaction donne à l'exploitant un moyen de nommer cette divergence sans attribuer au tunnel une garantie de livraison que le protocole ne formule pas.

CONNECT-ETHERNET emprunte le cadre de MASQUE pour faire circuler des trames de couche 2 par un serveur HTTP. En HTTP/3 avec l'extension QUIC DATAGRAM, chaque trame doit tenir dans un datagramme qui n'est pas fragmentable. La place réellement disponible se calcule après déduction de l'encapsulation HTTP Datagram, et non à partir de la seule taille nominale d'une interface. La version 15 prescrit la perte d'une trame trop grande et interdit expressément de la réacheminer, pour ce seul paquet, sous forme de capsule.

La découverte de la MTU du chemin peut guider l'ajustement de l'interface au fil du temps ; elle ne répare pas une trame déjà refusée.

Les capsules relèvent d'un autre choix de fonctionnement. Elles circulent sur un flux fiable en HTTP/1.1 ou HTTP/2, ainsi qu'en HTTP/3 sans l'extension QUIC DATAGRAM, et peuvent être réparties sur plusieurs paquets TCP ou QUIC. Elles peuvent ainsi transporter une trame plus grande que la MTU du chemin. Ce constat ne contredit pas l'interdiction de repli individuel : le texte distingue des modes, pas une conversion improvisée lorsque le datagramme est trop étroit. Une recette qui ne sonde que de petites trames peut donc manquer le problème de production pertinent.

À la sortie, la contrainte change de propriétaire. Même si la trame est parvenue au point de décapsulation, celui-ci doit la perdre si l'interface, le réseau ou l'équipement destinataire ne peut recevoir sa taille. Le projet recommande un compteur de trames trop grandes abandonnées. Un tel compteur précise l'emplacement du refus ; il ne démontre pas, à lui seul, la cause de toute perte vue par une application ni la qualité d'un service dans son ensemble.

Le changement sur le FCS exige également de lire les deux versions, et non d'inférer une propriété générale de « l'Ethernet ». La version 14 disait inclure le champ de contrôle dans la trame proxifiée pour éviter de le recalculer. La version 15 définit le contenu de l'identifiant de contexte zéro de l'adresse de destination au dernier octet précédant le FCS. Elle explique que les interfaces ordinaires ôtent ce champ à l'entrée puis en créent un nouveau à la sortie.

Elle n'abolit donc pas les contrôles d'erreurs des liens physiques ; elle refuse de présenter l'ancien FCS comme une preuve inchangée de bout en bout. Une extension future pourrait choisir une autre représentation.

Le projet parle d'une liaison Ethernet point à point émulée. Relier cette liaison à un domaine de diffusion externe peut exiger des fonctions de pontage et de prévention des boucles qui restent à la charge des extrémités ou de composants auxquels elles les délèguent. Les balises VLAN sont normalement transmises ; leur interprétation commune exige toutefois un accord que ce texte ne définit pas. L'association facultative de plusieurs VLAN à des URI distinctes facilite des politiques séparées, sans certifier pour autant la livraison de chaque trame.

Le statut mérite la même précision que la technique. Le Datatracker présente la version 15 comme un document actif du groupe MASQUE, transmis à l'IESG, avec un suivi par le directeur de domaine et une objection DISCUSS encore affichée. Son statut visé est Proposed Standard, mais il n'est pas devenu RFC. Le texte permet de décrire une exigence proposée, non de déduire une adoption universelle, un incident chez un fournisseur ou un taux mesuré de pertes.

Sources