Résumé

  • RFC 9743 exige le statut Experimental pour un algorithme destiné à l’Internet général qui ne dispose pas de données empiriques à l’échelle de l’Internet ; une spécification expérimentale ne devrait pas devenir le choix par défaut.
  • La mesure doit inclure les voisins : pertes, latence, famine, flux courts, trafic temps réel et concurrents existants. Un succès observé uniquement chez les participants ne constitue pas une preuve de coexistence.
  • La possibilité de désactiver doit être une chaîne testée — autorité, commande, propagation, repli et vérification — et non la simple présence d’un paramètre de configuration.

Le tableau de bord était vert parce qu’il ne voyait que les connexions inscrites à l’expérience. Leur débit avait augmenté. Leur durée médiane avait baissé. Les flux qui avaient renoncé avant d’achever leur travail n’entraient pas dans le dénominateur. Les connexions Reno et CUBIC partageant la file n’étaient pas reliées à la même analyse.

Le résultat était exact et la conclusion fausse.

RFC 9743, publié en mars 2025 comme BCP 133, ne propose aucun algorithme. Il décrit les questions que l’IETF doit poser avant de publier une nouvelle proposition de contrôle de congestion et avant de la considérer pour l’Internet. Son apport le plus utile aux dirigeants consiste à refuser une preuve à une seule colonne. Le comportement du nouvel algorithme, celui des autres flux, le périmètre du test, le statut documentaire, l’activation réelle et l’issue du repli appartiennent à des registres différents.

La norme n’attend pas toujours le déploiement

Le texte prend CUBIC et BBR comme rappel historique : le déploiement de nouveaux contrôles de congestion n’est pas commandé par la publication d’un RFC. CUBIC était déjà largement utilisé avant sa normalisation Standards Track. BBR a évolué et s’est diffusé sans attendre une spécification IETF achevée. Cela ne rend pas la spécification inutile. Elle fournit un langage commun, rend les hypothèses critiquables et permet des implémentations indépendantes.

Mais la chronologie interdit deux raccourcis. Un mécanisme non normalisé peut déjà toucher du trafic réel. Un mécanisme normalisé n’est pas, pour autant, automatiquement sûr dans chaque version, configuration et réseau. Le RFC porte sur une proposition et un degré de consensus ; le binaire porte une histoire de code, de paramètres et de dépendances locales.

RFC 9743 rattache donc le statut à la maturité des preuves. Experimental et Standards Track examinent les mêmes familles de questions, avec des attentes différentes. Sans preuve empirique d’un déploiement à l’échelle de l’Internet, une proposition d’usage général doit demander le statut Experimental. Des données solides issues d’un déploiement mesuré peuvent permettre une demande directe de Standards Track, mais elles ne dispensent pas d’étudier les autres critères.

La taille de l’échantillon ne transforme pas l’observation en garantie universelle. Elle augmente la force de certaines conclusions et laisse d’autres angles morts.

Le trafic voisin fait partie de l’expérience

Un algorithme de congestion agit sur une ressource partagée. Sa propre performance ne suffit donc pas à le juger. RFC 9743 demande d’évaluer la coexistence avec les contrôles IETF courants, notamment Reno, le contrôle de congestion QUIC et CUBIC, ainsi qu’avec des mécanismes non normalisés mais largement déployés.

Le préjudice n’est pas réduit au partage de capacité. Il inclut la latence ajoutée, la perte et la famine. La disparition de tout retour doit conduire à un recul. Les flux courts et longs doivent être confrontés, car une analyse en régime permanent peut ignorer la majorité des connexions qui ne quittent jamais le démarrage lent. Le trafic temps réel poursuit souvent une cible finie avec des contraintes de latence plus strictes ; il peut souffrir sans que le débit moyen du nouvel algorithme paraisse mauvais.

Une mesure exploitable doit donc préciser qui est observé. Il faut connaître la version de l’algorithme, la construction logicielle, le paramétrage, la cohorte, la référence, la file, le type de chemin, les concurrents, la période et le taux d’échantillonnage. Il faut relier les résultats aux flux qui n’emploient pas la nouveauté.

Le tableau vert devient probant seulement lorsqu’il peut montrer ce qui aurait pu rougir.

Plusieurs expériences peuvent être vraies en même temps

RFC 9743 ne sacralise pas une méthode. Une simulation explore les extrêmes et la surcharge. Un émulateur rend une séquence répétable. Un laboratoire isole une interaction. Plusieurs implémentations exposent une ambiguïté. Un essai contrôlé confronte le mécanisme à une exploitation réelle. Une mesure à grande échelle révèle des mélanges que le laboratoire n’avait pas imaginés.

Ces preuves ne s’annulent pas. Un résultat Internet favorable peut manquer les cas rares. Un laboratoire peut provoquer précisément une oscillation sans en mesurer la fréquence. Deux équipes peuvent produire le même résultat parce que la spécification est claire, ou répéter la même hypothèse implicite. Une implémentation unique peut encore justifier une publication, surtout Experimental, si elle est très utilisée, ouverte et associée à un effet Internet positif documenté.

La bonne question n’est pas « quelle méthode gagne ? », mais « quelle affirmation chaque méthode autorise-t-elle ? ». La sécurité contre l’effondrement, la coexistence, la robustesse à un changement de chemin et la valeur pour un utilisateur ne reposent pas nécessairement sur le même essai.

