RFC3393 Métrique de variation de délai de paquet Demichelis & Chimento

Groupe de travail Réseau

C. Demichelis, Telecomitalia Lab

Request for Comments : 3393

P. Chimento, Ericsson IPI

Catégorie : En cours de normalisation

novembre 2002

Traduction Claude Brière de L’Isle




Métrique de variation de délai de paquet IP pour la mesure des performances IP (IPPM)


Statut de ce mémoire

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.


Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.


Résumé

Le présent document se réfère à une métrique pour la variation du délai des paquets à travers les chemins de l’Internet. La métrique se fonde sur la différence du délai unidirectionnel des paquets choisis. Cette différence de délai est appelée "variation du délai de paquet IP (ipdv, Internet Protocol packet delay variation)".


La métrique est valide pour les mesures entre deux hôtes aussi bien dans le cas où ils ont synchronisé leurs horloges que dans celui où elles ne le sont pas. Les deux cas sont exposés dans ce document.


Table des Matières

1. Introduction 2

1.1 Terminologie 2

1.2 Définition 2

1.3 Motivation 3

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

2. Définition de singleton d’une métrique d’ipdv unidirectionnel 3

2.1 Nom de la métrique 4

2.2 Paramètres de la métrique 4

2.3 Unité de la métrique 4

2.4 Définition 4

2.5 Discussion 5

2.6 Méthodologies 5

2.7 Erreurs et incertitudes 6

3. Définitions pour les échantillons d’ipdv unidirectionnelle 7

3.1 Nom de la métrique 7

3.2 Paramètres 7

3.3 Unités de la métrique 7

3.4 Définition 7

3.5 Discussion 8

3.6 Méthodologie 8

3.7 Erreurs et incertitudes 8

4. Statistiques pour ipdv unidirectionnelle 8

4.1 Perte de paquet et statistiques d’ipdv 8

4.2 Distribution des valeurs de ipdv unidirectionnelle 9

4.3 Percentile d’ipdv unidirectionnelle de type P 9

4.4 Percentile inverse d’ipdv unidirectionnelle de type P 9

4.5 Gigue d’ipdv unidirectionnelle de type P 9

4.6 ipdv de crête à crête unidirectionnelle de type P 10

5. Discussion de la synchronisation d’horloge 10

5.1 Effets des erreurs de synchronisation 10

5.2 Estimation du biais des horloges non synchronisées 10

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

6.1 Déni de service 11

6.2 Confidentialité 11

6.3 Intégrité 11

7. Remerciements 11

8. Références 11

8.1 Références normatives 11

8.2 Références pour information 11

9. Adresse des auteurs 12

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



1. Introduction


Le présent mémoire définit une métrique pour la variation du délai des paquets qui s’écoulent d’un hôte à un autre sur un chemin IP. Il se fonde sur la RFC 2679 [2] "Métrique de délai unidirectionnel pour IPPM", et une partie du texte du présent mémoire est tirée directement de ce document ; le lecteur est supposé être familiarisé avec ce document.


Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [3].


Bien que le BCP 14, RFC2119 ait été écrit en pensant aux protocoles, les mots clés sont utilisés dans ce document pour des raisons similaires. Ils sont utilisés pour s’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.


La structure du mémoire est la suivante :

+ Une métrique analytique de 'singleton', appelée ipdv unidirectionnel de type P (Type-P-One-way-ipdv) sera introduite pour définir une seule instance de mesure d’ipdv.

+ En utilisant cette métrique de singleton, un 'échantillon', appelé flux de Poisson d’ipdv unidirectionnel de type P (Type-P-one-way-ipdv-Poisson-stream) sera introduit pour rendre possible le calcul des statistiques de séquences de mesures d’ipdv.

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


1.1 Terminologie


La variation du délai de paquet est parfois appelée la "gigue" (jitter). Ce terme cause cependant une confusion parce qu’il est utilisé de façon différente par différents groupes de gens.


"Gigue" a couramment deux significations : la première est la variation d’un signal par rapport à un certain signal d’horloge, où l’instant d’arrivée du signal est supposé coïncider avec l’arrivée du signal d’horloge. Cette signification est utilisée en référence à des signaux synchrones et pourrait être utilisée, par exemple, pour mesurer la qualité d’une émulation de circuit. Il y a aussi une métrique appelée "dérapage" (wander) qui est utilisée dans ce contexte.


La seconde signification a à voir avec la variation d’une métrique (par exemple, de délai) par rapport à une métrique de référence (par exemple, le délai moyen ou minimum). Cette signification est fréquemment utilisée par les informaticiens et se réfère souvent (mais pas toujours) à la variation de délai.


On évitera dans ce document, chaque fois que possible, le terme de gigue, et on s’en tiendra à celui de variation de délai qui est plus précis.


1.2 Définition


Une définition de la variation de délai de paquet IP (ipdv, IP Packet Delay Variation) peut être donnée pour les paquets à l’intérieur d’un flux de paquets.


L’ipdv d’une paire de paquets au sein d’un flux de paquets est définie pour une certaine paire de paquets choisis dans le flux allant du point de mesure MP1 au point de mesure MP2.


L’ipdv est la différence entre le délai unidirectionnel des paquets choisis.


1.3 Motivation


