Résumé

  • Le RFC 10055 consigne les appels système et formats de données auxiliaires utilisés par Chromium sur Apple, Linux et Windows ; il informe les implémenteurs sans imposer une API aux plateformes.
  • Pour exploiter un signal ECN, l’application doit activer sa remontée, lire les données associées à chaque datagramme et interpréter leur représentation propre au système.

La congestion peut être visible dans l’en-tête IP tout en restant absente du raisonnement du transport. Entre le routeur qui marque un paquet et le contrôleur qui adapte son débit, une interface de socket peut rompre la chaîne.

Le RFC 10055 documente cette interface à partir d’expériences menées pour faire fonctionner l’ECN sur UDP dans Chromium, sous Apple, Linux et Windows. Il s’agit d’un RFC Informational, pas d’une norme Internet qui obligerait les systèmes à adopter les mêmes options. Le texte se présente aussi comme un instantané et renvoie aux documents des plateformes pour les évolutions ultérieures.

L’ECN occupe deux bits du champ IP. Le RFC 3168 définit ce mécanisme de notification de congestion ; l’architecture L4S du RFC 9330 s’appuie sur des signaux explicites plus fréquents. Un transport doit cependant pouvoir lire ces bits. QUIC, décrit dans le RFC 9000, vérifie les compteurs ECN reçus sur un chemin et peut désactiver l’ECN si la validation échoue. Cette logique n’a de prise que si les marques parviennent au processus qui tient le transport.

Le RFC 10055 distingue l’activation de la réception et la lecture de la marque datagramme par datagramme. Sur Linux, Apple et FreeBSD, IPv4 utilise IP_RECVTOS et IPv6 IPV6_RECVTCLASS, puis l’application lit des données auxiliaires avec recvmsg(). Un socket IPv6 Linux qui reçoit aussi de l’IPv4 exige un réglage supplémentaire IP_RECVTOS. Apple et FreeBSD n’ont pas cette exigence dans le cas documenté. Une configuration « IPv6 activé » ne suffit donc pas à décrire une capacité commune.

Windows propose une autre surface. La documentation recommande WSASetRecvIPEcn(), dont les données arrivent avec WSARecvMsg, mais le RFC relève des cas particuliers pour le double empilement et les adresses IPv4 mappées dans IPv6. L’intégration doit vérifier la famille du socket, son mode et le type de message de contrôle effectivement rendu.

La donnée reçue n’a pas partout la même forme. Linux, Apple et FreeBSD peuvent fournir l’octet complet du champ DS, qui contient le DSCP et l’ECN ; Windows fournit le seul codepoint ECN dans IP_ECN ou IPV6_ECN. Un parseur commun qui applique partout le masque d’une seule plateforme risque de confondre une valeur ECN et un octet complet.

L’émission ajoute encore un choix. Un marquage constant peut être réglé au niveau du socket sur les plateformes Unix couvertes par le RFC. Un socket partagé par des connexions dont la capacité ECN varie peut plutôt nécessiter une marque par paquet. Dans l’instantané du RFC, Windows ne propose pas le marquage par socket. Modifier IP_TOS ou IPV6_TCLASS peut également écraser le DSCP sur certains systèmes : il faut préserver la valeur existante et coordonner les écritures concurrentes.

La conséquence dépasse la portabilité. Une application doit savoir si elle n’a reçu aucune marque parce que le chemin n’a pas signalé de congestion, parce que l’option n’était pas active ou parce que son parseur a mal compris le message. Le RFC souligne qu’un soutien ECN inégal peut aussi aider un pair à reconnaître le système d’exploitation. Il ne mesure ni la fréquence ni la portée de cette empreinte.

La preuve utile commence donc par la configuration concrète, pas par une case « IPv6 pris en charge ». Une matrice par version du système, famille IP et mode double pile doit noter l’option acceptée, le message auxiliaire présent, le codepoint extrait, le DSCP préservé puis les compteurs validés par le transport. La réception d’un codepoint ne prouve pas à elle seule que l’émetteur a ajusté son contrôle de congestion.

Le choix de conception est modeste : garder un objectif commun — livrer le bon codepoint pour chaque paquet sans altérer l’état DSCP adjacent — tout en laissant les API locales aux systèmes. L’uniformité utile se situe dans le contrat testé, pas nécessairement dans l’appel système.

Sources