Summary
- RFC 9599 explique comment empêcher qu’un signal explicite de congestion disparaisse lorsque le réseau retire une trame de couche basse ou l’en-tête externe d’un tunnel.
- Le codepoint
CEobservé à la sortie atteste l’état de cet en-tête à cet endroit. Il ne nomme pas, à lui seul, la file qui l’a produit et ne prouve ni le retour au récepteur ni la réduction de charge par l’émetteur.
Sur un écran d’exploitation, le raisonnement paraît immédiat : un paquet sort du tunnel avec CE, donc le tunnel était congestionné. La première moitié est une mesure. La seconde est déjà une attribution.
Entre les deux se trouvent plusieurs machines, plusieurs en-têtes et plusieurs règles. Le marquage pouvait être présent avant l’encapsulation. Il pouvait naître dans une file de couche 2. Le décapsuleur pouvait combiner l’état intérieur et l’état extérieur. Une opération de reframing pouvait reporter l’indication sur un paquet IP légèrement postérieur. Et le DSCP qui donnait son contexte au champ ECN pouvait avoir changé en traversant une frontière de domaine.
RFC 9599, publié en août 2024 dans la BCP 89, ne promet pas de résoudre cette attribution. Il traite une question plus fondamentale : comment faire survivre l’indication de congestion lorsqu’un protocole encapsule IP. Une perte se propage naturellement, puisque la trame et le paquet qu’elle contient disparaissent ensemble. Un marquage, lui, réside dans un en-tête qui peut être supprimé à la sortie. Sans transfert explicite, le paquet continue et le signal s’éteint.
Cette différence place le décapsuleur dans la boucle de contrôle. Deux terminaux compatibles ECN ne suffisent pas. Tous les maillons nécessaires pour remonter le signal jusqu’au régulateur de charge doivent savoir le conserver ou le convertir. C’est pourquoi la notion d’ECN-PDU du RFC porte sur la boucle entière. La capacité peut être inscrite dans le paquet, associée à un label, stockée dans un état de flux ou garantie par la configuration. Elle ne se réduit pas aux deux bits visibles au point de capture.
Le document distingue quatre modes. Dans le mode feed-forward-and-up, l’indication avance dans la couche basse, remonte dans IP à la sortie, atteint le destinataire, puis revient vers la source par le transport. Dans le mode feed-up-and-forward, un commutateur de couche basse modifie directement le champ ECN de l’en-tête IP qu’il transporte. Le mode feed-backward renvoie une commande vers l’entrée du sous-réseau. Enfin, le mode null suppose que le cœur de la couche basse ne possède pas de point de congestion propre.
Ces modes produisent des preuves différentes. Le feed-backward peut protéger efficacement un sous-réseau fermé, mais il ne rejoint pas directement la source IP d’origine. L’entrée ralentit, la source continue, et la file se reconstitue à la frontière. Le signal end-to-end apparaît plus tard et ailleurs. Une commande reçue par l’entrée du sous-réseau ne prouve donc pas que l’application source ait été informée.
Le feed-up-and-forward dépend, lui, de la visibilité. Un commutateur Ethernet peut fouiller sa charge utile pour trouver IP. Le chiffrement, un shim inconnu ou une profondeur excessive peuvent l’en empêcher. RFC 9599 demande de borner cette recherche et de revenir à une méthode sûre — par exemple la perte — si l’en-tête n’est pas accessible. L’absence de marque ne devient pas une preuve d’absence de congestion ; elle peut simplement révéler une limite d’inspection.
Dans le mode feed-forward-and-up, l’entrée doit savoir que la sortie traitera le signal. MPLS peut s’appuyer sur une discipline de domaine : dès qu’un nœud intérieur marque, toutes les sorties pertinentes doivent être prêtes. Cet invariant appartient à l’exploitation du réseau. Il n’est pas contenu dans le paquet.
TRILL choisit un autre compromis. Son indication est critique d’entrée à sortie. Une sortie ancienne qui ne la comprend pas rejette la trame. Le résultat est rude mais sûr : le signal ne devient pas invisible. La perte remplace le marquage pour un transport qui ne saurait pas interpréter CE.
Le décapsuleur ne doit donc pas recopier mécaniquement le champ externe. Il calcule l’état sortant à partir des deux couches. Si l’en-tête intérieur est Not-ECT et que l’extérieur porte l’indication la plus grave, le paquet doit être abandonné. Si les deux couches décrivent des niveaux valides, le niveau le plus grave doit prévaloir. Une combinaison impossible mérite un journal ou une alarme ; elle ne justifie pas toujours une règle de rejet gravée pour toujours, car un futur standard peut donner un sens à un codepoint aujourd’hui inutilisé.
À l’entrée, remettre le champ externe à zéro détruirait aussi une partie de l’histoire. Le RFC recommande de conserver le niveau reçu afin que les mesures externes représentent la congestion accumulée depuis le régulateur. La différence statistique entre états intérieur et extérieur peut alors estimer ce qui a été ajouté dans le tunnel.
Mais une estimation agrégée n’est pas un certificat par paquet. Elle suppose des populations alignées, un échantillonnage connu et les mêmes règles aux deux bords. Le reframing rend la limite encore plus claire : préserver la temporalité d’un marquage et préserver sa proportion sont deux objectifs distincts. Pour des raisons de pipeline, une indication peut même apparaître sur un paquet IP légèrement plus tardif que la trame marquée.
Le contexte sémantique compte autant que la copie. PCN, ECN classique et L4S n’interprètent pas toujours ECT(0), ECT(1) et CE de la même manière. Certaines sémantiques dépendent du DSCP. Une frontière qui modifie ce DSCP peut transporter les bits tout en perdant leur sens.
Enfin, le champ doit être déclaré mutable si un nœud intérieur peut le changer. Sinon, un marquage légitime invaliderait l’authentification d’un en-tête supposé immuable. Cette contrainte rappelle ce que le codepoint ne porte pas : aucune signature de la file, aucun reçu du récepteur, aucune preuve de réaction de l’émetteur.
Une validation sérieuse conserve donc l’état intérieur à l’entrée, la règle d’encapsulation, l’identité du tunnel, la capacité de la sortie, la configuration AQM, les états intérieur et extérieur au décapsulage, le paquet transmis ou abandonné, le retour du récepteur, la réception par l’émetteur et l’évolution mesurée du débit ou de la file.
RFC 9599 rend le signal transportable. Il ne rend pas son histoire auto-authentifiante. Le marquage est une pièce de preuve utile ; l’origine, la garde, l’interprétation et l’effet restent à démontrer.
Sources
- RFC 9599
- Fiche Datatracker de RFC 9599
- Errata de RFC 9599
- RFC 3168 : ECN dans IP
- RFC 6040 : ECN dans les tunnels
- RFC 5129 : marquage explicite dans MPLS
- RFC 7141 : notification par octets et paquets
- RFC 7713 : concepts ConEx
- RFC 8087 : bénéfices d’ECN
- RFC 3819 : conseils aux concepteurs de sous-réseaux
- RFC 8311 : expérimentation ECN
- RFC 7567 : recommandations AQM
- RFC 4774 : sémantiques ECN alternatives
- RFC 9331 : architecture L4S
- RFC 9600 : ECN dans TRILL
- RFC 9601 : ECN et tunnels IP avec shim
- Heng Lu : couches de réalité et pouvoir symbolique
- Heng Lu : primauté du code exécuté
- Heng Lu : la réalité plutôt que le plaidoyer
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