Une utilisation importante de la variation de délai est le dimensionnement des mémoires tampon de restitution pour les applications qui exigent la livraison régulière des paquets (par exemple, la restitution de la voix ou de vidéo). Ce qui est normalement important dans ce cas est la variation du délai maximum, qui est utilisée pour dimensionner les mémoires tampon de restitution pour de telles applications [7]. D’autres utilisations de la métrique de variation de délai sont, par exemple, de déterminer la dynamique des files d’attente au sein d’un réseau (ou d’un routeur) lorsque les changements de variation de délai peuvent être reliées à des changements du traitement de la longueur de la file d’attente à une certaine liaison ou combinaison de liaisons.


De plus, ce type de métrique est particulièrement robuste par rapport aux différences et variations des horloges dans les deux hôtes. Cela permet l’utilisation de la métrique même si les deux hôtes qui prennent en charge les points de mesure ne sont pas synchronisés. Les indications des biais réciproques des horloges peuvent être déduites de la mesure, et des corrections sont possibles. La précision relatée est souvent comparable à celle qui peut être obtenue avec des horloges synchronisées, qui est du même ordre de grandeur d’erreurs de synchronisation. Cela sera exposé plus loin.


Le domaine d’application de ce document est la fourniture d’un moyen de mesure de l’ipdv présente sur un chemin. Notre objectif est de fournir une métrique qui puisse faire l’objet de paramètres afin qu’elle puisse être utilisée à diverses fins. Tout rapport de la métrique DOIT inclure tous les paramètres qui lui sont associés afin que les conditions et significations de la métrique puissent être exactement déterminées. Comme la métrique ne représente pas un jugement de valeur (c’est-à-dire, ne définit pas un "bon" et un "mauvais") on ne spécifie pas précisément de valeurs particulières que devraient satisfaire les métriques des réseaux IP.


La souplesse de la métrique peut être vue comme un inconvénient mais il y a des arguments en faveur de la souplesse. D’abord, bien qu’il y ait certaines utilisations de ipdv mentionnées plus haut, les utilisations d’ipvd sont dans une certaine mesure toujours un sujet de recherches et une certaine place devrait être laissée à l’expérimentation. Ensuite, il y a des points de vue différents dans la communauté sur ce que devrait précisément être la définition (par exemple, [8], [9], [10]). L’idée ici est de donner les paramètres de la définition, plutôt que d’écrire un document différent pour chaque définition proposée. Tant que tous les paramètres sont pris en compte, ce que signifie une certaine utilisation de ipvd sera clair. Toutes les remarques du présent document tiennent, quels que soient les paramètres choisis.


1.4 Questions générales concernant l’heure


Tout de qui est contenu dans le paragraphe 2.2 de [2] s’applique aussi dans ce cas.


Pour résumer : comme dans [1] on définit un "biais" comme la dérivée première du décalage d’une horloge par rapport à "l’heure vraie" et on définit la "dérive" comme la dérivée seconde du décalage d’une horloge par rapport à "l’heure vraie".


À partir de là, on peut construire un "biais relatif" et une "dérive relative" pour deux horloges C1 et C2 l’une par rapport à l’autre. Ce sont des extensions naturelles des définitions du cadre de base de ces quantités :

+ Décalage relatif = différence de l’heure des horloges

+ Biais relatif = dérivée première de la différence de l’heure des horloges

+ Dérive relative = dérivée seconde de la différence de l’heure des horloges.


Note : La dérive d’une horloge, comme définie ci-dessus sur une longue période doit avoir une valeur moyenne qui tend vers zéro lorsque la période devient assez grande car la fréquence de l’horloge a une gamme finie (et petite). Afin de souligner l’ordre de grandeur de cet effet, il est considéré que la gamme maximum de la dérive pour les cristaux commerciaux est d’environ 50 par million (ppm). Comme elle est surtout en correspondance avec les variations de la température de fonctionnement (de 0 à 70 degrés Celsius) on s’attend à ce qu’un hôte ait une température presque constante durant sa période de fonctionnement, et les variations de température, même rapides, pourraient être de moins d’un degré Celsius par seconde, dans une gamme de l’ordre de quelques degrés. La gamme totale de la dérive est habituellement en rapport avec des variations de 0 à 70 degrés Celsius. Ces points sont importants pour évaluer la précision des mesures de l’ipdv, comme on le verra ci-dessous.


2. Définition de singleton d’une métrique d’ipdv unidirectionnel


L’objet de la métrique de singleton est de définir ce qu’est une seule instance d’une mesure d’une ipdv. Noter qu’elle n’a de signification que statistique en combinaison avec d’autres instances. Elle n’est pas destinée à être significative comme singleton, au sens d’être capable d’en tirer des conclusions.


Cette définition fait usage de la définition correspondante de la métrique de délai unidirectionnel de type P [2]. Cette section utilise les parties du projet de délai unidirectionnel qui s’appliquent directement à la métrique d’ipdv unidirectionnelle, ou fait des références directes à ce projet.


2.1 Nom de la métrique

ipdv unidirectionnel de type P (Type-P-One-way-ipdv)

2.2 Paramètres de la métrique

Src adresse IP d’un hôte

Dst adresse IP d’un hôte

T1 un instant

T2 un instant

L longueur d’un paquet en bits. Les paquets d’un flux de paquets de type P dans lequel la métrique d’ipdv de singleton est tirée DOIVENT tous être de la même longueur.

