Network Working Group G

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Table des matières

1. Introduction 1

1.1 Motivation 2

1.2 Problèmes généraux concernant l’heure 3

2. Définition de singleton pour le délai d’aller retour 3

2.1 Nom de la métrique 3

2.2 Paramètres de la métrique 3

2.3 Unités de la métrique 3

2.4 Définition 3

2.5 Discussion 4

2.6 Méthodologies 4

2.7 Erreurs et incertitudes 5

2.8 Rapport de la métrique 7

3 Définition pour les échantillons de délai d’aller retour 7

3.1 Nom de la métrique 8

3.2 Paramètres de la métrique 8

3.3 Unités de la métrique 8

4.4 Définition 8

3.5 Discussion 8

3.6 Méthodologies 9

3.7 Erreurs et incertitudes 9

4.8 Rapport de la métrique 9

4. Quelques définitions de statistiques pour le délai d’aller retour 9

4.1 Percentile de délai d’aller retour de type P 9

4.2 Médiane de délai d’aller retour de type P 10

4.3 Minimum de délai d’aller retour de type P 10

5.4 Percentile inverse de délai d’aller retour de type P 10

5. Considérations pour la sécurité 10

6. Remerciements 11

7. Références 11

8. Adresse des auteurs 11

9. Déclaration complète de droits de reproduction 11

Le présent mémoire définit une métrique pour le délai d’aller retour des paquets à travers les chemins de l’Internet. Elle s’appuie sur les notions introduites et discutées dans le document cadre IPPM, [RFC2330], et suit de près la métrique correspondante pour le délai unidirectionnel ("Métrique de délai unidirectionnel pour IPPM") [RFC2679] ; le lecteur est supposé familiarisé avec ces documents.

Le mémoire a été en grande partie écrit en copiant les matériaux provenant de la métrique du délai unidirectionnel. L’intention est que, lorsque les deux métriques sont similaires, elles soient décrites avec un texte similaire ou identique, et que lorsque les deux métriques diffèrent, un texte nouveau ou modifié soit utilisé.

Le présent mémoire est destiné à être parallèle dans sa structure à un futur document qui l’accompagnera sur la perte de paquet (RFC2680).

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document, sont à interpréter comme décrit dans la [RFC2119]. Bien que la RFC 2119 ait été écrite en visant les protocoles, les mots clés sont utilisés dans le présent document pour des raisons similaires. Ils sont utilisés pour assurer que les résultats de mesures provenant de deux mises en œuvre différentes sont comparables, et pour noter les instances où une mise en œuvre pourrait perturber le réseau.

+ Une métrique analytique de 'singleton', appelée délai d’aller retour de type-P, est introduite pour mesurer une seule observation de délai d’aller retour.

+ En utilisant cette métrique de singleton, un 'échantillon', appelé flux de Poisson de délai d’aller retour de type-P, est introduite pour mesurer une séquence de singletons de délais mesurée à des instants tirés d’un processus de Poisson.

+ En utilisant cet échantillon, plusieurs 'statistiques' de l’échantillon sont définies et discutées.

Cette progression du singleton à l’échantillon et aux statistiques, avec une claire séparation entre eux, est importante.

Chaque fois qu’un terme technique provenant du document cadre IPPM est utilisé pour la première fois dans le présent mémoire, il sera marqué à la fin avec un astérisque. Par exemple, "terme*" indique que "terme" est défini dans la [RFC2330].

Le délai d’aller retour d’un paquet de type-P* à partir d’un hôte* de source pour un hôte de destination est utile pour plusieurs raisons :

+ Certaines applications ne fonctionnent pas bien (ou pas du tout) si le délai de bout en bout entre les hôtes est grand par rapport à une certaine valeur de seuil.

+ Une variation erratique du délai rend difficile (ou impossible) de prendre en charge de nombreuses applications en temps réel.

+ Plus la valeur du délai est grande, plus il est difficile aux protocoles de couche transport de tenir des bandes passantes élevées.

+ La valeur minimum de cette métrique donne une indication du délai dû seulement à la propagation et la transmission.

+ La valeur minimum de cette métrique donne une indication du délai qui va probablement être subi lorsque le chemin* traversé est de faible charge.

+ Les valeurs de cette métrique qui sont au dessus du minimum donnent une indication de l’encombrement présent dans le chemin.

La mesure du délai d’aller retour au lieu du délai unidirectionnel présente plusieurs faiblesses, qu’on résume ci-dessous :

+ Le chemin Internet d’une source à une destination peut différer du chemin de retour de la destination à la source ("chemins asymétriques") comme des séquences différentes de routeurs qui sont utilisées pour les chemins aller et retour. Donc, les mesures d’aller retour mesurent en fait ensemble les performance de deux chemins distincts.

+ Même lorsque les deux chemins sont symétriques, ils peuvent avoir des caractéristiques de performances radicalement différentes dues à des mises en file d’attente asymétriques.

