Groupe de travail Réseau

Le présent mémoire apporte des informations pour la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

En utilisant la métrique de base de perte définie dans la RFC2680, le présent document définit deux métriques dérivées "distance de perte" et "période de perte", et les statistiques associées qui ensemble capturent les schémas de perte subis par les flux de paquets sur l’Internet. L’Internet affiche certains types de comportement spécifiques (par exemple, des pertes de paquet saccadées) qui peuvent affecter les performances vues par les usagers aussi bien que les opérateurs. Le schéma de perte ou la distribution des pertes est un paramètre clé qui détermine les performances observées par les usagers pour certaines applications en temps réel telles que les paquets vocaux ou de vidéo. Pour le même taux de perte, deux distributions de perte différentes pourraient produire des perceptions de performances largement différentes.

Table des Matières

1. Introduction 1

2. Terminologie 2

3. L’approche 2

4. Définitions de base 2

5. Définitions pour les échantillons de distance et de période de perte unidirectionnelle 3

5.1 Nom des métriques 3

5.2 Paramètres des métriques 3

5.3 Unités des métriques 3

5.4 Définitions 3

5.5 Méthodologies 4

5.6 Discussion 4

5.7 Considérations d’échantillonnage 4

5.8 Erreurs et incertitudes 5

6. Statistiques 5

6.1 Taux remarquable de perte unidirectionnelle de type P 5

6.2 Total de période de perte unidirectionnelle de type P 5

6.3 Longueurs de période de perte unidirectionnelle de type P 5

6.4 Longueurs de période inter pertes unidirectionnelle de type P 6

6.5 Exemples 6

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

7.1 Attaques de déni de service 7

7.2 Confidentialité 7

7.3 Intégrité 7

8. Considérations relatives à l’IANA 7

9. Remerciements 7

10. Références normatives 7

11. Références pour information 7

Déclaration complète de droits de reproduction 8

Dans certaines applications en temps réel (comme les paquets vocaux et vidéo) le schéma de perte, ou la distribution des pertes, est un paramètre clé qui détermine les performances observées par les usagers. Pour le même taux de perte, deux distributions de pertes différentes pourraient éventuellement produire des perceptions largement différentes des performances. L’impact du schéma de perte est aussi extrêmement important pour les applications qui ne sont pas en temps réel mais utilisent un protocole adaptatif tel que TCP. Voir les références [4], [5], [6], et [11] pour des preuves de l’importance et de l’existence de salves de pertes et de leurs effets sur les paquets des applications vocales et de vidéo.

Précédemment, IPPM a mis l’accent sur la spécification des métriques de base telles que le délai, la perte et la connectivité dans le cadre décrit dans la RFC2330. Cependant, des comportements spécifiques de l’Internet peuvent aussi se présenter sous le couvert du cadre IPPM, spécifiant de nouveaux concepts tout en réutilisant autant que possible les lignes directrices existantes. Dans le présent document, on propose deux métriques dérivées, appelées "distance de perte" et "période de perte", avec les statistiques associées, pour saisir les schémas de perte de paquet. La métrique de période de perte saisit la fréquence et la longueur (sporadicité) de la perte une fois qu’elle a commencé, et la métrique de distance de perte saisit l’espacement entre les périodes de perte. Il est important de noter que ces métriques sont dérivées de la métrique de base Perte de paquet unidirectionnelle de type P (Type-P-One-Way-packet-Loss).

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, [RFC2119].

Le présent document suit de près les lignes directrices spécifiées dans [3]. Précisément, les concepts de singleton, d’échantillon, de statistique, de principes de mesure, de paquet de type P, ainsi que de paquets de forme standard s’appliquent tous. Cependant, comme le document propose de capturer des comportements spécifiques de l’Internet, des modifications au processus d’échantillonnage PEUVENT être nécessaires. Bien sûr, ceci est mentionné dans [1], où il est noté que d’autres procédures d’échantillonnage peuvent être utiles selon les circonstances spécifiques. Le présent document propose que les comportements spécifiques soient capturés comme des métriques "dérivées" des métriques de base auxquelles les comportements se rapportent. Les raisons de l’adoption de cette position sont les suivantes :

- elle assure une utilisation cohérente de la définition de la métrique de singleton pour les différents comportements (par exemple, une seule définition de la perte de paquet est nécessaire pour capturer des salves de pertes, 'm sur n' pertes etc.)

