Wehbe Houssein

Amlioration des flux temps rel sur
les rseaux IP
Rapport de Stage
MASTER 2 RECHERCHE
Systmes, rseaux et architecture
Prsent par :
Houssein WEHBE
juin 2008
Encadr par :
Bernard COUSIN et Grard BABONNEAU

1
Remerciements
Je tiens remercier dans un premier temps, toute lquipe pdagogique de lIFSIC et les
intervenants responsables de la formation du master 2 recherche systmes, rseaux et
architecture .
Je remercie galement, avec toute ma reconnaissance, Monsieur Bernard COUSIN pour laide
et les conseils concernant les travaux voqus dans ce rapport.
Je tiens remercier tout particulirement Grard BABONNEAU, pour mavoir intgr

rapidement au sein du laboratoire de France tlcom R&D et mavoir accord toute sa
confiance ; pour le temps quil ma consacr tout au long de cette priode, sachant rpondre
toutes mes interrogations ; ainsi que pour lexprience enrichissante et pleine dintrt quil
ma fait vivre durant ces cinq mois au sein du laboratoire; sans oublier sa participation au
cours du cheminement de ce rapport.
Je remercie galement le personnel du laboratoire MAPS/DPC de France tlcom R&D pour

leur accueil sympathique et leur coopration professionnelle tout au long de ces cinq mois.
2
Rsum
Les premires applications distribues ont t caractrises par des contraintes dordre et de
fiabilit sur les donnes transmises (i.e. transfert de fichiers, courrier lectronique, accs aux
pages Web, etc.). De ce fait, les premiers services de communication ont t spcifiquement
conus pour rpondre ces besoins. Les protocoles de transport TCP et UDP sont des
exemples de cette vision restrictive de la conception des services de communication. Le
protocole TCP offre un service totalement fiable et totalement ordonn alors que le protocole
UDP fournit un service non fiable et non ordonn. Aujourdhui, de nouvelles applications
prsentant des contraintes de qualit de service plus complexes ont t conues. Les
applications telles que la vido la demande prsentent de fortes contraintes temporelles, de
bande passante et de synchronisation multimdia. Afin de rpondre ces contraintes, le
transport des flux audiovisuels sur Internet utilise principalement les protocoles RTP et RTCP
au dessus de UDP. Mais, en labsence de moyens de rparation des anomalies de transport, la
qualit reue nest pas garantie. De fait, il sagit dune difficult intrinsque au temps rel :
tout procd, introduit pour corriger les faiblesses dune transmission, exige du temps et des
ressources supplmentaires qui sont parfois incompatibles avec les contraintes temps rels du
flux multimdia ou celles du rseau. Pour garantir les dlais darrive des donnes, des
compromis sont raliser entre plusieurs contraintes, dont certaines peuvent se rvler
contradictoires. Lobjet du stage est dtudier les diffrents mcanismes de correction
derreurs ainsi que de proposer une solution doptimisation applique aux protocoles RTP et
RTCP, et conforme aux standards dfinis lIETF. Nos travaux, prsents dans ce document,
aboutissent des compromis acceptables, et au mieux des amliorations de la QoS (Qualit
de Service). La solution propose est valide dans un environnement de simulation de rseau
(OPNET) afin dexhiber ses avantages et inconvnients, notamment lorsque les erreurs
arrivent par rafale.
3
Sommaire
Introduction ........................................................................................................................................... 8
Chapitre 1 : tat de lart de la transmission sur Internet ............................................................... 11
1. Introduction..................................................................................................................11
2. Les protocoles de transmissions....................................................................................11
2.1 Les protocoles non adapts aux applications multimdia ...................................11
2.1.1 Le protocole TCP ...............................................................................11
2.1.2 Le protocole HTTP.............................................................................12
2.2 Les protocoles adapts aux applications multimdia ..........................................12
2.2.1 Le protocole UDP...............................................................................12
2.2.2 Le protocole RTP ...............................................................................13
2.2.3 Le protocole RTCP.............................................................................13
2.2.4 Le protocole RTSP .............................................................................14
2.3 Conclusion des protocoles .................................................................................15
3. Les mcanismes de contrle derreur ...........................................................................16
3.1 La rgulation du dbit .......................................................................................16
3.1.1 Cas point point.................................................................................17
3.1.2 Cas du multipoint ...............................................................................18
3.1.3 Conclusion sur la rgulation du dbit ..................................................19
3.2 Contrle derreurs par anticipation ....................................................................19
3.3 Contrle derreurs par retransmission ................................................................21
3.3.1 Mcanismes bass sur un accus de rception ....................................21
3.3.2 Mcanismes bass sur un accus de non rception .............................22
4. Conclusion ..................................................................................................................23
Chapitre 2 : La rparation par retransmission ................................................................................ 25
4
1. Introduction .................................................................................................................25
2. Description de la solution ............................................................................................25
2.1 Principe de fonctionnement ...............................................................................25
2.2 Exemple dutilisation des paramtres N et P ......................................................26
2.3 Le choix des paramtres ....................................................................................27
2.3.1 Les paramtres utiliss par lmetteur .................................................27
2.3.2 Les paramtres utiliss par le rcepteur...............................................29
2.3.3 Conclusion du choix des paramtres ...................................................31
3. Validation de la solution ..............................................................................................31
3.1 Les modles de perte utiliss .............................................................................32
3.1.1 La perte uniforme ...............................................................................32
3.1.2 La perte par rafale ..............................................................................32
3.2 Les simulations effectues .................................................................................33
3.2.1 Les simulations dans le cas du dbit constant (CBR) ..........................33
3.2.2 Les simulations dans le cas du dbit variable (VBR)...........................38
4. Conclusion ..................................................................................................................40
Conclusion ......................................................................................................................................... 43
Rfrences ......................................................................................................................................... 44
5
Table des figures
Figure 1 Reprsentation d'un systme de communication vido ..........................................8
Figure 2 RTT est le moment de rception du rapport (RR) le temps dmission du dernier
rapport (SR)- le dlai entre les deux rapports ......................................................14
Figure 3 Scnario de transmission des donnes multimdia en utilisant les protocoles RTSP
et RTP/RTCP au dessus de UDP ........................................................................15
Figure 4 Les paquets FEC gnrs chez lmetteur seront transmis avec les paquets RTP.
Le rcepteur les utilise pour reconstruire les paquets perdus ...............................20
Figure 5 Exemple de fonctionnement du modle avec N=6 ..............................................26
Figure 6 Exemple de fonctionnement du modle avec N=6; le Nime paquet est perdu ....27
Figure 7 RtxTime est en relation avec la dure des rafales et le rapport entre les dbits
dmission et de retransmission ..........................................................................29
Figure 8 La taille du buffer est gal au Dbit dmission*(RtxTime+D) avec D=RTT ......30
Figure 9 Le pourcentage des paquets perdus aprs la retransmission par rapport RtxTime;
RtxTime varie entre 500 et 1200 ms; RTT varie entre 100 ms (courbe verte), et
200 ms (courbe bleu) et 400 ms (courbe rouge) ..................................................34
Figure 10 Le pourcentage des paquets perdus aprs la retransmission en fonction de

RtxTime; perte uniforme, sans perte lors de la retransmission et sur le NACK;
RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 et 23. ..........................35

RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 et 28 ...........................35
Figure 12 La variation du dbit remontant par rapport celle de N (courbe bleu pour N=1 et
courbe rouge pour N=10,)...............................................................................36

RtxTime; perte uniforme, avec perte lors de la retransmission et sur le NACK;
RtxTime varie entre 500 ms et 1200 ms ; N varie entre 10 et 28. ........................36

RtxTime; perte par rafale, avec perte lors de la retransmission et sur le NACK
RtxTime varie entre 500 ms et 1200 ms ; N varie entre 10 et 28 .........................36

6
RtxTime; perte par rafale, sans perte lors de la retransmission et sur le NACK;

RtxTime; perte uniforme, avec perte lors de la retransmission et sur le NACK;
RtxTime varie entre 500 ms et 1200 ms ; N varie entre 50 et 59 .........................38
Figure 18 La variation du dbit remontant par rapport celle de N (courbe bleu pour N=1 et
rouge pour N=50,..) ............................................................................................38
Figure 19 Changement du dbit d'mission entre 1 et 5 Mbs...............................................38
Figure 20: Variation de la perte et du dbit d'mission en fonction du temps; la courbe rouge
est le nombre des paquets perdus un instant donn ...........................................39
Figure 21 La capacit du modle corriger les pertes .........................................................40

RtxTime; perte par rafale, sans perte lors de la retransmission et sur le NACK;
RtxTime varie entre 500 ms et 1200 ms ; N varie entre 27 et 30. ........................40
Figure 23 Le pourcentage des paquets corrigs par rapport aux paquets perdus pour
plusieurs taux de perte; perte uniforme avec une perte sur les NACK et lors de la
retransmission : rsultat de notre modle ............................................................41
Figure 24 Le pourcentage des paquets corrigs par rapport aux paquets perdus pour
plusieurs taux de perte; perte uniforme avec une perte sur le NACK et lors de la
retransmission : rsultat du modle dcrit par Rishi et Christos ..........................41
7
Introduction
Les avances dans le domaine des rseaux informatiques, ont permis le dveloppement de
nouveaux services interactifs sur Internet pour rpondre aux besoins toujours plus importants
et diversifis des utilisateurs. Si aux dbuts de lInternet (les annes 80) les transferts de
donnes dans les rseaux concernaient surtout des formats trs simples, comme le texte ou
limage fixe, les donnes multimdia occupent aujourdhui une part importante de la bande
passante. Ces donnes sont celles qui posent le plus des problmes pour leur transport, compte
tenu de leurs particularits : volume important, contraintes temporelles, etc.
Fournir le support et la technique de communication pour tous ces services est un dfi adress
aux sciences et technologies de linformation et de la communication. Des normes plus au
moins adquates standardisent les formats des donnes transfrer selon des protocoles de
communication varis, sans pour autant rpondre totalement aux besoins des utilisateurs.
Ce stage sinscrit dans la problmatique de la transmission de donnes temps rel telles que la
vido sur Internet, en essayant dapporter des solutions simples ce problme.
On peut gnralement considrer quun systme de communication vido est constitu de

cinq parties (voir Figure 1) [13]. La squence est dans premier temps compresse par un
codeur1 vido. Le flux gnr est ensuite segment en paquets de tailles fixes ou variables et
pourra tre multiplex avec dautres donnes telles que les donnes audio, des pages HTML,
etc. Les paquets pourraient tre transmis directement sur le rseau si celui-ci garantissait un
transport sans perte. Cette condition ntant gnralement pas remplie, on applique une
protection par redondance au niveau du canal (niveau physique) avant la transmission pour
protger les donnes.
Figure 1: Reprsentation d'un systme de communication vido
Au niveau du rcepteur, on exploite la redondance pour reconstituer les informations perdues.

A moins de possder des liens ddis une application particulire et garantissant une
1
Pour conomiser de lespace et de bande passante, les squences vido sont compresses en utilisant, par
exemple, le format MPEG. Celui-ci utilise des techniques de prdiction avec compensation de mouvement pour
rduire au minimum les informations additionnelles.
8
certaine qualit de service (QoS), on constate lors dune transmission des pertes des paquets
essentiellement dues des phnomnes de congestion sur le rseau Internet.
En effet, le rseau Internet offre un simple service : le service best effort [6][20]. Un tel
modle de service permet aux routeurs dtre sans tat et de ne garder aucune information de
grain fin propos du trafic. Par ailleurs, lutilisation de lInternet est libre de toute tarification
puisque les mmes ressources sont disponibles pour tous les utilisateurs. Linconvnient est
que, puisquil ny a pas de contrle dadmission, le rseau peut tre perturb par des
utilisateurs trop gourmands. En effet, si le dbit avec lequel le trafic est dirig sur les
interfaces dpasse la vitesse avec laquelle ces mmes interfaces sont capables dacheminer le
trafic vers laval, des congestions peuvent se produire. Le trafic en excs est plac dans les
files dattente des dispositifs physiques jusqu dbordement de ces files. Ainsi, les
applications peuvent faire lexprience de pertes de paquets.
Cependant, on peut regrouper les mcanismes de contrle derreurs suivant trois catgories :
lintroduction de redondance (code FEC Forward Error Correction ) par le codeur source
rendant le flux vido plus rsistant aux pertes. En effet, le rcepteur utilise ces informations
pour reconstruire les paquets perdus; Les mcanismes ncessitant une interaction entre
lmetteur et le rcepteur, et permettant aux codeurs de source de sappuyer sur les conditions
de rception mesures par le rcepteur pour adapter leur codage ; les mcanismes de
rparation par retransmission. Comme nous le verrons par la suite, les mcanismes prenant en
compte lors du codage les caractristiques du rseau (le code FEC et la rgulation du dbit) ne
sont pas compatibles avec des contraintes temps rel.
Lobjectif de ce stage est de concevoir un mcanisme de contrle derreurs capable dassurer