+ Les performances d’une application peuvent dépendre principalement des performances dans une direction.

+ Dans les réseaux à qualité de service (QS) garantie, l’approvisionnement dans une direction peut être radicalement différent de l’approvisionnement dans la direction inverse, et donc la garantie de QS diffère.

D’un autre côté, la mesure du délai d’aller retour a deux avantages spécifiques :

+ Facilité de déploiement : à la différence de la mesure unidirectionnelle, il est souvent possible d’effectuer une certaine forme de mesure du délai d’aller retour sans installer de logiciel de mesure spécifique à la destination prévue. Diverses approches sont bien connues, incluant l’utilisation de l’écho ICMP des méthodologies fondées sur TCP (similaire à celles décrites dans "Métriques IPPM pour la mesure de la connexité" [RFC2678]). Cependant, certaines approches peuvent introduire une plus grande incertitude sur l’instant où la destination produit une réponse (voir au paragraphe .7.3).

+ Facilité d’interprétation : dans certaines circonstances, le délai d’aller retour est en fait la quantité intéressante. Déduire le délai d’aller retour de la confrontation de mesures unidirectionnelles et d’une hypothèse sur le temps de traitement de la destination est moins direct et potentiellement moins précis.

Chaque fois qu’une heure (c’est-à-dire un moment dans l’histoire) est mentionné ici, il doit être compris qu’elle est mesurée en secondes (et ses fractions) par rapport à l’UTC.

Comme c’est décrit plus complètement dans le document cadre, il y a quatre notions distinctes, mais en rapport, d’incertitude d’horloge :

C’est la mesure dans laquelle deux horloges s’accordent sur l’heure qu’il est. Par exemple, l’horloge sur un hôte pourrait être de 5,4 µs en avance de l’horloge du second hôte.

C’est la mesure dans laquelle une certaine horloge s’accorde à l’UTC. Par exemple, l’horloge d’un hôte pourrait être de 27,1 µs en retard sur l’UTC.

Mesure la précision d’une certaine horloge. Par exemple, l’horloge sur un vieil hôte Unix pourrait battre seulement toutes les 10 ms, et donc avoir une résolution de seulement 10 ms.

Mesure le changement de précision, ou de synchronisation, avec le temps. Par exemple, l’horloge d’un certain hôte pourrait gagner 1,3 ms par heure et donc être 27,1 ms en retard de l’UTC à un moment et seulement de 25,8 ms une heure plus tard. Dans ce cas, on dit que l’horloge de cet hôte a un biais de 1,3 ms par heure par rapport à l’UTC, ce qui menace la précision. On peut aussi parler du biais d’une horloge par rapport à une autre horloge, ce qui menace la synchronisation.

La valeur d’un délai d’aller retour de type-P est soit un nombre réel, soit un nombre indéfini (informellement, infini) de secondes.

Pour un nombre réel dT, "le *délai d’aller retour de type-P* de Src à Dst à T est dT" signifie que Src a envoyé le premier bit d’un paquet de type-P à Dst à l’heure du réseau* T, que Dst a reçu ce paquet, puis immédiatement renvoyé un paquet de type-P à Src, et que Src a reçu le dernier bit de ce paquet à l’heure du réseau T+dT.

"Le *délai d’aller retour de type-P* de Src à Dst à T est indéfini (informellement, infini)" signifie que Src a envoyé le premier bit d’un paquet de type-P à Dst à l’heure du réseau T et que (soit Dst n’a pas reçu le paquet, soit Dst n’a pas envoyé un paquet de type-P en réponse) Src n’a pas reçu ce paquet de réponse.

"Le *délai d’aller retour de type-P entre Src et Dst à T" signifie soit le *délai d’aller retour de type-P de Src à Dst à T, soit le *délai d’aller retour de type-P de Dst à Src à T. Lorsque cette notion est utilisée, on comprend qu’il est spécifiquement ambigu de savoir quel hôte agit comme Src et comme Dst. {Commentaire : Cette ambiguïté va habituellement être un faible prix à payer pour être capable d’avoir une mesure, lancée soit de Src, soit de Dst, plutôt que d’avoir deux mesures.}

Les suggestions sur ce qu’il convient de rapporter avec les valeurs de métriques apparaissent au paragraphe 3.8 après une discussion de la métrique, des méthodologies de mesure de la métrique, et de l’analyse des erreurs.

Le délai d’aller retour de type-P est une métrique analytique relativement simple, et dont on pense qu’elle donne des méthodes efficaces de mesure.

+ Les valeurs d’horodatage (T) pour l’instant auquel les délais sont mesurés devraient être très précises afin de tirer des conclusions significatives sur l’état du réseau à un certain T. Donc, Src devrait avoir une connaissance précise de l’heure en cours. NTP [RFC1305] donne les moyens d’obtenir une heure précise au niveau de quelques millisecondes. Selon le serveur NTP, une précision plus grande peut être réalisée, par exemple, lorsque les serveurs NTP utilisent les systèmes GPS comme source horaire. Noter que NTP ajustera l’horloge de l’instrument. Si un ajustement est fait entre le moment où est apposé l’horodatage initial et l’instant où est apposé l’horodatage final, l’ajustement va affecter l’incertitude sur le délai mesuré. Cette incertitude doit être prise en compte dans le calibrage de l’instrument.

