DVMA : Un Algorithme de Marquage pour les Flux MPEG4 dans un Réseau DiffServ

Transcription

1 DVMA : Un Algorithme de Marquage pour les Flux MPEG4 dans un Réseau DiffServ Toufik AHMED Laboratoire CNRS-PRiSM., Université de Versailles 45, av. des Etats Unis Versailles - France tad@prism.uvsq.fr Guillaume BURIDANT 1, Ahmed MEHAOUA 1 et Jean-Pierre CLAUDÉ 1,2 Laboratoire CNRS-PRiSM., Université de Versailles 45, av. des Etats Unis Versailles - France {bug,mea}@prism.uvsq.fr Institut des Sciences et Techniques des Yvelines- ISTY 45, av. des Etats Unis Versailles - France jpc@prism.uvsq.fr RÉSUMÉ Le réseau IP traditionnel offre aux utilisateurs un service best-effort. Dans ce modèle, tous les paquets de l utilisateur se partagent les ressources du réseau équitablement. La plus grande attention est donnée au développement de mécanismes de QoS (Quality of Service) dans IP, qui permettent aux opérateurs réseau d offrir différents niveaux de traitement des paquets de l utilisateur. Dans cet article, nous nous intéresserons aux interactions de QoS entre les applications vidéo MPEG-4 et les réseaux IP DiffServ. Les interactions de QoS se traduisent par l association d un flux élémentaire MPEG-4 (vidéo, audio, indication, ODs) et d un PHB (Per Hop Behavior) de DiffServ, AF/EF. Notre dans ce domaine porte sur deux points : Premièrement, un protocole d encapsulation pour les paquets MPEG-4 à travers RTP/IP est mis en place, et ensuite, un mécanisme de marquage pour les routeurs Diffserv est proposé : l algorithme DVMA. Un réseau DiffServ tournant sous Linux 2.4 sera utilisé pour l analyse des performances de notre algorithme de marquage. MOTS-CLÉS : Qualité de Service, Service différentié, Vidéo, PHB. KEYWORDS: QoS, Diffserv, video, PHB

2 2 GRES, Décembre 2001, Marrakech. 1. Introduction Le standard MPEG-4 cible un très large rayon d applications : de la vidéoconférence classique et de la télédiffusion aux applications nécessitant un très haut niveau d interaction avec les scènes audiovisuelles. Afin d atteindre ce but final, des outils très avancés ont été définis dans les différentes parties du standard (Audio, Visuel, Système), qui peuvent être configurés suivant les différents profiles pour répondre aux demandes des applications. D un autre coté, de récentes recherches sur le support de la QoS sur Internet a conduit à deux approches distinctes : l architecture Intserv (Integrated Services) (Wroclawski, 1997) accompagné de son protocole de signalisation RSVP (Resource Reservation Protocol) (Braden et al., 1997), et l architecture Diffserv (Differentiated Services) (Blake et al., 1998). Le développement de Diffserv a été motivé par les besoins du marché dans le déploiement immédiat d une solution de QoS dans le réseau Internet. Contrairement à la gestion flux par flux de RSVP, les réseaux Diffserv classent les paquets dans l une des classes agrégées identifiées par le champs DSCP (DiffServ CodePoint) dans l entête du paquet IP (Blake et al., 1998). Dans chaque routeur Diffserv, on définit un PHB (Per-Hop Behavior), qui est déterminé par le DSCP. Un PHB permet de fournir un comportement d acheminement spécifique à chaque routeur dans le domaine Diffserv considéré. Deux schémas de PHB, EF (Expedited Forwarding) (Jacobson et al., 1999) et AF (Assured Forwarding) (Heinanen et al., 1999) ont été proposés pour offrir des traitements différentiels du trafic. Le PHB EF peut être utilisé pour avoir un faible taux de perte, une faible latence, une faible gigue, une bande-passante assurée et un service de bout en bout à travers les domaines DS (Jacobson et al., 1999), alors que le PHB AF fournit différents niveaux pour assurer l acheminement des paquets IP en jetant les paquets de plus faible priorité lors de congestion du réseau plutôt que les paquets de plus forte priorité. Le PHB AF offre 4 classes pour acheminer les paquets IP. Dans chaque classe AF, un paquet IP est associé à un des trois niveau de priorité de rejet (drop precedence) (Heinanen et al., 1999). Le groupe qui travaille sur Diffserv a discuté des fonctionnalités nécessaires aux extrémités du domaine DS pour sélectionner (classifier) et conditionner (e.g., policer et shapper) le trafic suivant différentes politiques (Blake et al., 1998). Plusieurs algorithmes sont proposés, parmi lesquels, TSWTCM (Time Sliding Window Three Color Marker) (Fang et al., 2000) et TRTCM (A Two Rate Three Color Marker) (Heinanen et al., 1999). Dans cet article, nous nous intéresserons aux interactions de QoS entre les applications vidéo MPEG-4 et les réseaux IP DiffServ. Deux fonctions de gestion de QoS sont discutées dans cet article: l encapsulation des flux vidéos et le marquage de flux. Notre contribution est ciblée sur deux points : Premièrement, un protocole d encapsulation pour les paquets MPEG-4 à travers RTP/IP est mis en

