Résumé

  • L’ECN ne supprime pas la perte. Il permet à une file active de remplacer, dans certaines conditions, une perte servant de signal par une marque explicite sur un paquet dont le transport s’est déclaré capable de réagir.
  • Le mécanisme n’existe qu’en boucle fermée : l’émetteur annonce sa capacité, le routeur marque, le récepteur renvoie l’indication et l’émetteur réduit sa charge.
  • L’histoire allant des RFC 2481 et 3168 aux règles de tunnel, puis à l’expérimentation L4S, montre que le problème essentiel n’était pas de trouver deux bits, mais de conserver leur sens entre systèmes indépendants.

Quand la perte faisait office de langage

Le contrôle de congestion s’est longtemps appuyé sur une preuve brutale. Une file se remplissait, un paquet disparaissait, l’émetteur déduisait que le chemin était sous pression et réduisait son débit. Ce mécanisme a contribué à éviter l’effondrement de congestion, mais il obligeait la même perte à jouer deux rôles : endommager la transmission et informer sur l’état qui l’avait endommagée.

La RFC 2309, publiée en avril 1998, explique les limites du tail drop. Une file peut rester pleine, allonger le délai et supprimer plusieurs paquets d’une rafale. Plusieurs flux peuvent alors reculer ensemble, puis repartir ensemble. Le document recommande la gestion active de file : agir avant le débordement et maintenir une file moyenne plus courte.

Mais une décision anticipée qui consiste encore à jeter un paquet reste une perte anticipée. La proposition ECN ajoute une autre possibilité. Si le transport a déclaré qu’il comprend la notification explicite, le routeur peut inscrire une marque de congestion sur le paquet au lieu de le supprimer. L’objet arrive ; il porte avec lui la trace de la file qu’il a traversée.

Ce déplacement est la clé historique. Le réseau ne doit plus toujours détruire la preuve pour produire la preuve.

Une boucle à plusieurs propriétaires

La RFC 3168, publiée sur la voie de normalisation en septembre 2001, définit quatre valeurs dans le champ ECN à deux bits : Not-ECT, ECT(0), ECT(1) et CE. ECT signifie qu’un transport est capable d’utiliser l’ECN ; CE indique qu’une congestion a été rencontrée.

La modification du paquet est effectuée dans le routeur, mais l’ECN n’est pas une fonction autonome du routeur. L’émetteur doit d’abord établir la capacité du transport et envoyer des paquets éligibles. Une gestion active de file peut ensuite placer CE là où elle aurait autrement utilisé une perte comme indication. Le récepteur renvoie l’information. L’émetteur réduit sa fenêtre de congestion et confirme qu’il a traité le signal.

Chaque acteur ne connaît qu’une partie de la situation. Le routeur voit sa file mais pas toute la logique de l’application. Le récepteur voit le paquet marqué mais ne règle pas directement la charge de l’émetteur. L’émetteur commande le débit mais ne voit pas lui-même le goulet. Le protocole transporte donc une observation courte entre des autorités séparées.

La perte reste nécessaire. Un paquet Not-ECT ne promet aucune réaction à une marque. Une congestion grave peut toujours imposer des suppressions. Une panne de route, une corruption ou une politique de filtrage ne disparaissent pas. Le fait exact est plus limité : pour un trafic éligible, dans les conditions prévues, le marquage peut remplacer une perte qui aurait servi à signaler la congestion.

De l’expérience au contrat déployable

La RFC 2481 présente l’ECN comme expérience en janvier 1999. Deux ans plus tard, la RFC 3168 l’abroge et précise le comportement d’IP et de TCP. Cette progression ne se réduit pas à l’attribution d’un champ. Elle précise la négociation, le retour de l’indication, la réaction de l’émetteur et la coexistence avec le trafic non ECN.

Le déploiement progressif a façonné le contrat. Un hôte ne peut supposer que tous les pairs ou tous les chemins préservent le signal. Un routeur ne peut marquer sans distinction. Le repli vers la perte doit continuer à protéger le réseau. La compatibilité n’est donc pas une politesse envers des équipements anciens : elle permet au premier adoptant de ne pas imposer une nouvelle défaillance aux autres.

On peut en tirer une inférence opérationnelle : compter les équipements compatibles ne mesure pas la réussite. Un système d’exploitation peut activer l’ECN alors que le goulet ne marque jamais. Un routeur peut marquer alors qu’un tunnel efface CE. Le chemin peut préserver la marque mais l’émetteur réagir autrement que prévu. La bonne unité de mesure est la boucle fermée.