+ Une certaine méthodologie devra inclure un moyen de déterminer si une valeur de délai est infinie ou si elle est simplement très grande (et que le paquet n’est pas encore arrivé à Dst). Comme noté par Mahdavi et Paxson [RFC2678], on pourrait utiliser de simples bornes supérieures (comme la limite théorique de 255 secondes de la durée de vie des paquets IP [RFC0791]) mais une bonne ingénierie, incluant la compréhension des durées de vie des paquets, sera nécessaire en pratique. {Commentaire : Noter que, pour de nombreuses applications de ces métriques, il peut n’y avoir pas de dommage causé en traitant un long délai comme une perte de paquet. Par exemple, un paquet audio en play-back qui arrive seulement après le point de play-back pourrait aussi bien avoir été perdu.}

+ Si le paquet est dupliqué de sorte que plusieurs instances non corrompues de la réponse reviennent à la source, le paquet est alors compté comme reçu, et la première instance qui revient à la source détermine le délai d’aller retour du paquet.

+ Si le paquet est fragmenté et si, quelle qu’en soit la raison, le réassemblage ne se fait pas, le paquet sera alors réputé perdu.

Comme avec les autres métriques de Type-P-*, la méthodologie détaillée va dépendre du type-P (par exemple, du numéro de protocole, du numéro d’accès UDP/TCP, de la taille, de la préséance).

Généralement, pour un certain type-P, la méthodologie se déroulerait comme suit :

+ Chez l’hôte Src, choisir les adresses IP de Src et de Dst, et former un paquet d’essai de type-P avec ces adresses. Toute portion de 'bourrage' du paquet qui n’est nécessaire que pour donner une certaine taille au paquet d’essai devrait être remplie avec des bits au hasard pour éviter les situations dans lesquelles le délai mesuré serait inférieur à ce qu’il serait autrement du fait des techniques de compression le long du chemin. Le paquet d’essai doit avoir des informations d’identification afin que sa réponse puisse être identifiée par Src lorsque Src reçoit la réponse ; un moyen de le faire est de placer l’horodatage généré juste avant l’envoi du paquet d’essai dans le paquet lui-même.

+ Chez l’hôte Dst, s’arranger pour recevoir et répondre au paquet d’essai. Chez l’hôte Src, s’arranger pour recevoir le paquet de réponse correspondant.

+ Chez l’hôte Src, prendre l’horodatage initial et envoyer ensuite le paquet de type-P préparé vers Dst. Noter que l’horodatage pourrait être placé à l’intérieur du paquet, ou conservé séparé tant que le paquet contient un identifiant convenable de sorte que l’horodatage reçu puisse être comparé à l’horodatage envoyé.

+ Si le paquet arrive à Dst, renvoyer un paquet de réponse correspondant de Dst à Src aussi tôt que possible.

+ Si le paquet de réponse arrive dans un délai raisonnable, prendre l’horodatage final aussitôt que possible à réception du paquet. En soustrayant les deux horodatages, une estimation du délai d’aller retour peut être calculée. Si le délai entre l’horodatage initial et l’envoi réel du paquet est connu, alors l’estimation pourra être ajustée en soustrayant cette quantité ; l’incertitude sur cette valeur doit être prise en compte dans l’analyse d’erreur. De même, si le délai entre la réception réelle du paquet de réponse et l’horodatage final est connu, alors l’estimation pourra être ajustée en soustrayant cette quantité ; l’incertitude sur cette valeur doit être prise en compte dans l’analyse d’erreur. Voir au paragraphe suivant, "Erreurs et incertitudes", pour un exposé plus détaillé.

+ Si le paquet échoue à arriver dans un délai raisonnable, le délai d’aller retour est pris comme indéfini (informellement, infini). Noter que le seuil de 'raisonnable' est un paramètre de la méthodologie.

Les questions telles que le format de paquet et les moyens par lesquels Dst sait quand attendre le paquet d’essai sortent du domaine d’application du présent document.

{Commentaire : Noter qu’en général, on ne peut pas ajouter deux valeurs de délai unidirectionnel de type-P (voir dans la [RFC2679]) pour former une valeur de délai d’aller retour de type-P. Pour former une valeur de délai d’aller retour de type-P, le paquet de retour doit être déclenché par la réception d’un paquet provenant de Src.}

{Commentaire : un "ping" serait qualifié comme mesure de délai d’aller retour selon cette définition, avec un type-P de demande/réponse d’écho ICMP avec des paquets de 60 octets. Cependant, l’incertitude associée à un programme ping normal doit être analysée comme dans le paragraphe suivant, incluant le type de point de réflexion (un routeur peut ne pas traiter une demande ICMP sur le chemin rapide) et les effets de charge dans le point de réflexion.}