3 DVMA: Un algorithme de marquage pour les flux MPEG-4 dans un réseau Diffserv 3 place, et ensuite, un mécanisme de marquage pour les routeurs Diffserv est proposé. L intégration de ces deux composants est essentielle pour fournir une QoS de bout en bout. Les performances sont évaluées à l aide d un réseau de routeurs DiffServ. Ce réseau est constitué de PC fonctionnant sous Linux avec le noyau 2.4. Ce dernier permet d implémenter DiffServ de manière logicielle. Le plan de cet article est le suivant : le chapitre 2 donnent une vue générale sur l architecture du système MPEG-4. Le chapitre 3 explique notre algorithme de marquage des flux vidéo MPEG-4. Le chapitre 4 décrit la configuration du noyau Linux DiffServ et la topologie de notre réseau. Les analyses de performance sont décrites dans les chapitres 5. Enfin, nous conclurons dans les chapitres 6 et Vue d ensemble du MPEG-4 Le MPEG-4 est un standard ISO/IEC qui spéficie les outils d encodage naturels et synthétiques des flux audio-vidéo. La vidéo est représentée par des objets élémentaires audio-visuels qui sont combinés afin de former une scène complète. MPEG-4 cible un large rayon d applications multimédia telles que la vidéoconférence classique et la télédiffusion. L intérêt principal de ce standard est de fournir un langage commun de description pour l encodage 2D et 3D des objets audio-visuels (ISO/IEC / / , 1998). 2.1 Architecture de MPEG-4 L architecture de MPEG-4 est composée de trois couches : La Compression Layer, la Sync Layer et la Delivery Layer(ISO/IEC , 1998). La Compression layer génère la représentation des données audiovisuelles dans des flux appelés ES (Elementary Streams). Les relations hiérarchiques, l emplacement et les propriétés des ES sont décrits par l ensemble des ODs (Object Descriptors). Les ODs sont eux-mêmes transportés dans un ou plusieurs ESs. Une scène MPEG-4 est décrite par un SD (Scene Description) qui contient les informations sur l adresse et l organisation des objets audiovisuels de la scène, en terme d emplacement aussi bien spatial que temporel. La description de scène utilise un langage basé sur le VRML appelé BIFS (Binary Format for Scene). Les ESs sont fractionnés en un ou plusieurs AUs (Access Units). Un flux élémentaire MPEG-4 valide peut être une vidéo MPEG-1, étiquetée avec le système d information MPEG-4 dans son entête. Un AU serait alors une trame vidéo I, B ou P. Ces AUs seront étiquetés avec des informations de priorité, de timing et autres. Un AU est la plus petite entité de donnée à laquelle on peut assigner une information de timing. Sur le Sync layer, les AUs sont transportés en une séquence de paquets appelés SL-PDUs. Un SL-PDU est composé d une entête de paquet SL et de données dans le paquet SL. L entête permet de contrôler en continuité les pertes de données, le cas échéant, et contient les informations de temps de contrôle.

