Résumé

  • RFC 9616 ajoute à Babel une mesure aller-retour entre voisins qui ne requiert pas d’horloges synchronisées, puis recommande lissage, fonction de coût bornée et hystérésis.
  • Les valeurs par défaut — 10 ms, 120 ms et une pénalité maximale de 150 — matérialisent des hypothèses d’exploitation : en dessous, tous les liens sont « bons » ; au-dessus, tous sont également « mauvais ».
  • La preuve utile doit distinguer horodatage, échantillon, valeur lissée, paramètres, décision de route, installation dans le plan de transfert et résultat applicatif.

Le premier seuil de RFC 9616 est facile à lire et facile à sous-estimer. Lorsque le RTT lissé reste sous rtt-min, la composante de coût demeure égale au coût nominal C. À 2 ms comme à 9 ms, si rtt-min vaut 10 ms, le protocole ne paie aucune différence supplémentaire. Cette indifférence est recherchée : de petites variations sur un lien local ne doivent pas provoquer des changements de route permanents.

Mais le plateau n’est pas une vérité physique. Il dit seulement que, pour cette politique de routage, la différence a été déclarée non pertinente. Une plateforme de négociation, un système industriel ou une application interactive peut lui attribuer une valeur tout autre. Le tableau de bord peut donc annoncer deux chemins équivalents alors que le produit ne les vit pas comme équivalents.

C’est la frontière centrale de ce RFC. Il normalise une chaîne de décision raisonnable. Il ne donne pas au nombre final l’autorité de représenter toute la qualité de service.

Le problème qu’un nombre de sauts ne savait pas voir

RFC 8966 définit Babel comme un protocole à vecteur de distance qui évite les boucles, mais il n’impose pas un unique algorithme de métrique. Des mises en œuvre évaluent les pertes sur les liaisons radio et utilisent ailleurs un simple nombre de sauts. Dans un réseau superposé, cette simplicité gomme la géographie.

Un tunnel Paris–Paris et un tunnel Paris–Tokyo peuvent chacun apparaître comme un saut. Dans la topologie en losange décrite par RFC 9616, Babel peut alors choisir le trajet lointain environ une fois sur deux. Le résultat augmente probablement délai et coût sans violer aucune règle de comptage.

L’extension ajoute le signal qui manquait. Chaque Hello porte un horodatage. Le voisin conserve cet instant et son heure locale de réception. Lorsqu’il renvoie un IHU avec un nouveau Hello horodaté, le premier routeur calcule RTT = (t2 - t1) - (t2' - t1'). Les différences sont formées à l’intérieur de chaque horloge locale ; les horloges n’ont donc pas à partager une origine.

La méthode vient des travaux de Mills documentés dans RFC 891 et rappelle les disciplines temporelles de RFC 5905. Sur le fil, l’ajout reste mince : le registre IANA Babel Parameters attribue le type 3 au sous-TLV Timestamp. Le Hello transporte quatre octets de temps, l’IHU huit.

Cette économie importe. Le mécanisme commun observe une grandeur interopérable ; il ne centralise ni le choix des seuils ni l’objectif commercial. Les opérateurs restent responsables de l’interprétation.

Où l’horloge touche la pile

La mesure commence avant l’équation. L’horodatage d’émission devrait être pris juste avant que le paquet soit remis à la pile réseau ; celui de réception, juste après sa sortie. Une implantation qui horodate plus tôt peut inclure sa propre attente locale. Une autre qui horodate plus tard peut attribuer la charge de son ordonnanceur à la liaison.

RFC 9616 propose précisément de réserver un sous-TLV de bourrage, puis de le remplacer au dernier moment par le temps réel. Ce détail est une limite de preuve. Deux équipements peuvent être conformes au format, échanger des valeurs plausibles et mesurer des surfaces légèrement différentes.

Les compteurs sont des entiers non signés de 32 bits en microsecondes. Ils bouclent après environ 71 minutes. Un redémarrage peut aussi déplacer arbitrairement l’origine. Le RFC recommande une fenêtre de trois minutes pour écarter des valeurs futures, anciennes ou incohérentes. Une moyenne sans compteur de rejets ne révèle pas si elle repose sur un flux dense d’échantillons actuels ou sur quelques survivants.

Enfin, ce RTT appartient à une adjacence Babel. Il ne mesure ni toutes les files d’attente ultérieures, ni les pertes sur le chemin complet, ni le serveur, ni les dépendances applicatives. L’échantillon est exact dans son domaine ; le faire parler hors de ce domaine produit la faute.

Le signal brut ferait courir la route après son ombre

Le délai n’est pas indépendant de la décision. Une route à faible RTT attire du trafic. Ce trafic peut la congestionner, donc augmenter le RTT. Le routeur la quitte ; la file se vide ; le RTT baisse ; le routeur revient. Sans frein, le contrôle crée le phénomène qu’il cherche à corriger.

Les pointes sporadiques posent le même problème. Un seul échantillon sous charge peut inverser deux routes proches. Le travail primaire A delay-based routing metric décrit ce risque et rapporte une absence d’oscillation dans ses essais réels, avec des oscillations de l’ordre de la minute dans des constructions défavorables. C’est un résultat expérimental situé, pas une garantie universelle.

La première protection est le lissage exponentiel : RTT := α RTT + (1 - α) RTTn. RFC 9616 recommande un alpha entre 0,8 et 0,9, et 0,836 par défaut. Le passé pèse lourd. Un pic isolé compte peu ; une rupture réelle met plus de temps à devenir visible.