- elle permet la réutilisation des méthodologies spécifiées pour la métrique de singleton avec des modifications chaque fois que nécessaire

- elle distingue clairement quelques métriques de base de nombreux comportements Internet.

Suivant les lignes directrices de [3], cela se traduit par la déduction des métriques d’échantillon des singletons respectifs. Le processus de déduction des métriques d’échantillon des singletons est spécifié dans [3], [1], et d’autres.

Dans les section qui suivent, on applique cette approche à un comportement Internet particulier, à savoir le processus de perte de paquet.

Numéro de séquence : les paquets consécutifs d’une série d’échantillons successifs reçoivent des numéros de séquence qui sont des entiers consécutifs. Le présent document ne spécifie pas exactement comment associer les numéros de séquence aux paquets. Les numéros de séquence pourraient être contenus au sein des paquets d’essai eux-mêmes, ou ils pourraient être déduits par le traitement ultérieur de l’échantillon.

Distance de perte : différence de numéros de séquence de deux paquets perdus successifs qui peuvent ou non être séparés par des paquets bien reçus.

Exemple : dans un flux de paquets, le paquet qui a le numéro de séquence 20 est considéré perdu, suivi par le paquet qui a le numéro de séquence 50. La distance de perte est 30.

Période de perte : soit P_i le i^ème paquet. Définir f(P_i) = 1 si P_i est perdu, 0 autrement. Alors, une période de perte commence si f(P_i) = 1 et f(P_(i-1)) = 0

Exemple : Considérons la séquence suivante de paquets perdus (notés x) et reçus (notés r).

et il y a quatre période de perte dans la séquence ci-dessus commençant à P_3, P_6, P_10, et P_13.

5. Définitions pour les échantillons de distance et de période de perte unidirectionnelle

Flux de distance de perte unidirectionnelle de type P (Type-P-One-Way-Loss-Distance-Stream)

Flux de période de perte unidirectionnelle de type P (Type-P-One-Way-Loss-Period-Stream)

lambda : un taux de toute méthode d’échantillonnage choisie par rapport à la seconde

Séquence de paires de la forme <distance de perte, perte>, où perte est déduit de la séquence de <temps, perte> dans [1], et distance de perte est soit zéro, soit un entier positif.

Séquence de paires de la forme <période de perte, perte>, où perte est déduit de la séquence de <temps, perte> dans [1], et période de perte est un entier.

Lorsque un paquet est considéré perdu (en utilisant la définition de [1]), on cherche son numéro de séquence et on le compare à celui du précédent paquet perdu. La différence est la distance de perte entre le paquet perdu et le précédent paquet perdu. L’échantillon devrait consister en paires <distance de perte, perte>. Cette définition suppose que les numéros de séquence des paquets d’essai successifs augmentent de façon monotone de un. La distance de perte associée au tout premier paquet perdu est considérée comme zéro.

Le numéro de séquence d’un paquet d’essai peut être déduit de la série temporelle d’échantillons collectée en effectuant la mesure de pertes conformément à la méthodologie de [1]. Par exemple, si un échantillon de perte consiste en <T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>, les numéros de séquence des cinq paquets d’essai envoyés aux instants T0, T1, T2, T3, et T4 peuvent être respectivement 0, 1, 2, 3 et 4, ou respectivement 100, 101, 102, 103 et 104, etc.

On démarre un compteur 'n' à une valeur initiale de zéro. Ce compteur est incrémenté de un chaque fois qu’un paquet perdu satisfait à la définition donnée à la Section 4. La métrique est définie comme <période de perte, perte> où "perte" est déduit de la séquence de <temps, perte> dans Flux de perte unidirectionnelle de type P [1], et la période de perte est réglée à zéro lorsque "perte" est zéro dans Flux de perte unidirectionnelle de type P, et période de perte est réglé à 'n' (ci-dessus) lorsque "perte" est un dans Flux de perte unidirectionnelle de type P.

Essentiellement, quand un paquet est perdu, la valeur courante de "n" indique la période de perte à laquelle appartient ce paquet. Pour un paquet qui est bien reçu, la période de perte est définie comme étant zéro.

Soit l’ensemble de paires suivant qui représente un Flux de perte unidirectionnelle de type P.

Les paquets envoyés aux instants T2, T5, T7, T9, T10 sont perdus. Les deux métriques dérivées peuvent être obtenues de cet échantillon de la façon suivante.