4 4 GRES, Décembre 2001, Marrakech. Les SL-PDUs sont transmis au Delivery Layer pour être multiplexés en un flux FlexMux. L outil FlexMux est un des composants de DMIF (Delivery Multimedia Integrated Framework) MPEG-4. FlexMux est un multiplexeur simple et flexible qui facilite l imbrication des SL-PDUs. Deux différents modes d opération de FlexMux sont définis. Le premier mode est appelé Simple Mode dans lequel un SL- PDU est encapsulé dans un paquet FlexMux, et le second mode est appelé MuxCode Mode dans lequel un ou plusieurs SL-PDU sont encapsulés dans un seul paquet FlexMux. L interface entre le Sync layer et le Delivery layer est connue sous le nom de DAI (DMIF Application Interface) (ISO/IEC , 1998). Il offre des procédures indépendantes qui permettent d établir des sessions MPEG-4 et d accéder à des canaux de transport comme RTP/UDP/IP. 3. PROPOSITION D UN ALGORITHME DE MARQUAGE DIFFSERV POUR LES FLUX VIDEOS MPEG-4 Une scène MPEG-4 est caractérisée par un nombre important de flux élémentaires dont leurs débits varient en fonction des outils de compression utilisés au niveau du codeur MPEG-4. Par exemple, les codeurs audio HVXC et CELP réalisent une compression de 2 kb/s à 24 kb/s. La compression vidéo H.261 et H.263 permet d atteindre des taux de 15 kb/s jusqu'à 30 kb/s. En conséquence, les flux vidéo sont plus gourmands en ressources que les flux audio. Dans notre marquage, il faut tenir compte de cette propriété qui nous permet, en cas de congestion, de soulager le réseau en éliminant des paquets vidéo par rapport aux paquets audio. Une autre solution est de dégrader la priorité d un paquet. Il est clair que les solutions proposées par DiffServ permettent de privilégier des sous-flux MPEG-4 jugés indispensables pour une bonne représentation de la scène du coté du lecteur. Ces sous-flux sont considérés comme essentiels pour avoir un rendu acceptable de la scène (QoS minimale). De plus, nous avons identifié quelques problèmes que nous résumions dans ce qui suit : quel est le PHB approprié qui garantie la meilleure QoS?, quel marquage de paquet IP utiliser?, est-il souhaitable de modifier le marquage des paquets IP suivant l état du réseau? Quelle est l architecture réseau la plus appropriée pour répondre à toute exigence? 3.1 Un marquage DiffServ pour la vidéo MPEG-4 Nous proposons ici un algorithme de marquage des paquets issus d un codeur MPEG-4 et qui seront encapsulés sur RTP/UDP/IP, pour plus d information sur le marquage voir (Ahmed et al. Juillet 2001), pour garantir la QoS en utilisant diffserv. Notons que cet algorithme est statique et dépend largement des choix (les propriétés) que nous allons détailler plus loin. Toutefois, l application (end-user)

5 DVMA: Un algorithme de marquage pour les flux MPEG-4 dans un réseau Diffserv 5 peut spécifier ses besoins en terme de QoS puisque le terminal de réception connaît bien ses performances et ses capacités de traitement. Il est clair que dans le cas des applications temps réel comme la vidéoconférence et la VoD (Video on Demand ), que l audio est plus important que la vidéo (propriété 1). Cette propriété nous mène à distinguer le marquage de l audio de celui de la vidéo dans diffserv. En ce qui concerne le choix des PHB, il est clair que les flux acceptant de la perte (comme l audio ou la vidéo) seront transmis avec un PHB AF. En outre, le PHB EF sera plus cher que le PHB AF, car il gère des contraintes supplémentaires par rapport au PHB AF (latence minimale, gigue minimale, perte minimale). Une fois que ce choix est fait, il nous reste à identifier la classe de service AF utilisée et le niveau de rejet de nos paquets. Rappelons que AF définit actuellement 4 classes composées de 3 niveaux de rejet selon l importance du flux. Si nous prenons le codage de l audio (figure 1) nous pensons que la parole a une plus grande importance par rapport à la musique ou d autres bruits de fond dans une scène. Nous préférons privilégier l audio de type parole par rapport à l audio de type musique de fond. D après cette figure, la parole a un débit entre 2 et 24 Kbps, ce qui veut dire que les débits faibles sont plus importants (propriété 2) que les débits élevés. Pour le codage vidéo, MPEG-4 utilise le codage hiérarchique (la scalabilité). Plusieurs modes existent : La scalabilité spatiale : permet à un décodeur de traiter un sous-ensemble de flux produit par le codeur pour reconstruire et afficher des Figure 1: outils de codage audio textures, des images et des objets vidéo avec une résolution spatiale réduite. Pour des textures, un maximum de 11 niveaux de scalabilité spatiale est supporté. Pour les séquences visuelles, un maximum de 3 niveaux est supporté (Koenen, 2000). La scalabilité temporelle : permet à un décodeur de traiter un sous-ensemble de flux produit par le codeur pour reconstruire et afficher la vidéo avec résolution temporelle réduite. Un maximum de 3 niveaux est supporté (Koenen, 2000). La scalabilité SNR (Signal to Noise Ratio ) : permet d améliorer la qualité subjective de l image finale. Dans le schéma de codage, on transmet la différence entre l image originale et l image précédente (déjà codée) La scalabilité nous permet de bien distinguer entre les flux principaux (indispensables au décodeur) et les flux optionnels qui permettent d améliorer la qualité des images (propriété 3).

