Amélioration des flux temps réel sur

les réseaux IP

Bibliographie de Stage
MASTER 2 RECHERCHE

« Réseaux et Systèmes Répartis »

Présenté par :

Houssein WEHBE

Encadré par :

Bernard COUSIN et Gérard BABONNEAU

Table de matières
Introduction ...................................................................................................................................... 3

Chapitre 1: RTP (Real Time Transport Protocol) ............................................................................... 5

1. Introduction .......................................................................................................................... 5

2. Format des paquets RTP ..................................................................................................... 5

3. Profil spécifique à la modification de l’entête RTP ........................................................... 6

4. Les composants ajouté avec l’utilisation de RTP............................................................... 6

5. Conclusion ............................................................................................................................. 6

Chapitre 2: RTCP (Real-time Transport Control Protocol) .............................................................. 7

1. Introduction .......................................................................................................................... 7

2. Le type des paquets RTCP................................................................................................... 7

2.1 Sender Report (SR) ............................................................................................................. 7

2.2 Receiver Report (RR) ......................................................................................................... 8

2.3 Les autres rapports de RTCP ............................................................................................ 8

3. Période de transmission des paquets RTCP ....................................................................... 8

4. Conclusion ............................................................................................................................. 9

Chapitre 3: Un profil pour le protocole RTCP basé feed-back ........................................................10

1. Introduction ........................................................................................................................ 10

2. Le protocole RTCP basé sur le feed-back(FB)................................................................. 10

2.1 La diminution du nombre des NACK ..............................................................................11

2.2 La diminution du volume des NACK ...............................................................................11

3. Conclusion ........................................................................................................................... 11

Chapitre 4: Le protocole NORM .............................................................................................................12

1. Introduction ........................................................................................................................ 12

2. Le protocole NORM ........................................................................................................... 12

1
 2.1 Définition ............................................................................................................................12

2.2 Utilisation de codes FEC....................................................................................................13

2.3 Gestion des NACK du côté du récepteur .........................................................................13

2.4 L’algorithme utilisé par l’émetteur et les récepteurs ......................................................13

3. Conclusion ........................................................................................................................... 14

Conclusion ....................................................................................................................................... 15

Références ....................................................................................................................................... 16

2
Introduction
De nombreuses applications multimédia (par exemple la visioconférence) sont basées sur
la transmission de flux temps réel. Par exemple, la visioconférence [10] est une technologie
multimédia qui permet à deux ou plusieurs interlocuteurs distants de communiquer en temps
réel par l’intermédiaire d’un dispositif de sonorisation et de visualisation. La communication
en temps réel entre deux sites s’établit, en général, soit localement à l'aide d'un réseau privée
conçu pour ce travail (et où le débit est garanti), soit mondialement à l'aide de l’Internet.

L’Internet a été conçu à l’origine pour des applications qui n’étaient pas multimédia d’où
trois types de problèmes. Afin de comprendre facilement le but de ce stage, on doit expliquer
en détail ces trois problèmes et les limites des protocoles utilisé dans l’Internet.

Le réseau Internet est basé sur un service de transmission de données très simple, dit best-
effort [8]. Avec ce service les données sont découpées en paquets et c’est le protocole IP qui
les achemine jusqu’au terminal final. Ces paquets peuvent parvenir à destination en suivant
des chemins variables, pas nécessairement dans le bon ordre, voire être détruits en cours de
route. Le protocole IP ne gère pas, donc, les pertes et les délais. De prime abord, ces
caractéristiques pourraient paraître totalement incompatibles pour une restitution correcte de
la vidéo et de l’audio qui exigent par nature un flux contrôlé et régulier. Pour cela, le
protocole IP est complété par le protocole TCP qui assure la fiabilité de la transmission en
demandant la réémission des paquets perdus ou détruits. Du fait de cette procédure de
réémission, TCP est un protocole qui engendre parfois un grand retard. Cette fiabilité qui est
un atout pour la transmission de fichiers informatiques devient, du fait de la grande gigue
(variation du délai), un inconvénient pour la transmission de la vidéo et de l’audio. Pour
compenser la lenteur de TCP, le protocole UDP (User Datagram Protocol) a été créé. C’est un
protocole qui est simplifié à l’extrême, sans ré-émission des paquets perdus. Il présente
l’avantage d’être beaucoup plus rapide, mais offre un niveau de service insatisfaisant.