Comme le paquet 2 est le premier paquet perdu, la distance de perte associée est zéro. Pour le prochain paquet perdu (paquet 5), la distance de perte est 5 - 2 soit 3. De même, pour les paquets perdus restants (paquets 7, 9, et 10) leur distances de perte sont respectivement 2, 2, et 1. Donc, le flux de distance de perte unidirectionnelle de type P est :

Le paquet 2 règle le compteur 'n' à 1, qui est incrémenté de un pour les paquets 5, 7 et 9 conformément à la définition de la Section 4. Cependant, pour le paquet 10, le compteur reste à 4, encore selon la définition de la Section 4. Donc, le flux de période de perte unidirectionnelle de type P est :

La même méthodologie présentée dans [1] peut être utilisée pour conduire les expériences d’échantillonnage. Un synopsis est présenté ci-dessous.

Généralement, pour un certain type P, une méthodologie possible procèderait comme suit :

- On suppose que Src et Dst ont des horloges qui sont synchronisées l’une avec l’autre. Le degré de synchronisation est un paramètre de la méthodologie et dépend du seuil utilisé pour déterminer les pertes (voir ci-dessous).

- Chez l’hôte Src, choisir les adresses IP de source et destination, et former un paquet d’essai de type P avec ces adresses.

- 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, la perte de paquet unidirectionnelle est prise pour zéro.

- Si le paquet échoue à arriver dans un délai raisonnable, la perte de paquet unidirectionnelle est prise pour un. Noter que le seuil de "raisonnable" est ici un paramètre de la méthodologie.

La métrique de flux de distance de perte permet d’étudier la séparation entre les pertes de paquet. Cela pourrait être utile pour déterminer un "facteur de dispersion" associé au taux de perte de paquet. conjointement, la métrique de flux de période de perte permet d’étudier la sporadicité de perte pour chaque occurrence de perte. Une seule période de perte de longueur 'n' peut prendre en compte une portion significative du taux de perte global. Noter qu’il est possible de mesurer la distance entre les salves de pertes séparées par un ou plusieurs paquets bien reçus. (Se reporter aux paragraphes 6.4 et 6.5).

Les métriques proposées peuvent être utilisées indépendamment de la méthode d’échantillonnage particulière utilisée. On note que l’échantillonnage de Poisson peut ne pas donner les valeurs appropriées pour ces métriques pour certaines applications en temps réel telles que la voix sur IP, ainsi que pour des applications fondées sur TCP. Pour les applications en temps réel, il peut être plus approprié d’utiliser le modèle ON-OFF [10], dans lequel une période ON débute avec une certaine probabilité 'p', durant laquelle un certain nombre de paquets sont transmis avec un 'lambda-on' moyen conformément à une distribution géométrique et une période OFF commence avec une probabilité '1-p' et dure pendant une période fondée sur une distribution exponentielle avec le taux 'lambda-off'.

Pour les applications fondées sur TCP, on peut utiliser le modèle proposé dans [8]. Voir dans [9] une application du modèle.

Les aspects de mesure, y compris la taille de paquet, le seuil de perte, le type de machine d’essai choisie,etc., influencent invariablement la métrique de perte de paquet elle-même et donc les métriques dérivées décrites dans ce document. Donc, quant on fait une estimation des résultats relevant des métriques présentées dans ce document, on doit porter attention à ces questions. Voir dans [1] un exposé détaillé des questions d’erreurs et d’incertitudes concernant la mesure de la métrique de base de perte de paquet.

Définit la perte d’un paquet comme "remarquable" [7] si la distance entre le paquet perdu et le précédent paquet perdu n’est pas supérieure à delta, un entier positif, où delta est la "contrainte de perte".

Exemple : Soit delta = 99. Supposons que le paquet 50 est perdu, suivi par une salve de perte de longueur 3 commençant au paquet 125. Les trois pertes commençant au paquet 125 sont remarquables.

