Résumé

  • Publiée le 4 septembre 2026, la révision 11 de draft-ietf-cats-metric-definition ajoute des règles d’exploitation sur l’accord multifournisseur, le rythme des mises à jour, le repli sur une valeur périmée et les alarmes. Elle reste un Internet-Draft.
  • CATS peut condenser calcul, communication et service dans une note sans unité codée sur un octet. Une représentation identique ne rend pas comparables deux valeurs issues de bornes, poids ou fonctions différents.
  • Le nouveau texte place ce sens dans un manifeste de configuration versionné et synchronisé hors ligne. Il faut encore prouver que chaque composant l’a chargé et que l’instance choisie a réellement servi la requête.

Une première plateforme transforme la marge CPU en note de huit. Une seconde obtient huit en combinant latence, profondeur de file et taux de succès. La première utilise les bornes min-max d’une grande grappe ; la seconde une courbe sigmoïde ajustée à un petit site périphérique. Les deux messages sont bien formés, authentifiés et récents.

Lequel doit recevoir la prochaine requête ?

Le chiffre seul l’ignore. Ses unités, ses entrées et sa politique de calcul ont disparu pendant la compression. Lire ces deux huit comme les degrés d’un même thermomètre donne à une interface compacte une précision qu’elle ne possède pas.

Voilà le point rendu explicite par la révision 11 de CATS Metrics Definition. Le groupe Computing-Aware Traffic Steering cherche à choisir un chemin vers une instance de service en réunissant état du réseau et état du calcul. Le cadre CATS distingue l’agent de métriques de service C-SMA, l’agent réseau C-NMA et le sélecteur de chemin C-PS.

Le projet organise l’information sur trois niveaux. Le niveau 0 garde les mesures brutes et propres au service. Le niveau 1 les regroupe en catégories calcul, communication, service ou composition. Le niveau 2 réduit les informations pertinentes à une note globale normalisée.

Cette abstraction paie l’échelle par une perte d’explication. Le tableau du projet attribue au niveau 0 une précision et une complexité d’encodage élevées. Le niveau 2 est simple et stable, mais moins précis. Sa représentation tient dans un octet, n’a pas d’unité physique et indique seulement que la source est une normalisation.

Même format, règles différentes

La plage proposée va de zéro à dix. Le texte cite la normalisation min-max et la fonction sigmoïde ; l’agrégation peut employer moyenne, minimum, maximum ou moyenne pondérée. Mais il ne normalise pas ces fonctions elles-mêmes : elles restent propres à l’implémentation et à la politique de l’opérateur.

Une borne déplacée change la note d’une mesure inchangée. Un poids différent change l’autorité relative du processeur et de la file. Un sens de comparaison inversé transforme le meilleur nombre en pire candidat. Le format commun transporte le résultat, pas la règle.

Plusieurs champs préservent néanmoins une partie du contexte. Source distingue valeur nominale, estimée, directement mesurée, agrégée ou normalisée. Statistics peut préciser maximum, minimum, moyenne ou valeur courante. Observation_Time rattache éventuellement la valeur à un instant RFC 3339, tandis que Validity_Interval définit sa durée d’usage ; à défaut, la politique locale tranche. RFC 5835 apporte le cadre de composition et RFC 9439 le modèle de provenance.

Ces champs disent de quelle famille de preuve il s’agit. Ils ne conservent pas les échantillons, les valeurs écartées, la formule, les bornes, la charge d’étalonnage ni la version exécutée. Une valeur fraîche et signée peut être calculée fidèlement avec le mauvais manifeste.

La nouveauté de la révision 11 est de traiter l’accord comme une opération. Dans un même domaine administratif, des composants de fournisseurs différents doivent partager la plage, le type et les paramètres de normalisation, la formule et les poids d’agrégation, ainsi que le sens dans lequel une note s’améliore. Sinon, la sélection peut être biaisée.

L’accord doit former un manifeste versionné, synchronisé hors ligne lors de l’initialisation. En production, les composants supposent ensuite que les notes reçues ont suivi ce contrat ; aucune négociation dynamique n’est prévue. Faute d’accord, le projet propose de centraliser normalisation ou agrégation, ou de choisir à partir d’une métrique brute déterminée.

Cette solution est fine : elle évite de charger chaque message de sa recette. Elle déplace toutefois la preuve. Le manifeste stocké ne prouve pas que chaque C-SMA et chaque C-PS l’a activé. La signature protège l’origine et l’intégrité du message, pas l’exactitude de sa dénomination.

Une note fraîche peut déjà décrire le passé

L’état d’un service évolue vite. Le projet lie donc la note à une fenêtre de mesure et à une fréquence d’annonce. Il recommande au plus une mise à jour par instance et par fenêtre, et demande d’évaluer la charge totale lorsque le domaine compte des centaines ou milliers d’instances.

Réduire cette charge retire de la visibilité. Allonger une fenêtre illustrative de dix à trente ou soixante secondes diminue les annonces mais vieillit l’image. N’envoyer que le niveau 2 cache les catégories. Remplacer la série par maximum, minimum, moyenne ou valeur courante change la question posée.

La panne révèle le compromis. La révision propose de conserver la dernière valeur valide pendant deux ou trois fenêtres à titre d’exemple, puis de dégrader ou d’exclure l’instance après le seuil de péremption. En dernier recours, la sélection redevient purement réseau. Les échecs de fraîcheur, composants indisponibles, notes figées, chutes brutales et contradictions entre niveaux 1 et 2 doivent déclencher une alarme.

Avec une fenêtre de dix secondes et une grâce de trois fenêtres, une note peut guider le trafic environ trente secondes après l’arrêt de sa source. Cela peut préserver le service. Cela ne transforme pas une observation ancienne en capacité présente. Il faut enregistrer l’heure d’observation, l’heure de réception, la règle de grâce et le moment de l’exclusion.

Le chapitre de sécurité traite correctement la métrique comme une entrée du transfert : intégrité, authentification de l’éditeur, autorisation par service, protection contre répétition et péremption, chiffrement. Pourtant, une identité cryptographique ne garantit ni le bon capteur ni les bons poids. Elle répond « qui a affirmé huit ? », pas « pourquoi huit était-il juste ? ».

La décision complète dépasse le score

La distinction des couches de réalité de Heng Lu éclaire la chaîne. Le capteur observe ; la fenêtre résume ; l’agrégation hiérarchise ; la normalisation retire les unités ; le sélecteur choisit ; le transfert exécute ; l’application accepte ; l’utilisateur reçoit un résultat. Chaque passage mérite sa propre preuve.

La primauté du code en fonctionnement exige donc un reçu rejouable : identités des observations, fenêtre et statistique, empreinte du manifeste, versions actives aux deux extrémités, note, décision de fraîcheur, entrées du C-PS, CSCI-ID choisi, règle installée, réception et résultat applicatif.

Une spécification initiale minimale peut imposer champs, provenance, temps et identité de manifeste sans centraliser la politique. Poids, bornes et repli peuvent rester locaux. Ce qui ne peut rester opaque, c’est le choix local qui a déplacé le trafic.

La révision 11 ne prouve aucun déploiement ni gain. Elle reconnaît une limite plus importante : la comparabilité est configurée avant l’exécution, puis supposée pendant l’exécution. Un opérateur sérieux doit pouvoir la démontrer avant qu’un mauvais aiguillage ne l’oblige à la reconstituer.

Sources