6 6 GRES, Décembre 2001, Marrakech. En plus, dans MPEG-4, il y a des flux tels que : la description de scène et la description des objets médias. Ces flux sont très importants pour reconstruire la scène initiale (propriété 4). Pour conclure, durant les congestions de réseau, le codage hiérarchique associé à un marquage intelligent, permet de mieux contrôler la QoS pour privilégier les flux vidéos indispensables qui offrent une qualité visuelle minimale par rapport aux flux vidéos complémentaires permettant l amélioration de la qualité visuelle. 3.2 Algorithme Dans ce qui suit, nous proposons à titre indicatif un algorithme de gestion de qualité de service sur diffserv (figure 2), que nous validerons plus tard dans par des tests. Remarque: (1) Si le PHB EF n est pas implémenté, les flux de description de scène passent dans un PHB AF avec un degré d élimination le plus faible. Par exemple, la classe 3 avec le degré de précédence suivant : (2) Le débit est contrôlé par un token bucket. 3.3 Commentaires Notre proposition tient compte du fait que les flux vidéo et les flux audio passent dans deux classes AF distinctes. Ce qui nous permet de privilégier le transport d un type de flux par rapport à l autre. Le problème qui résulte du transport des flux audio et des flux vidéo dans deux classes séparées est la synchronisation entre l audio et la vidéo. Deux classes AF distinctes sous-entendent deux files d attentes séparées dans le routeur IP. Si une file est plus congestionnée que l autre, alors le routeur risque de laisser passer des paquets d une file beaucoup plus vite que les paquets dans l autre file. La solution à ce problème est de synchroniser au niveau du récepteur (le player). Ce type de mécanisme a été déjà proposé dans le chapitre précédent avec une encapsulation sur RTP (le numéro de séquence sert à synchroniser les paquets entre eux). En plus du problème lié à la synchronisation des flux, nous identifions les contraintes suivantes : l algorithme précédent étant statique, c est à dire que le choix du marquage des flux est connu à l avance, il n est pas adaptable en fonction de l'état du réseau (congestion ou pas, taux de charge du routeur, une classe AF est sous chargée alors qu une autre classe est surchargée, etc). l application MPEG-4 ne peut pas exprimer ses besoins en terme de traitement particulier à certains types de flux i.e. manque de dialogue entre l application MPEG-4 et le réseau de transport

