Résumé

  • Le RFC 10052 ajoute au protocole STAMP une instruction facultative portant sur la taille, le nombre et l’intervalle des paquets renvoyés par le réflecteur.
  • Le bit C ne décrit que deux exceptions locales : dépassement de la MTU de sortie ou des plafonds de débit/volume du réflecteur.
  • Une rafale ressemblant davantage au trafic visé reste du trafic de mesure ; sa conformité ne prouve ni la capacité du chemin, ni le comportement de l’application, ni l’effet pour l’utilisateur.

Le chiffre huit paraît précis. Huit paquets demandés, huit paquets reçus : dans un tableau de bord, la ligne peut facilement devenir verte. Pourtant, la précision du compte ne suffit pas à préciser ce qui a été démontré.

Publié en septembre 2026, le RFC 10052 étend STAMP afin qu’une requête produise, si le réflecteur l’accepte, des réponses différentes du paquet initial par leur taille ou leur nombre. Le texte parle d’une meilleure approximation des conditions d’un trafic applicatif. Il ne déclare pas l’équivalence entre la sonde et l’application. Toute la valeur opérationnelle du document dépend de cette modestie.

La requête n’est pas encore la rafale

Le nouveau Reflected Test Packet Control TLV porte le numéro 12 dans les registres STAMP de l’IANA. Il complète l’échange de base défini par le RFC 8762 et la structure d’extensions du RFC 8972. Trois paramètres retiennent l’attention : longueur souhaitée, nombre de réponses et intervalle en nanosecondes.

Ces champs expriment une intention du Session-Sender. Le Session-Reflector exécute ensuite ses propres règles. Il retient au minimum la taille nécessaire au paquet STAMP et à ses extensions, aligne la longueur, tient compte de la MTU de son interface de sortie et applique des plafonds locaux de débit et de volume. Une valeur demandée ne devient donc un fait d’émission qu’après la décision du réflecteur.

Si la longueur calculée dépasse la MTU, le réflecteur envoie un seul paquet de la taille de cette MTU. Si la rafale demandée dépasserait son plafond de débit ou de volume, il envoie également un seul paquet. Avec un nombre nul, la règle normale est de ne rien renvoyer, sous réserve d’une politique locale ; le document préfère le mécanisme explicite « no reply » du Return Path lorsque le silence est réellement recherché.

Cette autonomie locale protège le réflecteur contre une instruction disproportionnée. Elle interdit en même temps de confondre le formulaire de commande avec le résultat. « Huit demandés » et « huit émis » sont deux colonnes.

Le bit C ferme une question, pas le dossier

Le RFC attribue au bit 3 le symbole C, « Conformant ». Le sender le met à zéro dans sa requête. Le réflecteur le met à un dans deux cas définis : la longueur excède sa MTU de sortie, ou le débit/volume demandé excède ses limites. Dans les autres réponses, il le laisse à zéro.

La taille du paquet unique permet de distinguer les deux causes. Plus court que la longueur demandée, il signale le cas MTU ; égal à cette longueur, il signale la limite de débit ou de volume. Voilà une preuve utile, mais étroite : elle décrit la construction locale de la réponse.

C=0 ne signifie pas « capacité suffisante ». Il n’atteste pas que tous les paquets ont traversé le réseau, que le collecteur les a tous enregistrés, que la route correspond à celle de l’application ou que les mêmes files d’attente ont été utilisées. C=1 ne diagnostique pas un réseau saturé : il peut simplement refléter une politique prudente du réflecteur.

La grille des couches de réalité de Lu Heng rend l’erreur visible. La consigne encodée appartient à une couche ; la décision du réflecteur à une autre ; le compteur d’interface, la capture du collecteur, la télémétrie applicative et le résultat commercial sont encore d’autres réalités. Les afficher sur le même écran ne les fusionne pas.