une qualit de service convenable des applications temps rel (comme la vido la demande
(VoD)) transmises dans un environnement htrogne aux caractristiques varient dans le
temps.
Une mthode simple permettant de rduire les erreurs de transmission consiste mise en
uvre de rparation par retransmission. Cette mthode sappuie sur les standards IETF RFC
4585 (RTCP Feedback) [3] et RFC 4588 (RTP retransmission) [5] o les rcepteurs
demandent une retransmission des paquets perdus. En effet, la perte des paquets sera dtecte
en analysant les numros de squence des paquets correctement reus (car lmetteur
numrote les paquets envoys). Cependant, il ne faut pas oublier, en utilisant la mthode de
retransmission, quune remonte de trs nombreux messages peut charger inutilement le
serveur et risque de dgrader ses performances. Pour cela, il faut dfinir un mode particulier
pour limiter les requtes de retransmission remontes vers le serveur. Ajoutons quen raison
de la nature temps rel des flux vido, le client ne doit pas attendre trop longtemps avant
denvoyer ses requtes. En effet, si ensuite le temps de rception des donnes retransmises est
trop long, les paquets de correction des pertes risquent d'arriver aprs le temps de fourniture
des donnes au dcodeur. Dans ce rapport nous proposerons une mthode allant dans ce sens.
Afin de montrer la validit de cette mthode, nous avons implment, sous OPNET2, un
modle de simulation qui modlise le systme VoD[8] (un serveur et un client connects).
Notre but est de dterminer les optimisations de la solution, en particulier le compromis entre
2
OPNET permet la modlisation et la simulation de rseaux de communication grce ses bibliothques de
modles (routeurs, commutateurs, ) et de protocoles (TCP/IP, FTP, ...).
9
la latence, la taille du tampon de rception et le surdbit disponible. Ce modle nous permet
de vrifier lefficacit du procd en fonction des profils de pertes.
En effet, le taux de pertes correspond au rapport du nombre de paquets non arrivs sur le
nombre total de paquets transmis. Nous avons ralis des simulations avec un haut taux de
perte (10% des paquets transmis) en utilisant plusieurs modles de perte comme la perte par
rafale. Ce modle reprsente le cas pire de perte o priodiquement un grand nombre des
paquets groups sont perdus. Il sagit, en effet, dintroduire un bruit impulsif lev sur les
deux voies du rseau restant un certain temps. Les rsultats obtenus ont montr la validit de
notre mthode dans les systmes VoD, en vrifiant que les paquets perdus sont retransmis et
arrivs au rcepteur en respectant les contraintes temps rel.
Nous prsenterons dans le chapitre 1 de ce document un tat de lart introductif sur la

transmission des donnes multimdia sur Internet. Nous expliquerons les principaux
protocoles utiliss ainsi que les diffrents mcanismes de contrle derreur. Dans ce chapitre
on va montrer les contraintes limitant lutilisation du mcanisme de rgulation de dbit (TCP,
TCP-fiendly) et de redondance dans les paquets envoys (le code FEC). Puis nous
proposons dans le chapitre 2 une mthode de contrle derreur base sur la retransmission. Ce
chapitre contient les dtails des simulations effectus ainsi que les principaux rsultats
obtenus.
10
Chapitre 1 : tat de lart de la transmission sur Internet
1. Introduction
Lchange des donnes multimdia sur Internet se fait selon un modle client/serveur. Le
serveur dlivre le fichier vido vers les internautes qui en ont fait la requte. Le lecteur se met
jouer la vido aprs quelques secondes ncessaires pour remplir un tampon ( buffer ) qui
stocke des donnes en avance pour pallier la gigue des images dans la transmission. Au fur
et mesure de la lecture, des donnes de contrle sont envoyes au serveur pour linformer
des conditions de rception du flux. Le serveur sadapte en consquence, acclrant ou
ralentissant le transfert des paquets.
Cette technologie de transmission sappelle streaming [19][20]. Elle permet de commencer

visualiser la vido avant que la totalit des donnes soit tlcharge. Le principal avantage
de cette technologie est que lon na pas besoin dattendre le tlchargement complet dun
fichier et aucune donne nest stocke sur le disque dur. Notons que dans lindustrie on
appelle cette technologie ( Download Progressif ) et le terme streaming sera utilis pour les
applications vido en directe live .
La plupart des programmes de streaming (ou de dowonload progressif ) existant sont

bases sur l'utilisation dun ensemble des protocoles de transmission pour dlivrer les donnes
vido compresss. Les protocoles le plus utilisable sont TCP, UDP, RTP, HTTP et RTSP.
Chaque protocole configure les donnes en paquets, en ajoutant pour chaque paquet un en-tte
identifiant son contenu. Dans ce chapitre on va expliquer en dtail chacun de ces protocoles
ainsi nous expliquerons les diffrents mcanismes utiliss pour rsoudre le problme de
congestion sur le rseau Internet. En effet, cest le problme principal de notre stage et une
tude des solutions existants permet de bien comprendre notre solution.
2. Les protocoles de transmissions

Nous expliquerons dans ce paragraphe les protocoles de transmission standards sur Internet.
Ces protocoles peuvent tre regroups en deux groupes : protocoles qui ne sont pas adapts
aux applications multimdia et les protocoles adapts ces applications.
2.1 Les protocoles non adapts aux applications multimdia
TCP est le protocole le plus utilisable sur Internet. Il possde beaucoup des avantages mais
son problme principal est quil est lent et non adapt pour les applications multimdia. Il
travaille au dessous de HTTP. Par consquent, HTTP nest pas adapt pour ces applications.
2.1.1 Le protocole TCP
TCP [15] ( Transmission Control Protocol ) est un protocole conu pour fournir un service
de transmission de donnes scuris entre deux machines raccordes sur un rseau de paquets.
Il offre un certain nombre de fonctionnalits :
Transfert de donnes de base : TCP est capable de transfrer un flux continu de

donnes entre deux ordinateurs, en dcoupant ce flux en paquets.
11
Correction derreur : TCP doit considrer et traiter les cas de donnes perdues,
errones, dupliques, ou arrives dans le dsordre lautre bout de la liaison Internet.
Ceci est ralis par linsertion dun numro de squence, et par lobligation dmission
dun accus de rception (ACK) par le destinataire. Si laccus de rception nest
pas reu au bout dun temps prdfini (RTO Retransmission TimeOut ), le paquet
sera rmis.
Contrle de flux : TCP fournit un moyen au destinataire pour contrler le dbit de
donnes envoy par lmetteur. Ceci est obtenu en retournant une information
( window ) indiquant le nombre doctets que lmetteur peut envoyer avant une
autorisation ultrieure. Lmetteur rgle par la suite son dbit dmission et sadapte
pour rpondre aux besoins du destinataire.
Gestion de connexions : Les mcanismes de fiabilisation et de contrle de flux
imposent TCP linitialisation et la maintenance de certaines informations pour
chaque communication (numro de port de lmetteur et du rcepteur, adresse du
rcepteur.). La combinaison de ces informations formera une connexion.
Un grand avantage de TCP, dduise de ses fonctionnalits, rside dans la fiabilit de la

communication offerte. Cependant, ses inconvnients pour la transmission de donnes
multimdia sont les retards quil peut accumuler en essayant de corriger les donnes
manquantes (lutilisation de la retransmission). TCP utilise un mcanisme de correction
derreurs bas sur la rgulation de dbit (contrle de flux). On va expliquer dans la deuxime
partie de ce chapitre (3.1) les limites de ce mcanisme.
2.1.2 Le protocole HTTP
Le protocole de transfert hypertexte (HTTP)[6] est le protocole standard sur le Web. Il sagit
dun protocole du niveau application, en gnrale implment au dessus de TCP. Il offre un
standard de communication entre les serveurs et les clients Web, mais nest pas adapt au
streaming audio-vido (il possde les mmes dfauts que TCP sil utilise TCP comme
support). Notons quil est parfois utilis pour les flux UDP mais sans garantie de pouvoir
fournir le temps rel.
2.2 Les protocoles adapts aux applications multimdia
UDP est un protocole qui travaille au niveau transport. Diffremment au TCP, il est adapt
aux applications multimdia mais il possde un certains limites, pour cela il sera utilis avec
le protocole RTP.
2.2.1 Le protocole UDP
Le protocole UDP [6] ( User Datagram Protocol) utilise IP pour acheminer en mode non
fiable, dun ordinateur un autre, des datagrammes qui lui sont transmis par une application.
UDP nutilise pas daccus de rception et ne peut donc pas garantir que les donnes ont bien
t reues. Il ne rordonne pas les messages si ceux-ci narrivent pas dans lordre dans lequel
ils ont t mis et il nassure pas non plus de contrle de flux. UDP est souvent utilis par les
applications multimdia, mais il ne permet pas dadapter la transmission au type de donnes
transportes.
12
2.2.2 Le protocole RTP
RTP [1] ( Real-time Transport Protocol) est un protocole bas sur IP fournissant un support
pour le transport des donnes en temps rel comme la vido. Il travaille au dessus de UDP.
Les services fournit par RTP consistent dans la reconstruction temporelle, la dtection de
pertes, la scurit et lidentification du contenu. Il fourni des services de bout en bout pour des
applications qui ncessitent un temps rel comme laudio et la vido interactive. Cependant,
RTP ne fournit aucun mcanisme pour assurer la dlivrance temps.
Les fonctionnalits de ce protocole sont assures en ajoutant des en-ttes RTP aux paquets de
donnes avant de les envoyer. Ces enttes forms de 12 octets, prcdent la charge utile
payload . On trouve par exemple :
Le champ squence number : (16 bits), sa valeur initiale est alatoire et il

sincrmente de 1 chaque paquet envoy, il peut servir dtecter des paquets
perdus.
Le champ timestamp : (32 bits), reflte linstant o le premier octet du paquet RTP
t chantillonn. Cet instant doit tre driv dune horloge qui augmente de
faon monotone et linaire dans le temps permettre la synchronisation la
destination.
Le champ SSRC : (32 bits), identifie de manire unique la source, sa valeur est
choisie de manire alatoire par lapplication. Le champ SSRC identifie la source.
Cet identification est choisi de manire alatoire avec lintrt quil soit unique
parmi toutes les sources dune mme session.
Le champ Payload Type PT : (1 bit), identifie le type des donnes transport (audio
ou vido) afin dadapter le transport selon ce type.
RTP est conu pour travailler en conjonction avec le protocole RTCP afin dobtenir des
retours concernant la qualit de la transmission et des informations au sujet des participants
pour la session raliser.
2.2.3 Le protocole RTCP
RTCP [21] ( Real Time Control Protocol ) est un protocole de contrle dsign pour
travailler en conjonction avec RTP. Il est standardis dans la recommandation RFC 1889 [21]
et RFC 1890 [22]. Dans une session RTP, les participants envoient priodiquement des
paquets RTCP pour donner des informations aux autres membres sur la qualit de service
dlivr. Le RFC 1889 [21] dfini 5 types de paquets pour transporter cette information de
contrle : RR (Receiver Report), SR (Sender Report), SDES (Source description), BYE
(indique la fin de la participation), AP (fonction spcifique application).
En plus de la gnration de ces cinq5 types de paquets, RTCP offre les services suivants :
Contrle de la congestion: Ceci constitue la fonction primordiale de RTCP. Ce

protocole fournit un feed-back lapplication au sujet de la qualit de distribution
des donnes. Linformation de contrle est utile aux metteurs et aux rcepteurs.
Lmetteur peut ajuster sa transmission en se basant sur le rapport du rcepteur.
Information de contrle : Les paquets RTCP sont envoys priodiquement parmi
les participants. Quand le nombre de participants augmente (ce qui peut tre le cas
13
dans une session multicast), il est ncessaire de limiter les informations de contrle
pour viter que le trafic de contrle dpasse le 5% du trafic total de la session.
Les paquets RTCP contient des diffrentes informations sur la qualit de transmission. On
trouve par exemple : le nombre des paquets perdus, le nombre des paquets correctement
reus, etc. Len-tte RTCP contient galement un champ DSLR (32 bits) : cest le dlai depuis
le dernier rapport reu. On peut utiliser ce champs avec des autres informations pour calculer
le temps aller retour RTT.
Rapport SR
Rapport RR
Figure 2: RTT est le moment de rception du rapport (RR)

le temps dmission du dernier rapport (SR)- le dlai
entre les deux rapports
Le couple RTP/RTCP offre des fonctionnalits et des mcanismes de contrle ncessaires

pour transporter les flux en temps rel. En complment, le contrle des flux est assur par le
protocole RTSP.
2.2.4 Le protocole RTSP
RTSP[6] ( Real Time Streaming Protocol ) est un protocole conu pour transfrer, contrler
et synchroniser un ou plusieurs flux temps rel comme la vido et l'audio. Le protocole est
fond sur le modle client-serveur. Il permet le contrle de la prsentation d'un objet mdia
transmis entre le client et le serveur. Autrement dit, les commandes de contrle de la
prsentation d'un objet mdia (comme dmarrer, stopper, faire une pause, etc.) sont traduites
sous forme de requtes d'accs RTSP envoyes par le client et excutes par le serveur.
RTSP hrite de toute la syntaxe de HTTP, de ses mcanismes de scurit et de ses procdures
d'extension (structure des URL: rtsp://).
En dtaillant le mcanisme de la communication, le serveur RTSP (serveur contenant les

vidos) maintient, pour chaque transfert de donnes, une session dsigne par un
identificateur unique. Pendant une session, le client RTSP peut ouvrir et fermer plusieurs
connexions avec le serveur RTSP en utilisant lidentificateur de cette session. Ces connexions
sont tablies afin d'changer les requtes RTSP entre le client et le serveur. Ces requtes
peuvent tre des requtes d'initialisation de session, de transfert de donnes et de contrle de
14
ces flots de donnes. Les diffrentes
rentes requtes RTSP sont dfinies travers un ensemble des
mthodes.
Les principales mthodes sont :

DESCRIBE : Elle est utilise par le client pour rcuprer la description d'une
prsentation ou d'un objet mdia,
mdia identifi par un URI, sur un serveur RTSP.
SETUP : Elle est utilise
utilis par le client pour spcifier au serveur les paramtres de
transport du flotot mdia, comme par exemple le type de protocole de transport
(RTP), le mode de transport (point point ou multipoint) et le numro du port de
communication.
PLAY : Elle signale au serveur qu'il peut commencer envoyer les donnes via le
mcanisme spcifi dans la mthode SETUP. Elle permet galement de jouer un ou
plusieurs sous-intervalles
intervalles de la dure d'un objet mdia,
a, par exemple jouer une audio
partir de la 10 me seconde jusqu'
jusqu' la 20 me seconde.
PAUSE : Elle est utilise par le client pour demander au serveur d'interrompre
temporairement le transfert du flux mdia. Le client peut reprendre
endre la transmission
du flux en envoyant la requte PLAY au serveur.
TEARDOWN : Elle est utilise utilis e par le client pour demander au serveur d'arrter
dfinitivement le transfert du flux mdia.
La Figure 3 donne un exemple dutili

dutilisation de RTSP avec les autres protocoles
Figure 3: Scnario de transmission des donnes multimdia