7 DVMA: Un algorithme de marquage pour les flux MPEG-4 dans un réseau Diffserv 7 4. Mise en oeuvre Diffserv Linux Les noyaux actuels Linux (2.4) offrent une large variété de fonctions de contrôle de trafic et un appui du modèle Diffserv décrit par le groupe de travail Diffserv (Almesberger, 1999). La classification de base et la manipulation des champs DS exigée par les nœuds de Diffserv sont toujours au stade expérimental dans le noyau Linux. if stream is audio stream then (application of property 2) if coder rate is low rate then D S C P =A F Low D rop P rec //exam ple A F11 if coder rate is m edium rate then D S C P =A F M edium D rop P rec //exam ple A F12 if coder rate is high rate then D S C P =A F H igh D rop P rec //exam ple A F13 if stream is video stream (application of property 3) if base layer video stream (level 1 = m im im um Q os ) then D S C P = A F low D rop P rec //exam ple A F21 if enhanced layer video stream 1 (level 2 = m edium Q os ) then D S C P = A F M edium D rop P rec //exam ple A F22 if enhanced layer video stream 2 (level 3 = m axim um Q os ) then D S C P = A F M edium D rop P rec //exam ple A F23 if stream is objects descriptor, scene descriptor (application of property 4 ) then D S C P = E F //descriptions stream s are significant, no loss //it s necessary that these stream s w ill be available //as soon as possible in M P E G -4 player to interpret //correctly the scene Figure 2: DVMA: L algorithme de marquage Diffserv Quand le noyau Linux reçoit des paquets du dispositif d'entrée qui doit précéder le dispositif de sortie, le contrôle du trafic décide si les paquets sont traités ou s ils sont rejetés - par exemple, si la file d'attente a atteint une certaine limite de longueur ou si le trafic excède un certain taux limite. Il décide dans quel ordre les paquets sont envoyés, pour pouvoir, par exemple, donner la priorité à certains flux. Finalement, il peut retarder l'envoi de paquets, afin de limiter le trafic en partance par exemple. Le PC Linux peut fonctionner en tant que routeur de bordure ou routeur de cœur. Le routeur de bordure peut classifier, faire le policing, marquer des groupes de paquets et réorganiser le trafic. Les routeurs de cœur fournissent le service d'expédition de paquet de transit entre d'autres routeurs de bordure et routeurs de cœur. Il gère le trafic afin de limiter la congestion et d y faire face le cas échéant. Les mécanismes de contrôle du trafic dans le noyau Linux sont constitués des composants suivants : gestionnaires de file d attente, classes (au sein d un

8 8 GRES, Décembre 2001, Marrakech. gestionnaire de file d attente), filtres et policing. La figure 3 montre les composants du contrôle de trafic Linux. La file d'attente détermine l'ordre dans lequel les données sont envoyées. Le trafic peut être divisé en classes selon certaines règles. Chaque classe respecte une discipline de file d attente pour gérer les paquets et elle peut être prioritaire. En réalité, il y a 11 outils de gestionnaires de file d attente dans le noyau Linux (Almesberger, 1999). Les filtres sont employés pour insérer le trafic dans des classes et faire la distinction parmi les différentes classes de paquets. La classification repose sur certaines propriétés du paquet. Dans le service différencié, la classification est basée sur le champ IP DSCP. Filter Queuing discipline Class Input Filter Filter Queuing discipline Class Output Queuing Discipline Figure 3: Composants du TC Linux Le policing est utilisé pour contrôler le trafic correspondant à une classe. Il s assure qu un trafic spécifique n'excède pas une certaine limite. La Configuration des routeur de bordures et de cœurs est présentée dans l article (Ahmed et al. Novembre 2001) 5. Analyse de Fonctionnement 5.1 banc d'essai d'expérimentation Notre banc d'essai expérimental est composé d un serveur vidéo qui génère le flux MPEG-4 vidéo pour une multitude de clients hétérogènes. Le serveur et les clients sont connectés par le réseau TCP/IP et communicant en utilisant l'api DMIF (Ahmed, 2000). On crée quelques scénarios d'essai pour le processus de transmission. On détermine les paramètres de QoS et on fait la comparaison entre le processus de transmission dans le service Best Effort et dans le Service DiffServ. Nous avons mis en œuvre un système de flux vidéo MPEG-4 pour évaluer l'algorithme de marqueur et un client vidéo simple pour recevoir les paquets

