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. Statut de ce mémoire 1

2. Introduction 1

2.1 Motivation 2

2.2 Questions générales concernant l’heure 3

3. Définition de singleton pour le délai unidirectionnel 3

3.1 Nom de la métrique 3

3.2 Paramètres de la métrique 3

3.3 Unités de la métrique 3

3.4 Définition 4

3.5 Discussion 4

3.6 Méthodologies 4

3.7 Erreurs et incertitudes 5

3.8 Rapport de la métrique 7

4. Définition pour les échantillons de délai unidirectionnel 8

4.1 Nom de la métrique 8

4.2 Paramètres de la métrique 8

4.3 Unités de la métrique 8

4.4 Définition 8

4.5 Discussion 8

4.6 Méthodologies 9

4.7 Erreurs et incertitudes 9

4.8 Rapport de la métrique 9

5. Quelques définitions de statistiques pour le délai unidirectionnel 9

5.1 Percentile de délai unidirectionnel de type P 9

5.2 Médiane de délai unidirectionnel de type P 10

5.3 Minimum de délai unidirectionnel de type P 10

5.4 Percentile inverse de délai unidirectionnel de type P 10

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

7. Remerciements 11

8. Références 11

9. Adresse des auteurs 11

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

Le présent mémoire définit une métrique pour le délai unidirectionnel des paquets à travers les chemins Internet. Il s’appuie sur les notions introduites et discutées dans le document cadre IPPM [RFC2330] ; le lecteur est supposé familiarisé avec ce document.

