Amélioration des flux temps réel sur les réseaux IP

Amélioration des flux temps réel sur les réseaux IP Rapport de Stage MASTER 2 RECHERCHE «Systèmes, réseaux et architecture» Présenté par : Houssein WEHBE juin 2008 Encadré par : Bernard COUSIN et Gérard BABONNEAU

1

Remerciements Je tiens à remercier dans un premier temps, toute l équipe pédagogique de l IFSIC et les intervenants responsables de la formation du master 2 recherche «systèmes, réseaux et architecture». Je remercie également, avec toute ma reconnaissance, Monsieur Bernard COUSIN pour l aide et les conseils concernant les travaux évoqués dans ce rapport. Je tiens à remercier tout particulièrement Gérard BABONNEAU, pour m avoir intégré rapidement au sein du laboratoire de France télécom R&D et m avoir accordé toute sa confiance ; pour le temps qu il m a consacré tout au long de cette période, sachant répondre à toutes mes interrogations ; ainsi que pour l expérience enrichissante et pleine d intérêt qu il m a fait vivre durant ces cinq mois au sein du laboratoire; sans oublier sa participation au cours du cheminement de ce rapport. Je remercie également le personnel du laboratoire MAPS/DPC de France télécom R&D pour leur accueil sympathique et leur coopération professionnelle tout au long de ces cinq mois. 2

Résumé Les premières applications distribuées ont été caractérisées par des contraintes d ordre et de fiabilité sur les données transmises (i.e. transfert de fichiers, courrier électronique, accès aux pages Web, etc.). De ce fait, les premiers services de communication ont été spécifiquement conçus pour répondre à ces besoins. Les protocoles de transport TCP et UDP sont des exemples de cette vision restrictive de la conception des services de communication. Le protocole TCP offre un service totalement fiable et totalement ordonné alors que le protocole UDP fournit un service non fiable et non ordonné. Aujourd hui, de nouvelles applications présentant des contraintes de qualité de service plus complexes ont été conçues. Les applications telles que la vidéo à la demande présentent de fortes contraintes temporelles, de bande passante et de synchronisation multimédia. Afin de répondre à ces contraintes, le transport des flux audiovisuels sur Internet utilise principalement les protocoles RTP et RTCP au dessus de UDP. Mais, en l absence de moyens de réparation des anomalies de transport, la qualité reçue n est pas garantie. De fait, il s agit d une difficulté intrinsèque au temps réel : tout procédé, introduit pour corriger les faiblesses d une transmission, exige du temps et des ressources supplémentaires qui sont parfois incompatibles avec les contraintes temps réels du flux multimédia ou celles du réseau. Pour garantir les délais d arrivée des données, des compromis sont à réaliser entre plusieurs contraintes, dont certaines peuvent se révéler contradictoires. L objet du stage est d étudier les différents mécanismes de correction d erreurs ainsi que de proposer une solution d optimisation appliquée aux protocoles RTP et RTCP, et conforme aux standards définis à l IETF. Nos travaux, présentés dans ce document, aboutissent à des compromis acceptables, et au mieux à des améliorations de la QoS (Qualité de Service). La solution proposée est validée dans un environnement de simulation de réseau (OPNET) afin d exhiber ses avantages et inconvénients, notamment lorsque les erreurs arrivent par rafale. 3

Sommaire Introduction... 8 Chapitre 1 : État de l art de la transmission sur Internet... 11 1. Introduction... 11 2. Les protocoles de transmissions... 11 2.1 Les protocoles non adaptés aux applications multimédia... 11 2.1.1 Le protocole TCP... 11 2.1.2 Le protocole HTTP... 12 2.2 Les protocoles adaptés aux applications multimédia... 12 2.2.1 Le protocole UDP... 12 2.2.2 Le protocole RTP... 13 2.2.3 Le protocole RTCP... 13 2.2.4 Le protocole RTSP... 14 2.3 Conclusion des protocoles... 15 3. Les mécanismes de contrôle d erreur... 16 3.1 La régulation du débit... 16 3.1.1 Cas point à point... 17 3.1.2 Cas du multipoint... 18 3.1.3 Conclusion sur la régulation du débit... 19 3.2 Contrôle d erreurs par anticipation... 19 3.3 Contrôle d erreurs par retransmission... 21 3.3.1 Mécanismes basés sur un accusé de réception... 21 3.3.2 Mécanismes basés sur un accusé de non réception... 22 4. Conclusion... 23 Chapitre 2 : La réparation par retransmission... 25 4

1. Introduction... 25 2. Description de la solution... 25 2.1 Principe de fonctionnement... 25 2.2 Exemple d utilisation des paramètres N et P... 26 2.3 Le choix des paramètres... 27 2.3.1 Les paramètres utilisés par l émetteur... 27 2.3.2 Les paramètres utilisés par le récepteur... 29 2.3.3 Conclusion du choix des paramètres... 31 3. Validation de la solution... 31 3.1 Les modèles de perte utilisés... 32 3.1.1 La perte uniforme... 32 3.1.2 La perte par rafale... 32 3.2 Les simulations effectuées... 33 3.2.1 Les simulations dans le cas du débit constant (CBR)... 33 3.2.2 Les simulations dans le cas du débit variable (VBR)... 38 4. Conclusion... 40 Conclusion... 43 Références... 44 5