La description de toute méthode de mesure spécifique devrait inclure une prise en compte et une analyse des diverses sources d’erreur ou d’incertitude. Le document cadre fournit des lignes directrices générales sur ce point, mais on note ici les spécificités relatives aux métriques de délai suivantes :

+ Les erreurs ou incertitudes dues aux incertitudes de l’horloge chez l’hôte Src.

+ Les erreurs ou incertitudes dues à la différence entre 'heure du réseau' et 'heure de l’hôte'.

+ Les erreurs ou incertitudes dues au temps requis par Dst pour recevoir le paquet de Src et envoyer la réponse correspondante.

De plus, le seuil de perte peut affecter le résultat. Chacun de ces points est discuté plus en détails ci-après, ainsi que dans le paragraphe "Calibrage" sur la façon de prendre en compte ces erreurs et incertitudes.

L’incertitude de mesure d’un délai d’aller retour se rapporte, en partie, aux incertitudes sur l’horloge chez l’hôte Src. Dans ce qui suit, on se réfère à l’horloge utilisée pour mesurer quand le paquet a été envoyé de Src par l’expression horloge de source, et on se réfère au temps observé lorsque le paquet a été envoyé par la source par Tinitial, et au temps observé lorsque le paquet a été reçu par la source par Tfinal. En ce qui concerne les notions de synchronisation, précision, résolution, et biais mentionnées dans l’introduction, on note ce qui suit :

+ Alors que dans le délai unidirectionnel, il y a un problème de synchronisation de l’horloge de source et de l’horloge de destination, dans le délai d’aller retour, il y a un problème (plus facile) d’auto-synchronisation, entre l’horloge de source au moment où le paquet d’essai est envoyé et la même horloge de source au moment où le paquet de réponse est reçu. Théoriquement, un cas de biais très sévère pourrait menacer cela. En pratique, la plus grosse menace est tout ce qui pourrait causer une discontinuité dans l’horloge de source durant le moment entre la prise de l’horodatage initial et final. Cela peut arriver, par exemple, avec certaines mises en œuvre de NTP.

+ La précision d’une horloge n’est importante que pour identifier l’heure à laquelle un certain délai a été mesuré. La précision, en elle-même n’a pas d’importance pour la précision de la mesure du délai.

+ La résolution d’une horloge ajoute à l’incertitude sur toute heure mesurée avec elle. Donc, si l’horloge source a une résolution de 10 ms, cela ajoute alors 10 ms d’incertitude à toute valeur horaire mesurée avec elle. On notera la résolution de l’horloge de source par Rsource.

En prenant ensemble tous ces éléments, on note qu’un calcul simple Tfinal-Tinitial sera trop court de 2*Rsource.

2.7.2 Erreurs ou incertitudes en rapport avec l’heure du réseau opposée à l’heure de l’hôte

Comme on a défini le délai d’aller retour, on souhaiterait mesurer le temps entre le moment où le paquet d’essai quitte l’interface réseau de Src et celui où le paquet réponse correspondant arrive (complètement) à l’interface réseau de Src, et on se réfère à ces temps comme à des "heures du réseau". Si les mesures de temps sont elles-mêmes effectuées par un logiciel sur Src, ce logiciel ne peut cependant mesurer directement que le temps entre l’instant où Src met un horodatage juste avant d’envoyer le paquet d’essai et celui où il met un horodatage juste après avoir reçu le paquet de réponse, et on se réfère à ces deux points comme à des "heures d’hôte".

Un autre contributeur à ce problème est le temps passé à Dst entre la réception du paquet d’essai et l’envoi du paquet réponse. Idéalement, ce temps est zéro ; cela est exploré plus avant au paragraphe suivant.

Dans la mesure où la différence entre l’heure du réseau et l’heure de l’hôte est connue avec précision, cette connaissance peut être utilisée pour corriger les mesures de l’heure de l’hôte et la valeur corrigée estime plus précisément la métrique désirée (en heure du réseau).

Cependant, dans la mesure où la différence entre l’heure du réseau et l’heure de l’hôte est incertaine, cette incertitude doit être prise en compte dans l’analyse d’une certaine méthode de mesure. On note Hinitial la borne supérieure de l’incertitude sur la différence entre l’heure du réseau et l’heure de l’hôte sur l’hôte Src en envoyant le paquet d’essai, et de même on définit Hfinal pour la différence sur l’hôte Src à la réception du paquet réponse. On note alors que ces problèmes introduisent une incertitude totale de Hinitial + Hfinal. Cette estimation de l’incertitude totale réseau contre hôte devrait être incluse dans l’analyse d’erreur/incertitude de toute mise en œuvre de mesures.

2.7.3 Erreurs ou incertitudes par rapport à la production d’une réponse par Dst

