Résumé

  • RFC 3357 a dérivé deux mesures d’un échantillon ordonné de pertes unidirectionnelles : la distance entre pertes et la période de pertes, afin de distinguer des pertes isolées d’une rafale.
  • Ces mesures dépendent encore du type de paquet, du sens, de l’échantillonnage, du délai de décision et des instruments ; elles décrivent une trace sans désigner la cause.

Cent paquets partent. Cinq ne sont pas reçus avant le délai fixé. Sur un premier trajet, chaque absence est entourée de livraisons réussies. Sur un second, les cinq absences sont contiguës. Dans les deux cas, le tableau de bord affiche cinq pour cent.

Le calcul n’est pas faux. Il est incomplet pour toute application qui réagit à l’ordre. Un décodeur vocal peut masquer une brève lacune grâce aux sons voisins et échouer lorsque plusieurs unités utiles disparaissent ensemble. Un transport adaptatif ne récupère pas nécessairement d’une série comme de pertes espacées. La proportion a conservé la quantité et supprimé la forme.

Publié en août 2002 comme RFC Informational, One-way Loss Pattern Sample Metrics a précisément travaillé sur ce reste. Rajeev Koodli et R. Ravikanth n’ont pas créé un indice universel de qualité. Ils sont partis de la discipline IPPM existante : observer chaque paquet, conserver l’échantillon, puis calculer des statistiques dont les conditions sont explicites.

RFC 2330 avait séparé le singleton, l’échantillon et la statistique. RFC 2680 avait ensuite défini la perte unidirectionnelle d’un paquet Type-P entre une source et une destination. La valeur est zéro lorsque le paquet arrive, un lorsqu’il n’arrive pas dans le délai choisi. Le type de paquet, la direction, l’heure, le seuil de perte, la calibration des horloges et le chemin observé font partie du résultat.

Cette prudence est essentielle. Un paquet peut avoir été supprimé dans le réseau, être arrivé après le seuil, ou sembler absent parce que la machine de mesure a manqué de ressources. La moyenne de RFC 2680 répond à une question utile : quelle part des observations a été classée comme perdue ? Mais elle ne conserve aucun voisinage. Déplacer les mêmes cinq valeurs « perdu » dans la série ne change pas la moyenne.

RFC 3357 a donc laissé intacte la décision de base et ajouté la distance entre pertes. On attribue des numéros consécutifs aux paquets échantillonnés. Lorsqu’un paquet est perdu, on soustrait le numéro du paquet perdu précédent. Si les paquets 20 puis 50 manquent, la distance vaut 30. La première perte reçoit zéro, faute de prédécesseur observé.

Cette distance est exprimée en positions de la séquence, pas spontanément en secondes. Pour parler de temps, il faut connaître le calendrier d’émission. Une distance de dix dans un flux dense et régulier ne couvre pas le même intervalle que dans une sonde rare et irrégulière. La mesure révèle l’espacement dans l’échantillon ; elle ne doit pas emprunter une unité qu’elle n’a pas.

La période de pertes donne une autre vue. Elle commence lorsqu’un paquet perdu suit un paquet reçu. Les pertes consécutives gardent le même numéro de période ; tout paquet reçu a la période zéro. Une série de cinq pertes contiguës constitue donc une période de longueur cinq, et non cinq incidents indépendants.

À partir de ces flux dérivés, le document propose le nombre total de périodes, leur longueur, leur séparation et un taux de pertes « perceptibles » conditionné par une contrainte delta. Ce dernier mot ne promet pas la perception réelle d’une personne. Il signifie que deux pertes se trouvent à une distance inférieure ou égale à la contrainte choisie. Le choix de delta appartient au modèle d’application et doit être déclaré.

L’échantillonnage change ce que l’on peut voir. RFC 3357 accepte plusieurs méthodes, tout en prévenant que l’échantillonnage de Poisson hérité du cadre général peut mal représenter la voix sur IP ou TCP. Une sonde aléatoire et peu dense peut passer entre les bords d’une courte rafale. Un flux périodique peut mieux imiter le média, mais se synchroniser avec un autre phénomène périodique ou devenir prévisible.