Table des figures Figure 1 Représentation d'un système de communication vidéo...8 Figure 2 Figure 3 Figure 4 RTT est le moment de réception du rapport (RR) le temps d émission du dernier rapport (SR)- le délai entre les deux rapports... 14 Scénario de transmission des données multimédia en utilisant les protocoles RTSP et RTP/RTCP au dessus de UDP... 15 Les paquets FEC générés chez l émetteur seront transmis avec les paquets RTP. Le récepteur les utilise pour reconstruire les paquets perdus... 20 Figure 5 Exemple de fonctionnement du modèle avec N=6... 26 Figure 6 Exemple de fonctionnement du modèle avec N=6; le Nième paquet est perdu... 27 Figure 7 RtxTime est en relation avec la durée des rafales et le rapport entre les débits d émission et de retransmission... 29 Figure 8 La taille du buffer est égal au Débit d émission*(rtxtime+d) avec D=RTT... 30 Figure 9 Le pourcentage des paquets perdus après la retransmission par rapport à RtxTime; RtxTime varie entre 500 et 1200 ms; RTT varie entre 100 ms (courbe verte), et 200 ms (courbe bleu) et 400 ms (courbe rouge)... 34 Figure 10 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte uniforme, sans perte lors de la retransmission et sur le NACK; RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 et 23.... 35 Figure 11 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte uniforme, sans perte lors de la retransmission et sur le NACK; RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 et 28... 35 Figure 12 La variation du débit remontant par rapport à celle de N (courbe bleu pour N=1 et courbe rouge pour N=10, )... 36 Figure 13 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte uniforme, avec perte lors de la retransmission et sur le NACK; RtxTime varie entre 500 ms et 1200 ms ; N varie entre 10 et 28.... 36 Figure 14 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte par rafale, avec perte lors de la retransmission et sur le NACK RtxTime varie entre 500 ms et 1200 ms ; N varie entre 10 et 28... 36 Figure 15 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte uniforme, sans perte lors de la retransmission et sur le NACK; RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 et 60... 37 6

Figure 16 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte par rafale, sans perte lors de la retransmission et sur le NACK; RtxTime varie entre 500 ms et 1200 ms ; N varie entre 1 et 60... 37 Figure 17 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte uniforme, avec perte lors de la retransmission et sur le NACK; RtxTime varie entre 500 ms et 1200 ms ; N varie entre 50 et 59... 38 Figure 18 La variation du débit remontant par rapport à celle de N (courbe bleu pour N=1 et rouge pour N=50,..)... 38 Figure 19 Changement du débit d'émission entre 1 et 5 Mbs... 38 Figure 20: Variation de la perte et du débit d'émission en fonction du temps; la courbe rouge est le nombre des paquets perdus à un instant donné... 39 Figure 21 La capacité du modèle à corriger les pertes... 40 Figure 22 Le pourcentage des paquets perdus après la retransmission en fonction de RtxTime; perte par rafale, sans perte lors de la retransmission et sur le NACK; RtxTime varie entre 500 ms et 1200 ms ; N varie entre 27 et 30.... 40 Figure 23 Le pourcentage des paquets corrigés par rapport aux paquets perdus pour plusieurs taux de perte; perte uniforme avec une perte sur les NACK et lors de la retransmission : résultat de notre modèle... 41 Figure 24 Le pourcentage des paquets corrigés par rapport aux paquets perdus pour plusieurs taux de perte; perte uniforme avec une perte sur le NACK et lors de la retransmission : résultat du modèle décrit par Rishi et Christos... 41 7

Introduction Les avancées dans le domaine des réseaux informatiques, ont permis le développement de nouveaux services interactifs sur Internet pour répondre aux besoins toujours plus importants et diversifiés des utilisateurs. Si aux débuts de l Internet (les années 80) les transferts de données dans les réseaux concernaient surtout des formats très simples, comme le texte ou l image fixe, les données multimédia occupent aujourd hui une part importante de la bande passante. Ces données sont celles qui posent le plus des problèmes pour leur transport, compte tenu de leurs particularités : volume important, contraintes temporelles, etc. Fournir le support et la technique de communication pour tous ces services est un défi adressé aux sciences et technologies de l information et de la communication. Des normes plus au moins adéquates standardisent les formats des données à transférer selon des protocoles de communication variés, sans pour autant répondre totalement aux besoins des utilisateurs. Ce stage s inscrit dans la problématique de la transmission de données temps réel telles que la vidéo sur Internet, en essayant d apporter des solutions simples à ce problème. On peut généralement considérer qu un système de communication vidéo est constitué de cinq parties (voir Figure 1) [13]. La séquence est dans premier temps compressée par un codeur 1 vidéo. Le flux généré est ensuite segmenté en paquets de tailles fixes ou variables et pourra être multiplexé avec d autres données telles que les données audio, des pages HTML, etc. Les paquets pourraient être transmis directement sur le réseau si celui-ci garantissait un transport sans perte. Cette condition n étant généralement pas remplie, on applique une protection par redondance au niveau du canal (niveau physique) avant la transmission pour protéger les données. Figure 1: Représentation d'un système de communication vidéo Au niveau du récepteur, on exploite la redondance pour reconstituer les informations perdues. A moins de posséder des liens dédiés à une application particulière et garantissant une 1 Pour économiser de l espace et de bande passante, les séquences vidéo sont compressées en utilisant, par exemple, le format MPEG. Celui-ci utilise des techniques de prédiction avec compensation de mouvement pour réduire au minimum les informations additionnelles. 8