F une fonction de tri qui définit sans ambiguïté les deux paquets dans le flux choisi pour la métrique.

I1, I2 instants qui marquent le début et la fin de l’intervalle dans lequel survient le flux de paquets duquel la mesure de singleton est tirée.

P la spécification du type de paquet, sur et au-dessus des adresses de source et de destination.


2.3 Unité de la métrique

La valeur d’une ipdv unidirectionnelle de type P est soit un nombre réel de secondes (positif, zéro ou négatif) soit un nombre indéfini de secondes.


2.4 Définition

On donne un flux de paquets de type P et I1 et I2 tels que le premier paquet de type P à passer le point de mesure MP1 après I1 reçoit l’indice 0 et le dernier paquet de type P à passer le point de mesure MP1 avant I2 reçoit le plus fort numéro d’indice.


ipdv unidirectionnel de type P est défini pour deux paquets allant de Src à Dst choisis par la fonction de tri F comme la différence entre la valeur du délai unidirectionnel de type P (type-P-One-way-delay) de Src à Dst à l’instant T2 et la valeur du délai unidirectionnel de type P de Src à Dst à T1. T1 est l’heure du réseau à laquelle Scr a envoyé le premier bit du premier paquet, et T2 est l’heure du réseau à laquelle Src a envoyé le premier bit du second paquet. Cette métrique est dérivée de la métrique de délai unidirectionnel.


Donc, pour un nombre réel ddT "l’ipdv unidirectionnelle de type P de Src à Dst à T1, T2 est ddT" signifie que Src a envoyé deux paquets, le premier à l’heure du réseau T1 (premier bit) et le second à l’heure du réseau T2 (premier bit) et que les paquets ont été reçus par Dst à l’heure du réseau dT1 + T1 (dernier bit du premier paquet) et à l’heure du réseau dT2 + T2 (dernier bit du second paquet) et que dT2 - dT1 = ddT.


"L’ipdv unidirectionnelle de type P de Src à Dst à T1,T2 est indéfinie" signifie que Src a envoyé le premier bit d’un paquet à T1 et le premier bit d’un second paquet à T2 et que Dst n’a pas reçu un des paquets ou les deux.


La Figure 1 illustre cette définition. Supposons que les paquets P(i) et P(k) sont choisis.


I1 P(i) P(j) P(k) I2

MP1 |------------------------------------------------------------|

|\ |\ |\

| \ | \ | \

| \ | \ | \ | \ | \ | \

|dTi \ |dTj \ |dTk \

|<--->v |<--->v |<--->v

MP2 |------------------------------------------------------------|

I1 P(i) P(j) P(k) I2


Figure 1 : Illustration de la définition


Alors ddT = dTk - dTi comme défini ci-dessus.


2.5 Discussion


Cette définition de métrique dépend d’un flux de paquets de délai unidirectionnel de type P qui ont été mesurés. En général ce peut être un flux de deux paquets ou plus, délimités par les points d’extrémité I1 et I2 de l’intervalle. Il doit y avoir un flux d’au moins deux paquets afin qu’une mesure de singleton d’ipdv ait lieu. L’objet de la fonction de tri est de spécifier exactement quels sont les deux paquets du flux qui vont être utilisés pour la mesure de singleton. Noter que la fonction de tri peut impliquer d’observer le délai unidirectionnel de tous les paquets de type P du flux dans l’intervalle spécifié. Des exemples de fonction de tri sont :

+ les paquets consécutifs de type P au sein de l’intervalle spécifié,

+ les paquets de type P avec les indices spécifiés au sein de l’intervalle spécifié,

+ les paquets de type P avec les délais unidirectionnels minimum et maximum au sein de l’intervalle spécifié,

+ les paquets de type P avec les indices spécifiés de l’ensemble de tous les paquets de type P de délai unidirectionnel définis (c’est-à-dire, non infini) au sein de l’intervalle spécifié.


Les questions pratiques suivantes sont à considérer :

+ Étant une mesure différentielle, cette métrique est moins sensible aux problèmes de synchronisation d’horloge. Cette question sera examinée plus en détails à la section 5 de ce mémoire. On souligne que, si les conditions relatives d’horloge changent avec le temps, la précision de la mesure va dépendre de l’intervalle de temps I2 - I1 et la magnitude des erreurs possibles sera exposée plus loin.

+ 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 si le paquet est déjà arrivé à Dst). Comme l’ont noté Mahdavi et Paxson, de simples limites supérieures (comme 255 secondes de limite théorique supérieure sur la durée de vie des paquets IP [Postel : RFC0791]) pourrait être utilisée, mais une bonne ingénierie, incluant la compréhension de la durée de vie des paquets, sera nécessaire en pratique. Commentaire : noter que, pour de nombreuses applications de ces métriques, l’inconvénient de traiter un grand délai comme infini pourrait être nul ou très petit. Un paquet de données TCP, par exemple, qui arrive seulement après plusieurs multiples du RTT peut aussi bien avoir été perdu.

+ Comme avec les autres métriques de 'type P', la valeur de la métrique peut dépendre de propriétés du paquet telles que le numéro d’accès du protocole (UDP ou TCP) de la taille, et des arrangements pour un traitement particulier (comme avec la préséance IP ou avec RSVP).