Dans un flux de distance de perte unidirectionnelle de type P (Type-P-One-Way-Loss-Distance-Stream), cette statistique peut être calculée simplement comme le nombre de pertes qui violent une certaine contrainte delta, divisée par le nombre de pertes. (Autrement, on peut aussi le définir comme le nombre de "pertes remarquables" par rapport au nombre de paquets bien reçus). Cette statistique est utile lorsque la distance réelle entre des pertes successives est importante. Par exemple, de nombreux codecs multimédia peuvent supporter des pertes en "dissimulant" l’effet de la perte en utilisant les informations de l’historique. Leur capacité à faire ainsi se dégrade avec un mauvais historique résultant de pertes séparées par des distances proches. En choisissant le delta sur la base de cette aptitude, on peut mesurer dans quelle mesure une perte est "remarquable" pour les besoins de la qualité. La perte remarquable exige un certain "facteur d »&talement" pour les pertes dans la série chronologique. Dans l’exemple ci-dessus où la contrainte de perte est égale à 99, un taux de perte de un pour cent avec un étalement de 100 entre les pertes (par exemple, 100, 200, 300, 400, 500 sur 500 paquets) peut être plus souhaitable pour certaines applications plutôt que le même taux de perte avec un étalement qui viole la contrainte de perte (par exemple, 100, 175, 275, 290, 400 : les pertes survenant en 175 et 290 violent le delta = 99).

Cela représente le nombre total de périodes de pertes, et peut être déduit de la métrique de période de perte Flux de période de perte unidirectionnelle de type P comme suit :

Total de période de perte unidirectionnelle de type P = valeur maximum de la première entrée de l’ensemble de paires, <période de perte, perte>, représentant la métrique de perte Flux de période de perte unidirectionnelle de type P.

Noter que cette statistique ne décrit pas elle-même la durée de chaque période de perte. Si cette statistique est grande, cela ne signifie pas que les pertes sont plus étalées qu’elles ne seraient autrement ; une ou plusieurs périodes de pertes peuvent inclure des salves de pertes. Cette statistique est généralement utile pour collecter une première approximation de l’étalement des pertes.

Cette statistique est une séquence de paires <période de perte, longueur>, avec l’entrée "période de perte" allant de 1 à Total de période de perte unidirectionnelle de type P. Donc, le nombre total de paires dans cette statistique est égale à Total de période de perte unidirectionnelle de type P. Dans chaque paire, la "longueur" est obtenue en comptant le nombre de paires, <période de perte, perte>, dans la métrique Flux de période de perte unidirectionnelle de type P qui a sa première entrée égale à "période de perte."

Comme cette statistique représente le nombre de paquets perdus dans chaque période de pertes, elle est un indicateur de la sporadicité de chaque période de pertes. En conjonction avec la statistique de total de période de perte, cette statistique est généralement utile pour observer quelles période de pertes sont potentiellement plus influentes que d’autres du point de vue de la qualité.

Cette statistique mesure la distance entre les périodes de perte successives. Elle prend la forme d’un ensemble de paires <période de perte, longueur de période inter-pertes>, avec l’entrée "période de perte" allant de 1 à Total de période de perte unidirectionnelle de type P, et "longueur de période inter-pertes" est la distance de perte entre le dernier paquet considéré comme perdu dans "période de perte" 'i-1', et le premier paquet considéré comme perdu dans "période de perte" 'i', où 'i' va de 2 à Total de période de perte unidirectionnelle de type P. La "longueur de période inter-pertes" associée à la première "période de perte" est définie comme étant zéro.

Cette statistique permet de considérer, par exemple, deux périodes de perte chacune de longueur supérieure à un (ce qui implique des salves de pertes) mais séparées par une distance de 2 pour appartenir à la même salve de pertes si une telle considération est jugée utile. Lorsque la longueur de période inter-pertes entre deux périodes de pertes sporadique est plus petite, cela pourrait affecter la capacité de dissimulation de perte des codecs multimédia car il y a un historique relativement plus petit. Lorsque il est plus grand, une application peut être capable de reconstruire son historique et pourrait atténuer les effets d’une période de pertes imminente.

On continue avec le même exemple qu’au paragraphe 5.4.3. Les trois statistiques définies ci-dessus auront les valeurs suivantes.

il y a trois distances de perte qui violent le delta de 2. Donc, Taux remarquable de perte unidirectionnelle de type P = 3/5 ((nombre de pertes remarquables)/(nombre de pertes total))

la cible de la première entrée dans la séquence de paires <période de perte, perte> est 4. Donc,

les longueurs des périodes individuelles de perte sont 1, 1, 1 et 2, respectivement. Donc,

Longueurs de période de perte unidirectionnelle de type P = {<1,1>,<2,1>,<3,1>,<4,2>}

les périodes de perte 1 et 2 sont séparées par 3 (5 - 2), les périodes 2 et 3 sont séparées par 2 (7 - 5), et 3 et 4 sont séparées par 2 (9 - 7). Donc, Longueurs de période inter-perte unidirectionnelle de type P = {<1,0>,<2,3>,<3,2>,<4,2>}