La deuxième protection est la fonction bornée. Sous rtt-min, coût nominal. Entre rtt-min et rtt-max, croissance linéaire. Au-dessus, pénalité plafonnée. Les valeurs recommandées sont 10 ms, 120 ms et 150. La troisième est l’hystérésis : une variation intermédiaire ne remplace pas immédiatement la route.

Le prix de la stabilité est donc mesurable : de la mémoire, des distinctions volontairement supprimées et une dette de convergence.

Le second plateau masque aussi des différences

Au-delà de 120 ms avec les réglages par défaut, 121 ms et 600 ms reçoivent la même pénalité de délai. L’objectif consiste à empêcher un lien très mauvais ou congestionné d’injecter une valeur sans borne dans la décision. Mais lorsqu’aucun bon chemin n’existe, cette égalité peut masquer la seule différence encore utile.

Réduire rtt-max améliore la stabilité et agrandit la zone où tous les chemins lents sont assimilés. L’augmenter conserve davantage d’information, au risque d’une métrique plus mobile. Régler max-rtt-penalty détermine avec quelle force cette composante repousse un trajet, relativement aux coûts nominaux accumulés.

Aucune de ces valeurs ne mesure directement le prix, la bande passante, le taux de perte ou la gravité pour le client. La pénalité 150 n’est pas une conversion des millisecondes en préjudice. C’est un poids dans l’algèbre choisie par Babel.

Le propriétaire opérationnel des paramètres doit donc être nommé. Il doit pouvoir expliquer ce qui est considéré local, ce qui est considéré évitable, combien de temps une route dépassée peut rester en place et quelle observation peut justifier un changement. Copier un défaut ne supprime pas cette responsabilité ; cela la rend seulement moins visible.

L’hystérésis achète du calme avec du retard

RFC 9616 reconnaît qu’après un changement de RTT, le réseau peut conserver une route sous-optimale pendant des secondes, voire des minutes. Dans un overlay fixe, ce délai évite des bascules coûteuses et du réordonnancement. Dans un réseau mobile, il peut maintenir une décision après que sa réalité physique a disparu.

Le faible nombre de changements de route n’est donc pas une preuve d’optimalité. C’est une preuve de stabilité. La stabilité est souvent désirable, mais elle doit être comparée à la fraîcheur requise.

Un essai valable doit provoquer des transitions : augmenter le délai sans toucher à la capacité, réduire la capacité sans modifier la propagation, introduire une rafale, redémarrer un voisin et déplacer un nœud. Il faut dater l’échantillon, la moyenne, le coût, la décision, l’installation FIB et le premier paquet effectivement transmis. Le test qui débute après stabilisation ne mesure pas la dette créée par le lissage.

La compatibilité préserve le réseau, pas une sémantique unique

Les routeurs qui ne comprennent pas le nouveau sous-TLV l’ignorent et analysent le reste du TLV. Des équipements étendus et non étendus peuvent donc cohabiter sans boucle ou pathologie causée par ce seul mélange. Le RFC prévient toutefois que le routage peut rester sous-optimal.

Cette propriété permet une adoption volontaire, progressive et réversible. Elle ne signifie pas que tous les segments calculent leur coût de la même façon. Une adjacence peut employer le délai, une autre le nombre de sauts, une troisième la perte radio. La route finale agrège alors plusieurs jugements.

Il faut cartographier la capacité par adjacence, tester les frontières et observer ce qui se passe lorsqu’un nœud ancien devient transit. La phrase « compatible avec l’existant » décrit la continuité du protocole ; elle ne certifie ni uniformité du métrique ni qualité finale.

Cette analyse ne répète pas celle de RFC 9647. Le modèle YANG rend certaines configurations et certains états visibles. RFC 9616 définit comment un signal de délai peut devenir un coût. Voir la valeur n’établit pas encore sa provenance ni son effet.

La sortie de confidentialité change la route

L’origine arbitraire des horodatages évite de révéler directement heure civile, fuseau ou date de démarrage. Une horloge assez précise peut néanmoins aider à inférer une position physique. RFC 9616 permet donc de ne pas envoyer les sous-TLV Timestamp ; les voisins retombent sur le nombre de sauts.

Refuser l’observation est une option réelle, pas un mode dégradé honteux. Mais cette décision modifie le métrique disponible. La gouvernance de confidentialité et la gouvernance du routage se rencontrent ici : exposer le signal augmente la précision possible ; le retirer peut changer le chemin.

Le registre d’exploitation doit indiquer quelles interfaces horodatent, selon quelle menace, quel métrique remplace le délai et quel changement de service suit. Sinon, une bascule de politique peut être confondue avec une panne.

Le reçu complet

Premier niveau : provenance temporelle. Implantation, emplacement des prises de temps, horloge, redémarrage, bouclage, rejets et densité d’échantillons. Deuxième niveau : transformation. Algorithme, alpha, minimum, maximum, pénalité, coût nominal et état d’hystérésis.

Troisième niveau : chronologie de contrôle. Coût calculé, candidats, route choisie, motif de changement et temps de stabilisation. Quatrième niveau : exécution. RIB, FIB, prochain saut, chemin de paquets et pertes. Cinquième niveau : produit. Distribution du délai applicatif, débit, taux d’achèvement et erreurs visibles.

Une baisse du coût prouve seulement que l’algorithme configuré a classé un chemin moins cher à cet instant. Pour affirmer qu’un service s’est amélioré, il faut fermer toute la chaîne.

Sources