+ ddT est déduit du début du premier bit d’un paquet envoyé par Src à la réception du dernier bit reçu par Dst. Le délai est corrélé à la taille du paquet. Pour cette raison, la taille du paquet est un paramètre de la mesure et doit être rapporté avec la mesure.

+ Si le paquet est dupliqué le long du 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 qui arrive détermine le délai unidirectionnel du paquet.

+ Si le paquet est fragmenté et si, pour quelque raison que ce soit, le réassemblage ne se fait pas, le paquet sera alors réputé perdu.


Dans ce document, on suppose que le flux de paquets de type P est généré conformément à la méthodologie d’échantillonnage de Poisson décrite dans [1].


La raison de l’échantillonnage de Poisson est qu’il assure un échantillonnage non biaisé et à distribution uniforme des temps entre I1 et I2. Cependant, d’autres méthodologies d’échantillonnage sont possibles. Par exemple, l’échantillonnage continu d’un flux binaire constant (c’est-à-dire une transmission de paquet périodique) est une possibilité. Cependant, dans ce cas, on doit être sûr d’éviter tous les effets de "pseudonyme" qui pourraient survenir avec des échantillons périodiques.


2.6 Méthodologies


Comme avec les autres métriques de type P-*, les détails de la méthodologie vont 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).


La méthodologie de mesure décrite dans cette section suppose la mesure et la détermination de ipdv en temps réel au titre d’une mesure active. Noter que cela peut également bien être fait a posteriori, c’est-à-dire, après l’achèvement de la mesure du délai unidirectionnel.


Généralement, pour un type P donné, la méthodologie va se dérouler comme suit :

Noter que cette méthodologie se fonde sur des horloges synchronisées. La nécessité d’horloges synchronisées pour Src et Dst sera exposée plus loin.


+ Démarrer après l’instant I1. Chez l’hôte Src, choisir les adresses IP Src et Dst, et former les paquets d’essai de type P avec ces adresses conformément à une technique donnée (par exemple, la technique d’échantillonnage de Poisson). Toute portion de 'bourrage' du paquet ayant seulement pour objet de donner au paquet d’essai une taille donnée devrait être remplie avec des bits aléatoires pour éviter une situation dans laquelle le délai mesuré serait inférieur à ce qu’il serait autrement à cause des techniques de compression le long du chemin.


+ Chez l’hôte Dst, s’arranger pour recevoir les paquets.


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


+ Si le paquet arrive dans un délai raisonnable, prendre un horodatage aussitôt que possible à réception du paquet. En soustrayant les deux horodatages, on peut calculer une estimation du délai unidirectionnel.


+ Si le paquet satisfait aux critères de la fonction de tri pour le premier paquet, enregistrer cette première valeur de délai. Autrement, continuer de générer le flux de paquets de type P comme ci-dessus jusqu’à ce que les critères soient satisfaits ou I2, selon ce qui se produit en premier.


+ Ches l’hôte Src, les paquets continuent d’être générés conformément à la méthodologie choisie. L’hôte Src place un horodatage dans le paquet de type P, et l’envoie vers Dst.


+ Si le paquet arrive dans un délai raisonnable, prendre un horodatage aussitôt que possible à réception du paquet. En soustrayant les deux horodatages, on peut calculer une estimation du délai unidirectionnel.


+ Si le paquet satisfait aux critères pour le second paquet, en soustrayant alors la première valeur de délai unidirectionnel de la seconde, on obtient la valeur de ipdv de la paire de paquets. Autrement, les paquets continuent d’être générés jusqu’à ce que les critères pour le second paquet soient remplis ou I2, selon le premier qui se produit.


+ Si un paquet ou les deux échouent à arriver dans un délai raisonnable, la ipdv est prise comme indéfinie.

2.7 Erreurs et incertitudes


Dans la métrique d’ipdv de singleton, les facteurs qui affectent la mesure sont les mêmes que ceux qui affectent la mesure de délai unidirectionnel, même si, dans ce cas, l’influence est différente.


Le document cadre [1] donne des lignes directrices générales sur ce point, mais on note ici les spécificités suivantes des métriques de délai qui s’y rapportent :

+ les erreurs/incertitudes dues aux incertitudes dans les horloges des hôtes Src et Dst,

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


Chacune de ces erreurs est discutée plus en détail dans les paragraphes qui suivent.


2.7.1 Erreurs/incertitudes en ce qui concerne les horloges

Si, en première approximation, l’erreur qui affecte la première mesure de délai unidirectionnel était la même que celle qui a affecté la seconde mesure, elle s’annuleraient l’une l’autre lors du calcul de l’ipdv. L’erreur résiduelle à l’égard des horloges est la différence des erreurs qui sont supposées changer de l’instant T1, auquel la première mesure est effectuée, à l’instant T2 auquel est effectuée la seconde mesure. La synchronisation, le biais, la précision et la résolution sont considérés ici avec les notes suivantes :

+ les erreurs de synchronisation entre les horloges de source et de destination contribuent aux erreurs dans les deux mesures de délai requises pour calculer l’ipdv ;