en utilisant les protocoles RTSP et RTP/RTCP au dessus de
UDP
2.3 Conclusion des protocoles
Pour le transport des flux multimdia, TCP ne convient pas car il est lent et il utilise des
mcanismes de rgulation de dbit pour pou contrler la congestion (voir le paragraphe
suivant3.1).
). Cest donc le protocole UDP qui a t choisi comme protocole de transport des
15
paquets multimdia temps-rel sur Internet. Mais le protocole UDP noffre aucun mcanisme
de contrle de dbit ou des pertes. UDP ne coopre pas non plus avec les autres flux pour la
gestion de la congestion dans le rseau. Le protocole RTP, protocole de bout en bout dfinit
par lIETF et port par UDP a t dfini pour le transport des flux continus et temps-rel.
Cest un protocole non orient connexion, et qui noffre aucune garantie de fiabilit. Il
apporte uniquement la capacit de distinguer les diffrents types de mdia (sous-module) et
de dtecter la perte des paquets. Ce protocole est compos de deux parties : une partie ddie
au transfert de donnes (RTP), lautre au contrle (RTCP). Le protocole de contrle RTCP
transporte des paquets contenant linformation ncessaire au contrle de congestion. Les
rcepteurs envoient des rapports de rception aux membres de la session, ce qui permet
lmetteur de rcuprer des informations sur les numros de squence reus, le taux de perte,
une mesure de la variance du dlai darrive, une estimation du dlai daller-retour, etc.
Lmetteur peut utiliser ces informations pour sadapter en appliquant un mcanisme de
contrle de congestion.
Plusieurs tudes ont t faites pour trouver des mcanismes optimums permettant le contrle
de congestion. Trois mcanismes ont t proposs. Lmetteur peut choisir un de ces
mcanismes pour sadapter. Dans la suite de ce chapitre on va expliquer ces mcanismes avec
leurs avantages et leurs limites.
3. Les mcanismes de contrle derreurs

Lorsque lagrgation des trafics transitant dans un point du rseau excde les capacits de
traitement des quipements intermdiaires (routeurs), des phnomnes de congestion se
produisent. Ceci aboutit la saturation des files dattente de ces quipements puis la
destruction, faute de place, de paquets de donnes. Diffrentes mcanismes sont utiliss pour
contrler la congestion. On peut regrouper ces mcanismes selon trois catgories : Les
mcanismes ncessitant une interaction entre lmetteur et le rcepteur, et permettant aux
codeurs de source de sappuyer sur les conditions de rception mesures par le rcepteur pour
adapter leur codage (la rgulation de dbit); lintroduction de redondance (code FEC) par le
codeur source rendant le flux vido plus rsistant aux pertes ; les mcanismes de rparation
par retransmission.
Dans ce paragraphe on va expliquer chacun de ces mcanismes et montrer les limites de

solutions existantes afin de proposer une nouvelle solution base sur le troisime mcanisme
dans le chapitre suivant.
3.1 La rgulation du dbit

Beaucoup des mthodes de contrle de congestion ont pour but de rguler le dbit de la
source de manire satisfaire au mieux les rcepteurs et en tentant de limiter la congestion.
Ceci ncessite notamment une bonne ractivit des mcanismes de contrle, mais aussi un
partage de dbit quitable entre les diffrentes applications. Le protocole TCP, protocole le
plus utilis sur Internet, assure une bonne quit ainsi quune bonne ractivit. Toutefois, ce
protocole ne peut tre utilis par les applications temps rel. Il sappuie en effet sur une
mthode de contrle derreur base ARQ ( Automatic Repeat Request) et gnre des dbits
trop saccads pour des applications demandant une QoS (Qualit de Service) stable. On lui
prfrera donc des protocoles tels que RTP/RTCP ou UDP. Toutefois, ces deux derniers
protocoles ne spcifient pas de mcanisme de contrle de congestion. Ils peuvent donc ne pas
rpondre aux signes de congestion, alors que TCP y rpondra en rduisant le dbit de ses
16
applications. En laissant TCP supporter seul lvitement de congestion, on obtient
invitablement un partage inquitable des ressources rseaux [16][19]. Pour viter cela, il faut
absolument que chaque application mette en uvre son propre mcanisme de contrle de
congestion. Dautre part, puisque le trafic dominant sur Internet sappuie sur le protocole
TCP, il parat important que ces mcanismes de contrle se comportent quitablement
(amicalement) avec TCP. Ces mthodes tenant de calquer leur comportement sur celui de
TCP sont regroupes sous lappellation TCP-friendly ou TCP-compatibles. Lobjectif de ces
mcanismes nest toutefois pas de miner intgralement le comportement de TCP. La
rgulation quils offrent engendre en gnrale des variations de dbit plus douces que TCP,
assurant ainsi une QoS plus stable lapplication.
3.1.1 Cas point point
Parmi les mcanismes de contrle de congestion TCP-compatible RAP (Rate Adaptation

Protocol) propose dans [23] est certainement le protocole dont le comportement est le plus
proche de TCP. La majorit des oprations sont ralises la source, le rcepteur se
contentant de renvoyer un ACK pour chaque paquet reu. En utilisant cette voie de retour
lmetteur peut dtecter les pertes et calculer le RTT (Round Trip Time : temps daller-
retour). Il augmentera priodiquement son dbit dmission si aucune congestion nest
dtecte et le diminuera immdiatement dans le cas contraire. RAP utilise donc un algorithme
dAugmentation Additive et de Diminution Multiplicative du dbit (AADM (AIMD :
Additive Increase Multiplicative Decrease)). La remise jour du dbit denvoie se fait tous les
RTT et se traduit par une modification de lintervalle de temps sparant lenvoi de deux
paquets de donnes.
Alors que RAP est plutt base observation des pertes, TFRC (TCP Friendly Rate Control)
est base dbit. Ce schma adapte le dbit de la source en se basant sur la modlisation du
dbit de TCP en fonction des pertes propose par Padhye et al. dans [27] :
O Peve, RTT, s et tRTO reprsentent respectivement le taux dvnements de pertes, le RTT,

la taille des paquets et le temps au del duquel on considre quun paquet est perdu et quil
faut le retransmettre (temps dexpiration : timeout). Le taux dvnement de pertes sappuie
sur les notions dvnement de pertes et dintervalle de pertes. Un vnement de pertes est
dfini comme une ou plusieurs pertes se produisant pendant un RTT. Le nombre de paquets
sparant deux vnements de pertes constitue un intervalle de pertes. Pour obtenir le taux
dvnements de pertes on calcule une moyenne pondre des derniers intervalles de pertes
17
O les li reprsentent les derniers intervalles de pertes mesures, mhisto est la taille de
lhistorique et les wi sont les pondrations. La pondration donne plus dimportance aux
derniers intervalles. Le taux dvnements de pertes est alors donn par linversion de
lintervalle de perte moyen.
Lutilisation du taux dvnements de pertes plutt que le taux de pertes classique permet de
ragir plus doucement aux congestions et dobtenir une meilleure stabilit du dbit. Le taux
dvnements de pertes est calcul au rcepteur une fois par RTT et envoy lmetteur.
Celui-ci remettra jour son dbit dmission ds rception de linformation de retour.
Une tude a compare ces deux protocoles sous le simulateur rseau NS [28]. Les tests
montrent que ces deux protocoles permettent tous les deux dobtenir des dbits similaires ce
quaurait donn TCP dans des conditions identiques. On constate toutefois un partage de
bande passante plus quitable entre TFRC et TCP quentre RAP et TCP. Les rsultats
montrent aussi que ces deux protocoles se comportent mieux en prsence de taux de pertes
faibles inferieurs 5% et quau del de cette valeur lquit nest plus vrifie.
3.1.2 Cas du multipoint
Les solutions de bout en bout utilises en point point ne sont plus envisageables en
multipoint. Il nest plus possible de permettre chaque rcepteur de transmettre directement
des informations lmetteur sous peine dcrouler la voie de retour. Dautre part en
imaginant que cette solution soit envisageable, on ne peut imaginer que lmetteur puisse
considrer les informations de chaque rcepteur une une et ajuste chaque fois son dbit en
consquence.
Il parat pourtant important dobtenir un partage quitable de la bande passante avec les
applications tlinformatiques en multipoint quen point point. Certains auteurs se sont donc
attaches obtenir des mcanismes de contrle de congestion TCP-compatible en multipoint.
Parmi ces approches on trouve dans [17] une adaptation de TFRC au multipoint appele
TFMCC (TCP-Friendly Multicast Congestion Control). Lapproche TFMCC sappuie elle
aussi sur lquation utilise par TFRC modlisant le comportement de TCP.
A la diffrence de TFRC toutefois ce sont les rcepteurs qui calculent leur RTT et estiment
leurs dbits. Cette information est priodiquement envoye vers lmetteur. Si un rcepteur
renvoie une information de retour (feedback) indiquant un dbit plus faible que le dbit actuel
de la source celle-ci rduira immdiatement son dbit au dbit indiqu. De manire liminer
un grand nombre de feedback, seuls les rcepteurs estimant un dbit plus faible que le dbit
de la source transmettent une information. Lun des points clef de TFMCC est de permettre
tous les rcepteurs destimer leur RTT sans pour autant augmenter le trafic.
Un protocole similaire nomm PGMCC (Pragmatic General Multicast Congestion Control) a

t propos dans [25]. Ce schma sappuie sur PGM [24], un protocole de robustification de
session multipoint. Ce protocole est bas sur lutilisation daccuss de rception ngatifs
(NACK) la dtection de chaque paquet perdu. Une procdure de suppression des feedbacks
permet de limiter la quantit de NACK. Dans le mme but que TFMCC, de nouvelles
fonctionnalits dans les routeurs sont aussi envisages. Elles permettraient de supprimer les
18
NACK identiques provenant dun mme ensemble des rcepteurs. PGM ne spcifie toutefois
pas de mcanisme de contrle de congestion et considr des sources dbit fixe. PGMCC
peut donc tre vu comme une volution de PGM permettant le contrle de congestion.
Comme dans TFMCC ce protocole slectionne le rcepteur le plus faible (nomm acker )
parmi lensemble des rcepteurs. Chaque rcepteur est capable destimer son dbit de
rception maximum. De plus chaque paquet de donnes transporte des informations sur le
acker courant de sorte qu chaque instant tous les rcepteurs peuvent comparer leurs dbits
celui du acker et devenir acker le cas chant.
Un mcanisme de contrle de congestion similaire celui de TCP est mis en place entre
lmetteur et le acker qui transmettra un ACK pour chaque paquet reu. Le acker contrle
donc le dbit dmission ainsi que les ventuelles retransmissions.
TFMCC et PGMCC se comportent quitablement avec TCP. On remarque toutefois que la

rgulation de dbit de PGMCC a plus tendance gnrer des dbits en dents de scie assez
proche de ce que donne TCP. Pour cela TFMCC est plus utilisable.
3.1.3 Conclusion sur la rgulation du dbit
On peut considrer que le problme de rgulation de dbit reste ouvert. Des solutions trs
efficaces ont pourtant t proposes pour des points particuliers. On peut ainsi citer TFRC qui
offre un mcanisme efficace de rgulation de dbit en point point. Lune des limitations de
TFRC est que ce protocole ne prend pas en compte la nature des flux transports (cette
constatation a amene Vieron et al. [19]). Do le besoin de proposer un protocole bas sur
RTP/RTCP et destin mieux prendre en compte les caractristiques des flux multimdia
dans lestimation des paramtres du modle de prdiction de bande passante.
Tous ces mcanismes de rgulation agissent par rduction du dbit quelque soit lorigine de la
perte mme si lorigine de perte nest pas un problme de congestion (bruit de fond,
problmes lectriques). Or, il ne sert rien dans ce cas de rduire le dbit car le rseau n'est
pas engorg.
Dautre part, la rduction du dbit vido ne peut se raliser que par modification des rgles
appliques au codeur. Par exemple, si une squence dimage est code 8 Mbps et lmetteur
dcide selon TFRC de rduire son dbit 6 Mbps. Dans ce cas nous avons deux possibilits :
soit on envoie les donnes avec un dbit faible, soit on recode les images 6Mbps do le
problme car pour respecter le temps rel on ne peut pas changer chaque mission le dbit
des donnes. En effet, ces donnes sont stockes sous un dbit et leur recodage ncessite un
temps supplmentaire avec une modification des rgles appliques au dcodeur (pour coder
6Mbps par exemple). Il est donc indispensable de maintenir le dbit du flux vido. Do le
besoin de trouver un mcanisme optimum, autre que la rgulation du dbit, permettant de
contrler les erreurs en respectant le temps rel.
3.2 Contrle derreurs par anticipation

Le principe des mthodes de contrle ou de correction derreurs par anticipation repose sur
lintroduction de redondance dans le flux transmis. En cas de pertes cette redondance
permettra de rcuprer une partie des donnes perdues.
19
Dans [31] Rosenberg et Schulzrinne dfinissent un format de conteneur (payload) des paquets
permettant denvisager des protocoles de FEC ( Forward rd Error Correction ) gnrique
destins la protection de donnes temps rels. Gnricit signifie pour eux indindpendant du
mdia protg et adaptatif. Leurs travaux les plus aboutis prconisent lutilisation de codes de
parit pour gnrer la redondance.
Lopration de protection propose par ce protocole commence par la concatnation de

