DVMA : Un Algorithme de Marquage pour les Flux MPEG4 dans un

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 78035 – Versailles - France
[email protected]
Guillaume BURIDANT1, Ahmed MEHAOUA1 et Jean-Pierre
CLAUDÉ1,2
Laboratoire CNRS-PRiSM.,
Université de Versailles
45, av. des Etats Unis 78035 –
Versailles - France
{bug,mea}@prism.uvsq.fr
Institut des Sciences et Techniques des
Yvelines- ISTY
45, av. des Etats Unis 78035 –
Versailles - France
[email protected]
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.
RÉSUMÉ
MOTS-CLÉS :
KEYWORDS:
Qualité de Service, Service différentié, Vidéo, PHB.
QoS, Diffserv, video, PHB
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
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 7.
2. 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 14496-1/14496-2/14496-3, 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 14496-1, 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
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 SLPDU 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 14496-6, 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)
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
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 : 011010. (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
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 stre am is “a u d io s tre a m ” th en (a p plicatio n of p rop erty 2 )
if cod er rate is “low ra te ”
th en D S C P = A F L ow D ro p P re c
//exa m p le A F 1 1
if co de r rate is “m e dium ra te ”
th en D S C P = A F M e dium D rop P re c
//exa m p le A F 1 2
if co de r rate is “h ig h rate”
th en D S C P = A F H ig h D ro p P re c
//exa m p le A F 1 3
if stre am is “v id e o strea m ” (a pp licatio n of pro p erty 3)
if “b ase la yer vid eo stre am ”
(le vel 1 = m im im u m Q oS )
th en D S C P = A F lo w D rop P rec
//exa m p le A F 2 1
if “ e nh a nce d la ye r vide o strea m 1 ”
(le vel 2 = m e dium Q oS )
th en D S C P = A F M ed iu m D ro p P rec
//exa m p le A F 2 2
if “e nh an ced laye r vid eo strea m 2 ”
(le vel 3 = m axim u m Q o S )
th en D S C P = A F M ed iu m D ro p P rec
//exa m p le A F 2 3
if stre am is “o b je cts d es c rip to r, sc en e d e sc rip to r” (a pp lication o f pro pe rty 4 )
th en D S C P = E F
//de scrip tio ns strea m s a re sig nifica n t, n o lo ss
//it’s n ecessa ry th at th ese stre am s w ill be a va ila ble
//as so on a s po ssib le in M P E G -4 p la yer to in te rp ret
//co rre ctly the scen e
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
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
Queuing
discipline
Output
Filter
Class
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
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
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
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 1997.
R. Braden, Berson, S. Herzog,S. Jamin « RFC 2205: Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification» September 1997.
S. Blake, D. Black M. Carlson,E. Davies, Z. Wang, W. Weiss «RFC 2475: An Architecture for
Differentiated Services » December 1998.
V. Jacobson, K. Nichols, K.Poduri «RFC 2598 An Expedited Forwarding PHB» June 1999.
J.Heinanen, et al. «RFC 2597 : Assured Forwarding PHB Group», June 1999.
W. Fang et al. «RFC2859: A Time Sliding Window Three Colour Marker (TSWTCM) » June 2000.
J. Heinanen, R. Guerin «RFC2698: A Two Rate Three Color Marker (TRTCM) » September 1999
ISO/IEC 14496-1 «Coding of audio-visual objects --Part 1: Systems -final committee draft» May 1998.
ISO/IEC 14496-2 «Coding of audio-visual objects – Part 2: Visual -final committee draft» May 1998.
ISO/IEC 14496-3 «Coding of audio-visual objects -- Part 3: Audio -final committee draft» May 1998.
ISO/IEC 14496-6 «Coding of audio-visual objects -- Part 6: Delivery Multimedia Integration Framework
(DMIF) final committee draft» May 1998.
Rob Koenen; ”Overview of the MPEG-4 Standard” (V.14 - Geneva Version), May/June 2000
Werner Almesberger «Differentiated Services on Linux » 1999.
T. Ahmed, «MPEG-4 DMIF Implementation in Java» Technical report, Master of CS, University of
Versailles, France, Sept. 2000.
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 2001.
T. Ahmed, A. Mehaoua, G. Buridant «Implementing MPEG-4 Video On Demand over IP Differentiated
Services». À paraître dans IEEE Global Telecommunication Conference GLOBCOM 2001. San-Antoinio,
Texas, USA, Nov. 2001.
12
GRES, Décembre 2001, Marrakech.
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%-
Fig. 5: Les Flux Video MPEG-4