Résumé

  • Dans le cadre DualQ de la RFC 9332, ECT(1) et, selon le contexte, CE identifient le trafic L4S. Ils ne constituent ni un journal de classement, ni un relevé de file, ni une mesure de délai.
  • Un opérateur peut envoyer un paquet ainsi identifié vers la file Classic sans réécrire son champ ECN ; il peut aussi admettre certains paquets non-L4S dans la file L sans leur fabriquer une identité L4S.
  • Le travail collectif de Koen De Schepper, Bob Briscoe, éditeur du texte, et Greg White devient vérifiable grâce aux témoins que la RFC demande de suivre : trafic, marquages, pertes, délai moyen, 99e centile et épisodes de surcharge pour chaque file.

Trois colonnes qu’un voyant vert efface

Un tableau d’exploitation reçoit une capture : le champ ECN contient ECT(1). Il pourrait inscrire trois colonnes. « Identifiant déclaré : L4S. » « File réellement utilisée : inconnue. » « Délai constaté : inconnu. » Il préfère souvent un seul voyant : « faible latence ».

La première version est prudente parce qu’elle respecte la portée de chaque preuve. ECT(1) permet à un nœud compatible de reconnaître l’identifiant L4S. Il ne transporte pas l’historique des classificateurs rencontrés, la révision de leurs politiques, le nom des files, les décisions de l’Active Queue Management ou le temps écoulé à chaque goulot. Deux bits d’en-tête ne peuvent devenir rétrospectivement un carnet de voyage.

Publiée en janvier 2023 dans la catégorie Experimental, la RFC 9332 décrit une AQM couplée à deux files : L pour le traitement L4S, C pour le trafic Classic, une logique AQM propre à chacune et un mécanisme de couplage. L’ordonnanceur donne la priorité à L, mais cette priorité doit être bornée afin que C ne soit pas affamée. Le cadre vise une latence de mise en file très faible, peu de pertes de congestion et un débit extensible. Ce but n’est pourtant pas présenté comme un état automatiquement certifié par le marquage.

L’identité survit à une décision locale contraire

La RFC 9331 définit ECT(1), et CE dans les cas pertinents, comme identifiant L4S. Le point d’extrémité qui l’emploie est censé satisfaire les exigences de contrôle de congestion L4S. Un nœud L4S classe normalement ce paquet vers L.

« Normalement » laisse une responsabilité à l’opérateur. La RFC 9332 lui permet, pour des motifs de politique, de faire sortir certains paquets identifiés L4S de la file L. Cette décision locale ne lui donne pas le droit d’effacer l’identifiant de bout en bout. Un opérateur situé plus loin doit pouvoir relire le signal initial et exercer son propre jugement.

Le reçu honnête devient alors : ECT(1) observé ; règle Y appliquée par le nœud X ; placement dans C ; identifiant préservé. Aucune incohérence : le premier fait vient de l’émetteur, les deux suivants du réseau local.

L’opération inverse existe. Une politique peut utiliser des adresses, des DSCP ou un protocole tel que DNS pour admettre un trafic supplémentaire dans L si cela ne nuit pas au service. Ce privilège local ne transforme pas Not-ECT ou ECT(0) en L4S. La file ne confère pas une identité de protocole, pas plus que l’identité ne garantit la même file à chaque saut.

DualQ règle une interaction, pas seulement un rangement

Séparer deux files n’est que la partie visible du dispositif. Les contrôles de congestion Classic ont souvent besoin d’une certaine quantité de données en attente pour utiliser le lien. Les contrôles Scalable peuvent répondre à des signaux ECN fréquents par de petites variations de débit. Réunir les deux comportements sans précaution permettrait au second d’être beaucoup plus agressif qu’un flux compatible Reno.

DualQ sépare les délais mais couple les signaux de congestion. Dans l’explication de la RFC, l’AQM Classic produit une probabilité de base. Son carré sert au marquage ou à la perte Classic ; une version mise à l’échelle fournit la pression couplée vers L. L’AQM de la file L retient le signal le plus fort entre sa propre réaction au délai immédiat et ce signal venu de C.

Un marquage CE n’est donc pas un chronomètre. Il peut traduire la dynamique immédiate de L, une pression importée par le couplage ou une réponse de surcharge. Il ordonne au contrôle de congestion de réagir ; il ne dit pas combien de microsecondes ce paquet précis a attendu.

Les mauvais appariements exigent eux aussi une preuve d’exécution. ECT(1) placé dans C devrait recevoir la probabilité couplée. ECT(0) dans L doit être traité en tenant compte d’un contrôle Classic et de la cible de délai de L. Pour Not-ECT dans L, la protection contre les flux non réactifs influence le comportement. Compter les seuls paquets ECT(1) ne révèle aucune de ces branches.

La faible latence a plusieurs horloges