+ les effets de dérive et d’erreurs de biais sur les mesures d’ipdv peuvent être quantifiées comme suit : supposons que les fonctions de biais et de dérive soient connues. Supposons d’abord que la fonction de biais est linéaire dans le temps. Le décalage d’horloge est alors aussi une fonction du temps et l’erreur évolue comme e(t) = K*t + O, où K est une constante et O est le décalage à l’instant 0. Dans ce cas, l’erreur ajoutée à la soustraction des deux différents horodatages (t2 > t1) est e(t2) - e(t1) = K*(t2 - t1) qui sera ajoutée à la différence de temps (t2 - t1). Si la dérive ne peut pas être ignorée, mais qu’on suppose que la dérive est une fonction linéaire du temps, alors le biais est donné par s(t) = M*(t**2) + N*t + S0, où M et N sont constants et S0 est le biais à l’instant 0. L’erreur ajoutée par le traitement de biais/dérive devient dans ce cas e(t) = O + s(t) et l’erreur ajoutée à la différence des horodatages est
e(t2) - e(t1) = N*(t2 - t1) + M*{(t2 - t1)**2}. On prétend ici (voir les remarques du paragraphe 1.3) que les effets du biais sont plutôt petits sur l’échelle de temps dont on discute ici, car les variations de température dans un système tendent à être lentes par rapport aux temps de transmission de paquet et que la gamme de dérive est si petite.


+ Pour ce qui concerne la précision et la résolution, ce qui est noté dans le paragraphe 3.7.1 du document sur le délai unidirectionnel [2] s’applique aussi dans ce cas, avec cette précision supplémentaire sur la résolution, que dans ce cas l’incertitude introduite est deux fois celle d’une seule mesure de délai. Les erreurs introduites par ces effets sont souvent plus grandes que celles introduites par la dérive.


2.7.2 Erreurs/incertitudes sur l’heure du réseau par rapport à l’heure de l’hôte

Le contenu du paragraphe 3.7.2 de [2] s’applique aussi dans ce cas, avec les considérations supplémentaires suivantes : la différence entre l’heure de l’hôte et l’heure du réseau peut en général être décomposée en deux composantes, dont une est constante et l’autre est variable. Seuls les composantes variables vont produire des erreurs de mesure, tandis que la constante peut être annulée lors du calcul de l’ipdv.


Cependant, dans la plupart des cas, les composantes fixes et variables ne sont pas exactement connues.


3. Définitions pour les échantillons d’ipdv unidirectionnelle


Le but de la définition d’échantillon est de rendre possible le calcul des statistiques de séquences de mesures d’ipdv. La définition de singleton est appliquée à un flux de paquets d’essai générés conformément à un processus pseudo-aléatoire de Poisson avec un taux moyen d’arrivée de lambda. Si nécessaire, l’intervalle dans lequel le flux est généré peut être divisé en sous intervalles sur lesquels peut être appliquée la définition de singleton d’ipdv. Le résultat de cela est une séquence de mesures d’ipdv qui peut être analysée par diverses procédures statistiques.


En partant de la définition de la métrique de singleton d’ipdv unidirectionnelle, on définit un échantillon de tels singletons. Dans ce qui suit, les deux paquets nécessaires pour une mesure de singleton seront appelés une "paire".


3.1 Nom de la métrique


Flux de Poisson d’ipdv unidirectionnelle de type P (Type-P-One-way-ipdv-Poisson-stream)


3.2 Paramètres

Src adresse IP d’un hôte

Dst adresse IP d’un hôte

T0 un instant

Tf un instant

lambda , taux en secondes réciproques

L longueur de paquet en bits. Les paquets d’un flux de paquets de type P duquel l’échantillon de métrique d’ipdv est tirée DOIVENT avoir tous la même longueur.

F fonction de tri qui définit sans ambiguïté les paquets dans le flux choisi pour la métrique.

I(i), I(i + 1) i ≥ 0, paires d’instants qui marquent le début et la fin des intervalles dans lesquels survient le flux de paquets duquel la mesure est prise. I(0) ≤ T0 et en supposant que n est le plus grand indice, I(n) ≥ Tf.

P spécification du type de paquet, sur et au dessus des adresses de source et de destination.


3.3 Unités de la métrique


Une séquence de triplets dont les éléments sont :

T1, T2 des instants

dT un nombre réel ou un nombre indéfini de seconde


3.4 Définition


Un processus de Poisson pseudo aléatoire est défini de telle sorte qu’il commence à T0 ou avant, avec un taux moyen d’arrivée de lambda, et se termine à Tf ou après. Ces valeurs de temps T(i) supérieures ou égales à T0 et inférieures ou égales à Tf sont alors choisies pour les instants de génération de paquet.


Chaque paquet qui tombe dans un des sous-intervalles I(i), I(i + 1) est vérifié pour déterminer si il satisfait aux critères de la fonction de tri F comme premier ou second paquet d’une paire nécessaire pour calculer l’ipdv. Des sous-intervalles peuvent être définis de telle sorte qu’un nombre suffisant d’échantillons de singletons puisse être obtenu pour une estimation statistique valide.


Les triplets définis ci-dessus consistent en les instants de transmission des premiers et seconds paquets de chaque singleton inclus dans l’échantillon, et de l’ipdv en secondes.


3.5 Discussion


Noter d’abord que, comme une séquence de nombres pseudo-aléatoires est employée, la séquence des temps, 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 réaliser les qualités désirées.