certains champs prsents dans ns len
len-tte
tte des paquets RTP mdia. On ajoute ensuite le
conteneur (payload) contenant les donnes. La mme opration est ralise sur plusieurs
paquets et on applique sur le flux binaire ainsi form un ou exclusif (XOR) pour gnrer
les conteneurs de FEC et construire des nouveaux paquets RTP.
Figure 4: Les paquets FEC gnrs chez lmetteur seront transmis avec les paquets RTP.
RTP Lee rcepteur les utilise
pour reconstruire les paquets perdus
Un paquet RTP contenant des FEC est constitu dun en-tte RTP dun en-ttette de FEC et du
conteneur de FEC. Cest dans len
len-tte
tte de FEC que se trouve un champ de 24 bits (mask field)
permettant de retrouver quels sont les paquets de donnes utiles associes avec ce paquet de
FEC (dans la figure : les paquets D3, D2, D1 sont indiqu dans P2). Ainsi les FEC ne
pourront porter que sur 24 paquets de donnes utiles conscutifs au maximum.
Les paquets de donnes utiles et les paquets contenant des FEC sont en gnral envoys dans
des flux RTP spars [33].. Lorsque des pertes de paquets se produisent on reconstruit un
paquet RTP la rception avec le rsultat du ou exclusif appliqu sur les paquets de FEC
et de donnes mdias reus.
Les codes FEC induisent un temps de latence supplmentaire lmetteur.

metteur. Si on oublie le
temps de codage et de dcodage (en effet, il existe des algorithmes de codage trs rapide), il
persiste tout de mme un temps de latence incompressible puisque pour pouvoir commencer
coder, le codeur de canal devra attendre davoir
davoir reu de la part du codeur de source
suffisamment de donnes. Le mme problme se posera la rception puisque en cas de
pertes le dcodeur devra attendre de recevoir suffisamment de donnes pour pouvoir
commencer dcoder. Ajoutons que nous somme oblig oblig de gnrer et transmettre les FEC
mme si le taux de perte sur le canal est nul. Pour cela les FEC peuvent tre efficacement
remplaces par dautres mthodes de contrle derreur telles que les mthodes bases sur des
demandes de retransmission des paquets
paqu perdus.
20
3.3 Contrle derreurs par retransmission
Ces mthodes de contrle derreurs sappuient sur la retransmission de donnes perdues. En
effet, il existe deux mcanismes de dtection de perte : soit par le rcepteur, soit par
lmetteur. Dans les deux cas, lmetteur numrote les paquets quil envoie de manire
squentielle. De cette manire, soit le rcepteur dtecte la perte des paquets et demande leur
retransmission en envoyant lmetteur un accus de non rception (NACK), soit le rcepteur
envoie lmetteur la rception de chaque paquet un accus de bon rception (ACK). Cet
accus permet lmetteur de dtecter la perte et retransmettre les paquets perdus. Nous nous
intressons la premire mthode (bas sur le NACK) mais avant dexpliquer cette mthode
nous donnerons le principe de fonctionnement des mcanismes bas sur le ACK .
3.3.1 Mcanismes bass sur un accus de rception
Le protocole majeur bas sur lutilisation de laccus ACK est le protocole ARQ. Dans ce
paragraphe on va expliquer ce protocole en dtail afin de dduire ses limites.
LARQ [26] (Automatic Repeat Request) est une mthode de contrle derreur qui sappuie
sur des retransmissions. Chaque paquet reu correctement est suivi dun envoi dun accus de
rception (ACK) contenant le numro de squence du paquet. Tous les paquets nayant pas
fait lobjet dun ACK pendant un intervalle de temps fix (temps dexpiration : Timeout) sont
considres comme perdus et sont retransmis.
LARQ peut se dcliner sous plusieurs formes. Nous citons les deux principales.
Mthode du arrt et attente (STOP and WAIT) : Lide de cette mthode est que
pour chaque paquet envoy lmetteur attend un accus de rception avant de
transmettre le suivant. Si aprs le temps dexpiration aucun ACK nest reu on renvoie
le paquet. Linconvnient vident de cette mthode est son faible dbit denvoi.
Mthode de la rptition slective : Ici les paquets sont transmis de manire continue.
Chaque paquet reu correctement fait lobjet dun ACK. Tout ACK non reu aprs le
temps dexpiration est suivi de la retransmission du paquet perdu. Lmetteur reprend
ensuite ses envois partir du paquet perdu mme si certains paquets le suivant ont
dj t reus.
la base lARQ tait destin des applications point point scurises et non contraintes par
le temps. Clairement une utilisation directe des mthodes dcrites prcdemment dans un
contexte multipoint conduirait de faon certaine une explosion de la voie de retour. En
effet tant donne la taille potentiellement grande des arbres multipoints, le trace gnre par
les demandes de renvoi a de grande chance de congestionner le lien menant la source.
Dautre part mme si ces demandes russissent aboutir, il nest pas vident que la source
puisse toutes les traiter. Lutilisation des demandes de renvoi en multipoint implique donc
leur adaptation ce cas spcifique.
Il est remarquable quARQ ne puisse tre pas utilis par les applications multimdia.
Plusieurs tudes ont montr son inefficacit [29][30] d au grand nombre des messages ACK
envoy par les participants. Pour cela nous nous intressant au mcanisme utilisant un accus
de non rception NACK.
21
3.3.2 Mcanismes bass sur un accus de non rception
Lmetteur numrote toujours les paquets par un numro de squence permettant au rcepteur
de dtecter les paquets perdus. Ce mcanisme de contrle est bas sur lmission vers
lmetteur dune requte demandant la retransmission de ces paquets (message NACK). la
rception de cette demande lmetteur retransmet les paquets perdus.
Cependant, une remonte de trop nombreux messages peut charger inutilement le serveur et
risque de dgrader ses performances. Pour viter cette surcharge, le rcepteur a tout intrt
regrouper plusieurs requtes de retransmission dans un unique message. Le RFC 4585 [3] a
normalis un format permettant de dclarer plusieurs requtes dans un unique message
NACK.
Ce format consiste ajouter dans le message un ou plusieurs champs FCI (ce message est
form dun en-tte (adresse et port source, etc.) et dun ensemble de FCI). Chaque FCI est
form de 32 bits divis en deux champs (PID et BLP). Le champ PID sert indiquer une
premire perte de paquet. Alors que le champ BLP qui contient 16 bites, est utilis pour
envoyer les numros de squence des paquets perdus parmi les 16 suivant le premier. Si un
paquet est perdu on met un (1) dans le bit correspondant. Pour dterminer son numro de
squence il suffit dajouter le numro du bit au numro de PID. Ceci permet de rduire le
volume du NACK.
Le format du champ FCI (inclut dans le NACK) est le suivant :
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cependant, en temps rel le rcepteur ne doit pas attendre trop longtemps avant d'envoyer ses
requtes. En effet, si ensuite le temps de rception des donnes retransmises est trop long, les
paquets de correction des pertes risquent d'arriver aprs le temps de fourniture des donnes au
dcodeur. Ajoutons que lmetteur ne peut pas garder les paquets dj envoy trop longtemps.
Selon le RFC 4588 [5], il peut les conserver pour un temps fixe RtxTime.
Donc, pour contrler lerreur de transmission en temps rel, il faut trouver une solution
rduisant le nombre des messages NACK (en utilisant le format dcrit prcdemment) et
prenant en compte les contraintes de lmetteur et du rcepteur (RtxTime,).
Plusieurs solutions bases sur la retransmission en utilisation du NACK ont t propos. On

trouve par exemple la solution propos par Levine, Paul et Garcia dans [29]. Selon ces
auteurs, cette solution est adapte multicast. Leur but est juste de limiter le nombre de
message NACK. Pour cela, chaque message NACK sera transmis en multipoint dans larbre.
Le premier rcepteur dun NACK donn, en transmettant en multipoint, informe les autres
nuds de sa rponse, leur vitant dy rpondre eux-mmes. Pour fonctionner, la mthode
sappuie sur une temporisation alatoire des NACK. Lordre denvoi dun NACK ne sera
excut au terme de cette temporisation que si le rcepteur ne voit pas passer un autre NACK
demandant le renvoi des mmes informations. De la mme manire pour pouvoir rpondre
un NACK, un rcepteur doit sassurer quil na pas reu lui-mme une rponse cette
demande ce qui indiquerait quun autre rcepteur y a dj rpondu.
22
Cependant, ces solutions utilisent un timer (temporisateur) pour dclencher la remonte du
NACK. Bien que ce timer permet au rcepteur dtre sr que le paquet est perdu (en effet, les
paquets arrivent dans un ordre diffrent), il possde certains limites.
En effet, sur les rseaux ADSL3, si des pertes apparaissent dans la voie descendante en raison
d'un bruit impulsif lev, il y a une forte probabilit que la mme chose se produise aussi sur
la voie remontante. Dans ces conditions, il est inutile d'envoyer des requtes de retransmission
quand le rseau n'est pas fiable, et il est prfrable d'attendre un retour la normale, dtect
simplement par la rception d'un paquet. Lutilisation du timer ne prend pas en compte ce cas
et toujours nous avons un risque de perdre les requtes de retransmission.
Une autre limite de lutilisation de timer est dcrite par Rishi et Christos dans [7]. En effet, le
timer sera calcul en fonction de RTT. Malgr la variation de RTT sur Internet lutilisation de
timer peut apparat dispensable puisque lmetteur peut recevoir les demandes aprs Rtxtime
(si RTT est grand) et risque de ne pas retransmettre les paquets demands.
Cependant, la plupart des solutions utilisant le timer sont bases sur lutilisation dun NACK
contenant la demande dun seul paquet et non pas le NACK dcrit prcdemment. En effet,
lmission dun NACK pour chaque paquet perdu peut charger le rseau et augmenter le
risque de nouvelles pertes. Pour ces raisons (le timer et un NACK pour chaque paquet) ces
solutions sont considr incompatibles avec les systmes temps rel.
Rishi Sinha et Christos Papadopoulos ont dfinis dans [7] une autre mthode base sur
lutilisation du NACK sans utiliser un timer. Le problme principal de cette mthode est
quelle suppose que lmetteur peut garder les paquets dj envoy jusqu' la fin de la session
(diffrent ce qui est dfini par lIETF), ajoutons quil ne prend pas en compte les contraintes
du rcepteur. En effet, le rcepteur ne peut pas attendre beaucoup avant de recevoir les
paquets perdus ce qui nest pas respect dans cette mthode. En plus, le NACK sera mis
directement la dtection de la perte dun paquet. C'est--dire que le rcepteur ne distingue
pas un paquet perdu dun paquet en retard.
Dans le chapitre suivant on va proposer une nouvelle mthode base sur la retransmission en
utilisant le NACK. Notre mthode nutilise pas le timer mais il respecte les contraintes de
lmetteur et le rcepteur tout en permettant au rcepteur de vrifier que les paquets non reus
sont perdus. Ajoutons quon utilise le format du NACK dfini par lIETF.
4. Conclusion
Ce chapitre a prsent les diffrents protocoles utiliss pour la transmission des flux temps
rel ainsi que trois mcanismes pour contrler la congestion.
Parmi les mthodes bases sur le mcanisme de rgulation du dbit nous avons dfini le
protocole TFRC. Ce protocole ne prend pas en compte la nature des flux transports. Il rduit
le dbit dmission selon une formule bien dfinie, mais cela ne peut se raliser que par
3
ADSL: Acronyme pour Asymmetric Digital Subscriber Line. Une nouvelle technologie permettant denvoyer plus de
donnes sur les lignes tlphoniques existantes. ADSL reoit les donnes un dbit situ entre 0.5 et 9 Mbps (downstream
rate), et envoie un dbit 16 640 Kbps (upstream rate).
23
modification du dbit vido. En effet, les donnes vido sont compresses et stocks avec un
dbit donn. Afin de garder leur qualit, ces donnes ne peuvent tre transportes quavec un
dbit dmission plus grand ou gale leur dbit.
Dautre part, la modification du dbit vido ne peut se raliser que par modification des rgles
appliques au codeur ce qui est possible pour la visiophonie (o le codage des donnes se fait
directement avant de les envoyer), mais est inapplicable un service VOD (o la vido est
dj cod et stock sur le serveur et il est difficile de la recoder). Il est donc indispensable de
maintenir le dbit du flux vido. En effet, le procd de correction derreur doit tre
totalement indpendant du codeur do la limite du mcanisme de rgulation du dbit.
Lintroduction de redondance dans les paquets de donnes (code FEC) induit une latence
lmetteur pour gnrer les codes et noptimise pas le dbit si le taux de perte nul. loppos,
les mthodes bases sur la retransmission en utilisant un accus de rception ACK (ARP)
risquent de charger la voie de retour, ce qui augmente le risque de nouvelles pertes. Do le
besoin doptimiser le dbit remontant.
Nous voudrions proposer dans le chapitre suivant une mthode bas sur la retransmission en
utilisant le message NACK. Dans cette mthode on ne retransmet que les donnes rellement
perdues par les usagers et il ny a pas de surdbit sur la voie descendante en absence de pertes,
en plus il y a une optimisation du dbit remontant en labsence dacquittements
systmatiques.
Comme les autres mthodes utilisant le NACK, cette mthode utilise le format de NACK
dfini par lIETF ce qui optimise au maximum le dbit remontant. Notre mthode nutilise
pas un timer. Elle prend en compte les conditions de temps rel o le rcepteur ne peut pas
attendre beaucoup avant denvoyer le NACK et paralllement lmetteur ne peut garder les
paquets que pour un temps maximum RtxTime.
24
Chapitre 2 : La rparation par retransmission
1. Introduction
Nous avons vu dans le chapitre prcdent un tat de lart introductif sur le domaine de la
transmission des flux temps rel sur Internet. Plusieurs mcanismes ont t proposs pour
contrler la congestion. Nous avons montr les limites des mcanismes utilisant la rgulation
du dbit et lintroduction des redondances dans les paquets transmis (codes FEC). Nous
proposerons dans ce chapitre une mthode de correction derreurs base sur la retransmission.
La mise en uvre de rparations par retransmissions s'appuie sur les standards IETF RFC
4585 (RTCP Feedback) [3] et RFC 4588 (RTP retransmission) [5]. la dtection de la perte
dun paquet, le rcepteur envoie lmetteur un message NACK demandant la
retransmission. Toutefois, une remonte de trop nombreux messages NACK peut charger
inutilement le serveur et risque de dgrader ses performances. Pour cela lIETF a dfini un
mode particulier pour limiter les requtes de retransmission remontes vers le serveur. En
effet, le rcepteur peut regrouper plusieurs requtes de retransmission dans un unique
message en utilisant le format dfini dans le RFC 4588 [5] (et dcrit dans le chapitre 1).
Cependant, ce document [5] ne dcrit aucun moyen explicite pour raliser cette agrgation
mais la mthode propose dans ce chapitre utilise ce format de la requte. Avant dexpliquer
en dtail cette mthode on va faire un petit rappel sur les conditions de transmission en temps
rel respecter dans toutes les solutions proposes.
En raison de la nature temps rel des flux vido, le rcepteur ne doit pas attendre trop
longtemps avant d'envoyer ses requtes. En effet, si ensuite le temps de rception des donnes
retransmises est trop long, les paquets de correction des pertes risquent d'arriver aprs le
temps de prsentation des donnes au dcodeur et seront considrs comme perdus. Ajoutons
que lmetteur ne peut garder les paquets envoys que pour un temps limit et fix RtxTime
[5]. Cependant, il est inutile d'envoyer des requtes de retransmission quand le rseau n'est
pas suffisamment fiable (lorsquil y a un grand nombre de pertes), et il est prfrable
d'attendre un retour la normale, ce qui est dtect simplement par la rception d'un paquet.
Notre mthode bien adapte au multicast ne retransmet que les paquets rellement perdus
avec une optimisation du dbit remontant (en absence dACK) et sans surdbit sur la voie
descendante en absence de pertes. Nous avons vrifi la validit de cette mthode dans le cas
de VOD (unicast), la vrification de la validit en multicast nest pas aborde dans notre stage
et reste faire dans le futur.
Ce chapitre dcrit le principe de fonctionnement de notre mthode ainsi que les rsultats
obtenus montrant sa validit.
2. Description de la solution
2.1 Principe de fonctionnement
En utilisant le format du paquet RTP dfini dans le RFC 4588 [5], lmetteur numrote les
paquets par un numro de squence initialis alatoirement et qui sincrmente lmission
de chaque paquet. Le fonctionnement de notre mthode s'appuie sur l'analyse des numros de
25
squence reus afin d'organiser la remonte
remont des requtes de retransmission (NACK) en
respectant les conditions de temps rel.
Pour fonctionner correctement,, cette mthode oblige les deux participants

