Résumé

  • RFC 3393 définit l’IPDV comme la différence entre les délais unidirectionnels de deux paquets choisis, puis distingue cette valeur isolée de l’échantillon et des statistiques qui en découlent.
  • RFC 4148 a tenté de recenser les métriques IPPM, mais RFC 6248 a jugé le registre trop imprécis face aux choix de Type-P, de paramètres et de flux ; RFC 8911 a ensuite mieux séparé paramètres fixes et paramètres d’exécution.

En 2002, le groupe IP Performance Metrics ne cherchait pas à réduire toute variation de trajet à un chiffre unique. RFC 3393 définit d’abord une valeur isolée : pour deux paquets choisis entre un point de mesure et un autre, on soustrait le délai unidirectionnel du premier à celui du second. La fonction de sélection compte. Les paquets peuvent être consécutifs, porter des indices donnés ou être choisis selon une autre règle explicite. Cette valeur n’est ni une distribution, ni un percentile, ni un jugement sur la qualité de service. Le texte définit séparément un échantillon en flux de Poisson et des statistiques ; tout rapport doit déclarer ses paramètres pour que le résultat soit interprétable. RFC 3393

Cette souplesse était volontaire. Une expérience et une application ne retiennent pas nécessairement les mêmes types de paquets, la même sélection de paires ou le même résumé statistique. La RFC relève aussi qu’une mesure différentielle peut éliminer un décalage d’horloge fixe entre les extrémités, sans faire disparaître les questions distinctes de dérive, de durée entre paquets et d’erreurs de mesure. La valeur observée dépend donc autant des choix qui la construisent que de son étiquette.

Même le mot « jitter » prêtait à confusion : le texte lui préfère « variation du délai », car ingénieurs du signal et informaticiens ne lui donnent pas toujours le même sens.

Trois ans plus tard, RFC 4148 a tenté d’inscrire les métriques IPPM dans un registre. Celui-ci attribuait des OBJECT-IDENTITIES aux métriques définies et incluait les travaux sur l’IPDV parmi ceux sur le délai, les pertes et d’autres mesures. L’intérêt semblait évident : un identifiant stable faciliterait les renvois d’un document à l’autre. Mais le registre héritait de la variabilité des paquets Type-P, des paramètres métriques et des paramètres de flux. Une étiquette ne pouvait pas, à elle seule, fixer tous les choix qui modifiaient sensiblement l’observation. RFC 4148

En 2011, RFC 6248 a formulé cette lacune sans détour. Elle a déclaré obsolètes RFC 4148 et le registre IANA associé, leur structure ne permettant pas d’identifier les métriques IPPM de façon univoque. Enregistrer chaque combinaison de type de paquet, de paramètre métrique et de flux n’était ni faisable ni utile, disait-elle. Elle ajoutait que l’ancien registre avait « très peu d’utilisateurs, voire aucun » et qu’aucune réponse n’avait suivi l’appel à manifestations d’intérêt lancé au second semestre 2010. Ces constats portent sur le registre, non sur l’absence d’utilisateurs des mesures de variation du délai. Le contenu du registre a été conservé ; seules les nouvelles inscriptions ont cessé. RFC 6248

La leçon n’était pas de supprimer les paramètres, mais de décider lesquels appartiennent à la définition et lesquels peuvent varier à l’exécution. Le registre des métriques de performance défini ensuite par RFC 8911 distingue les paramètres fixes — dont toute modification définit une autre métrique enregistrée — des paramètres d’exécution qu’un agent peut recevoir lors de la mesure. Il demande aussi si une entrée est interprétable, implémentable, déployable, utile et assez précise pour produire des résultats équivalents. RFC 8912 a fourni les premières entrées. Le changement de conception est net : un catalogue devait décrire assez de méthode pour qu’un autre acteur puisse choisir ou lancer la mesure, pas seulement reconnaître son nom. RFC 8911 RFC 8912

RFC 3393 n’a pas été rendue obsolète avec RFC 4148, et le nouveau registre ne garantit pas que chaque mesure d’IPDV soit comparable. La distinction durable oppose une métrique comme concept à une méthode comme ensemble de choix exécutables. Un registre ne peut coordonner ces choix que s’il précise lesquels sont fixes, lesquels restent variables et comment interpréter le résultat.

Sources

Fiche RFC 3393 · Texte RFC 3393 · RFC 4148 · RFC 6248 · RFC 8911 · RFC 8912 · RFC 5481 · RFC 2330 · RFC 2679 · RFC 7679 · RFC 3357 · RFC 5148 · Erratum éditorial vérifié 6981 · Erratum éditorial vérifié 8282