Le présent mémoire est destiné à être parallèle dans sa structure au document qui l’accompagne pour la perte de paquet ("Métrique de perte de paquet unidirectionnelle pour IPPM") [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 unidirectionnel de type P (Type-P-One-way-Delay) sera introduite pour mesurer une seule observation de délai unidirectionnel.

+ En utilisant cette métrique de singleton, un 'échantillon', appelé Flux de Poisson de délai unidirectionnel de type P (Type-P-One-way-Delay-Poisson-Stream) sera introduit pour mesurer une séquence de délais singletons mesurés à des instants pris d’un processus de Poisson.

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

Cette progression, du singleton à l’échantillon et à la statistique, 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 unidirectionnel d’un paquet de Type-P* provenant d’un hôte* de source à 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 unidirectionnel au lieu du délai d’aller-retour est motivée par les facteurs suivants :

+ Dans l’Internet d’aujourd’hui, le chemin d’une source à une destination peut être différent du chemin de retour de la destination à la source ("chemins asymétriques") de sorte que des séquences de routeurs différentes sont utilisées pour le chemin d’émission et le chemin inverse. Donc, les mesures d’aller-retour mesurent en fait ensemble les performances de deux chemins distincts. Mesurer indépendamment les deux chemins souligne les différences de performances entre les deux chemins qui peuvent traverser des fournisseurs de service Internet différents, et même des types de réseaux radicalement différents (par exemple, des réseaux de recherche par opposition à des réseaux commerciaux, ou ATM par opposition à du paquet-sur-SONET).

+ 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. Par exemple, un transfert de fichier qui utilise TCP peut dépendre plus des performances dans la direction du flux des données que de celles de la direction dans laquelle voyagent les accusés de réception.

+ Dans les réseaux à qualité de service (QS) l’approvisionnement dans une direction peut être radicalement différent de celui de la direction inverse, et donc, la garantie de QS diffère. Mesurer les chemins de façon indépendante permet la vérification des deux garanties.

Il sort du domaine d’application du présent document de dire précisément comment les métriques de délai seront appliquées à des problèmes spécifiques.

{Commentaire : La terminologie ci-dessous diffère de celle définie par les documents de l’UIT-T (par exemple, G.810, "Définitions et terminologie pour la synchronisation des réseaux" et I.356, "Performances de transfert de cellule ATM en RNIS-LB") mais elle est cohérente avec celle du document cadre IPPM. En général, ces différences découlent d’arrière-plans différents ; les documents de l’UIT-T ont historiquement une origine téléphonique, alors que les auteurs du présent document (ainsi que du Cadre) se fondent sur les systèmes informatiques. Bien que les termes définis ci-dessous n’aient pas d’équivalent direct dans les définitions de l’UIT-T, nous donnerons après nos définitions une transposition approchante. On notera cependant une confusion potentielle : notre définition de "horloge" est celle des systèmes d’exploitation informatique qui notent une horloge qui donne l’heure du jour, alors que la définition de l’horloge de l’UIT-T note une référence de fréquence.}

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. {Commentaire : à peu près l’équivalent UIT-T de "erreur horaire".}

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. {Commentaire : à peu près l’équivalent UIT-T de "erreur horaire 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. {Commentaire : à peu près l’équivalent UIT-T de "période d’échantillonnage".}

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. {Commentaire : à peu près l’équivalent UIT-T de "dérive horaire".}

La valeur d’un délai unidirectionnel 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 unidirectionnel de type P * de Src à Dst à T est dT<< signifie que Src envoie le premier bit d’un paquet de type-P à Dst à l’heure du réseau* T et que Dst a reçu le dernier bit de ce paquet à l’heure du réseau T+dT.

>>Le *Délai unidirectionnel de type P * de Src à Dst à T est indéfini (informellement, infini)<< signifie que Src envoie le premier bit d’un paquet de type-P à Dst à l’heure du réseau T et que Dst n’a pas reçu ce paquet.

Des suggestions sur ce qu’il convient de rapporter sur les valeurs de métriques figurent au paragraphe 3.8 après une discussion de la métrique, des méthodologies pour mesurer la métrique, et sur l’analyse d’erreur.

Le délai unidirectionnel de type P est une métrique analytique relativement simple, et on la croit une méthode de mesure efficace.

+ Les valeurs de délai réel seront positives. Donc, cela n’a aucun sens de faire rapport d’une valeur négative comme délai réel. Cependant, une valeur individuelle de délai zéro ou négatif pourrait être utile au titre d’un flux lorsque on essaye de découvrir une distribution d’un flux de valeurs de délais.

+ Comme les valeurs de délais vont souvent être dans une gamme de 100 µs à 10 ms, il sera important pour Src et Dst de se synchroniser très étroitement. Les systèmes GPS donnent un moyen de réaliser la synchronisation à quelques dizaines de µs. Une application ordinaire de NTP peut permettre une synchronisation de quelques ms, mais cela dépend de la stabilité et de la symétrie des propriétés de délai entre les agents NTP utilisés, et ce délai est ce qu’on essaye de mesurer. Une combinaison de serveurs NTP fondés sur le GPS et un ensemble d’autres serveurs NTP choisis et déployés avec prudence devrait donner de bons résultats, mais cela reste encore à vérifier.

+ Une méthodologie donnée 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, le dommage causé en traitant un long délai comme infini pourrait être zéro ou pas grand chose. Un paquet de données TCP, par exemple, qui n’arrive qu’après plusieurs temps d’aller-retour (RTT, round-trip time) peut aussi bien avoir été perdu.}

+ Si le paquet est dupliqué le long du chemin (ou des chemins) de sorte que plusieurs copies non corrompues arrivent à destination, le paquet est alors compté comme reçu, et la première copie arrivée détermine le délai unidirectionnel 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 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 :

+ S’arranger pour que Src et Dst soient synchronisés ; c’est-à-dire que leurs horloges soient très étroitement synchronisées l’une avec l’autre et chacune très proche de l’heure réelle.

+ À l’hôte Src, choisir les adresses de Src et de Dst, et former un paquet d’essai de type-P avec ces adresses. Toute portion de 'bourrage' du paquet qui ne serait nécessaire que pour donner au paquet d’essai une certaine taille, devrait être remplie avec des bits pris au hasard, pour éviter une situation dans laquelle le délai mesuré serait inférieur à celui qui serait subi autrement, à cause des techniques de compression le long du chemin.

+ Chez l’hôte Src, placer un horodatage dans le paquet de type P préparé, et l’envoyer vers Dst.

+ Si le paquet arrive dans un délai raisonnable, prendre un horodatage aussitôt que possible à la réception du paquet. En soustrayant les deux horodatages, une estimation du délai unidirectionnel peut être calculée. L’analyse d’erreur d’une certaine mise en œuvre de la méthode doit tenir compte de la proximité de synchronisation entre Src et Dst. Si le délai entre l’horodatage de Src et l’envoi réel du paquet est connu, l’estimation pourrait alors ê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 et l’horodatage de Dst est connu, l’estimation pourrait alors être ajustée en soustrayant cette quantité ; l’incertitude sur cette valeur doit être prise en compte dans l’analyse d’erreur. Voir à la section suivante, "Erreurs et incertitudes", un exposé plus détaillé.

+ Si le paquet ne réussit pas à arriver dans un délai raisonnable, le délai unidirectionnel est réputé indéfini (informellement, infini). Noter que le seuil de 'raisonnable' est un paramètre de la méthodologie.

Les questions telles que le format du paquet, les moyens par lesquels Dst sait quand attendre le paquet d’essai, et les moyens par lesquels Src et Dst se synchronisent sortent du domaine d’application du présent document. {Commentaire : On prévoit de documenter ailleurs notre propre travail en décrivant de telles techniques de mise en œuvre plus détaillées, et nous encourageons d’autres à le faire aussi.}

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 des horloges chez les hôtes Src et Dst.

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

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

L’incertitude de mesure d’un délai unidirectionnel se rapporte, en partie, aux incertitudes sur les horloges chez les hôtes Src et Dst. 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, on se réfère à l’horloge utilisée pour mesurer quand le paquet a été reçu par Dst par l’expression horloge de destination, on se réfère aux heures observées lorsque le paquet a été envoyé par l’horloge de source par l’expression Tsource, et lorsque le paquet a été reçu par l’horloge de destination par l’expression Tdest. Par rapport aux notions de synchronisation, précision, résolution, et de biais mentionnées dans l’Introduction, on note ce qui suit :

+ Toute erreur de synchronisation entre l’horloge de source et l’horloge de destination va contribuer à une erreur de la mesure du délai. On dit que l’horloge de source et l’horloge de destination ont une erreur de synchronisation de Tsynch si l’horloge de source est de Tsynch en avance sur l’horloge de destination. Donc, si on connaît exactement la valeur de Tsynch, on peut corriger la synchronisation d’horloge en ajoutant Tsynch à la valeur non corrigée de Tdest-Tsource.

+ 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. Lorsque on calcule des délais, on s’intéresse seulement aux différences entre les valeurs d’horloge, pas aux valeurs elles-mêmes.

+ 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 et de l’horloge de destination respectivement par Rsource et Rdest.

+ Le biais d’une horloge n’est pas tellement un problème supplémentaire car c’est une matérialisation du fait que Tsynch est lui-même une fonction du temps. Donc, si on tente de mesurer ou de borner Tsynch, cela doit être fait périodiquement. Sur une certaine durée, cette fonction peut être approximée comme une fonction linéaire plus des termes d’ordre plus élevé ; dans ces cas, une option est d’utiliser la connaissance du composant linéaire pour corriger l’horloge. En utilisant cette correction, la Tsynch résiduelle est réduite, mais reste une source d’incertitude qui doit être prise en compte. On utilise la fonction Esynch(t) pour noter une borne supérieure à l’incertitude de synchronisation. Donc, |Tsynch(t)| ≤ Esynch(t).

En prenant ensemble tous ces éléments, on note qu’un calcul simple Tdest-Tsource manquera de Tsynch(t) +/- (Rsource + Rdest). En utilisant la notion de Esynch(t), on note que ces problèmes d’horloge introduisent une incertitude totale de Esynch(t)+ Rsource + Rdest. Cette estimation de l’incertitude d’horloge totale devrait être incluse dans l’analyse d’erreur/incertitude de toute mise en œuvre de mesures.

3.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 unidirectionnel, on souhaiterait mesurer le temps entre le moment où le paquet d’essai quitte l’interface réseau de Src et celui où il arrive (complètement) à l’interface réseau de Dst, 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 et Dst, 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ù Dst met un horodatage juste après avoir reçu le paquet d’essai, et on se réfère à ces deux points comme à des "heures d’hôte".

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 d’heure d’hôte et la valeur corrigée estime de façon plus précise la métrique (d’heure du réseau) désirée.

Cependant, dans la mesure où la différence entre heure du réseau et heure d’hôte est incertaine, cette incertitude doit être prise en compte pour une analyse d’une certaine méthode de mesure. On note Hsource la borne supérieure de l’incertitude sur la différence entre heure du réseau et heure d’hôte chez l’hôte de source, et de façon similaire, on définit Hdest pour l’hôte Dst. On note alors que ces problèmes introduisent une incertitude totale de Hsource + Hdest. 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 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é ; et (3) même avec une mise en œuvre prototype de niveau utilisateur, 95 % est assez lâche pour exclure les valeurs excentrées.}