participants (lmetteur et le
rcepteur) utiliser un ensemble de paramtres bien dfinis.
En effet, la fentre
tre RtxTime est un paramtre de configuration dfini dans le RFC 4588[5]. Il
est utilis par lmetteur. Il dfinit
dfini une fentre pendant laquelle lmetteur garde les paquets
dj envoys dans le cas d'une ventuelle demande de retransmission.
En revanche, les paramtres utiliss par le rcepteur sont :
1. N : La taille dee la fentre dclenchant la remonte d'un NACK.
2. P : Lee nombre de paquets perdus sur une fentre partir duquel il ne sert rien
d'envoyer un NACK car les retransmissions temps des paquets perdus ne sont plus
possibles.
Cependant, les paramtres N, P et RtxTime doivent tre bien choisis pour assurer un
fonctionnement cohrent. En effet, le choix de ces paramtres dpend des autres paramtres
importants comme le dbit dmission, le dbit de retransmission, le dbit remontant, la taille
du buffer de rception
ception (le buffer stockant les paquets avant leur prsentation au dcodeur
dcodeur), et
le taux de perte moyen sur le canal (voir la deuxime partie du chapitre).
chapitre). Avant dexpliquer la
mthode utilise pour choisir ces paramtres on va prendre un exemple expliquant
expliquan bien leur
utilisation.
2.2 Exemple dutilisation des paramtres N et P
Les figures suivantes (Figure 5 et Figure 6) montrent un exemple de fonctionnement avec N =

6 et une premire perte de paquet se produisant partir du numro de squence 44.
La Figure 5 montre le regroupement de pertes partir de la dtection du premier paquet

perdu.. La rception des paquets 45 et 47 permet de dtecter respectivement les pertes des
paquets 44 et 46. L'arrive du paquet 49 permet de conclure que la taille de la fentre
d'agrgation (6 paquets) est atteinte et de bien vrifier que les paquets (44 et 46) sont perdus
et non pas en retards. Un message NACK contenant la demande de retransmission des
paquets 44 et 46 sera donc mis.
Figure 5:: Exemple de fonctionnement du modle avec N=6
La Figure 6 montre le regroupement de pertes

pe dans le cas o le Nime (6me) paquet de la
fentre (paquet 49) n'est pas reu. Dans ce cas, le rcepteur attend de recevoi
recevoir un paquet
26
correct (le 52 dans l'exemple) afin de remonter l'ensemble des pertes qu'il a dtectes depuis
la premire dtection.
Figure 6:: Exemple de fonctionnement du modle avec N=6; le Nime

N paquet est perdu
La rception du paquet
aquet 52 montre que la rception qui tait rompue depuis le paquet 48 est
rtablie, et par consquent le rcepteur peut en dduire que son message a beaucoup plus de
chances d'atteindre la source que lors d'une mission par expiration d'un timer.. Dautre ppart, si
la rception de ce paquet le rcepteur constate que le nombre des paquets perdus depuis le
paquet 44 est plus grand que P, il nenvoie plus le NACK car il considre qu'il nnest pas
possible de recevoir les donnes temps.
Remarquons que pour assurer

urer le bon fonctionnement de la mthode et respecter les conditions
temps rel, il faut trouver une manire cohrente pour choisir les valeurs de N et P et
RtxTime.
2.3 Le choix
hoix des paramtres
Les
es applications multimdia utilisent le protocole RTSP pour contrler
contrler les flux. Avant de
commencer une session, le rcepteur doit initialiser une connexion avec lmetteur en lui
envoyant un ensemble dinformations (nom de la vido demande, numro de port, ).
Lmetteur utilise ces informations pour initialiser ses paramtres
pa avant de les envoyer au
rcepteur en rpondant son message. Un des paramtres les plus importants est le RTT
RTT. Il
sera estim par lmetteur avant de commencer la session (en envoyant, par exemple, un
message ping au rcepteur) [7]
[7].
2.3.1 Les paramtres

mtres utiliss par lmetteur
2.3.1.a Le dbit dmission
Cest le dbit utilis par lmetteur pour envoyer les paquets vido. Ces paquets seront
gnrs en segmentant les squences vido stockes.
Une
ne squence vido reprsente une succession dimages en mouvement,
mouvem , dont la prsentation
est bien dfinie dans le temps. Par leur nature, les images ont une forme analogique, mais en
informatique bien videmment elles sont reprsentess sous une forme numrique. Ces images
numrises occupent un volume important. En consquence,
consquence, lune de leurs caractristiques les
plus importantes est le dbit mesur en bit par seconde (bps).
Pour conomiser de lespace et de la bande passante, les squences vido sont compresses. Il
existe plusieurs formats de compression, mais le plus
plus utilis pour la vido est le standard
MPEG. Ce format utilise des techniques de prdiction avec compensation de mouvement pour
dduire avec un minimum dinformations additionnelles la plupart des images de celles qui
les prcdent. Cette compression rduit
rd beaucoup le volume de stockage et le dbit des
27
squences vido compresses. Par exemple, MPEG 4 permet de descendre le dbit jusqu 10
kbps, ou doffrir une excellente qualit dimage avec 2 3 Mbps.
Dans la pratique, il est trs difficile dobtenir un codage qualit et dbit constant, car la
compression des donnes varie avec le contenu de la scne. Il existe donc deux types de
codeurs :
Ceux qui travaillent dbit constant (CBR), mais en modifiant la qualit de la

vido ou en ajoutant le cas chant des informations de bourrage.
Ceux qui travaillent dbit variable (VBR) o la qualit reste peu prs
constante, mais le serveur rduit son dbit quand le codage le permet.
2.3.1.b Le dbit de retransmission
Les paquets perdus seront numrots sparment mais retransmis en parallle avec les paquets
de donnes. Lmetteur choisit son dbit de retransmission en fonction du dbit dmission
(dcrit prcdemment) et du taux de perte sur le canal.
En utilisant un dbit de retransmission gal au dbit dmission, lmetteur a la capacit de

retransmettre tous les paquets perdus mais le rseau reste trs charg. En effet, le nombre de
ces paquets est gal au :

Donc ils peuvent tre retransmis avec un dbit de retransmission gal au :

Ceci diminue le surdbit sur la voie descendante.
2.3.1.c La fentre RtxTime
La fentre pendant laquelle lmetteur garde les informations en cas d'une ventuelle
retransmission sera calcule en fonction du RTT, du dbit de retransmission et de la perte sur
le canal.
Le RFC 4588 [5] nindique aucun moyen explicite pour choisir ce paramtre. Dans notre
mthode RtxTime sera calcul selon la formule suivante (voir Figure 7):
= +

+
Tel que

=
/
En effet, pour retransmettre un paquet donn, lmetteur doit le garder au moins jusqu la
rception dun NACK qui demandera sa retransmission (en cas de perte).
28
Supposons quun paquet est perdu. Le NACK
sera envoy par le rcepteur aprs la rception
dun paquet correct
ect indiquant la dtection de la
perte. Le rcepteur peut recevoir ce paquet
(selon la Figure 7) au maximum aprs la dure
de la rafale derreurs (enn effet, cest le pire cas
de perte, o il y a un problme sur le rseau et
un ensemble de paquets groups seront perdus).
perdus
Donc lmetteur reoit le NACK aprs la
+ (Voir la Figure
7).
Ajoutons que le dbit de retransmission est

faible donc lmetteur a besoin dun certain
certa
temps t pour renvoyer les paquets
demands. Ce temps est calcul en fonction du Figure 7:: RtxTime est en relation avec la dure des
dbit de retransmission et du nombre des rafales et le rapport entre les dbits dmission et de
retransmission
paquets retransmettre :
=
/
Cependant, on sait que le nombre des paquets demands est au maximum gale au nombre
des paquets perdus pendant la rafale. Ce nombre sera calcul en fonction du dbit dmission
et de la dure de rafale: =
. RtxTime est donc
calcul en se basant sur les formules prcdentes. Il est en relation avec la dure des rafales et
le rapport entre les dbits dmission et de retransmission. Toutefois, il i garantit la
retransmission
nsmission de tous les paquets de cette rafale type.
2.3.2 Les paramtres utiliss par le rcepteur
2.3.2.a La taille de buffer de rception
Le dcodeur du rcepteur permet de reconstruire les squences vido initiales partir des
paquets reus (une squence vido est forme dun ensemble de paquets). Le rcepteur a donc
besoin dattendre la rception
ception dun certain nombre de paquets avant de les envoyer ensemble
au dcodeur. Pour cela il garde les paquets reus dans une
un mmoire temporaire buffer .
Toutefois, dans le cas dune perte,

perte il faut que les paquets retransmis arrivent temps. C'est
C'est--
dire avant que le rcepteur fournisse les paquets du buffer au dcodeur. Le buffer a une taille
finie,, il sera vid par le rcepteur en envoyant les paquets au dcodeur, mais si sil est plein le
rcepteur le gre comme un FIFO IFO (First In First Out) do le risque de perdre des paquets. En
effet, les paquets arrivant crasent ceux existants dans le buffer, les paquets crass seront
considrs comme perdus (parce quils nnont pas encore t envoys au dcodeur). Pour cela
il faut trouver un moyen pour choisir la taille du buffer garantissant la bonne rce rception des
paquets mis et retransmis.
La taille du buffer en nombre de paquets est :
=
# + $% / &
29
Tel que D est un dlai additionnel compensant les latences des
de rseaux et des quipements
mis en uvre. (Voir la Figure 8).
).
En effet, si un paquet est perdu,

le rcepteur doit lattendre au
maximum RtxTime
txTime (car
lmetteur peut le retransmettre
au maximum aprs RtxTime).
Mais supposons que ce paquet
est retransmis aprs exactement
RtxTime (Figure 8),), il a besoin
donc dun certain temps avant
darriver
ver chez le rcepteur (il a
besoin dau moins RTT/2).
Donc le paquet sera reu par le
rcepteur aprs au maximum
+ $ (D=RTT/2).
Figure 8 : La taille du buffer est gal au Dbit dmission*(RtxTime+D)
Pendant ce temps lmetteur peut avec D=RTT
mettre w (dj dfini) paquets et
le rcepteur doit les enregistrer
dans le buffer en gardant la place du paquet attendu.
attendu Donc, il est prfrable de choisir un
buffer de taille w.
Remarquons quen prenant un buffer de cette taille et en calculant le RtxTime selon sa

formule, on peutt garantir quil ny a pas de perte ct rcepteur (buffer suffisant) et quil a
beaucoup de chance de recevoir les paquets retransmis (car il y aura de la place dans le
buffer). En revanche, lmetteur ne garde les paquets quun temps fini do le respect des
conditions imposes par le temps rel. En effet, ces conditions seront bien respectes si le
rcepteur envoie le NACK temps (cela dpend du choix de N).
2.3.2.b La fentre N
N indique la taille de la fentre dclenchant la remonte d'un NACK. En effet, lmission du

NACK aprs la rception dun certain nombre des paquets (et non pas aprs lexpiration du
timer)) nous permet de vrifier que les paquets sont perdus et non pas en retards.. Si on fait, par
la suite, lhypothse quil ny a quune faible chance de congestion sur le rseau alors il y a
une grande chance de recevoir le NACK de la part de lmetteur.
Cependant, il faut choisir une valeur prenant en compte le fait que lmetteur ne garde les
paquets que pendant RtxTime. Rappelons que RtxTime dpend de la dure maximale de
rafale (paragraphe 2.3.1.c). Si le NACK sera envoy directement aprs la rafale, lmetteur
peut retransmettre tous les paquets demands. Donc N est gal au nombre des paquets mis
pendant la dure de rafale. Cest au maximum :
=