certaine qualité de service (QoS), on constate lors d une transmission des pertes des paquets essentiellement dues à des phénomènes de congestion sur le réseau Internet. En effet, le réseau Internet offre un simple service : le service best effort [6] [20]. Un tel modèle de service permet aux routeurs d être sans état et de ne garder aucune information de grain fin à propos du trafic. Par ailleurs, l utilisation de l Internet est libre de toute tarification puisque les mêmes ressources sont disponibles pour tous les utilisateurs. L inconvénient est que, puisqu il n y a pas de contrôle d admission, le réseau peut être perturbé par des utilisateurs trop gourmands. En effet, si le débit avec lequel le trafic est dirigé sur les interfaces dépasse la vitesse avec laquelle ces mêmes interfaces sont capables d acheminer le trafic vers l aval, des congestions peuvent se produire. Le trafic en excès est placé dans les files d attente des dispositifs physiques jusqu à débordement de ces files. Ainsi, les applications peuvent faire l expérience de pertes de paquets. Cependant, on peut regrouper les mécanismes de contrôle d erreurs suivant trois catégories : l introduction de redondance (code FEC «Forward Error Correction») par le codeur source rendant le flux vidéo plus résistant aux pertes. En effet, le récepteur utilise ces informations pour reconstruire les paquets perdus; Les mécanismes nécessitant une interaction entre l émetteur et le récepteur, et permettant aux codeurs de source de s appuyer sur les conditions de réception mesurées par le récepteur pour adapter leur codage ; les mécanismes de réparation par retransmission. Comme nous le verrons par la suite, les mécanismes prenant en compte lors du codage les caractéristiques du réseau (le code FEC et la régulation du débit) ne sont pas compatibles avec des contraintes temps réel. L objectif de ce stage est de concevoir un mécanisme de contrôle d erreurs capable d assurer une qualité de service convenable à des applications temps réel (comme la vidéo à la demande (VoD)) transmises dans un environnement hétérogène aux caractéristiques varient dans le temps. Une méthode simple permettant de réduire les erreurs de transmission consiste à mise en œuvre de réparation par retransmission. Cette méthode s appuie sur les standards IETF RFC 4585 (RTCP Feedback) [3] et RFC 4588 (RTP retransmission) [5] où les récepteurs demandent une retransmission des paquets perdus. En effet, la perte des paquets sera détectée en analysant les numéros de séquence des paquets correctement reçus (car l émetteur numérote les paquets envoyés). Cependant, il ne faut pas oublier, en utilisant la méthode de retransmission, qu une remontée de très nombreux messages peut charger inutilement le serveur et risque de dégrader ses performances. Pour cela, il faut définir un mode particulier pour limiter les requêtes de retransmission remontées vers le serveur. Ajoutons qu en raison de la nature temps réel des flux vidéo, le client ne doit pas attendre trop longtemps avant d envoyer ses requêtes. En effet, si ensuite le temps de réception des données retransmises est trop long, les paquets de correction des pertes risquent d'arriver après le temps de fourniture des données au décodeur. Dans ce rapport nous proposerons une méthode allant dans ce sens. Afin de montrer la validité de cette méthode, nous avons implémenté, sous OPNET 2, un modèle de simulation qui modélise le système VoD [8] (un serveur et un client connectés). Notre but est de déterminer les optimisations de la solution, en particulier le compromis entre 2 OPNET permet la modélisation et la simulation de réseaux de communication grâce à ses bibliothèques de modèles (routeurs, commutateurs, ) et de protocoles (TCP/IP, FTP,...). 9

la latence, la taille du tampon de réception et le surdébit disponible. Ce modèle nous permet de vérifier l efficacité du procédé en fonction des profils de pertes. En effet, le taux de pertes correspond au rapport du nombre de paquets non arrivés sur le nombre total de paquets transmis. Nous avons réalisé des simulations avec un haut taux de perte (10% des paquets transmis) en utilisant plusieurs modèles de perte comme la perte par rafale. Ce modèle représente le cas pire de perte où périodiquement un grand nombre des paquets groupés sont perdus. Il s agit, en effet, d introduire un bruit impulsif élevé sur les deux voies du réseau restant un certain temps. Les résultats obtenus ont montré la validité de notre méthode dans les systèmes VoD, en vérifiant que les paquets perdus sont retransmis et arrivés au récepteur en respectant les contraintes temps réel. Nous présenterons dans le chapitre 1 de ce document un état de l art introductif sur la transmission des données multimédia sur Internet. Nous expliquerons les principaux protocoles utilisés ainsi que les différents mécanismes de contrôle d erreur. Dans ce chapitre on va montrer les contraintes limitant l utilisation du mécanisme de régulation de débit (TCP, TCP-fiendly ) et de redondance dans les paquets envoyés (le code FEC). Puis nous proposons dans le chapitre 2 une méthode de contrôle d erreur basée sur la retransmission. Ce chapitre contient les détails des simulations effectués ainsi que les principaux résultats obtenus. 10

Chapitre 1 : État de l art de la transmission sur Internet 1. Introduction L échange des données multimédia sur Internet se fait selon un modèle client/serveur. Le serveur délivre le fichier vidéo vers les internautes qui en ont fait la requête. Le lecteur se met à jouer la vidéo après quelques secondes nécessaires pour remplir un tampon («buffer») qui stocke des données en avance pour pallier à la gigue des images dans la transmission. Au fur et à mesure de la lecture, des données de contrôle sont envoyées au serveur pour l informer des conditions de réception du flux. Le serveur s adapte en conséquence, accélérant ou ralentissant le transfert des paquets. Cette technologie de transmission s appelle «streaming» [19] [20]. Elle permet de commencer à visualiser la vidéo avant que la totalité des données soit téléchargée. Le principal avantage de cette technologie est que l on n a pas besoin d attendre le téléchargement complet d un fichier et aucune donnée n est stockée sur le disque dur. Notons que dans l industrie on appelle cette technologie («Download Progressif») et le terme streaming sera utilisé pour les applications vidéo en directe «live». La plupart des programmes de streaming (ou de «dowonload progressif») existant sont basées sur l'utilisation d un ensemble des protocoles de transmission pour délivrer les données vidéo compressés. Les protocoles le plus utilisable sont TCP, UDP, RTP, HTTP et RTSP. Chaque protocole configure les données en paquets, en ajoutant pour chaque paquet un en-tête identifiant son contenu. Dans ce chapitre on va expliquer en détail chacun de ces protocoles ainsi nous expliquerons les différents mécanismes utilisés pour résoudre le problème de congestion sur le réseau Internet. En effet, c est le problème principal de notre stage et une étude des solutions existants permet de bien comprendre notre solution. 2. Les protocoles de transmissions Nous expliquerons dans ce paragraphe les protocoles de transmission standards sur Internet. Ces protocoles peuvent être regroupés en deux groupes : protocoles qui ne sont pas adaptés aux applications multimédia et les protocoles adaptés à ces applications. 2.1 Les protocoles non adaptés aux applications multimédia TCP est le protocole le plus utilisable sur Internet. Il possède beaucoup des avantages mais son problème principal est qu il est lent et non adapté pour les applications multimédia. Il travaille au dessous de HTTP. Par conséquent, HTTP n est pas adapté pour ces applications. 2.1.1 Le protocole TCP TCP [15] («Transmission Control Protocol») est un protocole conçu pour fournir un service de transmission de données sécurisé entre deux machines raccordées sur un réseau de paquets. Il offre un certain nombre de fonctionnalités : Transfert de données de base : TCP est capable de transférer un flux continu de données entre deux ordinateurs, en découpant ce flux en paquets. 11