Tout le temps passé chez l’hôte de destination à recevoir et reconnaître le paquet provenant de Src, et ensuite à produire et envoyer la réponse correspondante ajoute des erreurs et incertitudes supplémentaires à la mesure du délai d’aller retour. L’erreur est égale à la différence entre l’heure du réseau à laquelle le premier bit du paquet est reçu par Dst et l’heure du réseau à laquelle le premier bit de la réponse est envoyé par Dst. Dans la mesure où cette différence est connue avec précision, cette connaissance peut être utilisée pour corriger la métrique désirée. Cependant, dans la mesure où cette différence est incertaine, cette incertitude doit être prise en compte dans l’analyse d’erreur d’une mise en œuvre de mesure. On note cette incertitude Hrefl. Cette estimation de l’incertitude devrait être incluse dans l’analyse d’erreur/incertitude de toute mise en œuvre de mesure.

Si l’erreur systématique (le biais constant en valeurs mesurées) peut être déterminée, elle peut être compensée dans le résultat rapporté.

Le but du calibrage est de déterminer l’erreur systématique et aléatoire générée par les instruments eux-mêmes aussi en détails que possible. Au minimum, une limite ("e") devrait être trouvée telle que la valeur rapportée soit dans la gamme (vraie valeur - e) à (vraie valeur + e) au moins 95 pour cent du temps. On appelle "e" l’erreur de calibrage pour les mesures. Elle représente le degré avec lequel les valeurs produites par l’instrument de mesure sont répétables ; c’est-à-dire, avec quelle proximité un délai réel de 30 ms est rapporté comme 30 ms. {Commentaire : 95 pour cent a été choisi parce que (1) un certain niveau de confiance est souhaité qui soit capable de retirer les valeurs excentriques qui vont se trouver dans les mesures de toute propriété physique ; (2) un niveau de confiance particulier devrait être spécifié de sorte que le résultat de mises en œuvre indépendantes puisse être comparé.}

De la discussion des trois paragraphes précédents, les erreurs de mesures pourraient être bordées en déterminant toutes les incertitudes individuelles, et en les ajoutant ensemble pour former

Cependant, des bornes raisonnables à la fois sur l’incertitude en rapport avec l’horloge capturée par le premier terme et sur l’incertitude en rapport avec l’hôte capturée par les trois derniers termes, devraient être possibles par des techniques de conception soigneuses et le calibrage des instruments en utilisant un réseau connu, isolé, dans un laboratoire.

Les incertitudes en rapport avec l’hôte, Hinitial + Hfinal + Hrefl, pourraient être bordées en connectant deux instruments dos à dos avec une liaison de série à haut débit ou un segment de LAN isolé. Dans ce cas, des mesures répétées mesurent le même délai d’aller retour.

Si les paquets d’essai sont petits, une telle connexion réseau a un délai minimal qui peut être approximé par zéro. Le délai mesuré contient donc seulement l’erreur systématique et aléatoire de l’instrumentation. La "valeur moyenne" de mesures répétées est l’erreur systématique, et la variation est l’erreur aléatoire.

Une façon de calculer l’erreur systématique, et l’erreur aléatoire au niveau de confiance de 95 % est de répéter l’expérience de nombreuses fois – au moins des centaines d’essais. L’erreur systématique va alors être la médiane. L’erreur aléatoire sera alors trouvée en retirant l’erreur systématique des valeurs mesurées. L’intervalle de confiance à 95 % sera dans la gamme du 2,5^ème percentile au 97,5^ème percentile de ces déviations de la vraie valeur. L’erreur de calibrage "e" pourra alors être prise comme étant la plus grande valeur absolue de ces deux nombres, plus l’incertitude en rapport avec l’horloge. {Commentaire : comme on l’a décrit, cette limite est relativement lâche car les incertitudes sont ajoutées, et la valeur absolue de la plus grande déviation est utilisée. Tant que la valeur résultante n’est pas une fraction significative des valeurs mesurées, c’est une limite raisonnable. Si la valeur résultante est une fraction significative des valeurs mesurées, des méthodes plus exactes seront alors nécessaires pour calculer l’erreur de calibrage.}

Noter que l’erreur aléatoire est une fonction de la charge de mesure. Par exemple, si de nombreux chemins sont mesurés par un instrument, cela peut augmenter les interruptions, la programmation du processus, et la marche/arrêt du disque (par exemple, pour enregistrer les mesures) toutes choses qui peuvent augmenter l’erreur aléatoire des singletons mesurés. Donc, en plus de la charge minimale des mesures pour trouver l’erreur systématique, les mesures de calibrage devraient être effectuées avec la même charge de mesures que verront les instruments sur le terrain.

Nous souhaitons répéter que ce traitement statistique se réfère au calibrage de l’instrument ; il est utilisé pour "calibrer le mètre" et dire comment le mètre reflète la réalité.