Etant donn que N peut changer les rsultats par le dlai quil introduit,
introduit, sa valeur sera un
paramtre des simulations pour valuer son impact sur les rsultats obtenus.
30
2.3.2.c Le paramtre P
Lorsquun grand nombre de pertes apparat sur le rseau la chance de recevoir le NACK est
trs faible. Mme, si le NACK est reu, les donnes retransmises peuvent tre elles aussi
perdues et surtout elles risquent de ne pas arriver temps. Pour cela, la dtection de la perte
dun certain nombre des paquets successifs (P) le rcepteur peut dduire quil ne sert rien
denvoyer le NACK.
On sait que si des paquets groups sont perdus, la rception du premier paquet correct le
rcepteur dtecte la perte et garde la place de ces paquets dans le buffer avant denvoyer le
NACK. Rappelons que le rcepteur garde la place dun paquet, en attendant sa retransmission,
un temps limit ( + $). La chance de recevoir ce paquet temps dpend de la
capacit de retransmission. En effet, lmetteur peut retransmettre pendant le temps dattente
un $ # + $) bits. Compte-tenu du dbit autoris pour
les retransmissions, par exemple 50% du dbit normal d'mission, lmetteur peut
retransmettre 50% * # + $) bits. Donc il peut retransmettre
au maximum 50% de la taille du buffer de rception. Pour cela si le nombre des paquets
perdus est plus grand que 50% de la taille du buffer, il ne sert rien denvoyer le NACK car il
y a un risque de ne pas recevoir les paquets retransmis temps. De plus il faut y ajouter le
risque de ne pas trouver les paquets chez lmetteur et la possibilit de perdre le NACK. Par
consquent :
+ =
2.3.2.d Le dbit remontant
Afin dassurer une transmission fiable sur le rseau Internet, il ne faut pas surcharger la voie
du retour, en particulier pour les rseaux ADSL forte dissymtrie. En effet, le RFC 4588 [5]
permet lutilisation dun dbit remontant gale au maximum 5% du dbit dmission. Notre
mthode prend ce dbit comme dbit maximum mais en pratique, nous vrifierons que le
dbit des NACK est compatible avec les rseaux ADSL.
2.3.3 Conclusion du choix des paramtres
Nous avons expliqu dans ce paragraphe la mthode utilise pour choisir les diffrents
paramtres de notre solution. Cette mthode garantit le respect des conditions de temps rel
(ce qui est montr par les simulations prsentes dans le paragraphe suivant). Toutefois on
nutilise pas un timer, diffremment des solutions prcdentes : le NACK sera envoy aprs la
rception dun certains nombre de paquets. De plus, lmetteur nutilise quun paramtre
limitant la taille de son buffer (RtxTime). Ce qui rend notre solution diffrente des autres qui
se basent sur la retransmission.
3. Validation de la solution
Le modle dcrit prcdemment est bas sur un ensemble de paramtres bien choisis. Afin de
montrer la validit de cette solution et la possibilit de limplmenter rellement, nous avons
ralis un modle de simulation sappliquant une VOD entre un client et un serveur.
Le but de ce modle est de faire un ensemble des simulations dterminant les optimisations de
la solution. En particulier le compromis entre la latence, la taille du tampon de rception et le
31
surdbit disponible. Nous avons implment ce modle sous le logiciel OPNET. En effet,
lenvironnement OPNET permet la modlisation et la simulation de rseaux de
communication grce ses bibliothques de modles (routeurs, commutateurs, serveurs..) et
de protocoles (dont TCP/IP, Ethernet,).
Le modle implment permet de dfinir les profils de pertes pertinents. Il s'agit de

dterminer les cas critiques. Dans la suite nous expliquerons les modles de perte choisis ainsi
que les simulations effectues montrant la validation de la solution.
3.1 Les modles de perte utiliss

Les pertes sur Internet sont causes par la congestion, linstabilit du routage et les
dfaillances de liens. La congestion est la cause la plus importante de pertes. La perte de
paquet peut se produire par dpassement de la capacit des buffers dans les routeurs ou dans
les systmes dextrmit (le rcepteur). Le taux de perte correspond au rapport du nombre de
l
paquets non arrivs sur le nombre total de paquets transmis. La distribution des pertes est une
mtrique trs importante pour les protocoles traitant le problme de congestion (TCP,). Un
lien du rseau peut tre caractris par son taux derreur qui est calcul sur intervalle de temps
relativement long. Il correspond au nombre de paquets errons sur le nombre total de paquets
reus. Dans les liaisons filaires actuelles (Internet), ce taux derreur rsiduel est trs faible
(typiquement 10-8).
Pour modliser les cas rel, nous avons besoin dimplmenter des modles de pertes
particuliers. En effet, nous avons utilis deux modles de perte : la perte uniforme et la perte
par rafale.
3.1.1 La perte uniforme
On trouve dans les littratures [18][19] que le modle de canal le plus simple est le canal
perte sans mmoire. Dans ce canal les pertes sont indpendantes et identiquement distribues.
On appelle ce modle de perte uniforme . Il permet de perdre un ensemble des paquets
dont leur nombre est gal au :
&
t est donn avant de commencer la simulation (10% par exemple). Dans ce modle, un
paquet sera perdu chaque intervalle de temps qui sera fix et calcul en fonction de t .
Ce modle est simple et trs proche du cas rel. Il nous permet de tester la validit de notre
mthode avec un taux de perte constant. En effet, si une solution est valide avec un taux de
perte gal 10%, elle est valide avec nimporte quel taux de perte infrieure 10% et bien
videment avec un taux de perte gal 10-8.
3.1.2 La perte par rafale
Rappelons que sur les rseaux ADSL, si des pertes apparaissent dans la voie descendante en
raison d'un bruit impulsif lev, il y a une forte probabilit que la mme chose se produise
aussi sur la voie remontante. Dans ces conditions, il est inutile d'envoyer des requtes de
retransmission quand le rseau n'est pas fiable, et il est prfrable d'attendre un retour la
normale, dtect simplement par la rception d'un paquet. Notre mthode prend en compte ces
32
conditions (on utilise P et N). Nous allons le montrer en introduisant un modle de perte par
rafale.
En effet, ce modle est bas sur lintroduction dun bruit impulsif lev sur le canal. Ce bruit
sera rpt priodiquement. Il sagit dun bruit qui reste un certain temps (20 ms par
exemple). Pendant ce temps tout paquet envoy (y compris le NACK) sera perdu.
Nous proposerons de le caractriser par le taux moyen de perte. Par exemple, dans nos
simulations nous avons utilis un taux de perte moyen gal 10%. Il sagit dintroduire une
perte restant 60 ms et qui se rpte chaque 600 ms (60 ms permettent de modliser une perte
restant un temps suffisamment long). Notons que nous avons test la mthode implmente
avec dautres temps et nous avons obtenus les mmes rsultats.
Lintrt de ce modle est quil modlise le pire cas pouvant apparaitre sur le canal (perte des
paquets groups). Toutefois, la perte uniforme permet de modliser un cas rel. Pour cela
nous avons utilis ces deux modles dans les tests de notre solution.
3.2 Les simulations effectues
Pour montrer la validit du modle, nous avons besoin de raliser un ensemble de simulations
couvrant tous les cas. Elle sera montre en mesurant le pourcentage des paquets perdus aprs
la retransmission. C'est--dire les paquets que le rcepteur na pas pu fournir au dcodeur
parce quils ne sont pas arrivs temps ou parce quils ne sont pas retransmis.
On trouve dans la littrature [7][19] quil est prfrable de faire ce mesure dans deux cas
diffrents :
Le cas o il ny a pas une perte sur la retransmission ni sur le NACK (seulement les
paquets de donnes RTP seront perdus). En effet, ce cas permet de tester la validit du
modle et des profiles de pertes implments.
Le cas o des paquets peuvent tre perdus lors de leur retransmission (reprsentant le
cas rel).
En effet, nous avons vu dans le paragraphe 2.3.1.a de ce chapitre que lmetteur peut envoyer
les donnes avec un dbit constant (CBR) ou variable (VBR). Pour cela nous avons ralis
des simulations dans les deux cas.
3.2.1 Les simulations dans le cas du dbit constant (CBR)
Notre but est de montrer la validit de relations existantes entre les diffrents paramtres
(taille du buffer de rception, RtxTime, N, ). Pour cela nous avons ralis des simulations
en gardant un dbit dmission constant (CBR). Les simulations se divisent en deux parties :
avec un dbit dmission faible CBR SD (3 Mbps) et avec un haut dbit dmission CBR HD
(10 Mbps).
En effet, le concept de vido est trs li au concept de tlvision. Quelque soit le format de
tlvision, il est considr quune bonne qualit des squences visuelles est obtenue avec 25
ou 30 images par seconde. Cependant, la tlvision sur le rseau ADSL utilise le standard de
codage de vido MPEG 4 qui offre un dbit entre 2 et 3 Mbps pour une bonne qualit dans la
rsolution standard (SD), et entre 7 et 15 Mbps pour les hautes rsolutions (HD). Pour cela,
33
nous avons test notre modle dans les deux cas : CBR SD avec un dbit de 3 Mbps
(reprsente le dbit max) et CBR HD avec un dbit de 10 Mbps. En effet, cest une valeur
moyenne entre 7 et 15 Mbps nous permettant de bien vrifier la validit du modle.
Cependant, la taille maximale du paquet pouvant tre transmis sur Internet (MTU) est fixe
par lIETF 1500 octets. En liminant les octets contenant les enttes du paquet (entte IP,
UDP et RTP), il nous reste 1440 octets pour les donnes envoyer. Pour cela nous avons
utilis ce nombre comme une taille moyenne des paquets. En plus, nous avons pris un RTT
gal 100 ms mais les simulations effectues (3.2.1.1.a) ont montr la validit de nos
modles quelque soit la valeur de RTT. Les autres paramtres (RtxTime et la taille de buffer,
N,) sont calculs en utilisant les formules dfinies dans la premire partie de ce chapitre
(2.3) avec un taux de perte gal 10%.
3.2.1.1 CBR SD
En utilisant un dbit dmission gal 3 Mbps Tableau 1: Les valeurs de simulations utilises en CBR
SD
et un taux de perte gale 10% avec un RTT
gal 100ms, nous avons calcul les valeurs
des autres paramtres. Les valeurs choisies par Paramtres Valeurs
dfauts sont indiques dans le Tableau 1. Dbit dmission de vido 3 Mbps
Dbit de retransmission 300 Kbps
Dans la suite nous prsentons les rsultats dun RtxTime 760 ms
ensemble des simulations effectues dans le RTT 100 ms
cas de CBR SD. Taille moyenne du paquet 1440 octet
Dbit remontant 150 Kbps
D 100 ms
3.2.1.1.a Changement du RTT
Taille du buffer de rception 224 paquets
Lune des caractristiques principales de N 15 paquets
lInternet est la variation de RTT en fonction P 25 paquets
des utilisateurs. En effet, plusieurs paramtres
de notre modle dpendent de RTT. Notre but
est de montrer que les formules utilises pour
choisir ces paramtres (paragraphe 2.3) sont
applicables dans une plage de valeurs du RTT.
Pour cela, nous avons ralis une exprience

mesurant le pourcentage des paquets perdus
aprs la retransmission (par rapport aux
paquets mis) en fonction du RtxTime. Cette
exprience a t rpte plusieurs fois pour
plusieurs valeurs de RTT. Les autres
paramtres (N, P, buffer,) ont pris leurs Figure 9: Le pourcentage des paquets perdus aprs la
valeurs dfinies dans le Tableau 1. Nous avons retransmission par rapport RtxTime; RtxTime varie
utilis un modle de perte par rafale sans entre 500 et 1200 ms; RTT varie entre 100 ms (courbe
verte), et 200 ms (courbe bleu) et 400 ms (courbe rouge)
permettre la perte sur le NACK ni sur la
retransmission. Le rsultat obtenu est prsent dans la Figure 9.
En effet, la valeur optimale de RtxTime dpend de RTT. On peut remarquer que si RTT =100
ms, le nombre des paquets perdus aprs la retransmission est gal zro pour un RtxTime de
760 ms. Cependant, une haute valeur de RTT nous oblige augmenter la valeur de RtxTime
34
(comme montre la figure : pour un RTT=200 ms, le RtxTime doit tre gal 860 ms). Cela
montre bien que pour compenser le problme de RTT, il suffit de choisir les paramtres du
modle, surtout RtxTime, selon les formules dfinies prcdemment (voir paragraphe 2.3).
3.2.1.1.b Le choix du N et RtxTime
Lexprience prcdente a montr lefficacit du modle implment. Cependant, la

caractristique principale de notre solution est quelle respecte les conditions de temps rel en
utilisant un ensemble des paramtres ct metteur et rcepteur. Ces paramtres sont
dpendants les uns des autres (par exemple, la taille du buffer dpend de RtxTime). Pour cela
il faut leur donner des valeurs optimales garantissant la validit du modle.
Laugmentation de N oblige le rcepteur attendre beaucoup de temps avant de demander la

retransmission. En revanche, la diminution du RtxTime augmente le risque de ne pas trouver
les paquets demands chez lmetteur. Malgr le fait que les autres paramtres (comme la
taille du buffer et P) dpendent de ces deux paramtres, il parat important de trouver les
valeurs optimums de N et RtxTime. Pour cela nous avons mesur le pourcentage des paquets
perdus aprs la retransmission en fonction de RtxTime et pour plusieurs valeurs de N (les
autres paramtres ont les valeurs par dfaut reprsentes dans le Tableau 1).
Les rsultats prsents dans la Figure 10 et la Figure 11 sont obtenus dans le cas o il ny a
pas de perte sur les retransmissions ni sur les NACK. La Figure 10 est le rsultat dans le cas
de la perte uniforme alors que la Figure 11 est celui dans le cas de la perte par rafale.
Ces deux figures montrent quune trop grande valeur de N augmente le nombre des paquets
perdus aprs la retransmission (courbe bleu et bleu fonc dans la Figure 11). Toutefois, si N
est plus grand que P (N=28 Figure 114), nous navons pas des retransmissions et le taux de
perte reste trs haut. Ceci reprsente le cas o le rcepteur a constat quil ne sert rien
Figure 10: Le pourcentage des paquets perdus aprs la Figure 11: Le pourcentage des paquets perdus aprs la
retransmission en fonction de RtxTime; perte uniforme, retransmission en fonction de RtxTime; perte
sans perte lors de la retransmission et sur le NACK; uniforme, sans perte lors de la retransmission et sur le
RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 NACK; RtxTime varie entre 500 ms et 1200 ms ; N
et 23. varie entre 1 et 28
4
La courbe obtenue dans le cas de la perte uniforme avec N=28 est la mme que celle de la figure 11.
35
denvoyer le NACK car il sera reu aprs lexpiration du RtxTime (voir choix de P 2.3.2.c).
En revanche, si N est plus petit ou gal 15, et