Correction d erreur : TCP doit considérer et traiter les cas de données perdues, erronées, dupliquées, ou arrivées dans le désordre à l autre bout de la liaison Internet. Ceci est réalisé par l insertion d un numéro de séquence, et par l obligation d émission d un «accusé de réception» (ACK) par le destinataire. Si l accusé de réception n est pas reçu au bout d un temps prédéfini (RTO «Retransmission TimeOut»), le paquet sera réémis. Contrôle de flux : TCP fournit un moyen au destinataire pour contrôler le débit de données envoyé par l émetteur. Ceci est obtenu en retournant une information («window») indiquant le nombre d octets que l émetteur peut envoyer avant une autorisation ultérieure. L émetteur règle par la suite son débit d émission et s adapte pour répondre aux besoins du destinataire. Gestion de connexions : Les mécanismes de fiabilisation et de contrôle de flux imposent à TCP l initialisation et la maintenance de certaines informations pour chaque communication (numéro de port de l émetteur et du récepteur, adresse du récepteur.). La combinaison de ces informations formera une connexion. Un grand avantage de TCP, déduise de ses fonctionnalités, réside dans la fiabilité de la communication offerte. Cependant, ses inconvénients pour la transmission de données multimédia sont les retards qu il peut accumuler en essayant de corriger les données manquantes (l utilisation de la retransmission). TCP utilise un mécanisme de correction d erreurs basé sur la régulation de débit (contrôle de flux). On va expliquer dans la deuxième partie de ce chapitre ( 3.1) les limites de ce mécanisme. 2.1.2 Le protocole HTTP Le protocole de transfert hypertexte (HTTP) [6] est le protocole standard sur le Web. Il s agit d un protocole du niveau application, en générale implémenté au dessus de TCP. Il offre un standard de communication entre les serveurs et les clients Web, mais n est pas adapté au streaming audio-vidéo (il possède les mêmes défauts que TCP s il utilise TCP comme support). Notons qu il est parfois utilisé pour les flux UDP mais sans garantie de pouvoir fournir le temps réel. 2.2 Les protocoles adaptés aux applications multimédia UDP est un protocole qui travaille au niveau transport. Différemment au TCP, il est adapté aux applications multimédia mais il possède un certains limites, pour cela il sera utilisé avec le protocole RTP. 2.2.1 Le protocole UDP Le protocole UDP [6] («User Datagram Protocol») utilise IP pour acheminer en mode non fiable, d un ordinateur à un autre, des datagrammes qui lui sont transmis par une application. UDP n utilise pas d accusé de réception et ne peut donc pas garantir que les données ont bien été reçues. Il ne réordonne pas les messages si ceux-ci n arrivent pas dans l ordre dans lequel ils ont été émis et il n assure pas non plus de contrôle de flux. UDP est souvent utilisé par les applications multimédia, mais il ne permet pas d adapter la transmission au type de données transportées. 12

2.2.2 Le protocole RTP RTP [1] («Real-time Transport Protocol») est un protocole basé sur IP fournissant un support pour le transport des données en temps réel comme la vidéo. Il travaille au dessus de UDP. Les services fournit par RTP consistent dans la reconstruction temporelle, la détection de pertes, la sécurité et l identification du contenu. Il fourni des services de bout en bout pour des applications qui nécessitent un temps réel comme l audio et la vidéo interactive. Cependant, RTP ne fournit aucun mécanisme pour assurer la délivrance à temps. Les fonctionnalités de ce protocole sont assurées en ajoutant des en-têtes RTP aux paquets de données avant de les envoyer. Ces entêtes formés de 12 octets, précédent la charge utile «payload». On trouve par exemple : Le champ séquence number : (16 bits), sa valeur initiale est aléatoire et il s incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets perdus. Le champ timestamp : (32 bits), reflète l instant où le premier octet du paquet RTP à été échantillonné. Cet instant doit être dérivé d une horloge qui augmente de façon monotone et linéaire dans le temps permettre la synchronisation à la destination. Le champ SSRC : (32 bits), identifie de manière unique la source, sa valeur est choisie de manière aléatoire par l application. Le champ SSRC identifie la source. Cet identification est choisi de manière aléatoire avec l intérêt qu il soit unique parmi toutes les sources d une même session. Le champ Payload Type PT : (1 bit), identifie le type des données transporté (audio ou vidéo) afin d adapter le transport selon ce type. RTP est conçu pour travailler en conjonction avec le protocole RTCP afin d obtenir des retours concernant la qualité de la transmission et des informations au sujet des participants pour la session à réaliser. 2.2.3 Le protocole RTCP RTCP [21] («Real Time Control Protocol») est un protocole de contrôle désigné pour travailler en conjonction avec RTP. Il est standardisé dans la recommandation RFC 1889 [21] et RFC 1890 [22]. Dans une session RTP, les participants envoient périodiquement des paquets RTCP pour donner des informations aux autres membres sur la qualité de service délivré. Le RFC 1889 [21] défini 5 types de paquets pour transporter cette information de contrôle : RR (Receiver Report), SR (Sender Report), SDES (Source description), BYE (indique la fin de la participation), AP (fonction spécifique application). En plus de la génération de ces cinq5 types de paquets, RTCP offre les services suivants : Contrôle de la congestion: Ceci constitue la fonction primordiale de RTCP. Ce protocole fournit un feed-back à l application au sujet de la qualité de distribution des données. L information de contrôle est utile aux émetteurs et aux récepteurs. L émetteur peut ajuster sa transmission en se basant sur le rapport du récepteur. Information de contrôle : Les paquets RTCP sont envoyés périodiquement parmi les participants. Quand le nombre de participants augmente (ce qui peut être le cas 13

dans une session multicast), il est nécessaire de limiter les informations de contrôle pour éviter que le trafic de contrôle dépasse le 5% du trafic total de la session. Les paquets RTCP contient des différentes informations sur la qualité de transmission. On trouve par exemple : le nombre des paquets perdus, le nombre des paquets correctement reçus, etc. L en-tête RTCP contient également un champ DSLR (32 bits) : c est le délai depuis le dernier rapport reçu. On peut utiliser ce champs avec des autres informations pour calculer le temps aller retour RTT. Rapport SR Rapport RR Figure 2: RTT est le moment de réception du rapport (RR) le temps d émission du dernier rapport (SR)- le délai entre les deux rapports Le couple RTP/RTCP offre des fonctionnalités et des mécanismes de contrôle nécessaires pour transporter les flux en temps réel. En complément, le contrôle des flux est assuré par le protocole RTSP. 2.2.4 Le protocole RTSP RTSP [6] («Real Time Streaming Protocol») est un protocole conçu pour transférer, contrôler et synchroniser un ou plusieurs flux temps réel comme la vidéo et l'audio. Le protocole est fondé sur le modèle client-serveur. Il permet le contrôle de la présentation d'un objet média transmis entre le client et le serveur. Autrement dit, les commandes de contrôle de la présentation d'un objet média (comme démarrer, stopper, faire une pause, etc.) sont traduites sous forme de requêtes d'accès RTSP envoyées par le client et exécutées par le serveur. RTSP hérite de toute la syntaxe de HTTP, de ses mécanismes de sécurité et de ses procédures d'extension (structure des URL: rtsp://). En détaillant le mécanisme de la communication, le serveur RTSP (serveur contenant les vidéos) maintient, pour chaque transfert de données, une session désignée par un identificateur unique. Pendant une session, le client RTSP peut ouvrir et fermer plusieurs connexions avec le serveur RTSP en utilisant l identificateur de cette session. Ces connexions sont établies afin d'échanger les requêtes RTSP entre le client et le serveur. Ces requêtes peuvent être des requêtes d'initialisation de session, de transfert de données et de contrôle de 14