En plus du calibrage des instruments pour le délai fini, deux vérifications devraient être faites pour s’assurer que les paquets rapportés comme perdus ont bien été perdus. D’abord, le seuil pour la perte devrait être vérifié. En particulier, s’assurer que le seuil "raisonnable" est raisonnable : qu’il est très peu probable qu’un paquet arrive après la valeur seuil, et donc que le nombre de paquets perdus sur un intervalle n’est pas sensible à la borne d’erreur sur les mesures. Ensuite, considérer la possibilité qu’un paquet arrive à l’interface réseau, mais soit perdu à cause d’encombrement sur cette interface ou à cause de l’épuisement d’autres ressources (par exemple, des mémoires tampon) dans l’instrument.

Le calibrage et le contexte dans lesquels la métrique est mesurée DOIVENT être examinés avec attention, et DEVRAIENT toujours être rapportés avec les résultats de la métrique. On présente maintenant quatre éléments à considérer : le type-P des paquets d’essai, le seuil de délai infini (s’il en est), le calibrage d’erreur, et le chemin traversé par les paquets d’essai. Cette liste n’est pas exhaustive ; toute information supplémentaire qui pourrait être utile pour l’interprétation d’applications de la métrique devrait aussi être rapportée.

Comme noté dans le document cadre [RFC2330], la valeur de la métrique peut dépendre du type de paquets IP, ou "type-P" utilisé pour faire la mesure. La valeur du délai d’aller retour de type-P pourrait changer si le protocole (UDP ou TCP) le numéro d’accès, la taille, ou un dispositif pour un traitement particulier (par exemple, la préséance IP ou RSVP) change. Le type-P exact utilisé pour faire les mesures DOIT être rapporté avec précision.

De plus, le seuil (ou la méthodologie) pour distinguer entre un grand délai fini et la perte DOIT être rapporté.

+ Si l’erreur systématique peut être déterminée, elle DEVRAIT être retirée des valeurs mesurées.

+ On DEVRAIT aussi rapporter l’erreur de calibrage, e, de sorte que la vraie valeur soit la valeur rapportée plus ou moins e, avec un intervalle de confiance de 95 % (voir au paragraphe précédent).

+ Si possible, les conditions dans lesquelles un paquet d’essai avec un délai fini est rapporté comme perdu du fait de l’épuisement des ressources sur instrument de mesure DEVRAIENT être rapportées.

Finalement, le chemin traversé par le paquet DEVRAIT être rapporté, si possible. En général, il est impossible en pratique de savoir le chemin précis que prend un certain paquet à travers le réseau. Le chemin précis peut être connu pour certains types-P sur des chemins courts ou stables. Si le type-P comporte l’option Chemin enregistré (ou chemin de source lâche) dans l’en-tête IP, et si le chemin est assez court, et si tous les routeurs* sur le chemin prennent en charge l’enregistrement de chemin (ou le chemin de source lâche), et si l’hôte de Dst copie le chemin de Src à Dst dans le paquet de réponse correspondant, alors le chemin sera enregistré avec précision. Ceci est impraticable parce que le chemin doit être assez court, que de nombreux routeurs ne prennent pas en charge (ou ne sont pas configurés pour) l’enregistrement de chemin, et que l’utilisation de ce dispositif dégraderait souvent artificiellement les performances observées en retirant le paquet du traitement commun. Cependant, des informations partielles sont quand même un contexte précieux. Par exemple, si un hôte peut choisir entre deux liaisons* (et donc deux chemins séparés de Src à Dst) alors la liaison initiale utilisée est un contexte précieux. {Commentaire : Par exemple, avec l’établissement NetNow de Merit, une Src sur un NAP peut joindre une Dst sur un autre NAP par l’un ou l’autre de plusieurs cœurs de réseau différents.}

Après la métrique de singleton du délai d’aller retour de type-P, on va maintenant définir un échantillon particulier de tels singletons. L’idée de l’échantillon est de choisir un lien particulier des paramètres Src, Dst, et Type-P, puis de définir un échantillon des valeurs du paramètre T. Le moyen pour définir les valeurs de T est de choisir une heure de début T0, une heure de fin Tf, et un taux moyen lambda, puis de définir un processus de Poisson pseudo aléatoire de taux lambda, dont les valeurs tombent entre T0 et Tf. L’intervalle de temps entre les valeurs successives de T va alors moyenner 1/lambda.

{Commentaire : Noter que l’échantillonnage de Poisson est seulement une des façon de définir un échantillon. Il présente l’avantage de limiter le biais, mais d’autres méthodes d’échantillonnage peuvent être appropriées pour différentes situations. Tous sont encouragés à chercher des cas d’utilisation appropriés de ce cadre général et à soumettre leur méthode d’échantillonnage au processus de normalisation.}

Flux de Poisson de délai d’aller retour de type P (Type-P-Round-trip-Delay-Poisson-Stream)

Les valeurs de T dans la séquence sont d’accroissement monotone. Noter que T serait un paramètre valide pour le délai d’aller retour de type-P, et que dT serait une valeur valide de délai d’aller retour de type-P.