Même un reçu complet de la file L n’atteste qu’une composante de l’expérience. La mesure de délai définie par la RFC exclut le temps de sérialisation du paquet en tête et l’accès au média. Elle n’englobe ni la propagation, ni les autres nœuds, ni une reprise du transport, ni l’ordonnancement du serveur, ni le travail de l’application.

Un paquet peut donc traverser une file L en quelques microsecondes et terminer une requête lente. À l’inverse, un petit paquet Classic peut trouver une file vide et passer rapidement sans devenir L4S. Le nom du service, le délai local et la réponse de bout en bout doivent rester trois séries.

La moyenne ne suffit pas davantage. La RFC demande qu’une implémentation expérimentale permette de calculer, pour chaque file et chaque intervalle, le délai moyen et le 99e centile ; un maximum peut aider au diagnostic. Une moyenne basse cache une petite population de retards graves. Un maximum sans fenêtre transforme un incident ancien en état permanent. Il faut publier statistique, intervalle, population et emplacement.

Enfin, une DualQ sur un accès ne certifie pas le chemin. Un autre goulot, un ordonnanceur Wi-Fi, un tunnel ou une interface amont peut dominer le délai. Dire « chemin L4S » revient à énoncer une propriété distribuée, qui réclame plusieurs témoins.

La surcharge rend la promesse conditionnelle

En charge ordinaire et réactive, le couplage doit maintenir L peu profonde sans priver C. Sous un trafic inattendu, la priorité doit rester conditionnelle. Une L continuellement occupée pourrait sinon retarder même un petit échange Classic, par exemple une requête DNS ou une fenêtre initiale.

La surcharge persistante révèle une autre limite. Une fois le marquage ECN à 100 %, aucun marquage supplémentaire ne peut renforcer le signal. La RFC demande alors à l’implémentation qui détecte la surcharge d’introduire de la perte Classic pour les deux types de trafic compatibles ECN jusqu’au retour à la normale. Elle recommande aussi d’indiquer début et durée, avec hystérésis pour éviter une tempête d’événements.

L’identifiant d’un paquet ne change pas nécessairement pendant cette transition. La file, le risque de perte et le délai, eux, peuvent changer. Une page d’état crédible doit afficher l’épisode et sa fenêtre temporelle, pas repeindre le même badge L4S.

Une frontière dessinée à plusieurs mains

La RFC 9332 est signée par Koen De Schepper, Bob Briscoe et Greg White ; Briscoe en est l’éditeur. Les remerciements et la liste des contributeurs élargissent encore ce cercle. Il serait faux d’en faire l’œuvre solitaire d’un inventeur ou d’attribuer à Briscoe le contrôle d’un déploiement opérateur.

Le profil IETF Datatracker consulté pour cet article documente son activité durable sur ECN, le contrôle de congestion et les transports. Son site officiel fournit sa biographie publique et le portrait de référence. Ces sources établissent une identité et une contribution documentaire, non une part de marché actuelle ni le comportement d’un réseau donné.

L’intérêt de sa contribution tient à une limite bien formulée : stabiliser le plus petit signal interopérable, préserver la liberté de classement local, puis demander aux implémentations les mesures que le signal partagé ne saurait porter. Cela rejoint la spécification initiale minimale de Heng Lu. La primauté du code exécuté ajoute que la norme prouve la disponibilité d’un mécanisme ; seule l’exécution prouve la branche suivie.

Le problème d’agence apparaît lorsque la preuve la moins chère reçoit l’étiquette la plus ambitieuse. Un fournisseur expose aisément un compteur ECT(1). L’opérateur paie davantage pour conserver versions de classificateur, compteurs par file et longue traîne du délai. Le client supporte le risque du service. Accepter « L4S activé » sans reçu d’exécution transfère le pouvoir de déclarer vers celui qui mesure le moins.

Six reçus pour une affirmation mesurable

Le reçu de l’émetteur note transport, version du contrôle de congestion, décision de poser ECT(1), borne de flux et instant. Celui de la frontière réseau conserve le champ ECN observé, l’encapsulation, l’interface, le sens, l’heure et l’intégrité de capture.

Le troisième reçu appartient au classificateur : équipement, logiciel, politique, règle correspondante, identifiants supplémentaires et placement L ou C. Le quatrième appartient à la file : instance AQM, entrées et sorties, choix d’ordonnanceur et branche déclenchée par un appariement inhabituel.

Le cinquième joint les pressions native et couplée aux marquages CE, pertes ECN et non-ECN, entrée et sortie de surcharge, paquets arrivés, présentés à l’AQM et transmis. Le sixième conserve, par file, utilisation, moyenne, 99e centile, maximum éventuel, intervalle et définition de l’histogramme. RTT et temps applicatif restent des mesures séparées.

Ces reçus ne contestent pas l’identifiant L4S. Ils lui rendent sa véritable autorité : annoncer une intention de protocole, sans prétendre avoir déjà observé le traitement et le résultat.

Sources