ces flots de données. Les différentes requêtes RTSP sont définies à travers un ensemble des méthodes. Les principales méthodes sont : DESCRIBE : Elle est utilisée par le client pour récupérer la description d'une présentation ou d'un objet média, identifié par un URI, sur un serveur RTSP. SETUP : Elle est utilisée par le client pour spécifier au serveur les paramètres de transport du flot média, comme par exemple le type de protocole de transport (RTP), le mode de transport (point à point ou multipoint) et le numéro du port de communication. PLAY : Elle signale au serveur qu'il peut commencer à envoyer les données via le mécanisme spécifié dans la méthode SETUP. Elle permet également de jouer un ou plusieurs sous-intervalles de la durée d'un objet média, par exemple jouer une audio à partir de la 10 éme seconde jusqu'à la 20 éme seconde. PAUSE : Elle est utilisée par le client pour demander au serveur d'interrompre temporairement le transfert du flux média. Le client peut reprendre la transmission du flux en envoyant la requête PLAY au serveur. TEARDOWN : Elle est utilisée par le client pour demander au serveur d'arrêter définitivement le transfert du flux média. La Figure 3 donne un exemple d utilisation de RTSP avec les autres protocoles Figure 3: Scénario de transmission des données multimédia en utilisant les protocoles RTSP et RTP/RTCP au dessus de UDP 2.3 Conclusion des protocoles Pour le transport des flux multimédia, TCP ne convient pas car il est lent et il utilise des mécanismes de régulation de débit pour contrôler la congestion (voir le paragraphe suivant 3.1). C est donc le protocole UDP qui a été choisi comme protocole de transport des 15

paquets multimédia temps-réel sur Internet. Mais le protocole UDP n offre aucun mécanisme de contrôle de débit ou des pertes. UDP ne coopère pas non plus avec les autres flux pour la gestion de la congestion dans le réseau. Le protocole RTP, protocole de bout en bout définit par l IETF et porté par UDP a été défini pour le transport des flux continus et temps-réel. C est un protocole non orienté connexion, et qui n offre aucune garantie de fiabilité. Il apporte uniquement la capacité de distinguer les différents types de média (sous-module) et de détecter la perte des paquets. Ce protocole est composé de deux parties : une partie dédiée au transfert de données (RTP), l autre au contrôle (RTCP). Le protocole de contrôle RTCP transporte des paquets contenant l information nécessaire au contrôle de congestion. Les récepteurs envoient des rapports de réception aux membres de la session, ce qui permet à l émetteur de récupérer des informations sur les numéros de séquence reçus, le taux de perte, une mesure de la variance du délai d arrivée, une estimation du délai d aller-retour, etc. L émetteur peut utiliser ces informations pour s adapter en appliquant un mécanisme de contrôle de congestion. Plusieurs études ont été faites pour trouver des mécanismes optimums permettant le contrôle de congestion. Trois mécanismes ont été proposés. L émetteur peut choisir un de ces mécanismes pour s adapter. Dans la suite de ce chapitre on va expliquer ces mécanismes avec leurs avantages et leurs limites. 3. Les mécanismes de contrôle d erreurs Lorsque l agrégation des trafics transitant dans un point du réseau excède les capacités de traitement des équipements intermédiaires (routeurs), des phénomènes de congestion se produisent. Ceci aboutit à la saturation des files d attente de ces équipements puis à la destruction, faute de place, de paquets de données. Différentes mécanismes sont utilisés pour contrôler la congestion. On peut regrouper ces mécanismes selon trois catégories : Les mécanismes nécessitant une interaction entre l émetteur et le récepteur, et permettant aux codeurs de source de s appuyer sur les conditions de réception mesurées par le récepteur pour adapter leur codage (la régulation de débit); l introduction de redondance (code FEC) par le codeur source rendant le flux vidéo plus résistant aux pertes ; les mécanismes de réparation par retransmission. Dans ce paragraphe on va expliquer chacun de ces mécanismes et montrer les limites de solutions existantes afin de proposer une nouvelle solution basée sur le troisième mécanisme dans le chapitre suivant. 3.1 La régulation du débit Beaucoup des méthodes de contrôle de congestion ont pour but de réguler le débit de la source de manière à satisfaire au mieux les récepteurs et en tentant de limiter la congestion. Ceci nécessite notamment une bonne réactivité des mécanismes de contrôle, mais aussi un partage de débit équitable entre les différentes applications. Le protocole TCP, protocole le plus utilisé sur Internet, assure une bonne équité ainsi qu une bonne réactivité. Toutefois, ce protocole ne peut être utilisé par les applications temps réel. Il s appuie en effet sur une méthode de contrôle d erreur basée ARQ («Automatic Repeat Request») et génère des débits trop saccadés pour des applications demandant une QoS (Qualité de Service) stable. On lui préférera donc des protocoles tels que RTP/RTCP ou UDP. Toutefois, ces deux derniers protocoles ne spécifient pas de mécanisme de contrôle de congestion. Ils peuvent donc ne pas répondre aux signes de congestion, alors que TCP y répondra en réduisant le débit de ses 16