Étant donnés T0, Tf, et lambda, on calcule un processus de Poisson pseudo aléatoire commençant à T0 ou avant, avec un taux d’arrivée moyen de lambda, et se terminant à Tf ou après. Les valeurs horaires supérieures ou égales à T0 et inférieures ou égales à Tf sont alors choisies. À chaque instant de ce processus, on obtient la valeur du délai d’aller retour de type-P à cet instant. La valeur de l’échantillon est la séquence constituée des paires <heure, délai> résultantes. Si il n’y a pas de telles paires, la séquence est de longueur zéro, l’échantillon est dit vide.

Le lecteur est supposé s’être familiarisé avec l’exposé en profondeur sur l’échantillonnage de Poisson du document cadre [RFC2330], qui comporte les méthodes de calcul et vérification du processus de Poisson pseudo aléatoire.

Il n’y a pas de contrainte spécifique sur la valeur de lambda, excepté de noter les extrêmes. Si le taux est trop fort, les mesures de trafic vont alors perturber le réseau, et causer elles-mêmes de l’encombrement. Si le taux est trop faible, on ne pourra alors pas capturer un comportement de réseau présentant un intérêt. {Commentaire : On prévoit de documenter nos expériences et nos suggestions pour lambda dans d’autres RFC, avec un document de "bonnes pratiques actuelles".}

Comme on emploie une séquence de nombres pseudo aléatoires, la séquence des heures, et donc la valeur de l’échantillon, n’est pas pleinement spécifiée. Des générateurs de nombres pseudo aléatoires de bonne qualité seront nécessaires pour obtenir les qualités désirées.

L’échantillon est défini en termes de processus de Poisson aussi bien pour éviter les effets d’auto-synchronisation que pour capturer un échantillon qui soit statistiquement aussi peu biaisé que possible. {Commentaire : On ne prétend pas, bien sûr, que le trafic réel de l’Internet arrive conformément à un processus d’arrivée de Poisson.} Le processus de Poisson est utilisé pour programmer les mesures de délai. Les paquets d’essai ne vont généralement pas arriver à Dst selon une distribution de Poisson, pas plus que les paquets de réponse n’arrivent à Src selon une distribution de Poisson, car ils sont influencés par le réseau.

Toutes les métriques de singleton de délai d’aller retour de type-P dans la séquence auront les mêmes valeurs de Src, Dst, et Type-P.

Noter aussi que, étant donné un échantillon qui va de T0 à Tf, et de nouvelles valeurs horaires T0' et Tf' telles que T0 ≤ T0' ≤ Tf' ≤ Tf, la sous-séquence de l’échantillon dont les valeurs horaires sont toutes entre T0' et Tf' sont aussi un échantillon valide de flux de Poisson de délai d’aller retour de type-P.

+ la sélection d’heures spécifiques, en utilisant le processus spécifié d’arrivées de Poisson, et

+ la discussion des méthodologies déjà donnée pour la métrique de singleton de délai d’aller retour de type-P.

Il faut bien sûr veiller à traiter correctement les arrivées déclassées de paquets d’essai ou de réponse ; il est possible que la Src envoie un paquet d’essai à TS[i], puis en envoie un second (plus tard) à TS[i+1], et elle pourrait recevoir le second paquet de réponse à TR[i+1], et recevoir ensuite le premier paquet de réponse (plus tard) à TR[i].

En plus des sources d’erreurs et d’incertitudes associées aux méthodes employées pour mesurer les valeurs de singleton qui constituent l’échantillon, il faut veiller à analyser la précision du processus de Poisson par rapport à l’heure du réseau d’envoi des paquets d’essai. Des problèmes avec ce processus pourraient être causés par plusieurs choses, y compris des problèmes avec les techniques de nombres pseudo aléatoires utilisées pour générer le processus d’arrivée de Poisson, ou avec de la gigue dans la valeur de Hinitial (mentionnée ci-dessus comme incertitude dans la métrique de singleton du délai). Le document cadre montre comment utiliser l’essai de Anderson-Darling pour vérifier la précision d’un processus de Poisson sur des trames de courte durée. {Commentaire : Le but est de s’assurer que les paquets d’essai sont envoyés "assez près" d’une programmation de Poisson, et d’éviter un comportement périodique.}

On DOIT rapporter le calibrage et le contexte pour les singletons sous-jacents ainsi que le flux. (Voir "Rapport de la métrique" pour le délai d’aller retour de type-P.)

Connaissant la métrique d’échantillon de flux de Poisson de délai d’aller retour de type-P, on présente maintenant plusieurs statistiques de cet échantillon. Ces statistiques sont présentées principalement pour illustrer ce qui peut être fait.

Étant donnés un flux de Poisson de délai d’aller retour de type-P, c’est un pourcentage X entre 0 % et 100 %, le X^ème percentile de toutes les valeurs dT dans le flux. En calculant le percentile, les valeurs indéfinies sont traitées comme infiniment grandes. Noter que cela signifie que le percentile pourrait donc être indéfini (informellement, infini). De plus, le percentile de délai d’aller retour de type-P est indéfini si l’échantillon est vide.