9 DVMA: Un algorithme de marquage pour les flux MPEG-4 dans un réseau Diffserv 9 envoyés par le client voir (Ahmed et al. Octobre 2001). Les mesures de QoS sont faites pour évaluer l'algorithme de marquage. Notre banc d'essai physique est décrit dans la figure 4. Le banc d'essai est composé de routeurs de bordure et d un routeur de cœur faisant tourner l implémentation Diffserv du noyau Linux. Toutes les liaisons sont des connexions Ethernet avec chacune 10Mb/s de bande passante. Figure 4 : topologie de réseau pour le banc d'essai. Les figures 5 décrit la vidéo MPEG-4 envoyée par le serveur au client. Le réseau est chargé par un trafic de fond. Dans notre banc d'essai, le trafic de fond est marqué comme étant un trafic Best effort. La première mesure que nous avons faite est l évaluation des pertes de paquet à la fois dans le scénario Best Effort et dans le scénario Diffserv. En second lieu, nous mesurons le retard sur une transmission de bout en bout du serveur au client. Dans chaque scénario, nous chargeons le réseau différemment pour pouvoir obtenir des informations supplémentaires. 5.2 Pertes de Paquets La figure 6 montre le pourcentage de pertes de paquets quand la quantité de trafic de fond est d environ 80 % (6.5 Mbit/s) de la largeur de la bande. Cela engendre quelques pertes essentiellement au temps t=30s, c'est-à-dire quand le serveur envoie son taux maximal (figure 5). La majorité des pertes provient du flux de couche de base. Cela donne une mauvaise QoS au client. Celui-ci ne peut pas décoder les autres flux sans la réception du flux de couche de base. Les pertes augmentent de manière spectaculaire quand le réseau devient trop chargé (figure 7). Les grandes pertes de la couche de base sont dues à sa plus grande exigence de largeur de bande. Nous pouvons le comparer avec un flux vidéo MPEG-2 dans lequel des images I sont plus grandes que des images P et B. Cependant ils sont beaucoup plus importants. Dans ce cas, les pertes de paquet I doivent être inférieures aux autres types de pertes de paquet. Lorsqu il s agit de MPEG-4, le flux

10 10 GRES, Décembre 2001, Marrakech. de couche de base doit avoir une perte de paquet faible quand les flux de couches améliorés 1 et 2 doivent avoir une probabilité de chute respectivement croissante. Dans le scénario de Diffserv, nous pouvons voir que les pertes de paquets vidéo sont presque égales à 0 et nous nous sommes assurés que la couche de base n'a aucune perte. Les figures 8 et 9 illustrent ce fait. Nous pouvons aussi voir que dans ce scénario, les pertes de paquets vidéos sont les mêmes lorsque la charge de réseau est 80 % de la largeur de bande et lorsque celle-ci est de 95 %. Cela prouve bien que l'augmentation du trafic n'a aucun effet sur le trafic vidéo, ceci étant dû à son mécanisme de priorité statistique. Il est utile de noter que le trafic Best Effort (le trafic de fond) peut emprunter n importe quelle largeur de bande disponible. 5.3 Retard à sens unique de bout en bout Les figures 10 et 11 illustrent le retard continu, qui est aussi important que les pertes de paquet. Un paquet vidéo retardé n'est plus utilisable, car un flux vidéo est une application en temps réel. Un retard est donc assimilé à une perte. La figure 10 montre que durant le débit maximal, le retard augmente de manière spectaculaire. Lorsque la charge de réseau est d environ 95 %, le retard est très important et peut causer une faible QoS dans l application vidéo (figure 11). Lors de l utilisation du scénario Diffserv, le retard de paquet a incroyablement diminué et n'augmente pas réellement quand la charge de réseau atteint 95 %. Dans les deux figures 12 et 13, on peut aussi voir que le retard le plus important est dû au débit maximal au milieu du processus de transmission. 6. Travail complémentaire ultérieur et Un travail complémentaire ultérieur examinera l interaction entre le flux vidéo et le trafic de fond. Comme il a été mentionné, le trafic de fond dans notre banc d essai est marqué en tant que trafic de meilleur effort (Best Effort). Ce n est pas réellement le cas dans la prochaine génération Internet. De plus, l administrateur du domaine assure la configuration des routeurs de bordure et de cœur, nous envisagerons la configuration des routeurs par un Broker de largeur de bande utilisant le Protocole COPS (Common Open Policy Service) (Burham, 2000). 7. Conclusion Dans cet article, nos avons proposé et testé un marqueur de paquet vidéo MPEG-4 pour le service Diffserv de IP, ceci fut fait au moyen des flux de vidéo