applications. En laissant TCP supporter seul l évitement de congestion, on obtient inévitablement un partage inéquitable des ressources réseaux [16] [19]. Pour éviter cela, il faut absolument que chaque application mette en œuvre son propre mécanisme de contrôle de congestion. D autre part, puisque le trafic dominant sur Internet s appuie sur le protocole TCP, il paraît important que ces mécanismes de contrôle se comportent équitablement (amicalement) avec TCP. Ces méthodes tenant de calquer leur comportement sur celui de TCP sont regroupées sous l appellation TCP-friendly ou TCP-compatibles. L objectif de ces mécanismes n est toutefois pas de miner intégralement le comportement de TCP. La régulation qu ils offrent engendre en générale des variations de débit plus douces que TCP, assurant ainsi une QoS plus stable à l application. 3.1.1 Cas point à point Parmi les mécanismes de contrôle de congestion TCP-compatible RAP (Rate Adaptation Protocol) proposée dans [23] est certainement le protocole dont le comportement est le plus proche de TCP. La majorité des opérations sont réalisées à la source, le récepteur se contentant de renvoyer un ACK pour chaque paquet reçu. En utilisant cette voie de retour l émetteur peut détecter les pertes et calculer le RTT (Round Trip Time : temps d allerretour). Il augmentera périodiquement son débit d émission si aucune congestion n est détectée et le diminuera immédiatement dans le cas contraire. RAP utilise donc un algorithme d Augmentation Additive et de Diminution Multiplicative du débit (AADM (AIMD : Additive Increase Multiplicative Decrease)). La remise à jour du débit d envoie se fait tous les RTT et se traduit par une modification de l intervalle de temps séparant l envoi de deux paquets de données. Alors que RAP est plutôt basée observation des pertes, TFRC (TCP Friendly Rate Control) est basée débit. Ce schéma adapte le débit de la source en se basant sur la modélisation du débit de TCP en fonction des pertes proposée par Padhye et al. dans [27] : Où Peve, RTT, s et trto représentent respectivement le taux d évènements de pertes, le RTT, la taille des paquets et le temps au delà duquel on considère qu un paquet est perdu et qu il faut le retransmettre (temps d expiration : timeout). Le taux d événement de pertes s appuie sur les notions d événement de pertes et d intervalle de pertes. Un événement de pertes est défini comme une ou plusieurs pertes se produisant pendant un RTT. Le nombre de paquets séparant deux évènements de pertes constitue un intervalle de pertes. Pour obtenir le taux d évènements de pertes on calcule une moyenne pondérée des derniers intervalles de pertes 17

Où les li représentent les derniers intervalles de pertes mesurées, mhisto est la taille de l historique et les wi sont les pondérations. La pondération donne plus d importance aux derniers intervalles. Le taux d évènements de pertes est alors donné par l inversion de l intervalle de perte moyen. L utilisation du taux d évènements de pertes plutôt que le taux de pertes classique permet de réagir plus doucement aux congestions et d obtenir une meilleure stabilité du débit. Le taux d évènements de pertes est calculé au récepteur une fois par RTT et envoyé à l émetteur. Celui-ci remettra à jour son débit d émission dès réception de l information de retour. Une étude a comparée ces deux protocoles sous le simulateur réseau NS [28]. Les tests montrent que ces deux protocoles permettent tous les deux d obtenir des débits similaires à ce qu aurait donné TCP dans des conditions identiques. On constate toutefois un partage de bande passante plus équitable entre TFRC et TCP qu entre RAP et TCP. Les résultats montrent aussi que ces deux protocoles se comportent mieux en présence de taux de pertes faibles inferieurs à 5% et qu au delà de cette valeur l équité n est plus vérifiée. 3.1.2 Cas du multipoint Les solutions de bout en bout utilisées en point à point ne sont plus envisageables en multipoint. Il n est plus possible de permettre à chaque récepteur de transmettre directement des informations à l émetteur sous peine d écrouler la voie de retour. D autre part en imaginant que cette solution soit envisageable, on ne peut imaginer que l émetteur puisse considérer les informations de chaque récepteur une à une et ajuste à chaque fois son débit en conséquence. Il paraît pourtant important d obtenir un partage équitable de la bande passante avec les applications téléinformatiques en multipoint qu en point à point. Certains auteurs se sont donc attachées à obtenir des mécanismes de contrôle de congestion TCP-compatible en multipoint. Parmi ces approches on trouve dans [17] une adaptation de TFRC au multipoint appelée TFMCC (TCP-Friendly Multicast Congestion Control). L approche TFMCC s appuie elle aussi sur l équation utilisée par TFRC modélisant le comportement de TCP. A la différence de TFRC toutefois ce sont les récepteurs qui calculent leur RTT et estiment leurs débits. Cette information est périodiquement envoyée vers l émetteur. Si un récepteur renvoie une information de retour (feedback) indiquant un débit plus faible que le débit actuel de la source celle-ci réduira immédiatement son débit au débit indiqué. De manière à éliminer un grand nombre de feedback, seuls les récepteurs estimant un débit plus faible que le débit de la source transmettent une information. L un des points clef de TFMCC est de permettre à tous les récepteurs d estimer leur RTT sans pour autant augmenter le trafic. Un protocole similaire nommé PGMCC (Pragmatic General Multicast Congestion Control) a été proposé dans [25]. Ce schéma s appuie sur PGM [24], un protocole de robustification de session multipoint. Ce protocole est basé sur l utilisation d accusés de réception négatifs (NACK) à la détection de chaque paquet perdu. Une procédure de suppression des feedbacks permet de limiter la quantité de NACK. Dans le même but que TFMCC, de nouvelles fonctionnalités dans les routeurs sont aussi envisagées. Elles permettraient de supprimer les 18