Le nonce et l’honnêteté du retour

Une notification explicite ouvre une question d’incitation : un récepteur pourrait-il dissimuler les marques afin que son émetteur ne ralentisse pas ? La RFC 3540, expérimentale en 2003, propose un nonce ECN. L’émetteur fait varier la valeur ECT et vérifie, grâce au retour, que l’information n’a pas été discrètement amputée.

Cette expérience n’est pas devenue l’usage durable d’ECT(1), mais elle révèle une tension fondamentale. Une marque demande à un acteur de réduire son propre débit au bénéfice d’une ressource partagée. Le réseau produit l’observation ; il ne peut pas supposer que l’intérêt individuel suffira à la rendre efficace.

La RFC 8311, publiée en janvier 2018, classe la RFC 3540 comme historique et assouplit plusieurs restrictions concernant les expériences ECN. ECT(1) redevient ainsi disponible pour d’autres sémantiques expérimentales. Le bit n’était pas vide : il a fallu fermer explicitement l’usage antérieur avant de lui en donner un nouveau.

Le tunnel comme chaîne de garde

Lorsqu’un paquet est encapsulé, un en-tête externe traverse le tunnel tandis que l’en-tête interne est protégé. Si le chemin externe rencontre de la congestion, la sortie du tunnel doit réconcilier deux états. Effacer la marque externe rendrait au paquet interne une histoire faussement propre. Combiner les valeurs sans règle pourrait créer une congestion qui n’a jamais été observée.

La RFC 6040, sur la voie de normalisation en 2010, définit ce traitement. Ses tableaux sont techniques ; leur enjeu est simple : conserver le sens de la congestion lors de l’encapsulation et de la décapsulation, tout en supportant des modes plus anciens.

C’est un fait de traitement des paquets. Par inférence, c’est aussi une règle de chaîne de garde. L’entrée du tunnel choisit l’état externe, le chemin peut le modifier, la sortie décide ce que l’intérieur doit conserver. Le tunnel est donc un point de mesure et non un détail transparent. Deux hôtes compatibles ne prouvent rien sur un VPN, un cœur mobile ou un overlay précis sans mesure du chemin.

Assouplir une règle sans abolir les limites

La RFC 4774, bonne pratique courante publiée en 2006, encadre les sémantiques alternatives du champ ECN. Elle exige que le nouveau traitement soit identifiable, compatible avec l’usage établi et limité lors d’un déploiement partiel. La RFC 8311 autorise ensuite des expériences qui ne traitent plus nécessairement chaque marque comme l’équivalent classique d’une perte. Une permission d’expérimenter n’est pas une certification universelle.

Cette distinction conduit à l’architecture L4S publiée en 2023. La RFC 9330 en décrit l’ensemble. La RFC 9331, expérimentale, utilise ECT(1) pour identifier le trafic L4S et CE pour un retour plus fréquent. La RFC 9332, également expérimentale, définit une gestion active à deux files couplées.

L4S n’est pas seulement l’ECN classique avec un seuil plus bas. Un contrôle de congestion dit évolutif doit répondre à des marques fréquentes sans traiter chacune comme une perte classique. Le réseau sépare le traitement de latence du trafic classique, puis couple les indications afin que les deux files partagent la capacité. La RFC 9330 insiste : il s’agit de séparer la latence, pas d’accorder une priorité de bande passante sans condition.

L’architecture possède trois pièces : une réaction compatible à l’extrémité, un traitement de file au goulet et un identifiant. ECT(1) tout seul ne fournit aucune de ces promesses. Revendiquer l’identifiant sans adopter le comportement associé rompt le compromis de coexistence.

Ce que les RFC ne permettent pas d’affirmer

La chronologie prouve une évolution formelle : une gestion active a motivé un signal plus précoce ; une expérience est devenue norme ; l’intégrité du retour a été testée ; les tunnels et les sémantiques alternatives ont reçu des règles ; L4S a réutilisé le champ dans une architecture plus large.

Elle ne prouve pas qu’en 2026 la majorité des chemins publics préservent l’ECN. Elle n’identifie pas les middleboxes qui effacent les bits. Elle ne montre pas que chaque goulet utilise une gestion active utile, ni que L4S deviendra le service universel de faible latence. Ces inconnues exigent des mesures de déploiement.

L’acquis durable est plus précis : la congestion peut produire une preuve avant de produire une perte. En échange, chaque couche doit dire qui crée cette preuve, qui la conserve et qui agit.

Le paquet survit. La responsabilité, elle, ne disparaît pas.

Sources