Effectuer des mesures sur l’Internet soulève des problèmes à la fois de sécurité et de confidentialité. Le présent document ne spécifie pas une mise en œuvre particulière de 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 garder en mémoire les problèmes de sécurité et de confidentialité.

Les métriques d’échantillon dérivées de ce document se fondent sur la métrique de perte définie dans la RFC2680 [1], et il hérite donc des considérations pour la sécurité contenues dans ce document. Le lecteur devrait consulter [1] pour un traitement plus détaillé des considérations de sécurité. Néanmoins, quelques éléments doivent être soulignés.

Le lambda spécifié dans Flux de distance de perte de type P et dans Flux de période de perte de type P contrôle le taux d’envoi des paquets d’essai, et donc si il est réglé à une valeur inconsidérément grande, il pourrait perturber le réseau en essai, causer de l’encombrement, ou au pire constituer une attaque de déni de service contre le réseau soumis à l’essai. Les mesures légitimes doivent choisir leurs paramètres avec soin afin d’éviter d’interférer avec le trafic normal du réseau.

La confidentialité des données d’utilisateur n’est pas concernée, car la métrique sous-jacente est destinée à être mise en œuvre en utilisant des paquets d’essai qui ne contiennent aucune information d’utilisateur. Même si les paquets contenaient des informations d’utilisateur, les métriques dérivées ne livrent pas les données envoyées par l’usager.

Les résultats pourraient être perturbés par une tentative de corruption ou de perturbation du flux sous-jacent, par exemple, en ajoutant des paquets supplémentaires qui ressembleraient à des paquets d’essai. Pour s’assurer que les paquets d’essai sont valides et n’ont pas été altérés durant le transit, des vérifications d’authentification et d’intégrité des paquets, comme un hachage cryptographique signé, PEUVENT être utilisées.

Comme le présent document ne définit pas de protocole spécifique ni ne définit aucune valeur bien connue, il n’y a pas de considérations relatives à l’IANA pour le présent document.

Matt Zekauskas a fourni des retours notables et le texte de la section Considérations pour la sécurité. Merike Kao a aidé à réviser les Considérations pour la sécurité et le Résumé pour se conformer aux lignes directrices sur les RFC. Nous les remercions tous les deux. Merci à Guy Almes pour avoir encouragé ce travail, et Vern Paxson pour ses commentaires durant les réunions de l’IETF. Merci à Steve Glass pour sa présentation à la réunion d’Oslo.

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

[4] J.-C. Bolot and A. vega Garcia, "The case for FEC-based error control for Packet Audio in the Internet", ACM Multimedia Systems, 1997.

[5] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, "Internet Packet Loss: Measurement and Implications for End-to-End QoS," Proceedings, International Conference on Parallel Processing, août 1998.

[6] M. Handley, "An examination of MBONE performance", Rapport technique, USC/ISI, ISI/RR-97-450, juillet 1997

[7] R. Koodli, "Scheduling Support for Multi-tier Quality of Service in Continuous Media Applications", PhD dissertation, Electrical and Computer Engineering Department, University of Massachusetts, Amherst, MA 01003, septembre 1997.

[8] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP throughput: a simple model and its empirical validation", in Proceedings of SIGCOMM'98, 1998.

[9] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly rate adjustment protocol for continuous media flows over best-effort networks", présentation d’un petit article dans ACM SIGMETRICS'99. Disponible comme Umass Computer Science tech report à ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz

[10] K. Sriram and W. Whitt, "Characterizing superposition arrival processes in packet multiplexers for voice and data", IEEE Journal on Selected Areas of Communication, pages 833-846, septembre 1986,

[11] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation in the MBONE multicast network", Proceedings of IEEE Global Internet, London, UK, novembre 1996.

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.

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

Groupe de travail Réseau	R. Koodli, Nokia Research Center
Request for Comments : 3357	R. Ravikanth, Axiowave
Catégorie : Information	août 2002
Traduction Claude Brière de L’Isle

Rajeev Koodli	Rayadurgam Ravikanth
Communications Systems Lab	Axiowave Networks Inc.
Nokia Research Center	200 Nickerson Road
313 Fairchild Drive	Marlborough, MA 01752
Mountain View, CA 94043	USA
USA	mél : rravikanth@axiowave.com
téléphone : +1-650 625-2359
mél : rajeev.koodli@nokia.com