L’échantillon est défini dans les termes d’un processus de Poisson à la fois pour éviter les effets de l’auto-synchronisation et aussi pour capturer un échantillon qui soit statistiquement aussi peu biaisé que possible. Il n’est, bien sûr, pas prétendu que le trafic réel de l’Internet arrive selon un processus d’arrivée de Poisson.


La métrique d’échantillon peut être mieux expliquée avec un couple d’exemples : pour le premier, supposons que la fonction de tri spécifie les délais unidirectionnels maximum et minimum "non infinis" sur chaque sous-intervalle. On peut définir des sous-intervalles contigus d’une longueur fixe spécifiée et produire une séquence dont chacun de ces éléments est le triplet <instant de transmission du paquet de délai max, instant de transmission du paquet de délai minimum, D(max) - D(min)> qui est collecté pour chaque sous-intervalle. Un second exemple est la fonction de tri qui spécifie les paquets dont les indices (numéros de séquence) sont juste les entiers en dessous d’une certaine limite. Dans ce cas, les sous-intervalles sont définis par les instants de transmission des paquets générés et la séquence produite est juste <T(i), T(i + 1), D(i + 1) - D(i)> où D(i) note le délai unidirectionnel du ième paquet d’un flux.


Cette définition de la métrique d’échantillon renferme à la fois la définition proposée dans [9] et celle proposée dans [10].


3.6 Méthodologie


Comme des paquets peuvent être perdus ou dupliqués ou peuvent arriver dans un ordre différent de celui d’envoi, les paires de paquets d’essai devraient être marquées d’un numéro de séquence. Pour les paquets dupliqués, seule la première copie reçue devrait être prise en compte.


Autrement, la méthodologie est la même que pour la mesure de singleton, à l’exception que la mesure de singleton est répétée un certain nombre de fois.


3.7 Erreurs et incertitudes


Les mêmes considérations qu’à la métrique de singleton s’appliquent. Une erreur supplémentaire peut être introduite par le processus pseudo-aléatoire de Poisson comme exposé dans [2]. D’autres considérations seront données à la section 5.


4. Statistiques pour ipdv unidirectionnelle


On suggère certaines statistiques qui peuvent fournir des informations utiles pour analyse le comportement des paquets qui s’écoulent de Src à Dst. Les statistiques sont supposées être calculées à partir d’un échantillon de ipdv de taille raisonnable.


L’objet n’est pas de définir toutes les statistiques possibles pour ipdv, mais celles qui ont été proposées ou utilisées.


4.1 Perte de paquet et statistiques d’ipdv


Le traitement des paquets perdus comme ayant un délai "infini" ou "indéfini" complique la déduction des statistiques pour ipdv. Précisément, lorsque des paquets dans la séquence de mesure sont perdus, de simples statistiques comme la moyenne d’échantillon ne peuvent pas être calculées. Une approche possible pour traiter ce problème est de réduire l’espace d’événement par le conditionnement. C’est-à-dire qu’on considère des statistiques conditionnelles, à savoir qu’on estime l’ipdv moyenne (ou autre statistique dérivée) sous condition de l’événement que les paires de paquets sélectionnées arrivent à destination (dans le délai fixé). Bien qu’en soi ceci ne soit pas sans poser de problèmes (ce qui arrive, par exemple, quand tous les autres paquets sont perdus) cela offre un moyen de faire quelques constatations (valides) sur ipdv, en même temps que d’éviter des événements avec des résultats indéfinis.


En termes pratiques, cela veut dire de jeter les échantillons lorsque un des paquets sélectionnés ou les deux ont un délai indéfini. L’espace d’échantillons est réduit (conditionné) et on peut calculer les statistiques habituelles, en comprenant que formellement, elles sont conditionnelles.


4.2 Distribution des valeurs de ipdv unidirectionnelle


Les valeurs d’ipdv unidirectionnelle sont limitées en vertu du fait qu’il y a des limites supérieures et inférieures aux valeurs de délai unidirectionnel. Précisément, le délai unidirectionnel est limité vers le haut par la valeur choisie comme maximum au delà duquel le paquet est compté comme perdu. Sa limite inférieure est le délai de propagation, de transmission et de transit nodal en supposant qu’il n’y a pas de file d’attente ou de délais nodaux variables dans le chemin. On note U la limite supérieure de délai unidirectionnel et L la limite inférieure et on voit que l’ipdv unidirectionnelle ne peut prendre des valeurs que dans l’intervalle (ouvert) (L-U, U-L).


Dans tout intervalle fini, le délai unidirectionnel peut varier de façon monotone (non croissante ou non décroissante) ou bien sûr il peut varier dans les deux directions dans l’intervalle, au sein des limites de l’intervalle semi-ouvert [L,U). En conséquence, au sein de cet intervalle, les valeurs d’ipdv unidirectionnelle peuvent être positives, négatives, ou un mélange des deux (y compris 0).


Comme la gamme des valeurs est limitée, l’ipdv unidirectionnelle ne peut pas augmenter ou diminuer indéfiniment. Supposons, par exemple, que l’ipdv a un “cours” positif (c’est-à-dire, une longue séquence de valeurs positives). À un certain point de ce 'cours', les valeurs positives doivent s’approcher de 0 (ou devenir négatives) si le délai unidirectionnel reste fini. Autrement, les limites de délai unidirectionnel seraient violées. Si un tel cours devait se continuer infiniment, l’échantillon moyen (en supposant qu’aucun paquet n’est perdu) approcherait 0 (parce que les valeurs d’ipdv unidirectionnelle doivent s’approcher de 0). Noter cependant que cela ne dit rien sur la forme de la distribution, ou si elle est symétrique. Noter de plus que sur des intervalles significatifs, selon la largeur de l’intervalle [L,U) l’échantillon moyen d’ipdv unidirectionnelle pourrait être positif, négatif ou nul.