De la discussion des deux 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 les trois premiers termes et sur l’incertitude en rapport avec l’hôte capturée par les deux 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.

Par exemple, les incertitudes en rapport avec l’horloge sont bien réduites par l’utilisation d’une source horaire GPS. La somme de Esynch(t) + Rsource + Rdest est petite, et elle est aussi bordée par la durée de la mesure à cause de la source horaire mondiale.

Les incertitudes en rapport avec l’hôte, Hsource + Hdest, 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 unidirectionnel.

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 minimal de 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 unidirectionnel 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 les applications d’interprétation 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 unidirectionnel 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) 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 unidirectionnel 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 de la définition des 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 unidirectionnel de type P (Type-P-One-way-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 unidirectionnel de type-P, et que dT serait une valeur valide de délai unidirectionnel 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 unidirectionnel 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 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, car ils sont influencés par le réseau.

Toutes les métriques de singleton de délai unidirectionnel 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 unidirectionnel 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 unidirectionnel de type-P.

Il faut bien sûr veiller à traiter correctement les arrivées déclassées de paquets d’essai ; il est possible que la Src envoie un paquet d’essai à TS[i], puis en envoie un second (plus tard) à TS[i+1], alors que Dst pourrait recevoir le second paquet d’essai à TR[i+1], et ensuite recevoir le premier (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 Hsource (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 le singletons sous-jacent ainsi que le flux. (Voir "Rapport de la métrique" pour le délai unidirectionnel de type-P.)

Connaissant la métrique d’échantillon de métrique de flux de Poisson de délai unidirectionnel 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 unidirectionnel 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 unidirectionnel 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 unidirectionnel 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 unidirectionnel de type-P, la médiane de délai unidirectionnel 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 unidirectionnel 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 unidirectionnel de type-P est indéfini si l’échantillon est vide.

Étant donné un flux de Poisson de délai unidirectionnel 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 unidirectionnel 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 des Lawrence Berkeley Labs pour ses utiles commentaires sur les questions d’incertitude d’horloge et les statistiques. Merci aussi à Garry Couch, Will Leland, Andy Scherrer, Sean Shapira, et Roland Wittig 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 : 2679	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