NACK identiques provenant d un même ensemble des récepteurs. PGM ne spécifie toutefois pas de mécanisme de contrôle de congestion et considéré des sources à débit fixe. PGMCC peut donc être vu comme une évolution de PGM permettant le contrôle de congestion. Comme dans TFMCC ce protocole sélectionne le récepteur le plus faible (nommé «acker») parmi l ensemble des récepteurs. Chaque récepteur est capable d estimer son débit de réception maximum. De plus chaque paquet de données transporte des informations sur le acker courant de sorte qu à chaque instant tous les récepteurs peuvent comparer leurs débits à celui du acker et devenir acker le cas échéant. Un mécanisme de contrôle de congestion similaire à celui de TCP est mis en place entre l émetteur et le acker qui transmettra un ACK pour chaque paquet reçu. Le acker contrôle donc le débit d émission ainsi que les éventuelles retransmissions. TFMCC et PGMCC se comportent équitablement avec TCP. On remarque toutefois que la régulation de débit de PGMCC a plus tendance à générer des débits en dents de scie assez proche de ce que donne TCP. Pour cela TFMCC est plus utilisable. 3.1.3 Conclusion sur la régulation du débit On peut considérer que le problème de régulation de débit reste ouvert. Des solutions très efficaces ont pourtant été proposées pour des points particuliers. On peut ainsi citer TFRC qui offre un mécanisme efficace de régulation de débit en point à point. L une des limitations de TFRC est que ce protocole ne prend pas en compte la nature des flux transportés (cette constatation a amenée Vieron et al. [19]). D où le besoin de proposer un protocole basé sur RTP/RTCP et destiné à mieux prendre en compte les caractéristiques des flux multimédia dans l estimation des paramètres du modèle de prédiction de bande passante. Tous ces mécanismes de régulation agissent par réduction du débit quelque soit l origine de la perte même si l origine de perte n est pas un problème de congestion (bruit de fond, problèmes électriques ). Or, il ne sert à rien dans ce cas de réduire le débit car le réseau n'est pas engorgé. D autre part, la réduction du débit vidéo ne peut se réaliser que par modification des règles appliquées au codeur. Par exemple, si une séquence d image est codée à 8 Mbps et l émetteur décide selon TFRC de réduire son débit à 6 Mbps. Dans ce cas nous avons deux possibilités : soit on envoie les données avec un débit faible, soit on recode les images à 6Mbps d où le problème car pour respecter le temps réel on ne peut pas changer à chaque émission le débit des données. En effet, ces données sont stockées sous un débit et leur recodage nécessite un temps supplémentaire avec une modification des règles appliquées au décodeur (pour coder à 6Mbps par exemple). Il est donc indispensable de maintenir le débit du flux vidéo. D où le besoin de trouver un mécanisme optimum, autre que la régulation du débit, permettant de contrôler les erreurs en respectant le temps réel. 3.2 Contrôle d erreurs par anticipation Le principe des méthodes de contrôle ou de correction d erreurs par anticipation repose sur l introduction de redondance dans le flux transmis. En cas de pertes cette redondance permettra de récupérer une partie des données perdues. 19

Dans [31] Rosenberg et Schulzrinne définissent un format de conteneur (payload) des paquets permettant d envisager des protocoles de FEC («Forward Error Correction») générique destinés à la protection de données temps réels. Généricité signifie pour eux indépendant du média protégé et adaptatif. Leurs travaux les plus aboutis préconisent l utilisation de codes de parité pour générer la redondance. L opération de protection proposée par ce protocole commence par la concaténation de certains champs présents dans l en-tête des paquets RTP média. On ajoute ensuite le conteneur (payload) contenant les données. La même opération est réalisée sur plusieurs paquets et on applique sur le flux binaire ainsi formé un «ou exclusif» (XOR) pour générer les conteneurs de FEC et construire des nouveaux paquets RTP. Figure 4: Les paquets FEC générés chez l émetteur seront transmis avec les paquets RTP. Le récepteur les utilise pour reconstruire les paquets perdus Un paquet RTP contenant des FEC est constitué d un en-tête RTP d un en-tête de FEC et du conteneur de FEC. C est dans l en-tête de FEC que se trouve un champ de 24 bits (mask field) permettant de retrouver quels sont les paquets de données utiles associées avec ce paquet de FEC (dans la figure : les paquets D3, D2, D1 sont indiqué dans P2). Ainsii les FEC ne pourront porter que sur 24 paquets de données utiles consécutifs au maximum. Les paquets de données utiles et les paquets contenant des FEC sont en général envoyés dans des flux RTP séparés [33]. Lorsque des pertes de paquets se produisent on reconstruit un paquet RTP à la réception avec le résultat du «ou exclusif» appliqué sur les paquets de FEC et de données médias reçus. Les codes FEC induisent un temps de latence supplémentaire à l émetteur. Si on oublie le temps de codage et de décodage (en effet, il existe des algorithmes de codage très rapide), il persiste tout de même un temps de latence incompressible puisque pour pouvoir commencer à coder, le codeur de canal devra attendre d avoir reçu de la part du codeur de source suffisamment de données. Le même problème se posera à la réception puisque en cas de pertes le décodeur devra attendre de recevoir suffisamment de données pour pouvoir commencer à décoder. Ajoutons que nous somme obligé de générer et transmettre les FEC même si le taux de perte sur le canal est nul. Pour cela les FEC peuvent être efficacement remplacées par d autres méthodes de contrôle d erreur telles que les méthodes basées sur des demandes de retransmission des paquets perdus. 20