Il y a deux façons fondamentales de représenter la distribution des valeurs d’un échantillon d’ipdv : un pdf empirique et un cdf empirique. Le pdf empirique est le plus souvent représenté comme un histogramme où la gamme des valeurs d’un échantillon d’ipdv est divisé en boîtes d’une longueur donnée et chaque boîte contient la proportion de valeurs qui tombent entre les deux limites de la boîte. (Parfois, on utilise à la place le nombre de valeurs qui tombent entre les deux limites). Le cdf empirique est simplement la proportion de valeurs d‘échantillons d’ipdv inférieures à une certaine valeur, pour une séquence de valeurs choisies dans la gamme des valeurs d’ipdv.


4.3 Percentile d’ipdv unidirectionnelle de type P


Soit un échantillon d’ipdv unidirectionnelle de type P et un certain pourcentage X entre 0 % et 100 %. Le Xème percentile de toutes les valeurs d’ipdv est dans l’échantillon. Donc, le 50ème percentile est la médiane.


4.4 Percentile inverse d’ipdv unidirectionnelle de type P


Soit un échantillon d’ipdv unidirectionnelle de type P et une certaine valeur Y, c’est le pourcentage des valeurs d’échantillon ipdv inférieures ou égales à Y.


4.5 Gigue d’ipdv unidirectionnelle de type P


Bien que l’utilisation du terme "gigue" soit déconseillé, on l’utilise ici en suivant les auteurs de [8]. Dans ce document, la fonction de tri spécifie que des paquets consécutifs du flux de type P sont choisis pour les paires de paquets utilisées dans le calcul d’ipdv. On prend alors la valeur absolue des valeurs d’ipdv dans l’échantillon. Les auteurs de [8] utilisent l’échantillon résultant pour comparer le comportement de deux différents algorithmes de programmation.


Une autre façon, mais en rapport, de calculer une estimation de la gigue est donnée dans la RFC1889 [11]. La fonction de tri prend là des paires de paquets implicitement consécutifs, et la "gigue estimée" est calculée en prenant les valeurs absolues des séquences d’ipdv (comme définies dans ce document) et en appliquant un filtre exponentiel avec un paramètre 1/16 pour générer l’estimation (c’est-à-dire, j_new = 15/16* j_old + 1/16*j_new).


4.6 ipdv de crête à crête unidirectionnelle de type P


Dans ce cas, la fonction de tri utilisée pour collecter l’échantillon d’ipdv unidirectionnel de type P spécifie le premier paquet de chaque paire comme le paquet avec le délai unidirectionnel de type P maximum dans chaque sous-intervalle, et le second paquet de chaque paire comme le paquet avec le délai unidirectionnel de type P minimum dans chaque sous-intervalle. La séquence de valeurs résultante est la variation de délai de crête à crête dans chaque sous-intervalle de l’intervalle de mesure.


5. Discussion de la synchronisation d’horloge


Cette section examine le besoin d’avoir des horloges synchronisées à la source et la destination, bien que, dans le cas d’horloges non synchronisées, les données provenant des mesures elles-mêmes puissent être utilisées pour corriger les erreurs. Ces considérations sont données comme base de discussion et elles requièrent des investigations complémentaires.


5.1 Effets des erreurs de synchronisation


Les erreurs d’horloge peuvent être générées par deux processus : la dérive relative et le biais relatif de deux horloges données. On devrait noter que la dérive est physiquement limitée et ainsi le biais total relatif de deux horloges peut varier entre une limite supérieure et une limite inférieure.


Supposons ensuite que nous avons une mesure entre deux systèmes tels que les horloges dans les systèmes source et destination ont à l’instant 0 un biais relatif de s(0) et après un intervalle de mesure T ont un biais de s(T). On suppose que les deux horloges ont un décalage initial de O (c’est la lettre O).


Supposons maintenant que les paquets voyagent de la source à la destination en temps constant, auquel cas l’ipdv est zéro et la différence des horodatages des deux horloges est en fait juste le décalage relatif des horloges. Supposons de plus qu’au début de l’intervalle de mesure, la valeur d’ipdv est calculée à partir d’une paire de paquets et qu’à la fin de l’intervalle de mesure, une autre valeur d’ipdv est calculée à partir d’une autre paire de paquets. Supposons que l’intervalle de temps couvert par la première mesure est t1 et que l’intervalle de temps couvert par la seconde mesure est t2. Alors :


ipdv1 = s(0)*t1 + t1*(s(T) - s(0))/T


ipdv2 = s(T)*t2 + t2*(s(T) - s(0))/T


en supposant que le changement dans le biais est linéaire dans le temps. Dans la plupart des cas pratiques, on prétend que la dérive sera proche de zéro auquel cas le second terme (de correction) dans les équations ci-dessus disparaît.