Le 50^ème percentile serait alors 110 ms, car 90 ms et 100 ms sont plus petits et 110 ms et 'indéfini' sont plus grands.

Noter que si la possibilité qu’un paquet avec un délai fini soit rapporté comme perdu est significative, alors un haut percentile (90^ème ou 95^ème) peut être rapporté comme infini au lieu de fini.

Soit un flux de Poisson de délai d’aller retour de type-P, c’est la médiane de toutes les valeurs dT dans le flux. En calculant la médiane, les valeurs indéfinies sont traitées comme infiniment grandes. Comme avec le percentile de délai d’aller retour de type-P, la médiane de délai d’aller retour de type-P est indéfinie si l’échantillon est vide.

Comme noté dans le document cadre, la médiane ne diffère du 50^ème percentile que lorsque l’échantillon contient un nombre pair de valeurs, auquel cas, on utilise la moyenne des deux valeurs centrales.

Alors, la médiane serait 105 ms, la moyenne de 100 ms et 110 ms, les deux valeurs centrales.

Étant donné un flux de Poisson de délai d’aller retour de type-P, c’est le minimum de toutes les valeurs dT dans le flux. En calculant cela, les valeurs indéfinies sont traitées comme infiniment grandes. Noter que cela signifie que le minimum pourrait donc être indéfini (informellement, infini) si toutes les valeurs de dT sont indéfinies. De plus, le minimum de délai d’aller retour de type-P est indéfini si l’échantillon est vide.

Étant donné un flux de Poisson de délai d’aller retour de type-P et un seuil de durée, c’est la fraction de toutes les valeurs de dT dans le flux qui sont inférieures ou égales au seuil. Le résultat pourrait être aussi bas que 0 % (si toutes les valeurs de dT excèdent le seuil) ou aussi haut que 100 %. Le percentile inverse de délai d’aller retour de type-P est indéfini si l’échantillon est vide.

La pratique de mesures sur l’Internet soulève des problèmes à la fois de sécurité et de confidentialité. Le présent mémoire ne spécifie pas de mise en œuvre des métriques, de sorte qu’il n’affecte pas directement la sécurité de l’Internet ni des applications qui fonctionnent sur l’Internet. Cependant, les mises en œuvre de ces métriques doivent être attentives aux problèmes de sécurité et de confidentialité.

Il y a deux types de problèmes de sécurité : les dommages potentiels causés par les mesures, et les dommages potentiels aux mesures. Les mesures pourraient causer des dommages parce qu’elles sont actives, et elles injectent des paquets dans le réseau. Les paramètres de mesure DOIVENT être choisis avec soin afin que les mesures injectent des quantités triviales de trafic supplémentaire dans les réseaux qu’elles mesurent. Si elles injectent "trop" de trafic, elles peuvent biaiser les résultats des mesures, et dans des cas extrêmes, causer de l’encombrement et des dénis de service.

Les mesures elles-mêmes pourraient être endommagées par des routeurs qui donneraient aux mesures de trafic une priorité différente que celle du trafic "normal", ou par un agresseur qui injecterait des mesures de trafic artificielles. Si des routeurs peuvent reconnaître le trafic de mesure et le traiter séparément, les mesures ne vont pas refléter le trafic réel d’usager. Si un agresseur injecte du trafic artificiel qui est accepté comme légitime, le taux de perte sera artificiellement diminué. Donc, les méthodologies de mesure DEVRAIENT inclure des techniques appropriées pour réduire la probabilité que du trafic de mesures puisse être distingué du trafic "normal". Des techniques d’authentification , telles que les signatures numériques, peuvent être utilisées lorsque approprié pour se garder contre les attaques de trafic injecté.

Les problèmes de confidentialité de mesure de réseau sont limitées par les mesures actives décrites dans le présent mémoire. À la différence des mesures passives, il peut n’y avoir pas de livraison de données d’usager existant.

Des remerciements particuliers sont dus à Vern Paxson et à Will Leland pour plusieurs suggestions utiles.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	G. Almes
Request for Comments : 2680	S. Kalidindi
Catégorie : En cours de normalisation	M. Zekauskas
	Advanced Network & Services
Traduction Claude Brière de L’Isle	septembre 1999

Guy Almes	Sunil Kalidindi	Matthew J. Zekauskas
Advanced Network & Services, Inc.	Advanced Network & Services, Inc.	Advanced Network & Services, Inc.
200 Business Park Drive	200 Business Park Drive	200 Business Park Drive
Armonk, NY 10504	Armonk, NY 10504	Armonk, NY 10504
USA	USA	USA
téléphone : +1 914 765 1120	téléphone : +1 914 765 1128	téléphone : +1 914 765 1112
mél : almes@advanced.org	mél : kalidindi@advanced.org	mél : matt@advanced.org