11 DVMA: Un algorithme de marquage pour les flux MPEG-4 dans un réseau Diffserv 11 MPEG hiérarchiquement codés sur le réseau expérimental. Le résultat a montré le fonctionnement de nos algorithmes de marquage. Deux contraintes sensibles ont été améliorées par : (1) La réduction des pertes de paquet, (2) La réduction du délai de transmission. L'algorithme de marquage proposé tient mieux compte des caractéristiques et la pertinence des sous-flux MPEG-4 (audio, vidéo, BIFS, OD ). Par conséquent, des flux de données sensibles subiront un traitement privilégié par les routeurs Diffserv du réseau. C'est particulièrement utile en cas de vidéo hiérarchiquement codée comme MPEG-4. Une performance de QoS minimale sera assurée par l association de quelques paquets audiovisuels avec une probabilité de rejet faible et on lui donnera une probabilité de rejet importante pour les couches d amélioration vidéo. 8. Bibliographie: J. Wroclawski «RFC2210: The Use of RSVP with IETF Integrated Services» September R. Braden, Berson, S. Herzog,S. Jamin «RFC 2205: Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification» September S. Blake, D. Black M. Carlson,E. Davies, Z. Wang, W. Weiss «RFC 2475: An Architecture for Differentiated Services» December V. Jacobson, K. Nichols, K.Poduri «RFC 2598 An Expedited Forwarding PHB» June J.Heinanen, et al. «RFC 2597 : Assured Forwarding PHB Group», June W. Fang et al. «RFC2859: A Time Sliding Window Three Colour Marker (TSWTCM)» June J. Heinanen, R. Guerin «RFC2698: A Two Rate Three Color Marker (TRTCM)» September 1999 ISO/IEC «Coding of audio-visual objects --Part 1: Systems -final committee draft» May ISO/IEC «Coding of audio-visual objects Part 2: Visual -final committee draft» May ISO/IEC «Coding of audio-visual objects -- Part 3: Audio -final committee draft» May ISO/IEC «Coding of audio-visual objects -- Part 6: Delivery Multimedia Integration Framework (DMIF) final committee draft» May Rob Koenen; Overview of the MPEG-4 Standard (V.14 - Geneva Version), May/June 2000 Werner Almesberger «Differentiated Services on Linux» T. Ahmed, «MPEG-4 DMIF Implementation in Java» Technical report, Master of CS, University of Versailles, France, Sept D. Durham et al. «RFC 2748: The COPS (Common Open Policy Service) Protocol» January 2000 T. Ahmed, G. Buridant, A. Mehaoua «Encapsulation and Marking of MPEG-4 Video over IP Differentiated Services». In proceeding of Sixth IEEE ISCC 01. Hammamet Tunisia, Edition IEEE Press, Juillet 2001 T. Ahmed, G. Buridant, A. Mehaoua «Delivering Of MPEG-4 Multimedia Content Over Next Generation Internet». Dans Lecture Notes in Computer Science N 2216, Management of Multimedia Networks and Services, Kluwer Academic, Octobre T. Ahmed, A. Mehaoua, G. Buridant «Implementing MPEG-4 Video On Demand over IP Differentiated Services». À paraître dans IEEE Global Telecommunication Conference GLOBCOM San-Antoinio, Texas, USA, Nov

12 12 GRES, Décembre 2001, Marrakech. Fig. 5: Les Flux Video MPEG-4 Fig. 6: Perte de paquet dans Best Effort - Charge du réseau 80%- FIG. 7: Perte de paquet dans Best Effort - Charge du réseau 95 %- FIG. 8: Perte de paquet dans Diffserv - Charge du réseau 80%- FIG. 9: - Perte de paquet dans Diffserv - Charge du réseau 95 %- Fig. 10: Temps de transmission de bouten-bout - Charge du réseau 80%- Fig. 11: Temps de transmission de bouten-bout dans Best Effort - Charge du réseau 95%- Fig. 12: Temps de transmission de bouten-bout dans Diffserv - Charge du réseau 80%- Fig. 13: Temps de transmission de bouten-bout dans Diffserv - Charge du réseau 95%-