Noter que dans la discussion ci-dessus, d’autres erreurs, y compris les différences entre heure de l’hôte et heure du réseau, et les discontinuités d’horloges ayant des causes externes (par exemple, des corrections d’horloge) sont ignorées. Avec ces hypothèses, les erreurs d’horloge maximums seront dues au biais relatif maximum agissant sur le plus grand intervalle entre les paquets.


5.2 Estimation du biais des horloges non synchronisées


Si le biais est linéaire (c’est-à-dire, si s(t) = S * t pour S constant) l’erreur dans les valeurs d’ipdv va dépendre du temps entre les paquets utilisé pour calculer la valeur. Si ti est le temps entre la paire de paquets, alors soit Ti le temps moyen d’échantillon entre les paquets et s(Ti) = S * Ti le biais moyen. Dans le cas où les délais sont constants, le paramètre de biais S peut être estimé à partir de l’estimation de Ti du temps entre les paquets et la valeur moyenne d’échantillon d’ipdv. Sous ces hypothèses, les valeurs d’ipdv peuvent être corrigées en soustrayant le S * ti estimé.


On observe que le déplacement dû au biais ne change pas la forme de la distribution, et par exemple l’écart type reste le même. Ce qui introduit une distorsion est l’effet de la dérive, et aussi lorsque la valeur moyenne de cet effet est zéro à la fin de la mesure. La valeur de cette distorsion est limitée à l’effet de la variation du biais total sur l’intervalle d’émission.


6. Considérations pour la sécurité


La métrique d’ipdv unidirectionnelle a les mêmes propriétés de sécurité que la métrique de délai unidirectionnel [2], et donc elle hérite des considérations de sécurité de ce document. Le lecteur devrait consulter [2] pour un traitement plus détaillé des considérations de sécurité. Néanmoins, quelques éléments méritent d’être soulignés.


6.1 Déni de service

Il est toujours possible qu’il y ait une tentative d’attaque de déni de service par l’envoi de nombreux paquets de mesure dans le réseau. En général, les mesures légitimes doivent avoir leurs paramètres choisis avec soin afin d’éviter d’interférer avec le trafic normal.


6.2 Confidentialité

Les paquets ne contiennent pas d’informations d’utilisateur, donc il n’y a pas de problème de confidentialité des données d’utilisateur.


6.3 Intégrité

Il pourrait aussi y avoir des tentatives pour perturber les mesures en détournant les paquets ou en les corrompant. Pour s’assurer que les paquets d’essai sont valides et n’ont pas été altérés durant le transit, la vérification de l’authentification et de l’intégrité des paquets peut être utilisée.


7. Remerciements


Merci à Merike Kaeo, Al Morton et Henk Uiterwaal pour la correction des erreurs et pour avoir précisé la reformulation de ce document final.


Une révision majeure précédente du document a résulté de discussions par messagerie électronique avec des suggestions de Mike Pierce, Ruediger Geib, Glenn Grotefeld, et Al Morton. Pour les précédentes révisions de ce document, des discussions avec Ruediger Geib, Matt Zekauskas et Andy Scherer ont été d’une aide précieuse.


8. Références

8.1 Références normatives

[1] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Cadre pour la mesure des performances d'IP", RFC2330], mai 1998. (Information)


[2] G. Almes, S. Kalidindi, M. Zekauskas, "Métrique de délai unidirectionnel pour IPPM", RFC2679, septembre 1999. (P.S.)


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


8.2 Références pour information

[4] Recommandation UIT-T Y.1540 (anciennement I.380) "Service de communications de données au protocole Internet – paramètres de transfert de paquet IP et performances de disponibilité", février 1999.


[5] Demichelis, Carlo - "Packet Delay Variation Comparison between ITU-T and IETF Draft Definitions" novembre 2000 (dans les archives de messagerie de IPPM).


[6] Recommandation UIT-T I.356 "Performances de transfert de cellules de couche ATM sur RNIS-LB".


[7] S. Keshav - "An Engineering Approach to Computer Networking", Addison-Wesley 1997, ISBN 0-201-63442-2.


[8] V. Jacobson, K. Nichols, K. Poduri, "PHB Transmission expédiée", RFC2598, juin 1999. (Obsolète, voir RFC3246) (P.S.)


[9] Recommandation UIT-T Y.1541 - "Service de communications de données au protocole Internet – Performances IP et objectifs de disponibilité et d’allocations", avril 2000.


[10] Demichelis, Carlo - "Improvement of the Instantaneous Packet Delay Variation (IPDV) Concept and Applications", World Telecommunications Congress 2000, 7-12 mai 2000.


[11] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", RFC1889, janvier 1996. (Obsolète, voir RFC3550 STD64)


9. Adresse des auteurs


Carlo Demichelis

Philip Chimento

Telecomitalia Lab S.p.A

Ericsson IPI

Via G. Reiss Romoli 274

7301 Calhoun Place

10148 – TORINO

Rockville, Maryland 20855

Italia

USA

téléphone : +39 11 228 5057

téléphone : +1-240-314-3597

mél : carlo.demichelis@tilab.com

mél : chimento@torrentnet.com


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


Copyright (C) The Internet Society (2002). Tous droits réservés.


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 droits de reproduction ci-dessus et le présent 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 droits de reproduction 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 droits de reproduction 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 ses 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.


Remerciement

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

page - 12 -