RtxTime plus grand ou gal 760 ms, le taux de
perte aprs la retransmission devient nul. (Ces
deux valeurs sont calcules par les formules dj
dfinies).
Cependant, lutilisation dune petite valeur de N

(plus petit de 15) augmente le nombre des NACK
mis et le dbit remontant ce qui surcharge le
rseau et augmente par la suite le taux de la perte.
(La Figure 12 montre la diminution du dbit
remontant avec laugmentation du N). Pour cela il
est prfrable de prendre N=15 et RtxTime= 760
ms afin dassurer un bon fonctionnement du Figure 12 : La variation du dbit remontant par
modle tout en optimisant le dbit remontant. rapport celle de N (courbe bleu pour N=1 et
courbe rouge pour N=10,)
Lintroduction de pertes sur les NACK et les retransmissions change les rsultats obtenus
mais nous avons toujours un taux de perte trs faible (entre 0.5 et 0.8% si le taux introduit sur
le canal est 10%) (Figure 13 et Figure 14).
Ces deux figures montrent bien leffet de la variation de N sur le rsultat final (N augmente, la
perte augmente). On peut remarquer que le fait de prendre un RtxTime gale 760 ms avec
un faible N (N gal 15) garantit un bon fonctionnement du modle puisque le taux de perte
diminue fortement (0.74% dans le cas uniforme et 0.6% dans le cas de la rafale). De plus, en
prenant N infrieur 15, on peut trouver de meilleurs rsultats, mais rappelons que le dbit
remontant augmente ce qui contredis nos besoins.
Cependant, dans notre modle il ny a pas une rparation des NACK ni des paquets retransmis
(quand ceux-ci sont perdus). Pour cela il est normal de trouver un certain taux de perte, mais
limportance de notre modle est que ce taux est trs faible.
retransmission en fonction de RtxTime; perte retransmission en fonction de RtxTime; perte par rafale,
uniforme, avec perte lors de la retransmission et sur le avec perte lors de la retransmission et sur le NACK
NACK; RtxTime varie entre 500 ms et 1200 ms ; N RtxTime varie entre 500 ms et 1200 ms ; N varie entre 10
varie entre 10 et 28. et 28
36
En conclusion, nous avons une mthode de retransmission valide et applicable dans le cas de
CBR SD. Elle montre la possibilit de respecter les conditions temps rel des participants en
rduisant le taux de la perte et le dbit remontant.
3.2.1.2 CBR HD
Notre modle est valide dans le cas du faible dbit Tableau 2: Les valeurs de simulations utilises
dmission (CBR SD). Cependant, les donnes vido dans le cas du CBR HD
peuvent tre codes un haut dbit, ce qui oblige Paramtres Valeurs
lmetteur augmenter son dbit dmission. Dbit dmission de 10 Mbps
vido
Laugmentation du dbit dmission nous oblige Dbit de retransmission 1 Mbps
augmenter certains paramtres, par exemple la taille RtxTime 760 ms
du buffer de rception et N (en effet, N dpend du RTT 100 ms
nombre des paquets perdus pendant la rafale, ce Taille moyenne du paquet 1440 octets
Dbit remontant 5 Mbps
nombre augmente avec laugmentation du dbit).
Cependant, les valeurs prsentes dans le Tableau 2 D 100 ms
sont celles prises en appliquant les formules des Taille du buffer de 747 paquets
rception
paramtres (choix des paramtres 2.3) avec un dbit
N 53 paquets
dmission gal 10 Mbps. Remarquons que la
P 75 paquets
valeur de RtxTime reste, comme dans le cas CBR
SD, gale 760 ms.
Nous avons ralis les mmes expriences que dans le cas de CBR SD. Les rsultats obtenus
dans les deux modles de perte avec et sans perte lors de la retransmission sont prsents dans
les figures (15, 16, 17).
retransmission en fonction de RtxTime; perte uniforme, retransmission en fonction de RtxTime; perte par rafale,
sans perte lors de la retransmission et sur le NACK; sans perte lors de la retransmission et sur le NACK;
RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 et
et 60 60
37
Figure 17: Le pourcentage des paquets perdus aprs la
retransmission en fonction de RtxTime; perte par
rafale, avec perte lors de la retransmission et sur le Figure 18: La variation du dbit remontant par rapport
NACK; RtxTime varie entre 500 ms et 1200 ms ; N celle de N (courbe bleu pour N=1 et rouge pour N=50,..)
varie entre 50 et 59
Remarquons que les rsultats obtenus sont les mmes que dans le cas de CBR SD. C'est--dire
la plus petite valeur optimum de RtxTime est 760 ms pendant que celle de N est 53 (N= dbit
dmission* priode de rafale). En plus, on peut remarquer simplement laugmentation du
dbit dmission avec la diminution du N (Figure 18).
Les simulations effectues avec un dbit constant (CBR) ont montr la validit du modle
implment. Nous avons montr le compromis entre la latence, la taille du tampon de
rception, cela en remarquant un faible taux de perte aprs la retransmission (tenant compte
que le taux de perte sur le canal est de 10%) et une correction de la plupart des paquets
perdus. En effet, nous avons corrig au minimum 92 % des paquets perdus mme en ayant de
la perte sur le NACK et sur les paquets lors de leur retransmission.
Ces rsultats sont cohrents, car lalgorithme est bien adapt aux flux CBR. Dans ce qui suit,
nous tudierons si lalgorithme est aussi adapt aux flux VBR.
3.2.2 Les simulations dans le cas du dbit variable (VBR)
Nous avons expliqu que la vido est parfois

encode des dbits variables (on trouve des
scnes dans une mme vido ncessitant un
dbit plus lev que les autres). Lmetteur est
donc oblig dmettre les vidos des dbits
variables (VBR) cela afin de garder la qualit
des images envoyes. Dans ce cas il faut que le
dbit du canal reste suprieur au dbit
maximum de vido envoyer.
Nous avons ralis des simulations en

changeant priodiquement le dbit dmission
entre un faible dbit de 1 Mbps et un dbit Figure 19: Changement du dbit d'mission entre 1
et 5 Mbs
moyen de 5 Mbps (Figure 19). La grande
diffrence entre ces deux dbits nous permet
38
de bien vrifier la validit du modle quelque soit la variation du dbit dmission.
Cependant, les autres paramtres sont calculs Tableau 3: Les valeurs de simulations utilises dans
par leurs formules mais en utilisant 5 Mbps le cas du VBR
comme dbit dmission. Les valeurs choisies
sont prsentes dans le Tableau 3.
3 Paramtres Valeurs
Dbit dmission de vido De 3 5 Mbps
Nous supposons que lun des pires cas se Dbit de retransmission 500 Kb
Kbps
prsente quand une rafale de perte apparat sur la RtxTime 760 ms
transition entre une priode au dbit max suivie RTT 100 ms
dune priode au dbit min. Dans ces conditions, Taille moyenne du paquet 1440 octet
le rcepteur doit attendre N plus longtemps car Dbit remontant 250 Kb
Kbps
les paquets sont plus espacs et le dbit D 100 ms
dmission est devenu plus faible. Ceci Taille du buffer de 374 paquets
augmente le temps de rception des paquets paque rception
retransmis et par la suite le risque de les perdre N 27 paquets
parce quils nont plus de place dans le buffer de P 38 paquets
rception.
Pour modliser ce cas, nous avons

avons implment le modle prsent dans la figure 20. La
courbe rouge montre le nombre des paquets perdus chaque instant, pendant que la courbe
bleu reprsente la variation du dbit dmission. On peut remarquer que la rafale dmarre au
dbut avec un dbit gal 5Mbps puis sera rpte avec un dbit gal 4 Mbps et ainsi de
suite. Ceci garantit quon peut trouver une rafale pendant laquelle le dbit est variable (figure
20).
Figure 20: Variation de la perte et du dbit d'mission en fonction du temps; la courbe rouge est le nombre des
paquets perdus un instant donn
Cependant, en utilisant ce modle de perte et en introduisant des pertes sur les NACK et sur
les paquets lors de leur retransmission, nous avons mesur, la capacit du modle corriger
les paquets perdus. Le rsultat est prsent dans la Figure
F 21. La courbe bleue reprsente le
nombre des paquets non fournis au dcodeur pendant queque la courbe rouge reprsente celui des
paquets perdus sur le canal.. On peut remarquer que nous avons russi corriger la plupart des
paquets perdus. En plus, nous navons pas un haut taux de perte dans le pire cas o malgr la
39
variation du dbit, le rcepteur doit attendre plus de temps avant denvoyer le NACK (courbe
jaune). Ceci montre la validit de notre modle dans le cas du VBR.
La Figure 21 montre une perte dun ensemble des paquets (courbe bleu).. Ils sont perdus parce
quil y a une perte sur les paquets retransmis et sur le NACK mais comme montre la Figure
22, le pourcentage de perte reste toujours plus petit 0.8% (au lieu de 10%). En effet, cette
figure mesure (comme dans les cas du CBR)CBR la variation du pourcentage des paquets perdus
aprs la retransmission en fonction du RtxTime et pour plusieurs valeurs de N. Le rsultat
obtenu montre la validit de notre modle quelque soit le dbit dmission (variable ou
constant).
Figure 21: Laa capacit du modle corriger les pertes Figure 22 : Le pourcentage des paquets perdus
aprs la retransmission en fonction de RtxTime;
perte par rafale, sans perte lors de la retransmission
et sur le NACK;; RtxTime varie entre 500 ms et 1200
ms ; N varie entre 27 et 30.
4. Conclusion
Nous avons prsent dans ce chapitre une solution base sur la retransmission pour contrler
la perte des paquets. Elle est base sur lutilisation dun ensemble des paramtres ct c
metteur et rcepteurs. Pour cela, nous avons expliqu au dbut les mthodes utilises pour
choisir les paramtres du modle (choix des paramtres 2.3),, puis nous avons prsent
quelques rsultats montrant la validit du modle et la possibilit de limplmenter rellement
(les simulations effectus 3.2).
Dans ce modle on ne retransmet que les paquets rellement perdus

perdus et demands par le
NACK. Diffremment aux solutions bases sur lARQ o il faut
faut retransmettre un ensemble de
paquets mme sils
ils ne sont pas tous perdus (chapitre 1).
Cependant, lune des problmes principaux des solutions utilisant le code FEC est le surdbit
sur la voie descendante en absence de pertes. Notre modle ne comporte pas cet inconvnient.
En effet, lorsquil ny a pas de la perte,
perte il ny a pas des NACK et videmment il ny a pas par
la suite de retransmission inutile des paquets
paquets.
Nous avons vu dans le chapitre

hapitre 1 lexistence des solutions utilisant le timer (cot rcepteur)
pour envoyer le NACK. En effet, si les paquets nont pas t reus avant lexpiration du timer
un NACK sera envoy. Ce qui augmente la possibilit de perdre le NACK dans le cas o le
rseau est engorg. Notre solution rsout ce problme en utilisant N et P.
40
Cependant, nous avons parl (chapitre 1) dune solution
olution utilisant le NACK sans timer [7].
Cette solution possde certaines limites puisquelle suppose que lmetteur garde les paquets
pour un temps trs long (non dfini) et que le rcepteur peut recevoir les paquets retransmis
mme aprs longtemps (il nest pas garanti de recevoir les paquets temps). Cette solution
nest pas compatible aves les contraintes temps rel que nous imposons au service, cependant
la comparaison avec nos travaux est intressante. Les auteurs dcrivant cette solution ont fait
une comparaison pratique entre leur solution et les solutions utilisant le mme principe que
TCP (o lmetteur retransmet les paquets non acquitts
acquitt aprs un certain temps dmission
RTO). Nous avons donc configur notre modle pour raliser une mme exprience et la
comparer.
Nous avons mesur ur le pourcentage des paquets corrigs par rapport aux paquets perd
perdus pour
plusieurs taux de perte. Nous
ous avons utilis les mmes paramtres dfinis
dfini par Rishi et Christos
dans [7] avec un modle de perte unifor
uniforme: N=1, RTT=60 ms, dbit dmission = 6,5 Mbps et
les autres paramtres sont calculs par nos formules prsentes dans le paragraphe 2.3. Le
rsultat est prsent dans la Figure
igure 23.
On peut remarquer simplement que nos rsultats