Experimental décrit une dette de preuve

Une spécification expérimentale devrait expliquer pourquoi ce statut convient et quelles informations permettraient une progression. Ce point transforme l’incertitude en inventaire. Une équipe peut alors relier chaque phase de déploiement à un manque précis au lieu d’étendre une cohorte parce que « rien de grave n’est arrivé ».

RFC 9743 ajoute une discipline concrète : une spécification Experimental ne devrait pas être activée par défaut. Elle ne devrait être employée que là où elle est mesurée activement et peut être désactivée si un comportement pathologique apparaît.

Le mot Experimental ne signifie pas dangereux. Standards Track ne signifie pas infaillible. Le texte exige aussi que le résumé d’une spécification dise si le consensus IETF considère l’algorithme sûr pour l’Internet et nomme les environnements où son emploi n’est pas recommandé. Un mécanisme peut être sûr mais peu performant dans un contexte. La sûreté et la recommandation sont deux décisions.

Ces décisions documentaires ne changent aucun réglage. Elles modifient la charge de justification de celui qui déploie.

Le cadre d’évaluation n’est pas une note globale

RFC 9743 demande de considérer la protection contre l’effondrement de congestion, les files excessives, les pertes élevées, l’équité entre flux semblables et le sort des flux courts. Il élargit ensuite l’analyse au mélange d’algorithmes, à l’incrémentalité et aux écarts par rapport aux principes existants.

Pour l’usage général, la file FIFO tail-drop doit être évaluée. Un mécanisme qui dépend d’un signal de chemin doit étudier les tunnels. Les liens câblés forment un cas de base utile ; les liens radio ajoutent perte non liée à la file, capacité changeante, retransmissions et gigue.

Les cas spéciaux comprennent l’AQM, les circuit breakers, le délai minimal variable, les nœuds contraints, les chemins longs, les acteurs malveillants, le réordonnancement extrême, les événements transitoires, les changements soudains de route, le multipath et les centres de données. Le texte avertit que les mesures Internet ne révèlent pas forcément ces situations moins fréquentes.

Il n’existe pas un seuil numérique universel qui convertirait cette matrice en certificat. La communauté doit examiner les critères. Lorsqu’un critère recommandé n’est pas satisfait, elle doit expliquer pourquoi l’absence est acceptable. La transparence du raisonnement fait partie de la preuve.

Un environnement contrôlé doit avoir une frontière réelle

Un algorithme limité à un environnement contrôlé peut s’appuyer sur des données propres à cet environnement. Il n’a pas à simuler tout l’Internet. En échange, le périmètre doit être crédible. RFC 9743 demande comment le trafic est isolé, s’il partage des ressources avec le trafic Internet et ce qui arrive lorsqu’un protocole traverse un pont ou un tunnel vers un chemin public.

Une étiquette « data center » ne ferme pas un routeur. Une documentation interne ne bloque pas un tunnel de secours. Un espace d’adresses ne garantit pas que les ressources sous-jacentes ne soient pas partagées. Si la restriction écrite ne suffit pas, le mécanisme doit porter sa propre contrainte.

La même question vaut pour un essai non activé par défaut. Une option devient de fait obligatoire lorsque la cohorte couvre presque tous les nouveaux clients, lorsque l’ancien chemin disparaît ou lorsque le retrait n’est pas praticable. Il faut mesurer l’exposition, pas le nom du drapeau.

Désactiver est une opération distribuée

Un bouton dans la configuration ne démontre pas le repli. Il faut une autorité identifiée, une commande authentifiée, une sélection exacte des cibles, un délai de propagation, un traitement des connexions existantes, un algorithme de remplacement, des règles de remise à zéro de l’état et une vérification après changement.

Arrêter l’inscription de nouveaux flux peut laisser les anciens actifs. Changer le défaut peut ne pas toucher les politiques épinglées. Un retour de version peut conserver un état calculé sous une autre sémantique. Une partition du plan de contrôle peut laisser une partie de la flotte inchangée. Le repli doit être exercé avant l’incident et observé après exécution.

Les circuit breakers réseau décrits par RFC 8084 constituent une autre enveloppe : ils surveillent l’usage excessif et peuvent interrompre ou réduire un trafic. RFC 9743 attend qu’un bon algorithme réagisse avant cette limite. Le circuit breaker ne remplace ni le contrôle propre à l’algorithme ni la capacité de désactivation du produit. Les trois couches ont des responsabilités différentes.

La promotion n’autorise pas le défaut

Passer d’Experimental à Standards Track renouvelle une affirmation du processus de publication. Passer de l’opt-in au défaut modifie l’exposition des utilisateurs et des ressources partagées. Une organisation peut décider les deux le même jour, mais elle doit produire deux justifications.

Le dossier de promotion doit relier l’algorithme évalué au code livré, conserver les résultats défavorables, décrire les scénarios absents et montrer comment les lacunes annoncées ont été comblées. La décision locale de défaut doit ajouter la composition de la flotte, les files, les chemins, les applications, les concurrents et la capacité de repli.

RFC 9743 offre ainsi un modèle de modestie opérationnelle. Une preuve peut être solide sans être universelle. Une expérience peut être utile sans devenir un défaut. Un statut peut guider sans commander. Le rôle du dirigeant est de maintenir ces frontières jusqu’au dernier effet mesuré.

Sources