Cheickna B.

A BADO FMP307- B2277

Quelles solutions pour la transmission vido sur
Internet?
Aot 2008
Mmoire de fin d'tudes.
Remerciements
Je voudrais exprimer toute ma gratitude au couple HUBIN (Jean-Franois HUBIN et Assita
HUBIN) qui m'a soutenu et aid durant ma formation. Ils m'ont suivi de prs et ils n'ont pas
hsit un instant me donner un coup de main quand cela tait ncessaire.
Je tiens remercier les superviseurs de la sae, Monsieur Thierry LECHIEN, Sep stigo film
(Gatan et Corentin pour leur sage direction et leurs aides) et Monsieur BURTON.
Je remercie aussi tous mes enseignants pour les informations qu'ils m'ont donnes pendant
cette anne.
Merci tous les tudiants de la section film de la Sae, Alessandro MARETTI, Claire
BUKASSA, Momo.
Enfm, un merci du fond du coeur tous ceux qui ont contribu de prs ou de loin
l'aboutissement de ce travail.
?
mes parents ...
3
TABLE DES MATIERES
INTRODUCTION __________________ 5
Chapitre 1 ETAT DE L'ART
Introduction _________________________ 7
1.1- Calcul de la bande passante alloue au flux 7
1.1.1- Calcul du taux de perte 7
1.1.2- Calcul du RTT 7
1.2- Scalabilit 8
1.3- Htrognit des rcepteurs 11
1.4- Conclusion 15
Chapitre 2 ___ UNE SOLUTION A LA TRANSMISSION MUL TIPOINT
Introduction 16
2.1- Real Time Transport Protocol (R TP) 16
2.1.1- RTP Data Transfer Protocol 16
2.1.2- RTP Control Protocol (RTCP) 17
2.2- Organisation des agrgateurs dans le rseau 18
2.3- Classification des rcepteurs 19
2.3.1- Prliminaires 19
2.3.2- Algorithme de classification des agrgateurs 21
2.4- Travail existant 22
2.5- Travail du stage 22
2.5.1- Calcul du RTT 22
2.5.2- Dtection et rsolution des collisions des SSRC et CNAME. _______ 26
2.5.3- Synchronisation des abonnements aux couches Goin and leave). ______ 26
2.6- Rsultats attendus 27
2.7- Conclusion 28
CONCLUSION .......................................... . ........................... 29
J J I J J ~ I ( ) ( ; ~ I I I ~ ................................... .............................................. 30
INTRODUCTION
La transmission vido mme en point point sur Internet n'assure aucune garantie au niveau
de la perte, de la bande passante et du dlai reprsente un grand challenge, d'o la ncessit
d'utiliser des protocoles de contrle qui adaptent l'application l'tat du rseau.
La principale difficult pour adapter l'application aux conditions du rseau est due
l'htrognit des rcepteurs, la source, pour qu'elle puisse adapter son dbit en fonction de
l'tat du rseau, a besoin des informations autour les tats de rception des rcepteurs dans la
session.
Par la suite, chaque rcepteur doit envoyer un rapport de rception la source dans lequel il
indique sa bande passante disponible et son taux de perte.
Le rcepteur peut calculer facilement son taux de perte, il suffit qu'il surveille la rception du
flux de donnes sur une certaine priode.
La majorit des trafics sur Internet sont des trafics TCP, ds lors, le modle utilis par
l'application pour calculer la bande passante disponible dans le rseau doit tre quitable avec
les autres trafics TCP sur Internet.
Les modles TCP sont souvent utiliss, ils allouent au flux de donnes la mme bande
passante alloue avec le protocole TCP pour ce mme flux de donnes dans les mmes
conditions due taux de perte et due dlai.
Avec les modles TCP, la bande passante disponible du rcepteur est calcule en fonction de
son taux de perte et le temps aller retour (RTT) entre lui et la source.
La solution la plus simple pour calculer le RTT entre les rcepteurs et la source, est que
chaque rcepteur envoie un paquet de contrle la source, et le RTT sera calcul comme tant
le temps coul entre le temps d'mission du paquet la source par le rcepteur, et la
rception de l'acquittement correspondant de la source.
Cette solution est applicable pour les sessions avec un seul rcepteur ou avec un nombre trs
petit de rcepteurs, mais pour une session avec un grand nombre des rcepteurs, cette solution
prsente un problme de scalabilit et gaspillage de la bande passante du rseau.
Par la suite, les rapports de rception des rcepteurs gaspille de la bande passante dans le
rseau et peuvent causer une congestion dans le rseau et un problme de scalabilit, surtout
dans le cas des sessions avec un grand nombre des rcepteurs.
Dans ce mmoire, je dresse en dtail tous les problmes de la transmission vido multipoint
sur Internet, et les solutions proposes, ainsi qu'une prsente solution qui assure une
adaptation du dbit de la source, et en mme temps, qui ne prsente pas un problme de
scalabilit des rapports de rception, ni un gaspillage de la bande passante dans le rseau.
Dans le chapitre suivant, je dtaille ces problmes et quelques solutions proposes.
Dans le chapitre 2, je prsente le protocole de transport RTP, et en dtaille l'approche
prsente dans [12, 13] qui prsente une solution la transmission multipoint.
L'approche propose la transmission des donnes en plusieurs couches et chaque rcepteur
value sa bande passante disponible et choisit les couches joindre.
Dans ce travail, est implment un algorithme de calcul de RTT entre les rcepteurs et la
source propos dans notre approche.
Cet algorithme sert calculer les bandes passantes TCP-Friendly des rcepteurs [18]. Les flux
vido ont besoin d'un protocole de contrle de congestion qui vite les variations brusques de
dbit, (ce qui n'est pas le cas pour le TCP). En mme temps, ce protocole de contrle doit tre
quitable au niveau de la bande passante en comparaison avec les autres protocoles de
contrle.
Or, la majorit du trafic Internet est du trafic TCP, donc le protocole utilis doit allouer au
flux vido (sur un intervalle du temps, qui peut tre long), la mme bande passante que TCP
alloue ce mme flux, sous les mmes conditions du rseau, avec le mme taux de perte et le
mme temps aller retour (RTT).
L'intrt du calcul de la bande passante TCP-Friendly des rcepteurs est qu'on peut adapter le
dbit de l' application aux capacits disponibles dans le rseau, en vitant les variations
brusques de dbit, ainsi qu'on assure un partage quitable de la bande passante du rseau
entre les diffrentes applications, ce qui peut rpondre aux besoins des applications vidos sur
Internet.
CHAPITRE!
ETAT DE L'ART
Introduction :
La transmission vido multipoint sur Internet vers des rcepteurs htrognes est
problmatique. Elle ncessite des algorithmes adaptatifs pour d'une part, lutter contre la perte
de paquets sur Internet, et d'autre part, adapter le dbit de rception des flots vido aux
caractristiques de chaque rcepteur.
Pour que la source puisse adapter le dbit du flux de donnes aux caractristiques des
rcepteurs, les rcepteurs doivent envoyer la source des rapports de rception dans lesquels
ils indiquent leurs bandes passantes disponibles et leurs taux de perte moyens.
D'autre part, les flux vido ont besoin d'un protocole de contrle de congestion qui vite les
variations brusques de dbit, (c'est qui n'est pas le cas pour le TCP). En mme temps, ce
protocole de contrle doit tre quitable au niveau de la bande passante en comparaison avec
les autres protocoles de contrle.
Or, la majorit du trafic Internet est du trafic TCP, donc le protocole utilis doit allouer au
flux vido (sur un intervalle du temps, qui peut tre long), la mme bande passante que TCP
alloue a ce mme flux, sous les mmes conditions du rseau, avec le mme taux de perte et le
mme temps aller retour (RTT).
L'intrt de l'utilisation d'un protocole de contrle qui calcule la bande passante disponible
un flux de donnes est majeur.
Un flux de donnes qui est transmit sans aucun contrle de dbit, peut affecter les flux de
donnes transmis avec dbits contrls. Dans le cas o une congestion apparat dans le rseau,
tous les flux contrls diminuent leurs dbits, et les flux sans contrle continuent mettre
avec leurs mme dbit, en ignorant l'tat de congestion prsent, ce qui peut conduire des
congestion de large dure, ainsi qu'ils peuvent dominer la bande passante disponible dans le
rseau.
Pour rcapituler, les problmes principaux de la transmission vido multipoint sur Internet,
sont les suivants :
1- Le calcul de la bande passante alloue au flux.
2- Le problme de scalabilit des rapports de rception des rcepteurs.
3- L'htrognit des rcepteurs dus leurs tats de rception diffrents.
1.1- Le calcul de la bande passante alloue au flux:
Pour des raisons d'quit avec le trafic Internet, qui est en majorit, compos de flots TCP,
l'algorithme utilis peut calculer la bande passante alloue au flux vido, avec un modle TCP
[18], en fonction du taux de perte et du RTT.
1.1.1 Calcul du taux de perte:
Le calcul du taux de perte ne pose aucun problme, il suffit de surveiller la rception des
paquets de donnes par le rcepteur lui-mme, et l'aide du numro de squence de chaque
paquet, le rcepteur peut arriver facilement calculer son taux de perte.
1.1.2 Calcul du RTT :
La mthode la plus simple pour calculer le RTT, est que l'un des deux extrmes (la source ou
le rcepteur), envoie un message l'autre extrme. Le RTT est gal deux fois la diffrence
entre l'instant de rception de ce message et son instant d'mission.
7
Mais cette mthode ncessite des horloges synchronises entre les deux extrmes. D'autre
part, en ralit les rseaux sont souvent asymtriques, et dans ce cas, le temps d'aller n'est pas
le mme que le temps de retour, ce qui rend le calcul du RTT imprcis.
Une solution possible, est que l'un des deux extrmes envoie un message en mmorisant son
instant d'mission, et que l'autre rpond avec un acquittement dans lequel est indiqu le Tdlsr,
qui est la diffrence( en valeur absolue) entre l'instant de rception du message, et l'instant de
gnration de l'acquittement correspondant.
Le R TT est gal :
RTT = Trception de l'acquittement- Tmission du message- Tdlsr. q. (a)
Avec Tdlsr = 1 Trception du message- Tmission de l'acquittement correspondant 1
....---->-----. _1
~ '
/
Fig. 1.1 Schma reprsentant les diffrents paramtres dans le calcul de RTT.
Avec cette mthode, tous les rcepteurs doivent changer des messages de contrle avec la
source.
Ces messages envoys par les rcepteurs prsentent un problme de scalabilit et un
gaspillage de la bande passante du rseau et surtout dans le cas de sessions avec un grand
nombre de rcepteurs.
1.2 Scalabilit :
Au passage l'chelle, la scalabilit est un paramtre trs important qu'il faut prendre en
compte lors de l'implmentation d'un algorithme ou d'une discipline.
Dans notre cas, le calcul du RTT prsente un problme de scalabilit des rapports des
rcepteurs.
De nombreux algorithmes ont t proposs pour rsoudre le problme de rapports de
rcepteurs [ 1 ,2] .
[1] prsente un algorithme propos par Anindya Basu, S.Jamaloddin Golestani, mais avec une
hypothse forte, sur la distribution de rcepteurs dans le rseau.
8
Comme la montre la figure 1.2, les rcepteurs se distribuent dans le rseau sous la forme d'un
arbre.
Avec cet algorithme, la source diffuse un message, et le RTT pour chaque rcepteur est
calcul comme tant le temps coul entre la diffusion de ce message, et l'instant de rception
par la source de l'acquittement correspondant du rcepteur.
L'algorithme propose une mthode qui permet chaque rcepteur de calculer facilement les
RTT entre lui et chacun de ses fils (RTT diffrentiel).
Le rcepteur, aprs la rception d'un acquittement de son fils, calcule le RTT diffrentiel de ce
dernier.
Priodiquement, chaque rcepteur envoie un acquittement agrg au rcepteur de niveau
suprieur dont lequel il indique le R TT diffrentiel de chaque rcepteur duquel il a reu un
acquittement.
La manire de distribution des rcepteurs dans le rseau, prsente en mme temps le point fort
et le point faible de cet algorithme.
D'une part, cette distribution assure la fusion des acquittements des rcepteurs, ce qui vite le
problme de scalabilit de ces acquittements.
De l'autre part, avec une autre distribution des rcepteurs, par exemple des rcepteurs
distribus dans le rseau comme des feuilles, la fusion des acquittements des rcepteurs
devient inefficace, par suite, on aura un problme de scalabilit de ces acquittements.
Ainsi que chaque rcepteur envoie son acquittement au rcepteur de niveau suprieur (ou la
source s'il est en face d'elle), et ce dernier attend un certain temps avant l'mission de son
acquittement agrg au rcepteur de niveau suprieur (ou la source), et ainsi de suite
jusqu'au l'arrive la source, donc, on a un retard ajout au temps ncessaire pour que
l'acquittement du rcepteur arrive la source, ce qui rend le calcul des RTT des rcepteurs
imprcis.
------li
9
Fig. 1.2 La distribution des rcepteurs dans le rseau
[2] prsente une solution propose par T.Turletti, J.Bolot et I.Wakeman, avec laquelle, chaque
rcepteur envoie son rapport avec une probabilit qui est fonction du nombre de rcepteurs.
Aussi, une autre solution efficace au problme de scalabilit, est l'utilisation des agrgateurs
au sein du rseau [10,11].
Les agrgateurs se distribuent dans le rseau sous la forme d'un arbre, dont les feuille les
s'appellent des agrgateurs feuilles, et la racine, l'agrgateurs final.
Le rle de ces agrgateurs, est d'agrger les rapports des rcepteurs, et de les fusionner en un
seul rapport. Plusieurs paramtres sont pris en compte dans cette opration de fusion.
Un agrgateur feuille est lu pour chaque groupe des rcepteurs qui se trouvent dans une
mme rgion locale.
Chaque rcepteur envoie son rapport son agrgateur feuille, et ce dernier, chaque fois, il
reoit un rapport d'un rcepteur, il fusionne avec les autres, et envoie un rapport fmal
l'agrgateur de niveau suprieur, et ainsi de suite, jusqu'au l'arrive agrgateur final, qui
dlivre la source un rapport final agrg.
Avec cette solution, tous les rcepteurs peuvent envoyer leurs acquittements, et le nombre
d'agrgateurs est fonction du nombre de rcepteurs.
10
Fig. 1.3 La distribution des agrgateurs dans le rseau
1.3- L'Htrognit des rcepteurs:
Les solutions proposes pour le problme d'htrognit des rcepteurs sont nombreuses.
Les deux approches, MTCP [3] et RMTP [4] utilisent une fentre de congestion, comme TCP.
Avec ceux-ci, la fentre n'augmente que si la source reoit les acquittements de tous les
rcepteurs.
En plus, ces deux approches, utilisent les mmes protocoles que le TCP pour l'augmentation
ou la diminution de la fentre.
Avec ces approches, la source adapte son dbit selon l'tat du rcepteur le plus mdiocre du
groupe des rcepteurs, et par suite, ne prsentent pas une solution efficace au problme
d'htrognit. Aussi, ils utilisent une architecture complexe pour l'agrgation des
acquittements.
Une autre solution est la transmission de donnes en multicouches.
Avec cette solution, la source met les donnes en plusieurs couches, une couche de base, et
des couches supplmentaires, et chaque rcepteur, aprs l'valuation de sa bande passante
disponible, choisit les couches a joindre.
Dans la couche de base, la source met les donnes ncessaires pour une rception avec une
qualit minimale, et dans les couches supplmentaires, elle envoie le reste des donnes pour
augmenter la qualit de rception.
Chaque rcepteur s'abonne la couche de base, et si sa bande passante le permet, il s'abonne
aux couches supplmentaires, pour amliorer la qualit du flux qu'il reoit.
Cette opration d'abonnement est dtaille dans le chapitre suivant.
La source affecte chaque couche un niveau de protection, et la couche de base est la plus
importante. Cette protection dpend de l'algorithme utilis, soit en affectant chaque couche,
un niveau de priorit (et dans ce cas, le nombre maximal de couches gnres doit tre
infrieur ou gal au nombre maximal de niveaux de priorits que le rseau puisse supporter),
soit en envoyant les donnes avec redondance.
Ces couches peuvent tre statiques, c'est dire sont fixes en nombre et dbit, ou bien
dynamiques, qui sont variables, en fonction de l'tat du rseau.
Dans le premier cas, la source fixe, au dbut de la transmission, le nombre de couches et le
dbit de chaque couche.
Dans le cas des couches dynamiques, chaque rcepteur, envoie son rapport, en indiquant son
taux de perte, et sa bande passante disponible, et selon ces rapports, la source adapte le
nombre de couches et le dbit de chacune.
Avec cette solution, mme le dbit de la couche de base peut tre variable. Dans le cas o la
bande passante la plus faible dans le groupe de rcepteurs, est plus grande que le dbit de
cette couche de base, la source peut rgler le dbit de cette couche la valeur de la bande
passante minimale.
Dans le cas des couches dynamiques, et comme dans le calcul du RTT, les rapports des
rcepteurs prsentent un problme de scalabilit.
Mais l'avantage de cette solution, est qu'elle reflte toujours l'tat du rseau, ce qui n'est pas le
cas avec les couches statiques.
La source, avec des messages de contrle, transmet des informations concernant les couches,
nombre, dbit et adresse de chacune.
Les oprations "join and leave" qui permettent aux rcepteurs de joindre ou quitter une telle
couche, sont synchronises avec des messages envoys par la source (ces oprations sont
dtailles dans le chapitre suivant).
11
Le routeur, parmi les couches qu'il reoit, ne laisse passer que celles rclames par les
rcepteurs ce qui prsente une conomie de la bande passante utilise.
Vicisano L. Rizzo et J. Crowcroft [5], prsentent une approche avec une transmission de
donnes en un nombre de couches statiques, et chaque rcepteur, aprs l'estimation de son
taux de perte, dcide de son abonnement aux couches.
Les inconvnients de ce mcanisme, est qu'il utilise des couches statiques, et que le calcul de
la bande passante du rcepteur se fait en fonction du taux de perte uniquement, sans prendre
en compte son RTT entre lui et la source.
PLM ( packet pair receiver-driven layered multicast)[6] est bas sur une transmission de
donnes en multicouches, dont le nombre est fixe, ainsi que le dbit de chacune.
Avec cette approche, la source met deux paquets conscutifs, en indiquant dans leurs enttes
que ces sont des paquets de contrle, et le rcepteur, en fonction du temps coul entre la
rception de ces deux paquets, dtermine sa bande passante disponible et s'abonne aux
couches adquates.
Cette mthode permet d'viter le problme des rapports des rcepteurs, mais elle ncessite que
les routeurs utilisent une discipline quitable pour servir les paquets dans les files d'attentes,
car sinon, le temps coul entre la rception de ces deux paquets, ne sera plus proportionnel
la bande passante disponible.
T. Jiang, E. Zegura and M. Ammar[7] prsentent un mcanisme avec lequel, la source met
une couche de base dont le dbit est fixe, et des couches supplmentaires avec des dbits
variables. Ces dbits sont calculs en fonction des rapports de rcepteurs, qui valuent leurs
bandes passantes disponibles en fonction du taux de perte et ne prennent pas en compte leurs
RTT.
Aussi, cette approche, ne propose pas de solution pour viter la saturation du rseau avec les
rapports de rcepteurs.
Cheung, Ammar et Li [8], prsentent une solution, qui consiste dcomposer le groupe de
rcepteurs en sous-groupes. Vers chacun de ces sous-groupes, la source met les donnes avec
un dbit qui est calcul en fonction des rapports des rcepteurs du sous-groupe correspondant.
Une autre solution est prsente dans [9], avec laquelle la source met une seule couche avec
un dbit maximal.
Chaque noeud intermdiaire, quand elle reoit cette couche de donnes, calcule la bande
passante disponible entre lui et les noeud prochain et/ou les rcepteurs.
Puis, vers chacun des noeuds prochains et/ou les rcepteurs, le noeud intermdiaire transfre
la couche de donnes avec un dbit adapt la valeur correspondante de la bande passante
disponible.
Notons que cette solution a l'inconvnient de demander une architecture complexe des
routeurs.
[10] prsente deux approches qui adressent le problme d'htrognit des rcepteurs, et qui
permettent la source d'adapter dynamiquement son dbit en fonction de l'tat du rseau. Ces
deux approches sont cites ci-dessous :
a- Network-Based SAMM [10]: elle ncessite la contribution de noeuds intermdiaires pour
calculer la bande passante disponible sans perte qui peut tre alloue ce flux.
Pour cela, il est ncessaire d'implmenter dans les routeurs un algorithme, qui, en surveillant
les flux qui le traversent, calcule la bande passante totale alloue aux flux vido, ainsi que
celle de chacun d'eux.
La source met plusieurs couches de donnes, et pour chaque n paquets de donnes (n autour
32), elle met un paquet de contrle, dans lequel elle indiquant le nombre maximal de couches
qu'elle peut gnrer.
12
Dans ce paquet de contrle, la source fixe le champ RE la valeur du dbit maximum voulu,
qui est la somme des dbits de toutes les couches.
Le routeur, aprs la rception de ce paquet, calcule la bande passante disponible sans perte de
paquets qui le traversent, en fonction du taux de perte pendant l'intervalle du temps coul
entre la rception de ce nouveau paquet de contrle et le paquet prcdent.
Aprs, il affecte RE le minimum entre la valeur de la bande passante disponible calcule, et
la valeur courante de RE.
Le rcepteur, quand il reoit ce paquet, rpond avec un acquittement, en indiquant la valeur de
RE, qui reprsente sa bande passante disponible sans perte.
Cet approche, rsout le problme de scalabilit des acquittements, en implmentant des
agrgateurs dans le rseau.
La source, selon l'acquittement final agrg, adapte le nombre de couches et le dbit de
chaque couche.
b- End-to-End SAMM [10]: trs simple, il consiste une valuation des bandes passantes
disponibles aux rcepteurs, en surveillant la rception des paquets, ce qui vite de gaspiller de
la bande passante dans le rseau avec les paquets de contrle de la source.
Le rcepteur, en valuant le taux de perte des paquets de donnes, peut valuer si le dbit avec
lequel il reoit est infrieur ou suprieur que sa bande passante disponible.
La source adapte le nombre de couches et le dbit de groupe, en fonction des rapports de
rcepteurs. Aussi, cette approche utilise des agrgateurs, pour fusionner les acquittements de
rcepteurs.
Avec ces deux approches, le rcepteur calcule sa bande passante disponible sans perte, ce
qui prsente deux inconvnients :
Or la majorit du trafic Internet est un trafic TCP, par suite le calcul de la bande passante
disponible sans perte du rcepteur n'alloue pas ce rcepteur la mme bande passante alloue
avec un modle TCP [18] dans les mmes conditions du rseau, avec le mme taux de perte et
le mme RTT, ce qui rend le partage de la bande disponible dans le rseau entre les
diffrentes applications inquitable.
Le deuxime inconvnient est que les applications vidos ont besoin d'un protocole de
contrle qui vite les variations brusques de la bande passante disponible dans le rseau.
Le calcul de la bande passante disponible sans perte du rcepteur se fait la rception en
comptant le nombre des paquets reus pendant une priode T.
Ainsi, la prsence d'une congestion dans le rseau, la bande passante disponible sans perte
du rcepteur se diminue rapidement, et dans le cas o la congestion disparut, cette bande
passante augmente rapidement, par suite, on a une variation brusque dans la bande passante
disponible de l'application dans le rseau.
Les modles TCP sont utiliss pour viter cette variation brusque du dbit, ainsi que pour
avoir un partage quitable de la bande passante disponible dans le rseau entre les diffrentes
applications.
Notons que la premire approche demande une architecture complexe des routeurs.
MLDA [11]: est une approche qui adresse le problme d'htrognit de rcepteurs, en
proposant un algorithme pour calculer le RTT entre les rcepteurs et la source.
La transmission des donnes se fait en un nombre dynamique des couches. A l'aide des
rapports de rception des rcepteurs, la source adapte son dbit.
La source met priodiquement des messages de contrle (SR), en indiquant le nombre de
couches, le dbit et l'adresse de groupe.
13
Chaque rcepteur, aprs la rception du message SR, commence surveiller la rception de
paquets de donnes sur chaque couche sur une certaine priode (TO pour la couche de base,
Tl pour la premire couche supplmentaire, etc.).
Apres le calcul de son RTT, le rcepteur calcule sa bande passante disponible, attend un dlai
alatoire, et diffuse son rapport (RR) la source dans la couche la plus leve laquelle ce
rcepteur s'est abonn.
Les rcepteurs qui se trouvent dans une mme rgion locale reoivent le message SR presque
en mme temps.
Pour viter la congestion dans les files d'attentes de la source avec les rapports de rception
des rcepteurs, qui peut conduire une perte de rapports, chaque rcepteur attend un dlai
alatoire avant l'mission de son rapport. Pendant ce dlai alatoire, le rcepteur coute le port
correspondant sa couche la plus leve, et s'il reoit un RR d'un autre rcepteur qui demande
cette mme couche, il dtruit son rapport cet algorithme s'appelle suppression partielle, et il
prsente une solution efficace pour rsoudre le problme de scalabilit des rapports de
rcepteurs.
La source, avant d'mettre chaque SR, calcule le Tdlsr de chaque rapport de rcepteur reu
dans la priode coule entre l'instant du dernier SR, et l'instant d'mission de ce SR.
Sous forme de rponse aux RR de rcepteurs, la source introduit dans son message SR des
nouveaux champs contenant le Tdlsr d'un RR reu, et l'identit du rcepteur correspondant.
Pour les autres rcepteurs qui ont dtruit leurs rapports, la solution est la suivante :
Dans un rseau idal (avec des horloges synchronises et sans asymtrie), le RTT est gal
deux fois la diffrence (en valeur absolue), entre l'instant de rception du message de l'une des
deux extrmits, et l'instant d'mission de ce mme message de l'autre extrmit, donc:
RTT/2 =Trec- Tem (1)
Pour compenser la dsynchronisation d'horloges, on ajoute le p a r a m t r ~ et le paramtre pour
compenser l'asymtrie du rseau, et l'quation (1) devient:
RTT/2 =Trec- Tem + ft):rT- {z-) .
Supposons = f) :::- rr- )
donc : =Trec- Tem- RTT/2 (3).
La source inclut dans chaque message SR l'instant d'mission de ce message.
Le rcepteur, aprs la rception du message SR de la source, pour pouvoir calculer son
RTT entre lui et la source, il a besoin de calculer la valeur de e.
Chaque rcepteur qui obtient une rponse dans le message SR de la source, calcule son
RIT selon l'quation (a). Ensuite, il calcule la valeur delavee l'quation (3) et annonce aux
autres rcepteur cette valeur. Pour cela, il diffuse un message, avec un ttl (temps de vie)
faible, en indiquant la valeur de 8 . Avec un faible ttl, ce message n'atteint que les rcepteurs
locaux. Appelons ce rcepteur, Rs.
A prsent, chaque rcepteur qui a dtruit son RR, change des paquets de contrle avec un
rcepteur Rs local pour calculer le RTT entre lui et la source.
Aprs la rception du message de Rs, dans laquelle )e Rs indique sa valeur de le rcepteur
envoie son Rs un message (appel demande deJ'dont lequel il indique son identit, et il
mmorise son instant d'mission. d
Le Rs chaque fois il reoit une demande de/d'un rcepteur, il rpond avec un message (appel
rponse duRs) dont lequel il indique l'identit du rcepteur et le Tdlsr de sa demande de B.
A la rception de la rponse du Rs, le rcepteur calcule le R TT entre lui et ,.;;on Rs, puis, il /?
calcule son local avec ce dernier, et par suite, la valeur de 8 sera la somme du"local et du-Rs. fJ du s
L'intrt de cette approche, est qu'elle adresse savoir les problmes d'htrognit des
rcepteurs et de scalabilit des rapports de rception. Elle prsente aussi un algorithme pour
calculer les R TT des rcepteurs.
14
1.4- Conclusion :
Pour rcapituler les principaux problmes de la transmission multipoint vido sur l'Internet, et
des solutions proposes, il faut noter que l'htrognit des rcepteurs, et la scalabilit des
rapports de rception reprsentent un grand chalenge, d'o la ncessit d'un algorithme qui
adresse ces deux problmes, et ne gaspille pas de la bande passante dans le rseau avec les
paquets de contrle.
Dans le chapitre suivant, le protocole de transport RTP, ainsi qu'un algorithme propos dans
[12, 13] qui prsente une solution tous les problmes cits ci-dessus.
15
CHAPITRE II
UNE SOLUTION A LA TRANSMISSION MUL TIPOINT
Introduction:
L'tude du chapitre prcdent amne conclure de la ncessit d'un algorithme qui adresse
les principaux problmes de la transmission multipoint, savoir, l'htrognit des
rcepteurs ainsi que la scalabilit d'mission des rapports de ces derniers, et en mme temps,
d'viter de gaspiller de la bande passante dans le rseau avec les paquets de contrle.
Dans ce chapitre, une solution de contrle de transmission multipoint propose dans [12] et
[13].
L'approche consiste utiliser une transmission des donnes avec un nombre de couches
dynamiques pour rsoudre le problme d'htrognit des rcepteurs. Cette approche utilise
des agrgateurs pour rsoudre le problme de scalabilit d l'mission des rapports des
rcepteurs, ainsi qu'une mthode qui permet de calculer le R TT entre les rcepteurs et la
source.
Cette approche utilise le protocole RTP pour transfrer les paquets de donnes et de contrle
(RTCP).
Dans la section 2.1 le protocole R TP. La section 2.2 adresse plusieurs mthodes pour
l'organisation des agrgateurs dans le rseau. Dans la section 2.3, on prsente l'algorithme
utilis pour la classification des rcepteurs.
La section 2.4 prsente le travail dj fait au niveau de l'implmentation de cette approche.
Dans la section 2.6, les rsultats attendus aprs la fin de l'implmentation du programme, et
une conclusion est prsente dans la section 2. 7.
2.1- Real Time Transport Protocol (RTP):
RTP est un protocole de transport en temps rel qui est conu pour satisfaire les besoins des
applications multimdia sur internet.
RTP est utilis juste au dessus du protocole UDP, et on distingue, le protocole de transfert des
donnes RTP du protocole de contrle associ RTCP.
2.1.1- RTP Data Transfer Protocol :
Un paquet de donne est dcompos d'une entte et d'un champ de donne.
L'entte elle mme est dcompose en deux partie, une partie fixe (entte fixe) de douze
octets, qui est commune entre toutes les applications qui utilisent RTP, et une entte
supplmentaire qui est fonction de l'application considre.
Dans l'entte du paquet de donne, la source transmet toutes les informations ncessaires pour
le traitement de ce paquet, savoir, le type, la taille des donnes, le numro de squence de ce
paquet, l'identit de la source (SSRC) ou la liste des sources (CSRC liste) dans le cas o
plusieurs sources ont contribu ce paquet de donne, etc.
16
2.1.2- RTP Control Protocol (RTCP):
RTCP est bas sur la transmission priodique des paquets de contrle tous les participants
la session, et sa fonction principale est d'obtenir des rapports de rception des flux vido. Il y
a cinq types de messages RTCP:
1- SR (Sender Report):
C'est le rapport (ou le message de contrle) de la source qui contient des informations
concernant les donnes envoyes par cette source, et des statistiques sur la rception des flux
envoys par les autres sources dans le cas d'une session plusieurs sources.
2- RR (Receiver Report):
C'est le rapport de rception des rcepteurs, dans lequel le rcepteur indique son tat de
rception (sa bande passante disponible et son taux de perte). Dans le cas d'une session
plusieurs sources, ce rapport peut contenir des statistiques sur la rception d'au plus 31
sources.
3- SDES (Source description RTCP packet):
Le protocole RTP identifie chaque lment de la session indpendamment des couches
infrieures, pour cela, il affecte ceux-ci plusieurs identificateurs qui sont le
SSRC, CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE et PRIV.
Ces identificateurs sont choisis alatoirement, et les deux premiers (SSRC et CNAME)
doivent tre unique sur toute la session, d'o la ncessit d'utiliser des algorithmes pour la
dtection et la correction des collisions.
Chaque lment de la session (source ou rcepteur) transmet ces identificateurs dans un
paquet SDES, chaque fois qu'il transmet un rapport, donc chaque SR ou RR est suivi d'un
paquet SDES.
Notons que ces identificateurs sont affects chaque fois que l'on lance l'application.
Dans le cas o la source met plusieurs types de donnes, par exemple, un flux audio et un
flux vido, un mme paquet ne peut pas transporter ces diffrents types. Dans ce cas, RTP
affecte la session des identificateurs SSRC pour chaque application, condition que le
SSRC de chaque lment (source ou rcepteur) soit nouveau pour chaque application.
Afin d'un seul CNAME est affect chaque lment de la session pour toutes les applications,
permettre aux diffrents lments de synchroniser les flux reus. D'o la raison de l'utilisation
de plusieurs identificateurs et non pas un seul.
4- BYE:
Chaque lment de la session doit envoyer ce paquet pour indiquer la fm de sa contribution
la session.
5- APP:
Dans le cas des applications spcifiques, les donnes peuvent tre transmises dans des paquets
spcifiques de type APP. Ce paquet consiste en une entte de 12 octets et un champ de
donnes qui est fonction de l'application considre.
Le format de ce paquet APP est reprsent dans le schma ci -dessous :
17
-
011 1 L- "f C
.r - + -+ 2 6 -r 6 ) V A z "?. 1, :)
6
::t .'7 "'
1 -r -+-+- :: -+- 4- ...,
1
[}A 2 3
\1-::. "Z.. I '?l J n= 4-?P:=:- - + +- +,ol'79.rir .!:z_ !_ 1. l? c,
t - + -+ - - + - f- - + - f _ + _ + - vH:-, t
t Ss R cf cs R<' + +- - .J- - -+ - + -+
+ + +--t--+-+-+-+-+-+-+-+ + +- ,
1 ( + +
+ - -+ + -+ - + - + -+ - + - + - t - f- - + - + -t - +
1 p--C; ut - iJ.c;enoi'cn . . ..
-t -+--+- -t--+-+-+-+-+-+-+-+- -1- +--t.-.+
Fig.2.1 Format du APP
Plus de dtails concernant le protocole RTP et le rle de chaque champ de ces paquets sont
prsents dans [ 14]
2.2- Organisation des agrgateurs dans le rseau :
La figure ci-dessous (Fig. 2.2) reprsente un exemple d'implmentation hirarchique multi
niveau des agrgateurs dans le rseau. Les agrgateurs sont distribus sous la forme d'un arbre
dont la racine est le AAO (Agrgateur final), et AAi reprsente un agrgateur de niveau i. Les
agrgateurs de niveau le plus bas s'appellent agrgateurs feuilles.
Chaque rgion contient un agrgateur feuille qui fusionne les rapports des rcepteurs qui y
appartient, et l'envoie l'agrgateur de niveau suprieur.
Le rapport final agrg contient le nombre des rcepteurs dans chaque classe.
Les agrgateurs peuvent tre placs manuellement, ou automatiquement en utilisant des
fonctions qui s'occupent de lancer des agrgateurs dans le rseau.
[15] prsente une mthode de placement automatique des agrgateurs dans le rseau.
Cette mthode consiste implmenter une fonction en utilisant le custom concast. Le custom
concast est une application qui permet de dterminer une adresse destination pour un groupe
de sources.
Chaque groupe de rcepteurs applique cette fonction ou cette application pour choisir un
agrgateur feuille, et chaque groupe des agrgateurs feuilles applique cette fonction pour
choisir un agrgateur de niveau suprieur, et ainsi de suite jusqu'au le choix de l'agrgateur
final.
Le datagramme du custom concast contient un ensemble des groupes de sources et une
destination unique pour chacun de ces groupes.
18
Fig. 2.2 Utilisation hirarchique multi niveau des agrgateurs
Chaque rcepteur envoie son rapport l'adresse destination du groupe auquel il appartient, et
la source reoit un seul rapport final agrg.
La signalisation dans cet algorithme permet l'application d'avoir des informations
concernant la configuration du rseau, pour pouvoir dcomposer le groupe des rcepteurs en
sous-groupes, et dterminer les adresses des destinations correspondantes.
Une autre mthode est prsente dans [16], qui consiste utiliser dans le rseau plusieurs
noeuds actifs appel cluster (not AS 1 ).
Dans cet algorithme, les rcepteurs ragissent comme des clients qui lancent des Agents
(agrgateurs) dans des positions stratgiques dans le rseau.
Avant que le client (rcepteur) lance un Agent dans le rseau, il coute le rseau pour recevoir
des informations qui lui permettent d'effectuer un rendez-vous avec un nud actif. Ces
informations peuvent tre obtenues en coutant une adresse multipoint connue, ou en utilisant
le DHCP dcrit dans [17].
Une fois le client a affect un rendez-vous avec un AS 1, il lance son Agent.
AS 1 implmente un protocole de contrle (ASCP) qui utilise un HM (Home Manager).
Ce dernier reoit les demandes des agents des rcepteurs, et choisit un Agent principal et des
agents secondaires pour remplacer l'agent principal dans le cas o ce dernier tombe en panne.
Dans le cas o un rcepteur tombe en panne, le rcepteur est annul de la liste des rcepteurs,
et la mme chose pour son Agent.
Notons que dans les deux cas, les agrgateurs participent seulement aux flux RTCP et non pas
aux flux des donnes ou de contrle.
2.3- Classification des rcepteurs :
2.3.1- Prliminaires :
La classification des rcepteurs sert regrouper les rcepteurs homognes dans une mme
classe, pour laquelle la source prend les mmes dcisions d'adaptation. Cette classification ne
19
doit pas se faire seulement en fonction des rapports des rcepteurs actuels, mais elle doit
prendre en compte les rapports rcents du pass. Dans ce cas, une procdure doit tre ajoute
pour oublier les rapports trs anciens.
Avant de dcrire les mthodes utilises pour classifier les rcepteurs, il faut citer les
paramtres qui sont pris souvent en compte lors de la classification.
Parmi ces paramtres, le taux de perte et la bande passante disponible des rcepteurs.
Le taux de perte permet la source de dterminer le niveau de protection ncessaire pour
chaque couche, et il peut tre calcul en surveillant la rception du flux de donne sur un
intervalle de temps.
La bande passante disponible est utilise par la source pour adapter les dbits des diffrentes
couches. Dans le cas o l'on calcule les bandes passantes disponibles des rcepteurs avec une
quation TCP, qui utilise un modle de TCP (18], un algorithme scalable doit tre utilis pour
calculer les RTT entre les rcepteurs et la source. L'quation TCP utilise dans notre
approche est la suivante:
BW = S/[R*(2*p/3)2 + tRTo*(3*(3P/8)2)*P*(1 + 32P2)] (1)
O S est la taille moyenne des paquets de donnes en bytes estime par le rcepteur, Rest la
valeur du RTT en secondes entre le rcepteur et la source calcule en secondes.
pest le taux de perte moyen du rcepteur compris entre 0 et 1. tRTo(en secondes)= 4*R.
Dans une session avec une seule source et un seul rcepteur, le rcepteur envoie un
acquittement pour chaque paquet de donnes ou pour un groupe de paquets selon l'algorithme
utilis. Si l'acquittement correspondant au paquet (ou au groupe des paquets) de donnes
n'arrive pas la source avant tRTo partir de l'instant de son mission, il est considr perdu.
Plusieurs approches sont proposes pour modliser le processus de perte: Le modle de
Gilbert est un modle Markovien simple deux tats, un tat de perte reprsent par B (Bad),
et un tat dans lequel le paquet arrive la destination, et est reprsent par G (Good). p
dsigne la probabilit de passer de l'tat G l'tat B, et q la probabilit de passer de l'tat B
l'tat G. Les temps moyens de sjour dans l'tat G et dans l'tat B sont respectivement 1/p et
1/q. La moyenne de perte dans ce modle est : p1 = p/(p + q).
?
Fig. 3.3 Le modle de Gilbert
Dans le cas o la probabilit de perte dans l'tat B n'est pas 1, et la probabilit de rception du
paquet n'est pas 0, la moyenne de perte devient : p1 = p* pB /(p + q) + q*pa/(p + q).
La classification des rcepteurs peut se faire en fonction d'un seul paramtre ou un groupe de
paramtres dpendants ou indpendants. Elle se fait en regroupant les rapports similaires dans
une mme classe; Pour cela, il faut une mthode pour mesurer la distance entre les diffrents
rapports et choisir la classe la plus proche.
20
Cette distance peut tre mesure avec une quation cludienne Lp donne par la formule
sui vante : d( x, y) = ( l: (Xi - yi)p) l!p o Xi et Yi sont les diffrents paramtres des rapport x
et y respectivement.
2.3.2- Algorithme de classification des agrgateurs:
[12] prsente un algorithme simple pour la classification des rcepteurs. Chaque classe est
reprsente par un point reprsentatif et un poids, et chaque fois qu'un nouveau point rejoint
cette classe, il change la position du point reprsentatif ainsi que son poids.
L'agrgateur reoit les rapports des rcepteurs, et quand un nouveau rapport arrive, il joint la
classe la plus proche, qui correspond la distance cludienne minimale, et dans le cas o cette
distance est plus grande qu'un certain seuil, une nouvelle classe est cre, condition que le
nombre total des classes soit infrieur 5, qui est le nombre maximal des couches.
Notons que chaque classe correspond une couche.
Chaque agrgateur envoie rgulirement son rapport agrg vers l'agrgateur de niveau
suprieur. L'agrgateur feuille considre le point reprsentatif obtenu avec la priode passe
comme un point reprsentatif pour la nouvelle priode, et les agrgateurs de niveaux
suprieurs rinitialisent leurs points reprsentatifs aprs l'mission de leurs rapports.
gateur feuille est diminu chaque fois que ce dernier envoie son rapport, et quand le poids
descend sous un certain seuil, la classe est limine. Cette mthode prend en compte les
rapports des rcepteurs rcents du pass, et limine les rapports trs anciens.
Pseudo-Code de classification des rcepteurs:
dth = seuil dfini pour crer des nouvelles classes (si la distance entre un rapport de
rception reu et toutes les classes existantes est suprieur ce seuil, et si le nombre
des classes est infrieur 5, une nouvelle classe est cre, autrement, le rapport joint la
classe la plus proche).
Nmax =nombre maximal des classes (5)
r = rapport du rcepteur reu
Chercher la classe la plus proche d(r,
mine d(tj, t)
.si (d(r, c
dth}
Si (nombre des classes< Nmax)
Ajouter une nouvelle classe CNEw
&
Ajuster le poids (le nombre des rcepteurs) de la classe Gftew
Calculer le point reprsentatif de la classe t
xc= (poids()* x+ r)/(poids ( ._) f" 11 )
Augmenter le poids de la classe C de 1.
Mcanisme d'agrgation des rapports des rcepteurs:
W min = seuil de suppression de la classe
y = poids de la mmoire
V\
C = ~ W
Au dbut de la priode pour toutes les classes diminution du poids de la classe par le
facteur poids(C) = poids(C)* y
Si (poids(C) < Wmin)
enlever la classe
Recevoir un nouveau rapport
21
Envoyer le rapport agrg vers l'agrgateur de niveau suprieur
2.4- Travail existant :
L'approche implmente est utilise pour une transmission des donnes en plusieurs couches,
et en fonction de l'tat de rception, la source adapte les caractristiques des couches. Cette
approche propose l'utilisation d'agrgateurs pour rsoudre le problme de scalabilit
d'mission des rapports des rcepteurs.
Dans la version du code utilis, la transmission des donnes se fait en une seule couche, et
chaque T control (appele priode de contrle) la source diffuse un paquet de contrle
RTCP, compos d'une option SR, suivi d'une option SDES et d'une ou plusieurs options
APP.
Dans ces options APP, les informations concernant les caractristiques des couches sont
transmises.
Chaque rcepteur envoie son agrgateur feuille son rapport de rception en indiquant le taux
de perte moyen des flux des donnes la rception et sa bande passante disponible sans perte.
Ces rapports de rception sont envoys une fois dans chaque priode T control.
Les fonctions correspondantes la fusion des rapports des rcepteurs sont dj implmentes,
et par suite, le problme de scalabilit des rapports des rcepteurs est rsolu.
2.5- Travail :
L'approche de [12, 13] propose une solution pour mesurer les RIT entre les rcepteurs et la
source dans laquelle seuls les agrgateurs feuilles changent des messages avec la source, et
chaque rcepteur calcule son RTT avec la source comme tant la somme de son R TT avec son
agrgateur feuille et le R TT de son agrgateur feuille avec la source.
Dans mon stage, j'ai implment l'algorithme de calcul des RTT entre les rcepteurs et la
source en se basant sur l'ide cite ci-dessus.
Aprs l'intgration du code correspondant au calcul du RTT entre les rcepteurs et la source,
chaque rcepteur calcule le RTT entre lui et la source et transmet son rapport de rception
son agrgateur feuille en indiquant sa bande passante disponible calcule avec un modle de
TCP avec l'quation (1) au lieu de sa bande passante disponible sans perte, ainsi que le taux
de perte moyen des flux des donnes la rception.
Le problme de la dtection et la correction des collisions entre les identificateurs (SSRC et
CNAME) des diffrents lments de la session ainsi que les oprations d'abonnement des
rcepteurs aux couches supplmentaires, et des solutions qui peuvent tre implmentes et
intgres facilement avec les codes prsents.
2.5.1- Calcul du RTT :
La mthode suivie consiste changer des options APP entre la source et l'agrgateur feuille
d'une part, et le rcepteur et son agrgateur feuille d'autre part.
Les options APP changes pendant chaque priode de contrle T control pour le calcul des RTT
entre les rcepteurs et la source sont dcrites ci-dessous :
Chaque agrgateur feuille envoie priodiquement chaque Tcontrol (avec un dlai alatoire) une
option APP (appele demande du RIT de l'agrgateur feuille) la source en indiquant dans le
champ de donne le numro de squence de ce paquet, et il mmorise son instant d'mission.
22
0
0 A <2-
+-+- +
1 v ::;. "(___ t ?
i
1
-+
+ --t --+ --+ - +
1
.... ..- -+ --t - -t --t - +
1
6
8
-+
1
lj
--+
-+ +-+-+
t(eune ( A Sc 1 f )
- +
+ -=-- +
-
-
+ -::.. + --::z_ + --:::;__ +
1
1
+ :::: +-

fooifk
ruyueo t- /3 elu eyzce rttun
t :: + +
+
+
+
+
-+
-+
-
-t
1
-
+ = +-
Fig.2.4 Format de la demande du R TT des agrgateurs feuilles
Chaque fois que la source reoit une demande du R TT d'un agrgateur feuille, elle la
mmorise avec son instant de rception.
Avec le message priodique diffus par la source chaque T control, une option APP est ajoute
(appele rponse de la source), dont le champ de donne est compos de plusieurs sous-
rponses aux demandes de RTT reues.
Comme montre la figure 2.5 ci-dessous, chaque sous-rponse de ce champ de donnes est
compose de plusieurs champs correspondants au T dlsr d'une demande reue (qui est le temps
coul entre la rception de la demande et l'mission de la rponse correspondante), le
numro de squence de cette demande, ainsi que le SSRC de l'agrgateur feuille
correspondant.
Aprs la rception de la rponse de la source, chaque agrgateur feuille calcule le R TT entre
lui et la source avec l'quation suivante:
R TT Agrgateur = T rception de la rponse de la source - T mission de la demande de l'agrgateur - T dlsr
(1)

1
-t- - --f
1
+ -t
IZ
+
Fig. 2.5 Format de la rponse de la source aux demandes de RIT des agrgateurs feuilles
Le rcepteur, envoie priodiquement chaque T control (avec un dlai alatoire) un option
APP (appel demande de RTT du rcepteur) son agrgateur feuille, en indiquant dans le
~ h a m p de donnes le numro de squence de cette demande.
-t -t -1
1
+
-::::.. t ;::. t- ~ t--;::. + ;::- t :::=- t ::::: t ::::' t- :::::-+ :::: t ;:._ t -= + -;:::. -t :::::_ 1- .:::::.._ + -:::... -t :::: + =--t -::::: 1 : +
1
1
l ~
-+ -=- + =-+-=- f
Fig. 2.6 Format de la demande de RTT des rcepteurs
Si tous les rcepteurs envoient leurs demandes de RTT leurs agrgateurs feuilles
priodiquement chaque T control, on aura une congestion dans les files d'attentes des
agrgateurs feuilles, pour cela, chaque rcepteur attend un dlai alatoire avant l'mission de
sa demande de RTT.
24
La valeur alatoire peut tre positive ou ngative, elle varie entre deux valeurs extrmes,
V max et V min de telle faon que chaque rcepteur envoie une demande et une seule pendant
chaque priode T control. Les deux valeurs extrmes V max et V min sont choisies en fonction du
nombre maximal des rcepteurs connects un mme agrgateur feuille.
Pour la mme raison, et pour viter la congestion de la file d'attente de la source avec les
demandes de RTT des agrgateurs feuilles, chaque agrgateur feuille envoie sa demande du
R TT la source avec un dlai alatoire.
L'agrgateur feuille chaque fois qu'il reoit une demande de R TT d'un rcepteur, il la
mmorise avec son instant de rception.
A la rception de la rponse de la source, il cherche sa rponse dans le champ de donne du
paquet reu, en comparant son SSRC au SSRC indiqu dans chaque sous-rponse.
Tout de suite, l'agrgateur feuille calcule le RTT entre lui et la source selon l'quation (1),
puis il rpond les rcepteurs leurs demandes en diffusant un paquet RTCP (option APP) vers
ses rcepteurs (appel rponse de l'agrgateur feuille).
Le champ de donne de cette option APP est compos en plusieurs sous-rponse chacun
correspondant une demande d'un rcepteur reue, et dans laquelle est indiqu le T dlsr d'une
demande d'un rcepteur reue (qui est le temps coul entre la rception de la demande et
l'mission de la rponse correspondante), le numro de squence de cette demande, et le
SSRC du rcepteur correspondant.
L'agrgateur feuille indique aussi dans ce champ de donne la valeur de RTT entre lui et la
source.
_s
0-'( _) L,_ ){, ':C-..,:q '1 0 /( (._ 5 .l c
1
lJ
+-- -t - -t - -\ -+ - + -t - f + - + - -t + - +- -+ t - t f----- -1 - -+
1 \ f \ 1 4 PP-=- (._. t., 1 L.iV!. J
t - -t --- -\ - - -t - + --t - + - + - -t - + - t- - t - t -+-- t - - t - f- + - -+
j S s C f L SR (_ _ J
-i --t- -t-i- /
-r-:::: -t ::::-t-:::.+-=---\-
+ ::... -+ ::::.. t.= 1- .::=. -t =- +--=-+ -=-+ -= +- == + =-+-;:;...-J .:::: + --+ =: -t
1
1 s Y?/1 (L(!'- }
-t-::.. -t ;::::: +-::: + ;;.... + :::: +-:::: + :=-t:::-t ;:_ + -::...+ ::-+ -::=- + =- -f t--::-+:::f =+ = t-::: -j
5e..fu._ehc_l' hwrtb &f wze u c..u\Je .yl.{e.AJ f - j_ hMt
f - -t - t - -1 - -t - t - + - t -i - t- -\ - -t- - t - -t - -t- - -+ - f t .,
fZ.R_LitJP/1.. f s c -. 1 -
- -t - t--t -i --\- - -\ - * - \- - i" - + i - t - ....1..
;- --r-i -'i-i--+--+ --.
Fig. 2.7 Format de la rponse de l'agrgateur feuille aux demandes du RTT des rcepteurs
25
Lorsque le rcepteur reoit la rponse de son agrgateur feuille, il va chercher sa rponse dans
le champ de donne, en comparant son SSRC au SSRC indiqu dans chaque sous rponse,
puis il calcule son RTT avec la source selon l'quation suivante:
RTTRcepteur =Trception de la rponse de l'agrgateur- Tmission de la demande du rcepteur -Tdlsr-
R TT Agrgateur
Avec cette mthode, tous les rcepteurs peuvent calculer avec prcision leurs R TT avec la
source.
Grce au fait que seuls les agrgateurs finaux participent au calcul du RTT, cet algorithme ne
prsente pas un problme de scalabilit ni un gaspillage de la bande passante dans le rseau.
2.5.2- Dtection et rsolution des collisions des SSRC et CNAME :
Comme c'est indiqu dans la section 2.1, RTP affecte chaque lment de la session (source
ou rcepteur) parmi eux les deux identificateurs (SSRC et CNAME). Ces deux identificateurs
doivent tre uniques dans la session, d'o la ncessit d'un algorithme qui dtecte la collision
correspondant au cas o deux lments diffrents de la session gnrent un mme SSRC ou
un mme CNAME.
Chaque option SR ou RR est suivie d'une option SDES qui indique les deux identificateurs
SSRC et CNAME. Dans la version du code utilise, les rcepteurs envoient des rapports de
rception leurs agrgateurs feuilles, et ces derniers renvoient un rapport agrg aux
agrgateurs de niveau suprieur et ainsi de suite.
Chaque rapport de rception consiste en un paquet R TCP form de trois options, une option
SR, suivie d'une option SDES et une option APP. Le rapport de la source consiste aussi en un
paquet RTCP form de trois options, une option SR, suivie d'une option
SDES et une option APP.
Contrairement la spcification RTCP, ces messages de contrle priodiques ne sont pas
changs entre les diffrents lments de la session, et par suite une dtection de collision
entre les identificateurs n'est pas possible.
Ci-dessous, on prsente une solution simple la dtection et correction des collisions.
Cette solution peut tre intgre facilement avec les algorithmes dj implments.
La source mmorise pour chaque lment de la session (y compris la source elle mme) son
adresse IP avec ses deux identificateurs (SSRC et CNAME), et chaque fois qu'elle reoit un
paquet SDES d'un lment, elle compare si un mme identificateur est utilis par un autre
lment avec une adresse IP diffrente.
Chaque rcepteur et chaque agrgateur envoie un paquet RTCP la source, form d'une
option SDES.
Pour viter la congestion du rseau avec ces paquets dans le cas o plusieurs rcepteurs
s'abonnent ensemble la session, chaque rcepteur attend un dlai alatoire avant l'mission
de ses identificateurs la source.
Ce dlai alatoire est choisi en fonction du nombre des rcepteurs dans la session.
Dans le cas d'une collision, la source inclut dans son rapport une liste des lments qui ont
une collision, et chaque rcepteur ou agrgateur concern, chaque fois qu'il reoit le rapport
de la source, rgnre son identificateur (ou les deux dans le cas o il y a une collision avec
les deux identificateurs choisis).
2.5.3- Synchronisation des abonnements aux couches Goin and leave):
Le rcepteur, pour calculer sa bande passante disponible entre lui et la source, doit calculer le
taux de perte moyen sur toutes les couches.
26
Par exprimentations, ils ont trouv [11] que si deux rcepteurs essayent de joindre en mme
temps deux couches diffrentes, le rcepteur qui essaye de joindre la couche la plus basse, a
de grande chances de constater des pertes des paquets.
Ces pertes ne sont pas dus l'augmentation du dbit qu'il reoit, mais apparaissent la suite
de l'autre rcepteur qui essaye de joindre la couche la plus leve.
Ainsi, des algorithmes pour synchroniser l'abonnement aux diffrentes couches sont
ncessaires. L'approche prsente dans [11] adresse ce problme de synchronisation.
Dans cette approche, la source transmet les donnes en plusieurs couches, et elle diffuse dans
la couche de base des messages de contrle priodique autour les caractristiques des
diffrentes couches. Chaque rcepteur, aprs la rception du message de contrle de la source,
commence surveiller la rception des paquets sur la couche de base sur une certaine priode
To.
Puis, le rcepteur essaye de joindre la premire couche supplmentaire (s'il n'tait pas dj
abonn), et il surveille de nouveau la rception des paquets sur cette couche supplmentaire
sur une certaine priode TI, et ainsi de suite jusqu' la surveillance des toutes les couches.
Aprs la fm des priodes de surveillance, le rcepteur calcule sa bande passante disponible
entre lui et la source, puis il quitte les couches qui ne lui conviennent pas.
Tous les rcepteurs s'abonnent la couche de base, et si la bande passante disponible du
rcepteur le permet, ce dernier s'abonne des couches supplmentaires comme suit :
Soit Co le dbit de la couche de base, Ci celui de la couche supplmentaire d'ordre i, et soit R
la bande passante disponible du rcepteur : le rcepteur choisit K couches supplmentaires
joindre condition que Co+ ... + Ck < R < Co+ ... + Ck + Ck+I.
Pour rduire l'effet de dsynchronisation dans la rception des messages de contrle de la
source par les rcepteurs, une priode de synchronisation Tsync est ajout la priode To.
Tsync = ( RTT max- RTTi )/2 o RTT max est le RTT maximal sur tous les rcepteurs dans la
session, et R TTi est le R TT du rcepteur i.
Pour cela, les rcepteurs incluent leurs RIT dans leurs rapports vers la source, et cette
dernire inclut dans son message de contrle la valeur du R TT max.
Cet algorithme est simple et facile intgrer avec les codes dj implments.
2.6- Rsultats attendus :
Dans cette section, on prsente les rsultats attendus du programme aprs la fin de
l'implmentation.
La source diffuse priodiquement des paquets R TP des donnes, et priodiquement elle
envoie des messages de contrle SR, pour dcrire la transmission des donnes.
Chaque rcepteur surveille la rception des paquets de donnes, calcule son taux de perte,
ainsi que son RTT avec la source selon la mthode dcrite dans la section prcdente, et il
envoie priodiquement un rapport RR son agrgateur feuille.
Le rapport RR contient le taux de perte estim par le rcepteur, ainsi que la bande passante
disponible entre lui et la source.
Chaque fois que l'agrgateur reoit un RR, il le fusionne avec les autres RR reus selon
l'algorithme dcrit dans la section 2.3 et il envoie un rapport agrg l'agrgateur de niveau
suprieur, et ainsi de suite jusqu'au l'arrive l'agrgateur fmal.
Apres la rception du RR fmal agrg de l'agrgateur final, la source adapte les
caractristiques des couches comme c'est indiqu dans la section 2.4.
Pour viter la congestion dans les routeurs et les files d'attentes avec les messages de contrle
priodiques (les rapports de rception et les demandes du RIT des rcepteurs et des
agrgateurs), un dlai alatoire est ajout ces messages priodiques
RTP spcifie une allocation 5% de la bande passante totale de la session aux paquets
27
RTCP. Ainsi, les priodes des messages cits ci-dessus sont fonction du nombre des
participants la session.
Le choix du nombre des couches des donnes est trs important, et il dpend de plusieurs
paramtres. D'une part, un grand nombre des couches est ncessaire pour satisfaire les besoins
des rcepteurs htrognes. D'autre part, une petite priode de contrle (par suite un petit
nombre de couches) permet la source de rpondre rapidement aux fluctuations du rseau
l'aide des rapports de rceptions des rcepteurs.
Pendant chaque priode de contrle, chaque rcepteur surveille toutes les couches pour
calculer son taux de perte (To pour la couche de base, Tt pour la premire couche
supplmentaire, etc.), et par suite la priode totale de surveillance est proportionnelle au
nombre de ces couches.
La priode de contrle doit tre suffisante pour que les rcepteurs puissent surveiller toutes les
couches, ainsi un grand nombre des couches demande des rcepteurs une large priode de
surveillance et par suite une large priode de contrle.
Ainsi, le choix du nombre maximal des couches dpend de l'application considre. Avec
l' approche, le nombre maximal des couches est cinq.
2.7- Conclusion :
Dans ce chapitre le protocole R TP, plusieurs algorithmes pour organiser des agrgateurs dans
le rseau, ainsi que notre approche prsente dans [12, 13] ont t prsent.
L'intrt l'approche est qu'elle adresse les principaux problmes de la transmission multipoint
(la scalabilit des rapports de rception et l'htrognit des rcepteurs), et prsente un
algorithme pour calculer avec prcision les R TT entre les rcepteurs et la source sans avoir un
problme de scalabilit.
28
CONCLUSION
La transmission vido multipoint sur Internet reste un challenge, tant donn que le rseau
Internet ne prsente aucune garantie au niveau de la bande passante disponible et du dlai
(latence, gigue).
L'htrognit des rcepteurs reste le problme le plus difficile rsoudre. A cause de cette
htrognit, l'tat de rception des donnes n'est pas le mme pour tous les rcepteurs. Pour
cette raison, les rcepteurs doivent envoyer priodiquement la source des rapports de
rception concernant leurs tats de rception, selon lesquels la source adapte son dbit.
Dans son rapport de rception, le rcepteur inclut sa bande passante disponible ainsi que son
taux de perte.
Pour avoir un partage quitable de la bande passante du rseau entre les applications vido et
le trafic Internet, qui est en majorit un trafic TCP, chaque rcepteur peut calculer ses bandes
disponibles avec un modle TCP.
Les modles TCP allouent aux rcepteurs la mme bande passante alloue avec le TCP sous
les mmes conditions du rseau, avec le mme taux de perte et le mme temps aller retour
(R TT) entre ce rcepteur et la source.
Le calcul du RTT entre les rcepteurs et la source, prsente un problme de scalabilit et
gaspillage de la bande passante du rseau, car il demande l'change des paquets de contrle
entre les rcepteurs et la source.
Par suite, ces rapports de rception prsentent un problme de scalabilit et un gaspillage de la
bande passante du rseau.
L'approche propose une transmission des donnes en multicouches pour rsoudre les
problmes de l'htrognit des rcepteurs.
Cette approche utilise des agrgateurs pour rsoudre le problme de scalabilit des rapports de
rception des rcepteurs, et propose un algorithme scalable pour le calcul du R TT entre les
rcepteurs et la source, et prsente une conomie de la bande passante utilise dans le rseau.
Les problmes de la transmission multipoint sur Internet, le problme de synchronisation de
l'abonnement des rcepteurs aux diffrentes couches de donnes, la dtection et la correction
des collisions entre les identificateurs allous par le protocole RTP chaque lment de la
session (section 2.6) ont t rsolu.
L'implmentation d'un algorithme de calcul de RTT entre les rcepteurs et la source est
propose dans l'approche qui sert calculer les bandes passantes TCP-Freindly des rcepteurs
[18].
BIBLIOGRAPHIE
[1] A. Basu and S. J. Golestani,''Estimation ofReceiver Round Trip Times in Multicast
Communications,'' 1999,
[2] J.C. Bolot, T. Turletti and I. Wakeman, "Scalable Feed-back Control for Multicast Video
Distribution in the Internet,'' inproc. ofSIGCOMM, August 1994, pp.58-67. [3] I. Rhee, N.
Balaguru and G.N. Rouskas "MTCP :Scalable TCP-like congestion control for reliable
multicast," in Proceeding of the conference on computer communications (IEEE Infocom),
New York, USA, Mars 1999.
[4] S. Paul, K. Sabnani, J.C.Lin and S.Bhattacharyya, "Reliable Multicast Transport
Control (RMTP),'' IEEE Journal on selected A reas in Communications, April 1997.
[5] L. Vicisano, L. Rizzo and J. Crowcroft, "TCP-like congestion control for layered
multicast data transfer," in Proceeding of the conference on computer communications (IEEE
Infocom), San Francisco, USA, Mar. 1998.
[6] A. Legout and E.W. Biersack, "Fast convergence for cumulative layered multicast
transmission scheme," Tech. Rep., Eurecom, Sophia-Antipolis, France, Oct. 1999, under
submission.
[7] T. Jiang, E. Zegura and M. Ammar, "Inter-receiver fair multicast communication over the
internet,'' in Proc. International Workshop on Network and Operating System Support for
Digital Audio and Video (NOSSDAV), Basking Ridge, New Jersey, June 1999.
[8] S.Y. Cheung, M.H. Ammar and X. Li, "On the Use of Destination Set Grouping to
Improve Fairness in Multicast Video Distribution,'' inproc. of IEEE Infocom, 1996.
[9] E. Amir, S. McCanne and H. Zhang, "An Application-level Video Gateway," in Proc. of
ACM Multimedia, November 1995.
[10] B. J. Vikers, C. Albuquerque and T. Suda, "Source Adaptive Multi-layerd Multicast
Algorithm for Real-Time Video Distribution,'' Technical Report ICS-TR 99-45, University of
California, Irvine, June 1999.",
[11] D. Sisalem and A. Wolisz, "MLDA: A TCP-Friendly Congestion Control Frame for
Heterogeneous Multicast Environments,'' in Eighth International Workshop on Quality of
Service (IWQoS 2000), Pittsburgh, PA, June 2000.
[12] K. Salamatian and T. Turletti, "Classification ofreceivers in large multicast groups using
distributed clustering," in Proceedings of Packet Video, May 2001.
54
[13] X. Hnocq, C. Guillemot, K. Salamatian and T. Turletti, "Joint source and channel rate
control for multilayered multicast video transmission based on a distributed clustering
algorithm".
[14] "RTP: A Transport Protocol for Real-Time Applications," Internet Engineering Task
Force, INTERNET-DRAFT, draft-ieft-avt-rtp-new-06, January 14, 2000.
[15] K.L. Calvert, J. Griffioen, A. Sehgal and S. Wen," Concast: Design and implementation
of a new network service," in proceeding of International Conference on Network Protocols,
Toronto, Ontario, 1999.
[16] E. Amir, S. McCanne and H. Zang, "An application level geteway," in proc. Of ACM
Multimedia, San Francisco, California, November 1995.
[17] R. Droms, "Dynamique host configuration protocol," RFC-1541, Octobre 1993.
[18] "TCP-Friend1y Rate Control (TFRC): Protocol Specification," Internet Engineering Task
Force, INTERNET-DRAFT, draft-ieft-tsvwg-tfrc-00, 17 November 2001.
30