Résumé

  • RFC 3432 tirait T0 au hasard dans une fenêtre, puis espaçait les paquets selon incT jusqu’à Tf. Ce départ réduisait prévisibilité et certaines synchronisations, sans rendre l’échantillon périodique non biaisé.
  • Le résultat n’avait de sens qu’avec Type-P, seuil transformant retard en perte, règles d’exclusion, étalonnage des horloges et des hôtes, chemin connu et conditions de fond.

Une phase choisie, puis une cadence fixe

Une sonde attend dans une fenêtre, tire un instant, puis émet toutes les vingt millisecondes. Le premier événement surprend ; les suivants peuvent rencontrer toujours la même phase d’un phénomène périodique.

C’est la construction de RFC 3432, publié en novembre 2002. Son texte, sa notice, sa fiche IETF, son historique, ses références et la recherche d’errata documentent une méthode Standards Track, pas la performance d’un réseau nommé.

Des paquets égaux ou presque, envoyés régulièrement, imitaient un flux CBR ou presque CBR. Pour la voix ou la conférence, une cadence dense pouvait révéler une brève rafale de pertes ou de variation que des sondes rares ignoraient.

Un biais connu pouvait répondre à la bonne question

Le cadre IPPM de RFC 2330 rappelait qu’une série régulière ne parcourt qu’une partie du spectre de performance. RFC 3432 comparait l’échantillonnage de Poisson, non biaisé pour des mesures générales, aux paramètres périodiques qui créent un biais.

Ce biais pouvait être voulu. Pour étudier ce que vit un flux média à une cadence précise, reproduire cette cadence définit la population pertinente. Le mensonge commence lorsque « ce flux » devient « le réseau ».

Une perturbation périodique peut tomber toujours sur les sondes, ou toujours entre elles. Des équipements peuvent anticiper un rythme ; le trafic de test peut synchroniser des émetteurs sensibles à la congestion. Le tirage indépendant de T0 dans [T,T+dT] et la durée finie limitaient certains risques. Ils ne randomisaient pas chaque incT.

Type-P empêchait le paquet générique

La métrique s’appelait Type-P-One-way-Delay-Periodic-Stream. Type-P pouvait fixer version IP, UDP ou TCP, port, taille, priorité ou traitement particulier. Modifier le paquet pouvait modifier le résultat.

Une mesure active avec plusieurs tailles devait reproduire leur distribution ; une mesure passive héritait des tailles réelles. Les définitions de délai de RFC 2679, mises à jour par RFC 7679, et celles de perte dans RFC 2680 puis RFC 7680 conservent cette discipline.

Une valeur absente n’était pas zéro

Les points source et destination gardaient horodatages, identifiants et tailles. Un statut optionnel pouvait signaler en-tête corrompu, payload corrompu, doublon ou fragment, à condition de publier le critère.

Le singleton de délai était l’horodatage destination moins celui de la source. Impossible de le calculer pour un paquet parasite sans départ, non reçu sans arrivée, ou doté d’un en-tête corrompu. Pour un doublon, seule la première copie non corrompue recevait une valeur.

La moyenne ne concernait donc que les singletons valides. La variation entre deux paquets était indéfinie si l’un des délais manquait. RFC 3393 et RFC 5481 explicitent ce contexte. Une moyenne faible peut coexister avec une rafale de pertes exclue du dénominateur.

Le seuil fabriquait la frontière entre tard et perdu

Avant la fin de l’attente, impossible de distinguer un paquet absent d’un paquet très tardif. dTloss définissait le délai maximal avant de déclarer la perte. RFC 3432 exigeait de publier la valeur ou sa méthode.

Une application temps réel peut considérer inutile un paquet arrivé après son échéance ; une autre peut encore l’exploiter. Les métriques de perte aller-retour de RFC 6673 et bi-paquet de RFC 6534 montrent encore que la procédure d’observation appartient à la définition.

Deux rapports sur les mêmes arrivées peuvent compter différemment avec deux seuils. Le seuil est un paramètre, pas une note de bas de page.

L’instrument avait sa propre performance

Synchronisation, résolution et dérive des horloges affectaient le délai aller simple. Les horodatages logiciels mesuraient aussi du temps d’hôte, différent du temps sur le fil. Charge CPU, ordonnancement et I/O pouvaient déplacer incT et accroître l’erreur.

Le mémo demandait de retirer l’erreur systématique connue et de publier une erreur d’étalonnage e, interprétable à 95 %. Il recommandait un étalonnage sous charge comparable au terrain. RFC 7312 fournit un contexte ultérieur sur les flux ; RFC 2119 fournit les mots normatifs visant la comparabilité.

Le nombre voyageait avec cinq contextes

Type-P, seuil retard-perte, étalonnage, chemin et conditions de fond devaient accompagner le résultat. Le chemin exact est souvent inconnu ; Record Route peut être ignoré et peut lui-même pousser le paquet hors du traitement courant. Une information partielle, comme le premier lien, reste utile.

Un résultat IP ne mesure pas automatiquement le codec, le système d’exploitation ou l’auditeur humain. Pertes groupées, retards, doublons, réordonnancement et corruption ont des effets propres à chaque application.

Sources et limites

La méthode de lecture suit aussi Heng Lu sur les couches de réalité et le code en fonctionnement. Définition du test, paquet émis, observation, singleton calibré, agrégat et expérience ne se remplacent pas.

Les sources ne prouvent ni déploiement actuel, ni chemin précis, ni panne nommée, ni mécanisme QoS, ni manipulation, ni expérience universelle. Elles définissent comment ne pas faire dire trop à une mesure périodique.