Groupe de travail Réseau	C. Perkins	
Request for Comments : 2354	O. Hodson	
Catégorie : Information	University College London	
Traduction Claude Brière de L'Isle	juin 1998	

Options pour la réparation de supports de direct

Statut de ce mémoire
Le présent mémoire donne des informations pour la communauté de l'Internet. Le présent mémoire ne contient aucune sorte de norme de l'Internet. La distribution de ce mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (1998). Tous droits réservés.

Résumé
Le présent document récapitule une gamme de techniques possibles pour la réparation de flux de support continu sujets à la perte de paquets. Les techniques exposées incluent la transmission redondante, la retransmission, l'interpolation et la correction d'erreur directe. La gamme d'application de ces techniques est notée, ainsi que les exigences des protocoles et leurs implications.

1.	Introduction

Un certain nombre d'applications qui utilisent le transport RTP/UDP pour livrer des flux de transport en continu sont apparues. Du fait de la nature non fiable de la livraison de paquet UDP, la qualité des flux reçus sera affectée défavorablement par la perte de paquet. Un certain nombre de techniques existent, par lesquelles les effets de la perte de paquet peut être réparée. Ces techniques ont une large gamme d'application et exigent divers degrés de soutien du protocole. Dans le présent document, un certain nombre de ces techniques sont exposées, avec des recommandations sur leur application.

Il devrait être noté que le présent document est introductif par nature, et qu'il n'essaye pas d'être exhaustif. En particulier, nous restreignons notre exposé aux techniques de réparation qui exigent l'implication de l'envoyeur d'un flux de support, et n'exposons pas les possibilités de réparation fondée sur le receveur.

Pour un exposé plus complet, le lecteur est invité à se reporter à la référence [5].

2.	Terminologie et cadre de protocole

Une unité est définie comme un intervalle mesuré dans le temps de données de support, normalement déduites du travail d'un codeur de support. Un paquet comporte une ou plusieurs unités, encapsulées pour la transmission sur le réseau. Par exemple, de nombreux codeurs audio fonctionnent sur des unités de 20 ms, qui sont normalement combinées pour produire des paquets de 40 ms ou 80 ms pour la transmission. On suppose le cadre de travail de RTP [18]. Cela implique que les paquets ont un numéro de séquence et un horodatage. Le numéro de séquence note l'ordre dans lequel les paquets sont transmis, et il est utilisé pour détecter les pertes. L'horodatage est utilisé pour déterminer l'ordre d'exécution des unités. La plupart des schémas de récupération s'appuient sur les unités envoyées dans le désordre, et donc une application doit utiliser l'horodatage RTP pour programmer l'exécution.

L'utilisation de RTP permet d'utiliser plusieurs codeurs de supports différents, avec un champ de type de charge utile utilisé pour faire la distinction entre eux à la réception. Certains schémas de réparation de pertes envoient plusieurs copies des unités, à des moments différents et éventuellement avec des codages différents, pour augmenter la probabilité qu'un receveur ait quelque chose à décoder. Un receveur est supposé avoir un classement de la "qualité" des différents codages, et être ainsi capable de choisir la "meilleure" unité pour l'exécution, étant données plusieurs options.

Une session est définie comme interactive si le délai de bout en bout est inférieur à 250 ms, y compris le codage et le décodage du support, le transit du réseau et la mise en mémoire tampon de l'hôte.

3.	Caractéristiques de la perte sur le réseau

Si on désire réparer un flux de support sujet à perte de paquets, il est utile d'avoir quelques connaissances des caractéristiques des pertes qui sont susceptibles de se rencontrer. Un certain nombre d'études ont été menées sur les caractéristiques des pertes du Mbone [2, 8, 21] et bien que les résultats soient un peu divergents, la conclusion est en gros claire : dans une grosse conférence, il est inévitable que certains receveurs rencontrent des pertes de paquet. Les relevés de paquets faits par Handley [8] montrent une session dans laquelle la plupart des receveurs subissent des pertes dans la gamme de 2 à 5 %, avec un assez petit nombre subissant des taux de perte significativement plus élevés. D'autres études ont présenté des résultats assez similaires.