Preuve Conclusion défendable Conclusion prématurée
TLV envoyé Cette forme de réponse a été demandée Cette forme a été émise
Bit C Le réflecteur a ou non invoqué l’une des deux exceptions Le chemin dispose de la capacité voulue
Compteur d’émission Le système local a compté des paquets sortants Le collecteur les a tous reçus
Capture du collecteur Ces paquets sont arrivés à ce point d’observation L’application a rencontré les mêmes conditions
Télémétrie applicative Cette charge nommée a eu ce comportement Toute application se comportera ainsi

La métrique reste à construire

Le RFC 10052 le dit sans détour : la métrique de débit d’accès et la méthode de mesure sont hors de son périmètre. Le TLV fournit des commandes répondant à des besoins du RFC 7497, notamment l’asymétrie de taille et de cadence. Il ne produit pas, à lui seul, une valeur de capacité.

Le RFC 7497 distingue d’ailleurs les essais en service, où le trafic utilisateur est présent, des essais hors service. Il avertit qu’un trafic de test aux caractéristiques différentes peut recevoir un traitement différent, fausser le résultat ou créer la congestion recherchée. Le RFC 7799 classe explicitement ces méthodes comme actives : elles injectent leur propre trafic dans le système observé.

Les méthodes du RFC 9097 et du RFC 9946 ajoutent les règles de charge, de progression, d’emplacement des points de test et de concurrence avec le trafic normal. Leur complexité n’est pas accessoire. Elle montre pourquoi une belle rafale STAMP est un matériau de mesure, pas la mesure achevée.

En multidiffusion, sélectionner n’est pas échantillonner

Dans le scénario multicast, une requête peut atteindre plusieurs réflecteurs placés aux feuilles d’un arbre. Les sous-TLV de groupe de couche 2 et de couche 3 permettent de réduire les répondants au moyen d’un masque d’adresse matérielle ou d’un préfixe IP. Le RFC donne, entre autres, l’exemple d’une correspondance sur une adresse sur seize.

Ce mécanisme maîtrise le volume ; il n’établit aucune représentativité. Les adresses peuvent être liées à un fournisseur, à une génération d’équipement, à une zone ou à une topologie. Une règle déterministe « une sur seize » n’est pas un tirage aléatoire d’un utilisateur sur seize. Le dénominateur, la distribution des caractéristiques et le biais de sélection doivent être documentés séparément.

La multidiffusion augmente aussi le risque d’amplification. Le RFC impose un contrôle du débit, recommande une première requête limitée à une réponse et exige que la fonction soit administrativement désactivée par défaut. L’usurpation d’une requête pourrait provoquer un déni de service ; l’identité doit être protégée et l’authentification STAMP ou le HMAC est recommandé. Le RFC 8085 rappelle la discipline générale applicable aux charges UDP.

Le lieu de collecte fait partie du résultat

Avec les extensions Return Path du RFC 9503, les réponses peuvent être dirigées vers un collecteur distinct. Le cadre LMAP décrit ces rôles de mesure. Un paquet de test peut ainsi suivre le trajet aller d’un flux vidéo, tandis que ses réponses partent vers un centre d’analyse.

Cette séparation est utile, mais elle ne gomme pas les chemins. Le collecteur prouve ce qu’il a reçu à son point de vue et selon son horloge. Il ne prouve pas ce qu’un client vidéo a vu. Même sur l’aller, partager une destination générale ne garantit ni le même hachage, ni la même classe de service, ni les mêmes files, ni le même état transitoire.

Le dossier Datatracker, l’historique du projet et le rapport d’activité de septembre prouvent le parcours éditorial et la publication. La fiche courante, le texte brut et le XML fixent les détails du standard. Aucun de ces documents ne compte les déploiements.

La primauté du code en fonctionnement exige le nom de l’implémentation, sa version, sa configuration et son résultat observé. La spécification initiale minimale permet de lire la portée limitée du RFC comme une qualité : la norme définit le contrôle commun, les opérateurs gardent la méthode et les seuils. Enfin, le problème d’agence oblige à nommer qui choisit la forme de la sonde, les limites, le groupe, le collecteur et l’interprétation.

Le nombre huit n’est pas faible. C’est une preuve solide lorsqu’il reste attaché à la phrase exacte qu’il peut soutenir.

Sources