rsultats sont sensiblement quivalents aux rsultats
prsents dans la Figure 23 (par exemple, le pourcentage des paquets corrigs avec un taux de
perte gal 10% est 90,5% dans la figure 23 pendant quil est 89 % dans la figure 224).
Rappelons que dans notre modle lmetteur ne corrige pas les paquets perdus lors de leur
retransmission, ce qui est pris en compte dans les solutions avec lesquelles il est compar.
Malgr que ces solutions aient les mmes limites que la solution
solution implmente par Rishi et
Christos [7] (ceux dcrits avant les figures), nos rsultats restent lgrement meilleurs.
Ajoutons que leurs expriences ont t faites en utilisant un modle de perte uniforme (qui est
donc favorable) et ils nont pas pris
pri en compte le modle de la rafale.
Figure 23:: Le pourcentage des paquets corrigs Figure 24:: Le pourcentage des paquets corrigs par rapport
par rapport aux paquets perdus pour plusieurs aux paquets perdus pour plusieurs taux de perte; perte
taux de perte; perte uniforme avec une perte sur uniforme avec une perte sur le NACK et lors de la
les NACK et lors de la retransmission : rsultat de retransmission : rsultat du modle dcrit
crit par Rishi
Ris et
notre modle Christos [7]
41
Toutefois, nos rsultats ont montr une optimisation du dbit remontant, qui atteint au
maximum 0.02 % du dbit dmission. Ce pourcentage montre que notre modle respecte
bien les conditions indiques par lIETF (le dbit remontant doit tre au maximum 5% du
dbit dmission). Cela est d lutilisation dune valeur optimum de N et labsence de
lacquittement systmatique.
En conclusion nous avons un modle valide et applicable rellement. Ce modle nutilise pas
de timer dclenchant la remont du NACK, ni des codes FEC. Cependant, nous avons une
optimisation du dbit remontant et navons pas un surdbit sur la voie descendante. En
revanche, le problme principal de cette solution est que la capacit de correction est limite
par un groupe de paramtres comme la taille du buffer et le dbit de retransmission. Ajoutons
quil y a une lgre sensibilit du RTT sur les retransmissions.
42
Conclusion
Ltude mene durant ce stage sinscrit dans la problmatique de la transmission de donnes
vido temps rel sur un rseau de paquets. Nous nous sommes attachs dfinir des
approches capables dassurer une qualit de service convenable des applications de type
vido la demande (VOD) sur Internet malgr les problmes de pertes de paquets et de dlais
de transmission caractrisant ce rseau.
Dans la premire partie de ce stage nous avons tudi les principaux mcanismes de
correction derreurs rpondant aux problmes de pertes de paquets. Cette tude montre que les
protocoles de transport traditionnels nont pas t conus spcifiquement pour offrir une
transmission fiable des donnes en temps rel. Cependant, plusieurs mcanismes de
correction derreurs ont t proposs, le premier est bas sur lintroduction de redondance
dans les paquets envoys (code FEC) permettant au rcepteur de reconstruire les paquets
perdus. Le deuxime mcanisme est bas sur la rgulation du dbit. Il sappuie sur une
reprsentation concise de ltat du rseau fourni par un mcanisme dagrgation des rapports
issus des rcepteurs et se fait suivant un critre doptimisation de la qualit perue par
lensemble des rcepteurs. En effet, lmetteur utilise ces rapports pour sadapter aux
conditions du canal, il augmente ou diminue son dbit ce qui diminue le risque de la perte. Ce
mcanisme oblige lmetteur recoder les vidos stockes pour chaque mission. Ceci
ncessite une modification des rgles appliques au codeur ce qui est possible pour la
visiophonie (o le codage des donnes se fait directement avant de les envoyer), mais
inapplicable un service VOD (o la vido est dj code et stocke par anticipation sur le
serveur). Cependant, les temps de latence ainsi que la redondance induits par les codes FEC
sont deux limitations majeures des mthodes prcdemment envisages. Ces limitations
peuvent tre vites par les techniques de retransmission tudies dans ce stage.
Conformment aux standards dfinis lIETF, la deuxime partie du stage propose une
solution aux pertes. Celle-ci est base sur la retransmission en utilisant les protocoles RTP et
RTCP. Son fonctionnement est bas sur un ensemble de paramtres et de mcanismes
associs. Ces mcanismes garantissent la rception, temps, des paquets retransmis tout en
respectant la limitation du buffer de lmetteur. Ils ont lavantage doptimiser le dbit sur la
voie descendante et aussi de contrler et limiter svrement le dbit remontant.
Nous avons ralis un ensemble des simulations ayant montr la validit de cette mthode en
unicast (cas du VOD). Plus particulirement, nous avons exhib son efficacit en envoyant les
paquets avec un dbit constant ou variable. Celle-ci est de aux meilleurs rsultats obtenus en
introduisant un bruit impulsif lev sur le canal (perte par rafale).
Cette mthode pourrait tre amliore en appliquant un mcanisme permettant de

retransmettre les paquets de retransmission perdus. Ce mcanisme doit mettre en uvre une
rparation des NACK en tenant compte que le rcepteur ne doit pas attendre trop longtemps
avant d'envoyer ses requtes. En effet, si le temps de rception des donnes retransmises est
trop long, les paquets de correction des pertes risquent d'arriver aprs le temps de fourniture
des donnes au dcodeur. Notre modle de simulation permettra dvaluer les paramtres et
les capacits de rcupration des paquets perdus dans ces conditions.
43
Rfrences
[1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport Protocol for
Real-Time Applications. RFC 3550. July 2003.
[2] J-Ch. Grgoire. Cours Multimdias et QoS. Edition AUF. Mars 2007.
[3] J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey. Extended RTP Profile for Real-time
Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF). RFC 4585. July
2006.
[4] B. Adamson, C. Bormann, M. Handley, J. Macker. Negative-acknowledgment
(NACK)-Oriented Reliable Multicast (NORM) Protocol. RFC 3940. November 2004.
[5] J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg. RTP Retransmission Payload
Format. RFC 4588. July 2006.
[6] Vincent Roca. Un Etat de lArt sur les Techniques de Transmission Multipoint Fiable.
Distributed Systems Engineering (DSE) Community. Dcembre 2001.
[7] Rishi Sinha, Christos Papadopoulos. An Adaptive Multiple Retransmission Technique
for Continuous Media Streams. Nossdav. Cork, Ireland. June 2004.
[8] Vaishnav Janardhan, Henning Schulzrinne. Peer assisted VoD for set-top box based IP
network. P2P-TV. Kyoto, Japan. August 2007.
[9] Lin Ma, Wei Tsang Ooi. Retransmission in Distributed Media Streaming. NOSSDAV.
Washington, USA, June 2005.
[10] Dmitri Loguinov, Hayder Radha. Retransmission Schemes for Streaming Internet
Multimedia: Evaluation Model and Performance Analysis. ACM SIGCOMM Computer
Communications Review. April 2002.
[11] Armando L. Caro Jr., Paul D. Amer, Randall R. Stewart. Retransmission Schemes for
End-to-end Failover with Transport Layer Multihoming. IEEE Globecom. 2004.
[12] Anirban Mahanti, Derek L.Eager, Mary K.Vernon, David J. Sundaram-Stukel. Scalable
On-Demand Media Streaming With Packet Loss Recovery. IEEE, transactions on
networking editor. 2003.
[13] Xu Chenguang, Xu Yinlong, Zhan Cheng, Wu Ruizhe, Wang Qingshan. On Network
Coding Based Multirate Video Streaming in Directed Networks. Computing and
Communications Conference IEEE. 2007.
[14] Feng Xie, Gang Feng, and Chee Kheong Siew. The Effects of NAK-based Loss
Recovery Mechanism on Window-based Multicast Congestion Control. IEEE
Globecom. 2005.
[15] Haining Wang, Kang G. Shin. Robust TCP Congestion Recovery. Distributed
Computing Systems, IEEE international conference. Mesa,USA. 2001.
[16] Guillaume Jourjon, Emmanuel Lochin, Patrick Senac. Towards sender-based TFRC.
ICC proceedings. 2007.
[17] Jun Lu, Qiuqi Ruan, Rongrong Ni. A Scalable Overlay Multicast Congestion Control
for Multimedia Streaming. Conference on Local Computer Networks 30th Anniversary
IEEE. 2005.
[18] Pascale PRIMET. Contribution au Support rseau des applications rparties Qualit de
Service : pour un rseau sensible aux flux. Document dHabilitation Diriger des
Recherches, Laboratoire RESAM, ENS Lyon. 2002.
[19] Xavier Henocq. Contrle derreur pour transmission de flux vido temps rels sur
rseaux de paquets htrognes et variant dans le temps. Thse prsente devant
luniversit Rennes 1, 2002.
44
[20] Cezar Plesca. Optimisation du streaming vido. rapport de stage DEA : Programmation
et Systme. Laboratoire d'Informatique et de mathmatiques appliques, Toulouse.
2003.
[21] H. Schulzrinne, S. Casner, V. Jacobson. RTP: A Transport Protocol for Real-Time
Applications. RFC 1889. January 1996.
[22] H. Schulzrinne. RTP Profile for Audio and Video Conferences with Minimal Control.
RFC 1890. January 1996.
[23] Columbia U., R. Lanphier, A. Rao. Real Time Streaming Protocol (RTSP). RFC 2326.
April 1998.
[24] Gemmell, J. Montgomery, T.Speakman, T.Crowcroft, J.. The PGM reliable multicast
protocol. Network, IEEE, Jan 2003.
[25] Luigi Rizzo. PGMCC: a TCP-friendly singlerate Multicast congestion control scheme.
SIGCOMM. Stockolm, Sweden. 2000.
[26] Marc M. Darmon, Philippe R. Sadot. A hybrid FEC-ARQ communication system using
sequential decoding. Springer Berlin / Heidelberg. Jan 2006.
[27] J. Padhye, V. Firoiu, D. Towsley, J. Kurose. Modeling TCP Throughput: A simple
model and its empirical validation. Proc SIGCOMM. September 1998.
[28] S. Hassan, M. Kara. Simulation-based performance comparison of TCP-friendly
congestion control protocols. Proc. of the 16th Annual UK Performance Engineering
Workshop. Durham, UK. July 2000.
[29] B. Levine, N. Paul, J. Garcia_Luna_Aceves. Organizing multicast receivers
deterministically by packet-loss correlation. ACM Multimedia pp: 201-210. 1998.
[30] B. Levine, J. Garcia_Luna_Aceves. A comparison of reliable multicast protocols.
Multimedia Systems. August 1998.
[31] J. Rosenberg, H. Schulzrinne. An RTP Payload Format for Generic Forward Error
Correction. RFC 2733. December 1999.
[32] J. Vieron (J), C.Guillemot. Real_time constrained TCP-compatible rate control for
video over the internet. IEEE Tr. on Multimedia. 2002.
[33] Seong-ryong Kang, Dmitri Loguinov. Impact of FEC overhead on scalable video
streaming. International Workshop on Network and Operating System Support for
Digital Audio and Video ACM. New York, USA. 2005.
45

Wehbe Houssein

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Wehbe Houssein

Загружено:

Авторское право:

Доступные форматы

Amlioration des flux temps rel sur

Systmes, rseaux et architecture

Bernard COUSIN et Grard BABONNEAU

Je tiens remercier tout particulirement Grard BABONNEAU, pour mavoir intgr

Je remercie galement le personnel du laboratoire MAPS/DPC de France tlcom R&D pour

Chapitre 1 : tat de lart de la transmission sur Internet ............................................................... 11

2. Les protocoles de transmissions....................................................................................11

2.1 Les protocoles non adapts aux applications multimdia ...................................11

2.1.1 Le protocole TCP ...............................................................................11

2.1.2 Le protocole HTTP.............................................................................12

2.2 Les protocoles adapts aux applications multimdia ..........................................12

2.2.1 Le protocole UDP...............................................................................12

2.2.2 Le protocole RTP ...............................................................................13

2.2.3 Le protocole RTCP.............................................................................13

2.2.4 Le protocole RTSP .............................................................................14

2.3 Conclusion des protocoles .................................................................................15

3. Les mcanismes de contrle derreur ...........................................................................16

3.1 La rgulation du dbit .......................................................................................16

3.1.1 Cas point point.................................................................................17

3.1.2 Cas du multipoint ...............................................................................18

3.1.3 Conclusion sur la rgulation du dbit ..................................................19

3.2 Contrle derreurs par anticipation ....................................................................19

3.3 Contrle derreurs par retransmission ................................................................21

3.3.1 Mcanismes bass sur un accus de rception ....................................21

3.3.2 Mcanismes bass sur un accus de non rception .............................22

Chapitre 2 : La rparation par retransmission ................................................................................ 25

2. Description de la solution ............................................................................................25

2.1 Principe de fonctionnement ...............................................................................25

2.2 Exemple dutilisation des paramtres N et P ......................................................26

2.3 Le choix des paramtres ....................................................................................27

2.3.1 Les paramtres utiliss par lmetteur .................................................27

2.3.2 Les paramtres utiliss par le rcepteur...............................................29

2.3.3 Conclusion du choix des paramtres ...................................................31

3. Validation de la solution ..............................................................................................31

3.1 Les modles de perte utiliss .............................................................................32

3.1.1 La perte uniforme ...............................................................................32

3.1.2 La perte par rafale ..............................................................................32

3.2 Les simulations effectues .................................................................................33

3.2.1 Les simulations dans le cas du dbit constant (CBR) ..........................33

3.2.2 Les simulations dans le cas du dbit variable (VBR)...........................38

Figure 1 Reprsentation d'un systme de communication vido ..........................................8

Figure 5 Exemple de fonctionnement du modle avec N=6 ..............................................26

Figure 10 Le pourcentage des paquets perdus aprs la retransmission en fonction de

Figure 11 Le pourcentage des paquets perdus aprs la retransmission en fonction de

Figure 13 Le pourcentage des paquets perdus aprs la retransmission en fonction de

Figure 14 Le pourcentage des paquets perdus aprs la retransmission en fonction de

Figure 15 Le pourcentage des paquets perdus aprs la retransmission en fonction de

Figure 17 Le pourcentage des paquets perdus aprs la retransmission en fonction de

Figure 19 Changement du dbit d'mission entre 1 et 5 Mbs...............................................38

Figure 21 La capacit du modle corriger les pertes .........................................................40

Figure 22 Le pourcentage des paquets perdus aprs la retransmission en fonction de

On peut gnralement considrer quun systme de communication vido est constitu de

Figure 1: Reprsentation d'un systme de communication vido

Au niveau du rcepteur, on exploite la redondance pour reconstituer les informations perdues.

Lobjectif de ce stage est de concevoir un mcanisme de contrle derreurs capable dassurer

Nous prsenterons dans le chapitre 1 de ce document un tat de lart introductif sur la

Cette technologie de transmission sappelle streaming [19][20]. Elle permet de commencer

La plupart des programmes de streaming (ou de dowonload progressif ) existant sont

2. Les protocoles de transmissions

2.1 Les protocoles non adapts aux applications multimdia

2.1.1 Le protocole TCP

Transfert de donnes de base : TCP est capable de transfrer un flux continu de

Un grand avantage de TCP, dduise de ses fonctionnalits, rside dans la fiabilit de la

2.1.2 Le protocole HTTP

= +

+ =

&