3.3 Contrôle d erreurs par retransmission Ces méthodes de contrôle d erreurs s appuient sur la retransmission de données perdues. En effet, il existe deux mécanismes de détection de perte : soit par le récepteur, soit par l émetteur. Dans les deux cas, l émetteur numérote les paquets qu il envoie de manière séquentielle. De cette manière, soit le récepteur détecte la perte des paquets et demande leur retransmission en envoyant à l émetteur un accusé de non réception (NACK), soit le récepteur envoie à l émetteur à la réception de chaque paquet un accusé de bon réception (ACK). Cet accusé permet à l émetteur de détecter la perte et retransmettre les paquets perdus. Nous nous intéressons à la première méthode (basé sur le NACK) mais avant d expliquer cette méthode nous donnerons le principe de fonctionnement des mécanismes basé sur le «ACK». 3.3.1 Mécanismes basés sur un accusé de réception Le protocole majeur basé sur l utilisation de l accusé ACK est le protocole ARQ. Dans ce paragraphe on va expliquer ce protocole en détail afin de déduire ses limites. L ARQ [26] (Automatic Repeat Request) est une méthode de contrôle d erreur qui s appuie sur des retransmissions. Chaque paquet reçu correctement est suivi d un envoi d un accusé de réception (ACK) contenant le numéro de séquence du paquet. Tous les paquets n ayant pas fait l objet d un ACK pendant un intervalle de temps fixé (temps d expiration : Timeout) sont considérées comme perdus et sont retransmis. L ARQ peut se décliner sous plusieurs formes. Nous citons les deux principales. Méthode du «arrêt et attente» (STOP and WAIT) : L idée de cette méthode est que pour chaque paquet envoyé l émetteur attend un accusé de réception avant de transmettre le suivant. Si après le temps d expiration aucun ACK n est reçu on renvoie le paquet. L inconvénient évident de cette méthode est son faible débit d envoi. Méthode de la répétition sélective : Ici les paquets sont transmis de manière continue. Chaque paquet reçu correctement fait l objet d un ACK. Tout ACK non reçu après le temps d expiration est suivi de la retransmission du paquet perdu. L émetteur reprend ensuite ses envois à partir du paquet perdu même si certains paquets le suivant ont déjà été reçus. À la base l ARQ était destiné à des applications point à point sécurisées et non contraintes par le temps. Clairement une utilisation directe des méthodes décrites précédemment dans un contexte multipoint conduirait de façon certaine à une explosion de la voie de retour. En effet étant donnée la taille potentiellement grande des arbres multipoints, le trace générée par les demandes de renvoi a de grande chance de congestionner le lien menant à la source. D autre part même si ces demandes réussissent à aboutir, il n est pas évident que la source puisse toutes les traiter. L utilisation des demandes de renvoi en multipoint implique donc leur adaptation à ce cas spécifique. Il est remarquable qu ARQ ne puisse être pas utilisé par les applications multimédia. Plusieurs études ont montré son inefficacité [29] [30] dû au grand nombre des messages ACK envoyé par les participants. Pour cela nous nous intéressant au mécanisme utilisant un accusé de non réception NACK. 21

3.3.2 Mécanismes basés sur un accusé de non réception L émetteur numérote toujours les paquets par un numéro de séquence permettant au récepteur de détecter les paquets perdus. Ce mécanisme de contrôle est basé sur l émission vers l émetteur d une requête demandant la retransmission de ces paquets (message NACK). À la réception de cette demande l émetteur retransmet les paquets perdus. Cependant, une remontée de trop nombreux messages peut charger inutilement le serveur et risque de dégrader ses performances. Pour éviter cette surcharge, le récepteur a tout intérêt à regrouper plusieurs requêtes de retransmission dans un unique message. Le RFC 4585 [3] a normalisé un format permettant de déclarer plusieurs requêtes dans un unique message NACK. Ce format consiste à ajouter dans le message un ou plusieurs champs «FCI» (ce message est formé d un en-tête (adresse et port source, etc.) et d un ensemble de FCI). Chaque FCI est formé de 32 bits divisé en 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. Ceci permet de réduire le volume du NACK. Le format du champ FCI (inclut dans le NACK) est le suivant : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PID BLP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cependant, en temps réel le récepteur ne doit pas attendre trop longtemps avant d'envoyer ses requêtes. En effet, si ensuite le temps de réception des données retransmises est trop long, les paquets de correction des pertes risquent d'arriver après le temps de fourniture des données au décodeur. Ajoutons que l émetteur ne peut pas garder les paquets déjà envoyé trop longtemps. Selon le RFC 4588 [5], il peut les conserver pour un temps fixe RtxTime. Donc, pour contrôler l erreur de transmission en temps réel, il faut trouver une solution réduisant le nombre des messages NACK (en utilisant le format décrit précédemment) et prenant en compte les contraintes de l émetteur et du récepteur (RtxTime, ). Plusieurs solutions basées sur la retransmission en utilisation du NACK ont été proposé. On trouve par exemple la solution proposé par Levine, Paul et Garcia dans [29]. Selon ces auteurs, cette solution est adaptée multicast. Leur but est juste de limiter le nombre de message NACK. Pour cela, chaque message NACK sera transmis en multipoint dans l arbre. Le premier récepteur d un NACK donné, en transmettant en multipoint, informe les autres nœuds de sa réponse, leur évitant d y répondre eux-mêmes. Pour fonctionner, la méthode s appuie sur une temporisation aléatoire des NACK. L ordre d envoi d un NACK ne sera exécuté au terme de cette temporisation que si le récepteur ne voit pas passer un autre NACK demandant le renvoi des mêmes informations. De la même manière pour pouvoir répondre à un NACK, un récepteur doit s assurer qu il n a pas reçu lui-même une réponse à cette demande ce qui indiquerait qu un autre récepteur y a déjà répondu. 22