RFC 3432, publié trois mois plus tard, a formalisé les flux périodiques : départ aléatoire, durée finie, cadence et taille des paquets documentées, charge limitée. Il ne remplaçait pas une vérité par une autre. Il reconnaissait qu’une mesure représentative d’une application peut accepter un biais connu différent de celui recherché par une sonde générale.

RFC 7312 a ensuite élargi le cadre des flux et de l’échantillonnage. RFC 7680 a remplacé RFC 2680 comme définition actuelle de la perte unidirectionnelle, en tenant compte de cette évolution. L’histoire technique doit donc garder deux repères : RFC 3357 explique la dérivation de 2002 ; une mesure présente doit aussi suivre les spécifications de base plus récentes.

La notion de rafale a trouvé des emplois opérationnels voisins, sans devenir une définition unique. RFC 3611 a introduit des rapports RTCP étendus, avec encodage des séquences reçues ou perdues et mesures de périodes de rafale et d’accalmie pour les médias. RFC 7003 mesure des rejets en rafale ou en intervalle dans un tampon de gigue. Un paquet livré par le réseau mais rejeté trop tard par le tampon n’est pas la même observation qu’une perte IPPM.

RFC 5348 offre une autre frontière. TFRC regroupe une ou plusieurs pertes survenues dans un temps aller-retour en un événement de perte utilisé par son équation de débit. Cette unité sert le contrôle de congestion. Elle n’est pas synonyme de la période de RFC 3357, fondée sur la contiguïté des positions échantillonnées.

Le réordonnancement complique encore le classement. RFC 4737 mesure les paquets arrivés dans un ordre différent. Sans seuil d’attente et règle de consolidation, un paquet momentanément absent peut d’abord être déclaré perdu puis apparaître comme réordonné. La trace reste interprétable seulement si ces règles l’accompagnent.

RFC 6390 a plus tard résumé la discipline : préciser entrées, unités, points de mesure, calendrier, échantillonnage, validité et incertitude. Il relève justement que certaines applications tolèrent des pertes isolées mais souffrent de courtes périodes très chargées. Le nom d’une métrique ne suffit jamais à lui donner une portée.

Pour comparer deux résultats, il faut donc aligner source, destination, sens, Type-P, taille, intervalle, cadence, méthode d’échantillonnage, seuil de perte, numérotation, horloges et santé des instruments. Il faut conserver la séquence brute. Pour une statistique utilisant delta, la valeur de delta doit rester liée au résultat.

Même une rafale nette ne localise pas sa cause. Elle ne désigne ni routeur, ni file, ni lien, ni opérateur, ni terminal. Elle ne prouve une violation contractuelle que si le contrat emploie la même définition dans les mêmes conditions. L’attribution réclame des données de routage, d’interface, de file, d’hôte et d’application corrélées dans le temps.

La mesure active n’est pas extérieure au réseau. RFC 3357 avertit qu’un trafic d’essai mal réglé peut contribuer à un déni de service, que les données peuvent exposer de l’information et que des résultats falsifiés peuvent tromper une décision. La petite taille d’un paquet ne rend pas automatiquement la campagne neutre.

L’apport durable de RFC 3357 tient dans une retenue : une moyenne ne doit pas se faire passer pour une séquence. Le taux de perte, les distances, les périodes, la cause et l’expérience appartiennent à des niveaux distincts.

Cette lecture emploie aussi deux perspectives déclarées de Lu Heng. « Minimum Initial Specification » invite à garder une définition de base étroite puis à laisser des usages locaux dériver les vues nécessaires. « Reality Layers » aide à séparer trace observée, étiquette métrique, explication opérationnelle, affirmation commerciale et expérience. Ce sont des outils éditoriaux, non des affirmations sur l’intention des auteurs.

Les deux flux avaient perdu cinq paquets. Seul l’ordre disait s’ils étaient tombés seuls ou ensemble.

Sources