Il a aussi été montré que la grande majorité des pertes est d'un seul paquet. Les salves de perte de deux paquets ou plus sont moins fréquentes d'un ordre de grandeur que la perte d'un seul paquet, bien qu'elle surviennent en fait plus souvent qu'on aurait pu le supposer de la part d'un processus purement aléatoire. Les salves de pertes plus longues (de l'ordre de la dizaine de paquets) ne surviennent que rarement. Ces résultats sont cohérents avec un réseau qui n'a que de faibles encombrements transitoires, cause de la majorité des pertes de paquet. Dans quelques cas, une liaison réseau se trouve être en surcharge sévère, d'où résultent de grosses quantités de pertes.

La cible principale d'un schéma de réparation doit donc être de corriger la perte d'un seul paquet, dans la mesure où c'est de loin l'occurrence la plus fréquente. Il est souhaitable que les pertes d'un nombre relativement faible de paquets consécutifs puissent aussi être réparées, car de telles pertes représentent une fraction faible mais perceptible des pertes observées. La correction de grosses salves de pertes est d'importance considérablement moindre.

4.	Schémas d'atténuation de perte

Dans les paragraphes qui suivent, quatre schémas d'atténuation de perte sont exposés. Ces schémas ont été exposés un certain nombre de fois dans la littérature, et ont été trouvés utiles dans un certain nombre de scénarios. Chaque technique est brièvement décrite, avec ses avantages et ses inconvénients.

4.1.	Retransmission

La retransmission des paquets perdus est un moyen évident par lequel les pertes peuvent être réparées. Elle montre toute sa valeur dans les applications non interactives, avec des limites de délai lâches, mais les délais imposés signifient qu'elle n'est pas normalement adaptée pour une utilisation interactive.

En plus d'une latence qui peut être élevée, il y a une redondance potentiellement élevée de bande passante liée à l'utilisation de la retransmission. Non seulement les unités de données sont envoyées plusieurs fois, mais du trafic de contrôle supplémentaire doit s'écouler pour demander la retransmission. Il a été montré que, dans une grande session Mbone, la plupart des paquets sont perdus par au moins un receveur [8]. Dans ce cas, la redondance de la demande de retransmission pour la plupart des paquets peut être telle que l'utilisation de la correction d'erreur directe (FEC, Forward Error Correction) est plus acceptable. Cela conduit à une synergie naturelle entre les deux mécanismes, avec un schéma de correction d'erreur directe utilisé pour réparer toutes les pertes d'un seul paquet, et les receveurs qui rencontrent des salves de pertes, et qui veulent accepter la latence supplémentaire, utilisent la réparation fondée sur la retransmission comme mécanisme de récupération supplémentaire. Des mécanismes similaires ont été utilisés dans un certain nombre de schémas fiables de diffusion groupée, et ont été discutés dans la littérature [9, 13].

Afin de réduire la redondance de retransmission, les unités retransmises peuvent être portées sur les transmissions en cours, en utilisant un format de charge utile tel que celui décrit dans [15]. Cela permet aussi que la retransmission soit recodée dans un format différent, pour réduire encore la redondance de bande passante. Comme solution de remplacement, les informations de FEC peuvent être envoyées en réponse aux demandes de retransmission [13], permettant à une seule retransmission de potentiellement réparer plusieurs pertes. Le choix d'un algorithme de demande de retransmission qui soit à la fois respectueux des délais et sans douleur pour le réseau est un domaine d'étude actuel. Un point de départ évident est le protocole SRM [7], et des expériences ont été menées qui l'utilisent, avec une variante de faible délai, STORM [20]. Ces travaux montrent le compromis à tenir entre latence et qualité pour les schémas de réparation fondés sur la retransmission, et illustrent que la retransmission est une approche de réparation efficace pour les applications qui peuvent tolérer la latence.

Il n'y a pas de cadre de protocole standard pour la demande de retransmission de support en direct. Une extension expérimentale de profil RTP pour les demandes de retransmission de style SRM a été décrite dans [14].

4.2	Correction d'erreur directe

La correction d'erreur directe (FEC, forward error correction) est le moyen par lequel les données de réparation sont ajoutées à un flux de support, de telle sorte que les pertes de paquet puissent être réparées par le receveur de ce flux sans autre recours à l'envoyeur. Il y a deux classes de données de réparation qui peuvent être ajoutées à un flux : celles qui sont indépendantes du contenu du flux, et celles qui utilisent la connaissance du flux pour améliorer le processus de réparation.

4.2.1	FEC indépendante du support
L'utilisation d'un certain nombre de schémas de FEC indépendants du support ont été proposés avec les supports en direct. Ces techniques ajoutent des données redondantes, qui sont transmises dans des paquets séparés, à un flux de support. Traditionnellement, les techniques de FEC sont décrites comme détectant et/ou corrigeant les pertes. Dans le cas de support de direct, la détection de pertes est fournie par les numéros de séquence dans les paquets RTP.

Les données redondantes de FEC sont normalement calculées en utilisant la mathématique des champs finis [1]. Le plus simple des champs finis est GF(2) où l'addition est simplement l'opération OU exclusif. Les schémas de base de FEC transmettent k paquets de données avec n-k paquets de parité permettant la reconstruction des données d'origine à partir de tout k des n paquets transmis. Budge et autres [4] ont proposé d'appliquer l'opération OUX à travers différentes combinaisons des données de support avec les données redondantes transmise séparément comme paquets de parité. Ceux-ci font varier le schéma des paquets sur lesquels la parité est calculée, et donc ont une bande passante différente, ainsi que les caractéristiques de latence et de réparation de pertes.

Les techniques de FEC fondées sur la parité ont un avantage significatif en ce qu'elles sont indépendantes du support, et fournissent une réparation exacte des paquets perdus. De plus, les exigences de traitement sont relativement légères, en particulier par rapport à certains schémas de FEC spécifique du support (redondance) qui utilisent une bande passante très lente, mais des codages de très haute complexité. L'inconvénient de la FEC fondée sur la parité est que les codages ont une latence plus élevée que celle des schémas spécifiques du support exposés au paragraphe suivant.

Un certain nombre de schémas de FEC existent sur la base de champs finis d'ordre supérieur, par exemple les codes Reed-Solomon (RS), qui sont plus sophistiqués et plus exigeants en puissance de calcul. Ceux-ci sont habituellement structurés de telle sorte qu'ils présentente une bonne protection contre les aléas de pertes, bien que cela se fasse normalement aux dépens d'une latence accrue. Selon les schémas de pertes observés, de tels codes peuvent donner des performances améliorées, par rapport à la FEC fondée sur la parité.

Un format de charge utile RTP pour la FEC générique, convenable à la fois pour la FEC fondée sur la parité et sur la FEC codée en Reed-Solomon est définie dans [17].

4.2.2	FEC spécifique du support
Le fondement de la FEC spécifique du support est d'employer la connaissance du schéma de compression du support pour réaliser une réparation de flux plus efficace que ce qui pourrait être réalisé autrement. Pour réparer un flux qui subit des pertes de paquets, il est nécessaire d'ajouter de la redondance à ce flux : sont ajoutées certaines informations qui ne seraient pas exigées en l'absence de perte de paquets, mais qui peuvent être utilisées pour se remettre de cette perte.

La nature d'un flux de support affecte les moyens par lesquels la redondance est ajoutée. Si l'unité des données du support est le paquet, ou si plusieurs unités sont incluses dans un paquet, il est logique d'utiliser l'unité comme niveau de redondance, et d'envoyer des unités dupliquées. En recodant la copie redondante d'une unité, des économies significatives de bande passante peuvent être faites, au dépens d'une complexité de calcul supplémentaire et d'une réparation approximative. L'utilisation de cette approche a été défendue pour l'audio en direct [2, 10] et a montré de bonnes performances. Un format de charge utile RTP pour cette forme de redondance a été défini dans [15].

Si les unités de support s'étendent sur plusieurs paquets, par exemple de vidéo, il est raisonnable d'inclure la redondance directement au sein de la sortie d'un codec. Par exemple, le format de charge utile RTP proposé pour H.263+ [3] comporte de multiples copies de portions clés du flux, séparées pour éviter les problèmes de la perte de paquet. Les avantages de cette seconde approche sont l'efficacité (le concepteur du codec sait exactement quelles portions du flux il est important de protéger) et une faible complexité car chaque unité n'est codée qu'une seule fois.

Une autre approche est d'appliquer des techniques de FEC indépendantes du support aux bits de plus fort poids de la sortie des codecs, plutôt que de l'appliquer sur le paquet entier. Plusieurs descriptions de codec comportent la sensibilité binaire qui rend cela possible. Cette approche a un faible coût en calcul et peut être taillée sur mesure pour représenter une fraction arbitraire des données transmises.

L'utilisation de la FEC spécifique du support présente l'avantage d'une latence faible, avec l'ajout du délai d'un seul paquet. Cela la rend adaptée aux applications interactives, où des délais importants de bout en bout ne peuvent être tolérés. Dans un environnement unidirectionnel non interactif, il est possible de retarder l'envoi des données redondantes, pour réaliser des performances améliorées en présence de salves de pertes [11], aux dépens d'une latence supplémentaire.

4.3	Interpolation

Lorsque la taille unitaire est inférieure à celle du paquet, et que le délai de bout en bout est sans importance, l'interpolation [16] est une technique utile pour réduire les effets des pertes. Les unités sont reséquencées avant la transmission, de sorte que les unités adjacents à l'origine soient séparées par une distance garantie dans le flux transmis, et retournées dans leur ordre d'origine au receveur. L'interpolation disperse les effets des pertes de paquet. Si, par exemple, les unités sont longues de 5 ms et les paquets de 20 ms (c'est-à-dire, 4 unités par paquet), le premier paquet pourrait alors contenir les unités 1, 5, 9, 13 ; le second paquet contiendrait les unités 2, 6, 10, 14 ; et ainsi de suite. On peut voir que la perte d'un seul paquet d'un flux interpolé résulte en plusieurs petits trous dans le flux reconstruit, par opposition à un seul gros trou qui apparaîtrait dans un flux non interpolé. Dans de nombreux cas il est plus facile de reconstruire un flux avec de tels schémas de pertes, bien que cela dépende clairement du support et du codec. Noter que la taille des trous dépend du degré d'interpolation utilisé, et pourrait être rendu arbitrairement petit aux dépens de la latence supplémentaire.

L'inconvénient évident de l'interpolation est l'augmentation de la latence. Cela limite l'utilisation de cette technique pour les applications interactives, bien que ses performances soient bonnes pour les utilisations non interactives. L'avantage majeur de l'interpolation est qu'elle n'augmente pas les exigences de bande passante d'un flux.

Un format de charge utile RTP potentiel pour les données interpolées est une simple extension de la charge utile audio redondante [15]. Cette charge utile exige que la copie redondante d'une unité soit envoyée après la principale. Si cette restriction est supprimée, il est possible de transmettre une interpolation arbitraire des unités avec ce format de charge utile.

5.	Recommandations

Si le scénario désiré est une transmission non interactive unidirectionnelle, dans le style des diffusions de radio ou de télévision, la latence est d'une importance considérablement moindre que la qualité de réception. Dans ce cas, l'utilisation de l'interpolation, de la réparation fondée sur la retransmission ou de la FEC est appropriée. Si une réparation approximative est acceptable, l'interpolation est clairement préférable, car elle n'augmente pas la bande passante d'un flux. La FEC indépendante du support est normalement la meilleure option suivante, car un seul paquet de FEC a le potentiel de réparer plusieurs paquets perdus, pourvu qu'on ait une transmission efficace.

Dans une session interactive, le délai imposé par l'utilisation de l'interpolation et de la retransmission n'est pas acceptable, et un schéma de FEC à faible latence est le seul moyen de réparation convenable. Le choix entre la correction d'erreur directe indépendante du support et celle spécifique du support est moins tranché : la REC spécifique du support peut être rendue plus efficace, mais requiert des modification à la sortie du codec. Lorsque on aura défini le format de paquet pour un nouveau codec, ce sera clairement une technique  appropriée, et elle devrait être encouragée.

Si on doit utiliser un codec existant, un schéma de correction directe indépendant du support est généralement plus facile à mettre en œuvre, et peut avoir de bonnes performances. Un flux de support protégé de cette façon peut être augmenté de la réparation fondée sur la retransmission avec une redondance minimale, procurant une qualité améliorée pour ceux des receveurs qui tolèrent des délais supplémentaires, et permettant l'interactivité aux receveurs qui la désirent. Bien que l'ajout des données de FEC à un flux de support soit un moyen efficace pour protéger les flux contre la perte de paquet, les concepteurs d'application devraient être conscients de ce que l'ajout de grandes quantités de données de réparation lorsque la perte est détectée va accroître l'encombrement du réseau, et donc, la perte de paquets, conduisant à un problème pire que celui que l'utilisation du codage de correction d'erreur était destinée à résoudre.

Au moment de la rédaction du présent mémoire, il n'y a pas de solution standard qui puisse être utilisée au problème du contrôle de l'encombrement pour les supports de direct. Il y a cependant eu un certain nombre de contributions qui montrent la forme vraisemblable de la solution [12, 19]. Cela fonctionne avec certaines formes de codage en couches des données sur plusieurs canaux, les receveurs rejoignant et quittant les couches en réponse à la perte de paquet (qui indique l'encombrement). Le but de tels schémas est d'émuler le comportement de contrôle d'encombrement d'un flux TCP, et donc entre en compétition directe avec le trafic en différé. Ceci est nécessaire pour un comportement stable du réseau en présence de beaucoup de supports de direct.

Comme les applications de supports de direct sont maintenant utilisées, sans contrôle de l'encombrement, il est important de donner quelques conseils aux auteurs de ces outils sur les comportement qui sont acceptables, jusqu'à ce que des mécanismes de contrôle de l'encombrement puissent être développés. Le reste de la présente section utilise le débit d'une connexion TCP sur une liaison avec un taux de perte donné comme exemple pour indiquer le comportement qui peut être compris comme raisonnable.

Comme l'ont noté un certain nombre d'auteurs (par exemple, [6]), le taux de perte et le débit d'une connexion TCP sont dans le rapport approximatif suivant :
T = (s * c) / (RTT * sqrt(p))
où T est le débit observé en octets par seconde, s est la taille de paquet en octets, RTT est le temps d'aller retour pour la session en secondes, p est le taux de perte de paquet et c est une constante dans la gamme 0,9 à 1,5 (une valeur de 1,22 a été suggérée [6]). En utilisant cette relation, on peut déterminer le taux de perte de paquets qui résulterait d'un débit donné pour une session particulière, si on  utilise une connexion TCP.

Bien que cette relation entre taux de perte de paquet et débit soit spécifique de l'algorithme de contrôle d'encombrement de TCP, elle fournit aussi une estimation du taux de perte acceptable pour une application de support en direct utilisant le même chemin réseau, ce qui coexiste assez bien avec le trafic TCP. Ceci n'est évidemment pas suffisant pour un bon partage d'une liaison avec du trafic TCP, car cela ne prend pas en compte le comportement dynamique de la connexion, c'est simplement le comportement moyen, mais cela ne donne pas une définition d'un comportement "raisonnable" en l'absence d'un contrôle d'encombrement réel.

Par exemple, une session audio RTP avec un codage DVI et des paquets de données de 40 ms aura un en-tête RTP/UDP/IP de 40 octets, un état du codec de 4 octets, et 160 octets de flux de support, donnant une taille de paquet, s, de 204 octets. Elle va envoyer 25 paquets par seconde, donnant T = 4800. Il est possible d'estimer le délai d'aller-retour à partir des statistiques de rapport de réception de RTCP (disons 200 millisecondes pour les besoins de l'exemple). En substituant ces valeurs dans l'équation ci-dessus, on estime un taux "raisonnable" de perte de paquet, p, à 6,7 %. Cela représenterait une limite supérieure du taux de perte de paquet que cette application devrait être estimée tolérer.

On devrait noter qu'une estimation du délai d'aller retour fondée sur les statistiques de rapport de réception de RTCP est, au mieux, approximée; et qu'un délai d'aller-retour pour un groupe de diffusion groupée ne peut être qu'une mesure "moyenne". Cela implique que le taux débit/perte équivalent TCP déterminé par cette relation sera une approximation de la limite supérieure du taux qu'une connexion TCP réaliserait en fait.

6.	Considérations pour la sécurité

Certaines des techniques de réparation exposées dans le présent document résultent en la transmission de trafic supplémentaire pour corriger les effets de la perte de paquets. Les concepteurs d'applications devraient être conscients que la transmission de grandes quantités de trafic de réparation va augmenter l'encombrement du réseau, et donc la perte de paquets elle-même, conduisant à une aggravation du problème que l'utilisation de la correction d'erreur était destinée à résoudre. Au pire, cela peut conduire à un encombrement excessif du réseau et peut constituer une attaque de déni de service. La Section 5 expose cela en plus grand détail, et donne des lignes directrices pour prévenir ce problème.

7.	Résumé

Les applications de support en direct qui utilisent l'Internet seront sujettes à des pertes de paquet dues à la nature non fiable de la livraison de paquet UDP. Le présent document a résumé les schémas typiques de perte vus sur le cœur de réseau public au moment de la rédaction, et une gamme de techniques de récupération de telles pertes. Il est de plus exposé le besoin d'un contrôle d'encombrement, et quelques lignes directrices pour un comportement raisonnable pour les applications en direct pendant la période intérimaire de déploiement du contrôle d'encombrement.

8.	Remerciements

Les auteurs tiennent à remercier Phil Karn et Lorenzo Vicisano pour leurs utiles commentaires.

9.	Adresse des auteurs

Colin Perkins	Orion Hodson	
Department of Computer Science	Department of Computer Science	
University College London	University College London	
Gower Street	Gower Street	
London WC1E 6BT	London WC1E 6BT	
United Kingdom	United Kingdom	
mél : c.perkins@cs.ucl.ac.uk	mél : o.hodson@cs.ucl.ac.uk	

Références

[1]	R.E. Blahut. "Theory and Practice of Error Control Codes". Addison Wesley, 1983.

[2]	J.-C. Bolot et A. Vega-Garcia. "The case for FEC based error control for packet audio in the Internet". À paraître dans ACM Multimedia Systems.

[3]	C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, S. Wenger et C. Zhu. "RTP payload format for the 1998 version of ITU-T recommendation H.263 video (H.263+)". Travail en cours.

[4]	D. Budge, R. McKenzie, W. Mills, W. Diss et P. Long. "Media-independent error correction using RTP", Travail en cours.

[5]	G. Carle et E. W. Biersack. "Survey of error recovery techniques for IP-based audio-visual multicast applications. IEEE Network", 11(6): 24-36, novembre/décembre 1997.

[6]	S. Floyd et K. Fall. "Promoting the use of end-to-end congestion control in the internet". Texte soumis aux IEEE/ACM Transactions on Networking, février 1998.
[7]	S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu et L. Zhang. "A reliable multicast framework for light-weight sessions and applications level framing". IEEE/ACM Transactions on Networking, 1995.

[8]	M. Handley. "An examination of Mbone performance". Rapport de recherche USC/ISI : ISI/RR-97-450, avril 1997.

[9]	M. Handley et J. Crowcroft. "Network text editor (NTE): A scalable shared text editor for the Mbone". Dans le rapport de ACM SIGCOMM'97, Cannes, France, septembre 1997.

[10]	V. Hardman, M. A. Sasse, M. Handley et Watson. "Reliable audio for use over the Internet". Dans le rapport de INET'95, 1995.

[11]	I. Kouvelas, O. Hodson, V. Hardman et J. Crowcroft. "Redundancy control in real-time Internet audio conferencing". Dans le rapport de AVSPN'97, Aberdeen, Scotland, septembre 1997.

[12]	S. McCanne, V. Jacobson et M. Vetterli. "Receiver-driven layered multicast". Dans le rapport de ACM SIGCOMM'96, Stanford, CA., août 1996.

[13]	J. Nonnenmacher, E. Biersack et D. Towsley. "Parity-based loss recovery for reliable multicast transmission". Dans le rapport de ACM SIGCOMM'97, Cannes, France, septembre 1997.

[14]	P. Parnes. "RTP extension for scalable reliable multicast", Travail en cours.
[15]	C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. Bolot, A. Vega-Garcia et S. Fosse-Parisis, "Charge utile RTP pour données audio redondantes", RFC 2198, septembre 1997.

[16]	J.L. Ramsey. "Realization of optimum interleavers". IEEE Transactions on Information Theory, IT-16:338--345, mai 1970.

[17]	J. Rosenberg et H. Schulzrinne. "An A/V profile extension for generic forward error correction in RT". Travail en cours.

[18]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", RFC 1889, janvier 1996.

[19]	L. Vicisano, L. Rizzo et J. Crowcroft. "TCP-like congestion control for layered multicast data transfer". Dans le rapport de IEEE INFOCOM'98, 1998.

[20]	R. X. Xu, A. C. Myers, H. Zhang et R. Yavatkar. "Resilient multicast support for continuous media applications". Dans le rapport du 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV'97), Washington University in St. Louis, Missouri, mai 1997.

[21]	M. Yajnik, J. Kurose et D. Towsley. "Packet loss correlation in the Mbone multicast network". Dans le rapport de IEEE Global Internet Conference, novembre 1996.

Déclaration complète de droits de reproduction

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

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.