L’Internet offre, donc, avec ces protocoles (TCP et UDP) le transfert de paquets mais sans
aucune garantie sur le délai. Ce délai dans le pire des cas peut être infini, c'est à dire les
paquets peuvent être perdus (c’est le premier problème de l’Internet). Cependant, il existe
aussi le risque qu'une ou plusieurs applications surchargent les routeurs et ne permettent pas
que d'autres applications puissent envoyer leurs paquets (d’où le deuxième problème). Pour
cela et afin d’optimiser la transmission des flux temps réel, ces protocoles majeurs ont été
complétés par des protocoles spécifiques comme RTP (Real-time Transport Protocol) et
RTCP (Real Time Transport Control Protocol). Le protocole RTP contrôle les flux et aide à
détecter la perte des paquets. Pendant que RTCP aide l’émetteur à s’adapter, en effet pour
résoudre le problème de surcharge des routeurs, il faut que les applications adaptent en temps
réel le débit des données émis (par exemple la vidéo) en fonction des capacités instantanées
du réseau. Ce qui permettra d’assurer par exemple une qualité des images aussi bonne que
possible. Cette adaptation repose sur des échanges de paquets de contrôle effectués à
intervalles réguliers entre les applications distantes. C’est le rôle du protocole RTCP. RTCP
permet aussi la transmission des paquets ACK ("acknowledgement") qui indiquent
explicitement les paquets correctement reçus, et la transmission des paquets NACK ("negative
acknowledgement") qui indiquent explicitement les paquets incorrectement reçus.

3
 Pour la transmission des flux temps réel, l’Internet utilise, donc, conjointement les
protocoles RTP et RTCP. Mais le problème est que la plupart des applications multimédias
sont des applications multicast avec un grand nombre de récepteurs. En effet, ce problème (le
troisième problème) provient du fait d’envoyer, selon RTCP, un NACK à chaque paquet
perdu. Donc du grand nombre des messages NACK est envoyé. On ne trouve pas ce problème
dans le cas d’une transmission unicast où il n’y a qu’un seul récepteur. Prenons le cas où le
paquet perdu est proche de l’émetteur, tous les récepteurs répondent par un NACK. Alors cela
risque de se terminer par la saturation de la mémoire de l’émetteur. En plus le trafic augmente
sur le réseau ce qui augmente le temps de réponse de l’émetteur (le temps de rétro-contrôle) et
la probabilité de nouvelles pertes.

Le but de ce document est d’expliquer les mécanismes de multicast dont la réduction du

volume et le nombre des messages NACK. Ceci afin d’optimiser le temps de rétro-contrôle et
assurer, par la suite, une transmission multicast fiable. C'est-à-dire une transmission continue,
même avec des pertes, des données audio et vidéo vers un grand nombre des récepteurs. Mais
il faut respecter certaines conditions surtout dans le cas où la solution utilise la diffusion. En
effet, cette méthode oblige le récepteur détectant une perte de diffuser le NACK vers tous les
participants, et en conséquence oblige les autres récepteurs d’attendre un certain temps
(« backoff time ») avant d’envoyer leur NACK. Le but d’attendre est que le récepteur n'a plus
besoin d'envoyer son propre message NACK s’il reçoit le même message d’un autre récepteur
pendant le backoff time; En conséquence le nombre des messages NACK envoyés diminue.
Toutefois, le récepteur ne doit pas attendre trop longtemps afin de garantir que l’émetteur
renvoie le paquet demandé assez rapidement (par exemple, prenons le cas de diffusion vidéo,
l’émetteur ne peut pas stocker tous les paquets envoyés depuis une heure). Pour cela il faut
trouver une bonne valeur de « backoff time » ce qui optimisera le temps de rétro-contrôle.

Dans ce document on va expliquer le protocole RTP. Il résout le premier problème et aide

à détecter la perte des paquets (Chapitre 1). Puis on présentera le protocole RTCP (Chapitre 2)
qui résout le deuxième problème (la surcharge des routeurs) en utilisant le message de
contrôle (NACK). Ensuite on va donner un exemple d’utilisation de RTCP dans le cas de
diffusion audio et vidéo en expliquant le profil AVPF et quelques solutions proposées dans ce
profil pour limiter le nombre des messages NACK (Chapitre 3). On terminera par une des
solutions proposées pour diminuer le nombre des messages de rétro-contrôle en utilisant la
méthode de diffusion : c'est le protocole NORM (Chapitre 4). En fait, ce protocole assure une
transmission multicast fiable mais il nécessite un mécanisme sophistiqué pour calculer le
« backoff time». Pour cela NORM est un protocole très complexe et dans ce stage on devra
trouver une solution moins compliquée que NORM.

4
 Chapitre 1: RTP (Real Time Transport Protocol)

1. Introduction

RTP [1] est un protocole qui a été développé par l’IETF1 afin de faciliter le transport temps
réel des flux données audio et vidéo sur l’Internet. Et comme on a dit dans l’introduction son
but principal est de détecter la perte des paquets. C’est un protocole qui se situe au niveau
applicatif. Cependant, RTP utilise généralement le protocole de transport UDP, car UDP
permet d’atteindre plus facilement le temps réel et admet la transmission multicast. RTP
encapsule les données du flux temps réel dans des paquets UDP contenant des champs qui
facilitent la détection de la perte et qui assurent la synchronisation entre les différents médias.
Dans ce chapitre on doit expliquer comment RTP utilise les champs des paquets pour atteindre
son but principal et on en déduira finalement la nécessité du protocole RTCP pour atteindre
une qualité de la liaison.

2. Format des paquets RTP

Les différentes fonctions du RTP cités par le groupe AVT« Audio Video Transport» de
l’IETF dans le RFC 3550 [1] (la détection de la perte et la synchronisation), seront assurées
en ajoutant des champs spécifiques dans l'entête des paquets des données. L’entête d’un
paquet RTP est obligatoirement formé de 12 octets. Cet entête précède la charge utile
«payload». Dans cette partie on doit expliquer le rôle des principaux champs de l’entête des
paquets RTP.

L'identification et l'ordonnancement des paquets appartenant à un même flux facilitent la

détection des pertes. Pour cela l’entête contient un champ pour le numéro de séquence. La
valeur initiale de ce champ est aléatoire et il s’incrémente à chaque paquet envoyé. Il est
facile, alors, au récepteur de détecter une perte: il attend le paquet numéroté (n) et il reçoit le
numéro (n+1).

Dans le but d’assurer la synchronisation, RTP ajoute à l’entête le champ « Timestamp » (ou
estampille temporelle). Sa valeur initiale est obtenue d’une horloge globale puis s’incrémente
selon des règles propres à l’application. L’utilisation de ce champ se fait comme l’exemple
suivant. Nous sommes dans une conférence vidéo diffusée et il y a quelqu’un qui parle. Les
flux audio et vidéo sont transportés dans des sessions RTP différentes. Les estampilles des
paquets de deux sessions prennent leurs valeurs de la même horloge de référence ce qui
permet au destinataire de synchroniser chaque trame audio et vidéo.

En plus, RTP identifie chaque source d’une session multicast d’une manière unique par le
champ « SSRC » qui prend une valeur aléatoire choisi par l’application. Donc, à partir de ces

1
RTP approuvé en 1995 comme proposition de standard et en 1996 comme standard

5
 champs, RTP assure ses principales fonctionnalités. Il y a d'autres champs ayant chacun un
rôle spécifique (par exemple dans la partie 4, on va voir le rôle d’un champ qui s’appelle
CSRC).

3. Profil spécifique à la modification de l’entête RTP

RTP peut être utilisé par une grande variété d’applications qui auraient des exigences
différentes. Pour s’adapter à ces exigences il faut définir des extensions pour les
environnements particuliers. On définit alors un profil, on dit « RTP profil for.. ». Par exemple
un profil pour les applications audio et vidéo « AVP ». Chaque application utilise un profil
pour chaque type de session RTP. Le profil défini, par exemple, le service et l’algorithme de
sécurité demandés par l’application, ou les moyens d’encapsulation des paquets, etc. Dans le
chapitre 3 on va expliquer le profil AVPF.

4. Les composants ajouté avec l’utilisation de RTP

Dans cette partie on doit expliquer comment RTP fonctionne dans le cas où les récepteurs
possèdent des caractéristiques différentes (par exemple un type de codage différent...). Dans
ce cas, le protocole RTP peut placer deux types d'équipements intermédiaires entre eux et la
source. Ce sont les translateurs et les mixeurs. Ils modifient les flux pour les adapter aux
récepteurs.

Le translateur a pour fonction de traduire les données transmises par une application et
codée dans un format en un autre format. Par exemple les applications de vidéo conférence
codés en MPEG 2 peuvent être décodées et recodées en MPEG 4, si l’on souhaite réduire la
quantité d’information transmise pour respecter les contraintes d’un réseau traversé. Prenons
le cas où un récepteur se place dans un sous-réseau dont le débit maximal est, par exemple, 3
Kbit/s et les flux sont transmis avec un débit de 10 Kbit/s. Dans ce cas c’est le rôle du
translateur d’adapter les flux.

Le mixeur a pour but de regrouper plusieurs flux dans un seul flux en conservant le même
format. Il ajoute l’ensemble des sources dans un champ s’appelle « CSRC ». Il peut être
utilisé, par exemple, pour rassembler dans un même document vidéo deux vidéos qui viennent
de deux émetteurs différents.

5. Conclusion
RTP est un protocole qui ajoute des informations de synchronisation aux paquets de
données IP afin d'éviter des pertes de données et de mieux gérer les flux audio et vidéo
transitant en temps réel. Donc il résout le premier problème de l’Internet cité dans
l’introduction de ce document. Mais puisqu’il est unidirectionnel, il ne garantie aucune qualité
du service. Pour cela il est accompagné d’un protocole de contrôle RTCP [1]. Avec RTCP les
récepteurs donnent un feedback sur la qualité de la transmission. Les messages de feedback
permettent à l’émetteur de s’adapter et ainsi on résout une partie des problèmes de l’Internet.
On diminue, par exemple, la surcharge des routeurs. Les problèmes qui proviennent de
l’utilisation du RTCP (voir le chapitre 2) sont ceux de ce stage.

6
 Chapitre 2: RTCP (Real-time Transport Control Protocol)

1. Introduction

Nous avons vu dans l’Introduction, que les données temps réel sont transférées sur Internet
dans des paquets. Ces paquets peuvent être perdus, car le délai maximum n’est pas garanti.
Dans le chapitre précédent nous avons expliqué le protocole RTP. Il ajoute aux paquets des
champs facilitant la gestion des pertes et des délais. Mais sur Internet, il existe toujours le
risque qu'un ou plusieurs applications surchargent les routeurs et ne permettent pas que
d'autres applications puissent transmettre simultanément et efficacement leurs paquets. Donc,
afin de limiter le nombre de pertes provenant de ce problème, il faut que l’émetteur, adapte en
temps réel le débit des données émis en fonction des capacités instantanées du réseau.
L’émetteur a besoin, donc, d'informations suffisamment régulières sur la qualité de la
transmission : comme le nombre des paquets perdu et le temps aller-retour, etc. Puisque le
protocole RTP (qui est unidirectionnel) n’assure pas seul ces fonctionnalités, l’IETF l'a
accompagné un protocole de contrôle. Il s’appelle RTCP («Real-time Transport Control
Protocol »). RTCP, selon le RFC 3550 [1], est fondé sur la transmission régulière des paquets
de contrôle (« feedback ») du récepteur à tous les participants de la session. Ces paquets,
comme est expliqué dans les documents décrivant le RTCP ([7], [1]), comprennent des
informations permettant à l’émetteur de s’adapter. Un exemple de ce type de paquets est le
paquet NACK ("negative acknowledgement"). Il indique explicitement les paquets perdus
(rappelons que, le récepteur peut connaître les paquets perdus en utilisant les informations
ajoutées par RTP). Dans le cas où le nombre des récepteurs est grand, le fait que tous les
récepteurs envoient un NACK à chaque paquet perdu pose une nouvelle fois le problème de
surcharge de routeurs. C'est le problème typique à RTCP, et que nous voulons résoudre. Dans
ce qui suit, on va voir les différents types des paquets RTCP, et comment RTCP assure ses
fonctionnalités et finalement on en déduira la présence du problème provenant du NACK.

2. Le type des paquets RTCP

Le protocole RTCP demande aux participants de la session (l’émetteur inclus) d'envoyer

périodiquement vers tous les autres participants des paquets RTCP. Ces paquets (ou rapports
RTCP), contenant des informations de contrôle, commencent par une partie fixe suivie par
une partie variable contenant des éléments structurés. Ces éléments peuvent être de longueur
variable selon le type de paquet. En fait, il existe plusieurs types de paquets RTCP, mais la
partie variable est toujours terminée sur une frontière de quatre octets. Il existe de nombreux
type de rapports RTCP : Sender Report, Receiver Report, BYE, SDES, etc.

2.1 Sender Report (SR)

Le rapport RTCP (SR) est envoyé par toute source active en émission. Il contient des
champs qui permettent de donner des statistiques sur l’état de la transmission : le nombre des
paquets perdu, le nombre des paquets transmis, etc. Ce rapport contient le champ « NTP
timestamp » qui représente la valeur de l’horloge de référence lors de son émission. Ce
champ, facilite le calcul du temps d'aller-retour (RTT) (voir la Figure 1). C'est une valeur

7
importante pour la qualité des communications. On va voir dans le chapitre 4 (NORM) une
manière d’utiliser le RTT.

2.2 Receiver Report (RR)

Le rapport RTCP (RR) est envoyé des Source Récepteur

récepteurs à tous les participants de la T1 SR

session. Il contient les mêmes
informations que le rapport SR plus un T2
champ contenant le temps entre
l’émission et la réception des rapports
(c’est la variable « j » dans la Figure 1). T3
RR
Il aide l’émetteur à calculer le RTT.
T4 J=T3-T2

2.3 Les autres rapports de RTCP

Ces deux rapports, SR et RR, sont les RTT=T4-T1-j

rapports le plus utilisés mais on trouve Figure 1 : RTT est le moment de réception du rapport (RR) – le
dans [7] qu’il existe aussi d'autres temps d’émission du dernier rapport (SR)- le délai entre les deux
rapports comme « Membership rapports
Management (BYE) » et « Source
Description (SDES) ». « BYE » est utilisé pour indiquer que des participants ont quitté la
session. « SDES » fournit des informations sur les participants, telle que le nom,
l’emplacement, l’adresse, etc. Ajoutons que plusieurs paquets RTCP peuvent être transportés
ensemble dans un même paquet UDP. C’est pour combiner différents types des rapports
comme SR et SDES.

Ces paquets permettent à l’émetteur de s’adapter, mais ils sont envoyés vers tous les
participants. En effet, avec ces informations les participants peuvent savoir si les problèmes
sont partagés ou non avec les autres. Dans ce qui suit on doit expliquer pourquoi ces paquets
sont envoyés périodiquement.

3. Période de transmission des paquets RTCP

On a dit dans l’introduction de ce chapitre que l’émetteur a besoin d’adapter le débit des
données émis selon la capacité instantanée du réseau. Donc, il a besoin périodiquement de
recevoir des paquets RTCP. La périodicité dépend du nombre totaux des participants. En
effet, quand le nombre des participants augmente le nombre des paquets RTCP augmentent,
afin de diminuer le trafic sur le réseau on augmente la période d’émission des paquets RTCP.
Le nombre des participants sera estimé périodiquement de la part de l’émetteur (il envoie des
messages de consultation par exemple). La période dépend aussi de la taille des paquets
RTCP et de la bande passant allouée pour RTCP. En effet, on admet généralement que la
bande passante maximum allouée à RTCP soit égale à 5% de la bande passante de la session.
Selon [7] l’intervalle est :

Intervalle = (Taille moyenne des paquets RTCP) × (nombre total des participants) ÷
(Bande passante maximum allouée à RTCP).

8
4. Conclusion

Le récepteur envoie, donc, des paquets périodiques RTCP. Si le récepteur détecte une perte
dans le cas de la transmission audio et vidéo, il n’est pas judicieux d’attendre le prochain
rapport RTCP pour informer l’émetteur. Notamment et par exemple pour maintenir une bonne
qualité des images (pour reconstruire le flux vidéo par exemple). Pour cela, le récepteur
envoie vers l’émetteur un message de feedback qu’on l’appelle NACK ("negative
acknowledgement") indiquant explicitement les paquets perdu. Avec ce message, et surtout
dans le cas du multicast, le trafic sur le réseau augmente. Cela augmente le risque de
nouvelles pertes. Donc, il faut trouver un mécanisme pour diminuer le nombre et le volume
des messages NACK. Dans le chapitre suivant, on va voir en détail comment le protocole
RTCP fonctionne dans le cas de flux audio et vidéo en décrivant les solutions donnée dans le
profil AVPF.

9
 Chapitre 3: Un profil pour le protocole RTCP basé feed-back

1. Introduction

Le protocole RTCP permet la transmission des messages de feedback (FB), ces messages
circulent des récepteurs vers tous les participants. Ces messages, comme le NACK ("negative
acknowledgement") qui indique explicitement les paquets perdus, seront transmis soit avec les
paquets réguliers RTCP (décrit dans le chapitre précédent), soit indépendant de ces paquets.
Dans ce cas le trafic sur le réseau augmente d’où la nécessité de limiter le nombre et le
volume de ces messages. Dans ce chapitre on va donner une solution proposée en expliquant
un profil RTP spécifique pour l’audio et le vidéo, ce profil s’appelle AVPF [3]. Il représente
une modification de l’algorithme utilisé par le protocole RTCP, afin de résoudre ce problème.
L’utilisation de ce profil nécessite une session particulière qui supporte ces modifications.
Elle sera définie par le protocole SDP [4] (« Session Description Protocol »). Selon l’IETF,
SDP est un format de description et d’initialisation des paramètres. Il est destiné à la
description des sessions multimédia. Il ajoute de nouveaux attributs à la session. Par exemple,
pour indiquer les messages FB autorisé dans cette session. Dans ce qui suit, on doit décrire le
protocole RTCP dans le profil AVPF et ses nouvelles fonctionnalités.

2. Le protocole RTCP basé sur le feed-back(FB)

RTCP permet la transmission de messages de type FB. Ces messages ont le même format
d’entête que les paquets RTCP. Ils ont été décrits dans le chapitre précédent. Ils sont utilisés
selon la taille du groupe des participants (N). Par exemple les messages ACK qui indiquent
explicitement les paquets correctement reçus, seront utilisés quand N est égal à deux. Alors
que le NACK est utilisé selon le mode de fonctionnement du protocole RTCP.

En fait, on trouve dans le RFC 4588 [7] qui décrit le format de paquets RTCP, qu’il existe
trois modes de fonctionnement de RTCP. Ils diffèrent par la taille du groupe (N). Ceci dépend
de plusieurs paramètres comme le bande passante de la session RTCP (B), la taille moyenne
des paquets (R), l’intervalle de réception des paquets RTCP (T), le taux de perte.

Quand N <= B * T / R, on dit que le mode est « Immediate Feedback mode ». Alors qu’il
est « Early RTCP mode » quand N> B * T / R. Cependant, quand N est plus grand que la
limite maximale de ce mode (qui, selon le l’IETF [7], est assez difficile à estimer), on dit que
le mode de fonctionnement est « Regular RTCP Mode ». NACK sera utilisé seulement dans
les deux premiers modes pour limiter le trafic dans le cas où N est très grand. On va voir
maintenant comment AVPF limite le nombre et le volume des messages NACK.

2.1 La diminution du nombre des NACK

AVPF comme est décrit dans [3], travaille selon le principe suivant. Si le récepteur R
détecte la nécessité de transmettre un ou plusieurs messages FB (Feed-Back) par exemple,
parce que les médias nécessitent un ACK ou NACK. Il génère un message FB mais il attend
un certain temps « t » avant de l’envoyer vers tous les participants. Le but d’attendre est
d’envoyer ce message dans un paquet régulier RTCP dans le cas où il y a émission d’un tel

10
paquet pendant ce temps "t". Et on annule son émission si le récepteur reçoit la même
message d’un autre participant (c'est-à-dire que l’émetteur est déjà informé). Le temps « t »
est calculé en fonction de l’intervalle d’émission des paquets régulier RTCP (Chapitre 2). Ce
temps est indépendant, donc, de l’émetteur. En effet, dans le cas de la diffusion vidéo
l’émetteur ne peut pas retransmettre les paquets envoyés depuis une heure (par exemple). Le
problème du profil AVPF est que le temps d’attente « t » ne prend pas en compte les délais de
l’émetteur.

2.2 La diminution du volume des NACK

Afin de limiter le nombre des messages NACK, AVPF regroupe plusieurs messages dans
un seul message NACK. Mais pour diminuer le volume de ce message il utilise un format qui
contient deux champs (PID et BLP). Le champ PID sert à indiquer une première perte de
paquet. Alors que le champ BLP qui contient 16 bites, est utilisé pour envoyer les numéros de
séquence des paquets perdus parmi les 16 suivant le premier. Si un paquet est perdu on met un
(1) dans le bit correspondant. Pour déterminer son numéro de séquence il suffit d’ajouter le
numéro du bit au numéro de PID. Ce qui permet de réduire le volume du NACK. Le format
du message 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Conclusion

Pour utiliser le protocole décrit précédemment, AVPF nécessite la définition d’une session
particulière. Comme on a dit dans l’introduction de ce chapitre, cette session sera décrit par le
protocole SDP. SDP [4] décrit la session par un ensemble des variables. Ces variables
indiquent par exemple que seulement les messages NACK (de type indiqué dans la partie 2.2)
sont autorisés.

Donc, AVPF nécessite une session particulière. Il limite le nombre et le volume des NACK
mais il ne prend pas en compte les délais de l’émetteur. Dans le chapitre suivant on doit
expliquer une autre solution proposée basé sur le feed-back qui est le protocole NORM.
NORM est utilisé pour la transmission multicast fiable. Il possède encore certaines limites
mais on peut profiter des solutions proposé par NORM afin de trouver une solution optimale
pour diminuer le nombre et le volume des messages FB.

11
 Chapitre 4: Le protocole NORM

1. Introduction

La visioconférence, la diffusion radio et beaucoup d’autres applications en temps réel sur

internet ont besoin d’une transmission multicast fiable. C'est-à-dire, Ils ont besoin d’une
transmission continue, sans perte, des données vers toutes les destinations (cela afin de
garantir, par exemple, une bonne qualité des images). Généralement la perte des paquets des
données augmente quand le trafic sur le réseau augmente, cela est dû au fait que les routeurs
possèdent une mémoire de taille finie pour stocker les paquets avant de les acheminer vers
leurs destinations. On a vu que les solutions proposés pour diminuer la perte consistent à
utiliser des messages de feed-back (par exemple les messages NACK). Ces messages envoyés
par les récepteurs permettent à l’émetteur de s’adapter aux qualités instantanées du réseau.
Cependant, dans le cas du multicast où le nombre des récepteurs est grand, le grand nombre
des messages NACK envoyés par ces récepteurs augmente le trafic sur le réseau ce qui cause
le problème. Prenons l’exemple où un paquet est perdu près de l’émetteur, si chaque
participant répond par un message NACK, cela se termine par saturation de la mémoire et des
liaisons menant à l’émetteur. Afin de résoudre ce problème, plusieurs approches ont été
proposées pour la fourniture de services multicast fiable. Cela fait l’objet depuis 1999 de
travaux de standardisation au sein du groupe RMT (``Reliable Multicast Transport’’) de
l’IETF. Parmi les protocoles les plus utilisés, le protocole NORM [5] est choisi pour être
étudié comme il peut répondre le plus à nos besoins. Dans ce chapitre, on va expliquer les
fonctionnalités principales et les limites du NORM afin de faciliter la proposition d’une
nouvelle solution pendant le stage.

2. Le protocole NORM (« Negative Acknowledgment Oriented Reliable Multicast”)

2.1 Définition

Le protocole NORM, repose sur la transmission de NAK en cas de pertes de paquets de

données. Il est conçu pour fournir un service de transport fiable des données d'un ou plusieurs
expéditeurs à un groupe de récepteurs au-dessus de l’Internet.

NORM répond aux critères des protocoles assurant le multicast fiable. En fait, dans son
article « Un Etat de l’Art sur les Techniques de Transmission Multipoint Fiable » [8], Roca
définit ces critères. Selon cet article, les protocoles assurant le transport multicast fiable
doivent résoudre le problème de « scalabilité » (celui du grand nombre des messages NACK),
fonctionner indépendamment des équipements internes du réseau (sans aide des routeurs), et
travailler dans n’importe quel réseau avec la bande passante disponible. En effet, cette bande
passante disponible varie au cours du temps en fonction de l'utilisation du réseau. Ce dernier
critère est assuré en utilisant les messages de feedback (comme on a vu dans le cas de RTCP).
Alors, pour diminuer le nombre des messages NACK, NORM utilise un code FEC et un
mécanisme de gestion de NACK côté récepteur. Dans ce qui suit, on doit expliquer en détail
comment NORM assure ces deux fonctionnalités.

12
2.2 Utilisation de codes FEC

Les codes FEC ("Forward Error Correction") sont des codes correcteurs d’erreurs [2]. Un
paquet FEC permet de reconstituer n'importe quel paquet de données qui pourrait être perdus.
Les paquets FEC évitent donc d'avoir à transmettre des NACK. En général, la source suppose
qu’il y aurait un certain taux de pertes et ajoute systématiquement dans le flux de données
transmis des paquets FEC supplémentaires (on va voir dans 2.4 comment le récepteur
distingue entre les paquets des données et celle de FEC). Lorsque le récepteur demande la
retransmission d’un certain nombre de paquets. La source transmettra en fait un certain
nombre de paquets FEC du fait de leur propriété de se substituer à n’importe quel paquet de
données. Pour assurer leur fonctionnalité, la FEC nécessite l’utilisation des codes complexes
(Ce ne sont pas simplement une combinaison XOR des deux ou trois paquets précédents).

2.3 Gestion des NACK du côté du récepteur

Pour limiter le nombre d’informations de contrôle qu’un récepteur peut être tenté
d’émettre, NORM oblige les participants d’envoyer le message NACK en multicast. Ainsi
tous les voisins ayant subit la perte des mêmes paquets de données seront informés de la
demande de retransmission et ils n’ont pas besoin de retransmettre leurs messages NACK
pour les paquets déjà demandés. Pour cela chaque récepteur attend, avant d’envoyer son
propre NACK, un certain temps (fixé par le « backoff timer »). Pour garantir une meilleure
scalabilité, la valeur du backoff timer devra dépendre de la distance à la source c.-à-d. du
RTT. En effet, s’il y a un autre participant qui a envoyé un NACK, la réponse de l’émetteur
doit arriver pendant le RTT (temps de transmission de NACK vers l’émetteur plus le temps de
la réponse de l’émetteur).

Cependant, il y a des réseaux où le multicast n'est disponible qu’à partir de la source. Dans
ce cas, selon le RFC 3940 [5], Les récepteurs sont obligés de remonter les NACKs en unicast.
Afin de diminuer le nombre de ces messages, et pour reproduire un comportement similaire
au premier cas, la source émet périodiquement des listes des NACKS reçus. Dans ce cas, le
récepteur doit attendre un « backoff timer » calculé en fonction de RTT.

Dans ce qui suit, on va expliquer plus en détail, l’algorithme utilisé par le protocole
NORM. Dans cet algorithme on va montrer comment NORM utilise le code FEC avec les
paquets de données.

2.4 L’algorithme utilisé par l’émetteur et les récepteurs

Avant de transmettre les données, l’émetteur envoie un message NORM_CMD (CC) dont
le rôle est de collecter le temps aller- retour (RTT) et les autres informations sur le groupe
(par exemple, nombre des participants). À la réception de ces informations, il les envoie à
tous les participants en utilisant un message « NORM_INFO ».

Afin d’ajouter des codes FEC dans les messages transmis, et pour faciliter la distinction
entre les paquets de données et les symboles de FEC, l’émetteur et les récepteurs emploient
un algorithme commun. Le but de cet algorithme est de segmenter les données et les symboles
FEC. L’émetteur ajoute alors dans l’entête du message de donnée « NORM_DATA » un
champ indiquant que ce message contient des symboles FEC, avec des informations
supplémentaires comme le nombre de blocs FEC et leur taille (en octets) et la taille totale du
13
message. Ces informations permettent au récepteur de trouver les paquets FEC. Donc,
l’émetteur prépare le message NORM_DATA et le transmet à tous les participants.

À partir de numéro de séquence des paquets reçus, le récepteur détecte s’il y a des paquets
perdus. S’il ne peut pas corriger cette perte par les codes FEC, il génère un message NACK
contenant une demande de retransmission des paquets perdus ou des codes FEC associés à ces
paquets. Comme on a dit dans le paragraphe précédent (2.3), pour diminuer le trafic sur le
réseau et assurer une transmission multicast fiable le récepteur attend un certains temps
(t_max) fixé par le « backoff timer », avant d’envoyer le NACK à tous les participants ou
seulement en unicast vers l’émetteur. Pendant ce temps, si le récepteur reçoit un message
NACK émis par un des autres participants (dans le premier cas), ou s’il reçoit (dans le
deuxième cas) un message NORM_CMD (REPAIR_ADV) de l’émetteur (ce message
indique que l’émetteur est informé par la demande de retransmission), le récepteur rejette son
message NACK. Le temps t_max est un temps aléatoire calculé par le récepteur t_max
=K*RTT, avec k>=1. Prenons l’exemple illustré dans la Figure 2, où le récepteur 1 (resp. 2) a
détecté une perte à l’instant t1 (resp. t2). Le récepteur 1 a envoyé le NACK par unicast. Le
récepteur 2 doit attendre au moins RTT (temps d’aller de NACK du récepteur 1 vers
l’émetteur + le temps de transfert du message NORM_CMD(REPAIR_ADV) de l’émetteur
vers tous les participants.

Figure 2 : Le récepteur 2 doit attendre au moins un RTT avant d'envoyer son NACK

3. Conclusion

Le protocole NORM est utilisé pour assurer une transmission multicast fiable. L’émetteur
ajoute aux paquets (comme dans le cas de RTP) des informations permettant de détecter la
perte. Il est basé sur la retransmission des messages de feed-back des récepteurs. Pour
diminuer le nombre de ces messages, NORM utilise un mécanisme de la gestion de NACK
côté récepteur, mais il nécessite l’évaluation de RTT entre chacun des membres ce qui s’avère
relativement complexe à obtenir. Concernant le volume des messages NACK, NORM utilise
les paquets FEC. Au lieu de demander la transmission d’un grand nombre de paquets perdus
dans un message NACK, le récepteur n’a besoin de demander que quelques paquets FEC, ce
qui diminue le volume du NACK. Mais l’utilisation de FEC nécessite la génération d’un code
complexe (Ce ne sont pas simplement une combinaison XOR des deux ou trois paquets
précédents). En plus, la FEC nécessite l’utilisation des mécanismes de segmentation des
paquets de données afin de faciliter la distinction entre les paquets FEC et celles de données
d’où la complexité du protocole NORM.

14
Conclusion
Le réseau Internet est basé sur un service simple de transmission dit « best-effort ». Avec
ce service, les données sont découpées en paquets et acheminées vers leurs destinations mais
sans aucune garantie pour le délai. Ce délai dans le pire des cas peut être infini, c'est à dire les
paquets peuvent être perdus. L’Internet donc, pourrait paraître totalement incompatible pour
une restitution correcte des données audio et vidéo. En effet, ces données exigent par nature
un flux contrôlé et régulier.

Le transport de flux audiovisuels utilise principalement les protocoles RTP et RTCP, que
ce soit en unicast ou en multicast. RTP permet de détecter la perte des paquets, alors que
RTCP, qui est basé sur la transmission régulière des messages de feed-back des récepteurs,
aide l’émetteur à s’adapter aux caractéristiques de réseau. Cette adaptation permet de
diminuer la perte des paquets. RTCP est introduit pour corriger les anomalies du transport,
mais dans le cas du multicast où le nombre des récepteurs est grand, le nombre des messages
de feed-back est grand (surtout les messages NACK indiquant explicitement les paquets
perdus). Ces messages permettent d’augmenter le trafic sur le réseau et la probabilité de
nouvelles pertes, ainsi que d’augmenter le temps de réponse de l’émetteur (le temps de rétro-
contrôle).

Plusieurs solutions ont été proposées pour diminuer le nombre et le volume des messages
NACKs. Nous avons étudié celles qui sont proposées par le profil AVPF et le protocole
NORM. Ces deux solutions obligent le récepteur détectant une perte de diffuser le NACK
vers tous les participants, et en conséquence oblige les autres récepteurs d’attendre un certain
temps (« backoff time ») avant d’envoyer leur NACK. Le but d’attendre est que le récepteur
n'aura plus besoin d'envoyer son propre message NACK s’il reçoit le même message d’un
autre récepteur pendant le backoff time; En conséquence le nombre des messages NACK
envoyés diminue.

Le problème du profil AVPF est que le temps d’attente (« backoff time ») ne prend pas en
compte les délais de l’émetteur. Le protocole NORM calcule le backoff time en fonction du
RTT. Il nécessite, donc, une évolution de RTT entre chacun des membres ce qui s’avère
relativement complexe à obtenir. En revanche, NORM utilise des codes complexes FEC qui
permettent aux récepteurs de reconstituer n'importe quel paquet de données qui pourrait être
perdu, et au lieu de demander la retransmission d’un certain nombre des paquets, le récepteur
demande la retransmission de quelques paquets FEC. Il diminue par la suite le volume de
messages de demande (NACK). Mais le problème est qu’il faut trouver un algorithme
complexe pour générer les paquets FEC (Ce ne sont pas simplement une combinaison XOR
des deux ou trois paquets précédents).

La fiabilité de transmission multicast est l’objet des travaux du groupe RMT (``Reliable
Multicast Transport’’) de l’IETF. Nous avons étudié dans ce document les solutions
proposées et nous avons montré leurs limitations. Dans le stage qui suivra, on va profiter de
ces solutions pour trouver une optimisation qui convienne au flux temps réel. Cette solution
sera validée dans un environnement de simulation de réseau pour montrer ses avantages et ses
inconvénients.

15
Références

[1] H. Schulzrinne, S.Casner, R.Frederick, V.Jacobson, “RTP: A Transport Protocol for

Real-Time Applications”, RFC 3550, July 2003.
[2] J-ch grégoire, Edition AUF, « Cours Multimédias et QoS », 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] M. Handley, V.Jacobson, « SDP: Session Description Protocol », RFC 2327, April 1998.
[5] B. Adamson, C. Bormann, M. Handley, J. Macker, “Negative-acknowledgment (NACK)-
Oriented Reliable Multicast (NORM) Protocol”, RFC 3940 November 2004.
[6] B. Adamson, C. Bormann, M. Handley, J. Macker, “Negative-Acknowledgment
(NACK)-Oriented Reliable Multicast (NORM) Building Blocks”, RFC 3941, November
2004.
[7] J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg, “RTP Retransmission Payload
Format”, RFC 4588, July 2006.
[8] Vincent Roca, « Un Etat de l’Art sur les Techniques de Transmission Multipoint Fiable »,
Distributed Systems Engineering (DSE) Community, décembre 2001.
[9] Florestan de Belleville, « Transport multipoint fiable à très grande échelle : Intégration de
critères de coût en environnement Internet hybride satellite / terrestre », Thèse pour le
doctorat en Réseaux et Télécommunications de l’Institut National Polytechnique de Toulouse,
Octobre 2004.
[10] Philippe GASSER, « Visioconférence : les technologies d’aujourd’hui », MSH Paris nord
- Plate forme Arts, Sciences, Technologies, Janvier 2005.
[11] Nonnenmacher, Jörg; Biersack, Ernst W, “Scalable feedback for large groups”
IEEE/ACM Transactions on Networking, Volume 7 N°3, June 1999, pp /375-386/.
[12] Georg Carle, Ernst W. Biersack, “Survey of Error Recovery Techniques for IP based
Audio-Visual Multicast Applications”, IEEE Network Magazine, Volume 11, N°6,
November/December 1997, pp /24-36/.
[13] L. Vicisano, L. Rizzo, and J. Crowcroft, "TCP-like congestion control for layered
multicast data transfer ", IRTF RM Workshop September 1997, Cannes, September 1997.
[14] L. Rizzo and L. Vicisano, "A Reliable Multicast data Distribution Protocol based on
software FEC techniques (RMDP)", In Proceedings of HPCS'97 Workshop, Chalkidiki,
Grece, June 1997, IEEE.

16