Applications multimédia sur l'Internet

Walid Dabbous
INRIA Sophia Antipolis

1.0 Introduction

L'Internet a été conçu pour offrir un service simple, à savoir connecter tous les ordinateurs du monde, de la façon la plus économique possible. Mais il n'a pas été conçu pour supporter un type d'applications particulier. Cependant, l'augmentation rapide des capacités des ordinateurs a fait que ceux-ci sont maintenant capables de coder et de traiter des sons ou de la voix, ainsi que des images fixes ou animées (c'est à dire de la vidéo). Il est donc naturel de penser à transmettre ces nouveaux types de données sur l'Internet. Les avantages potentiels sont en effet très nombreux, puisque la transmission de données multimedia de qualité permettrait d'offrir des services de téléphonie, et plus généralement des services de collaboration à distance combinant vidéoconférence et tableau blanc partagé (c'est dire une fenêtre commune visible et modifiable par tous les utilisateurs) qui font intervenir la transmission de la voix, d'images animées, et de texte.

2.0 Les besoins des applications

La transmission de données multimédia sur l'Internet n'est malheureusement pas une simple extrapolation de la transmission de données textuelles, pour la simple raison que les besoins des applications multimédia sont différents de ceux des applications classiques de transfert de données. Ces dernières applications ne font en général intervenir que deux utilisateurs, une source et une destination. D'autre part, leur utilité pour un utilisateur ne dépend pas, ou peu, du temps qu'il a fallu pour transférer les données. Au contraire, les applications multimedia mettent généralement en jeu un nombre important d'utilisateurs. De plus, il est très important que les données émises par un utilisateur atteignent rapidement les autre utilisateurs. En résumé, les applications multimédia interactives ont besoin d'une part d'une transmission de groupe (entre plusieurs utilisateurs) efficace, et d'autre part de garanties de performance.

Bien sûr, une transmission de groupe, ou transmission multipoint, peut être fournie de façon triviale en ouvrant autant de connexions qu'il y a de destinations possibles. Mais cette solution n'est pas souhaitable car d'une part elle utilise mal les ressources du réseau, et d'autre part elle suppose que la source connaisse toutes les destinations. L'approche utilisée dans l'Internet est plus simple. Un groupe multipoint est défini par un seul identificateur de groupe, que l'on appelle adresse multipoint. Une source désirant envoyer des données aux membres du groupe enverra ces données à l'adresse multipoint du groupe. Les utilisateurs qui désirent participer aux activités d'un groupe s'abonnent à l'adresse multipoint du groupe. L'acheminement efficace des paquets d'une source vers toutes les destinations d'un groupe est calculé et effectué par certains noeuds Internet en utilisant des algorithmes de routage multipoint. Le MBone (Multicast backBone, ou coeur multipoint de l'Internet) est l'ensemble des noeuds qui permettent une telle transmission. A terme, tous les noeuds de l'Internet pourront effectuer du routage multipoint et le MBone sera identique à l'Internet.

Le deuxième besoin des applications multimédia qui les séparent des applications «classiques» comme la messagerie est le besoin de garanties de qualité. La notion de qualité est très vaste, et elle varie avec chaque application. Mais d'une façon générale, la qualité reflète l'utilité des données reçues par un utilisateur pour les besoins de cet utilisateur. Cette utilité dépend de façon essentielle des caractéristiques du réseau, en particulier de trois d'entre elles qui sont le délai, le débit (ou bande passante), et les pertes. On a vu plus haut qu'il est nécessaire que le délai d'acheminement entre participants soit suffisamment faible pour permettre l'interactivité. De même, le débit disponible doit être suffisamment élevé. Par exemple, une transmission audio de qualité téléphonique nécessite environ 13 kb/s (c'est à dire légèrement moins que le débit d'un modem 14.4 kb/s), alors que la qualité CD nécessite environ 64 kb/s (c'est à dire une liaison RNIS). Enfin, le taux de pertes doit être suffisamment faible. Par exemple, dans le cas d'une transmission audio, les psycho-acousticiens indiquent qu'il doit être inférieur à 5%.

3.0 Les mécanismes de contrôle

Cependant, l'Internet est un réseau qui fournit un service d'acheminement sans garantie aucune sur les performances. En particulier, un paquet émis par une source peut être perdu; et s'il n'est pas perdu, le temps qu'il mettra pour atteindre une destination n'est pas connu à l'avance. Ceci est dû au fait qu'il n'y a pas de réservation de bande passante dans le réseau. Les ressources sont partagées par tous les utilisateurs. Ce manque de garanties peut sembler être en contradiction avec la nécessité de garanties exprimée plus haut. Deux approches sont alors possibles, que l'on peut résumer sous la forme «le réseau s'adapte aux applications» ou «les applications s'adaptent au réseau».

La première approche consiste à dire que l'Internet actuel fournit un service qui n'est pas adapté aux besoins des applications multimedia, et donc qu'il faut modifier ce service avant de pouvoir utiliser ce type d'applications. En particulier, il s'agit de modifier le réseau pour offrir un ou des services offrant des garanties de qualité. Cette approche nécessite la mise en place dans le réseau de nouveaux algorithmes et protocoles, en particulier d'ordonnancement, de signalisation, et de contrôle d'admission. Nous ne décrivons pas cette approche dans cet article.

La deuxième approche consiste à dire que le service offert par l'Internet, même s'il n'est apparemment pas idéal pour les applications multimédia, est de toute façon le seul service disponible à l'heure actuelle. Il s'agit donc de minimiser l'impact négatif des caractéristiques de ce service sur la qualité des données multimedia reçues par les destinations. Ceci est fait en pratique par l'utilisation de mécanismes de contrôle. Nous avons vu plus haut que trois caractéristiques du réseau ont un impact important sur la qualité, à savoir le délai, la bande passante disponible, et les pertes. A chacune de ces caractéristiques sera donc associé un mécanisme de contrôle.

Considérons d'abord les mécanismes de contrôle de délai. Le délai mis par un paquet d'une connexion audio pour traverser le réseau dépend du nombre et de la taille des paquets envoyés par les autres utilisateurs qui partagent les mêmes noeuds que la connexion audio. Les noeuds ne favorisent pas une connexion plutôt qu'une autre. Il est donc impossible à cette connexion audio d'avoir un impact direct sur le délai qui sera mis par ses paquets pour traverser le réseau, à moins de changer la façon dont sont traités les paquets dans les noeuds, c'est à dire la politique d'ordonnancement des paquets. Par contre, il est facile de contrôler les variations de délai en ajoutant un tampon mémoire à chaque destination. Un paquet arrivant à la destination est mis en attente provisoire dans le tampon, ce qui lui permet d'attendre les paquets suivants en retard, afin qu'ils soient rejoués de façon synchrone.

Les mécanismes de contrôle de débit cherchent à faire en sorte que le débit de la source soit égal à la bande passante disponible dans le réseau. Comme cette bande passante varie au cours du temps, il faut pouvoir i) estimer ces variations, et ii) ajuster le débit de la source en fonctions des variations estimées. Cet ajustement est effectué pour la vidéo en contrôlant soit le nombre d'images par seconde soit la qualité visuelle de l'image transmise. Ceci permet une variation contrôlée de la qualité de la vidéo transmise en fonction de la bande passante disponible dans le réseau à chaque instant. On obtient donc un mécanisme basé sur une boucle de contre réaction. En fait, ce genre de mécanisme n'est pas nouveau. Il est par exemple utilisé dans TCP, puisque TCP modifie son débit en fonction des pertes dans le réseau. Pour les applications multimédia, on utilise un principe similaire, mais avec deux différences principales. Cet échange d'information est réalisé à l'aide d'un protocole spécifique appelé RTP (Real-Time Transport Protocol, ou Protocole de Transport Temps Réel). Ceci dit, il est clair que l'échange de tous ces taux de pertes peut lui même générer un trafic important. RTP inclut donc un mécanisme de régulation de trafic, qui permet en particulier à la source de recevoir, sans que le réseau ne soit trop chargé, les taux de pertes observés aux destinations. Un problème se pose pourtant, à savoir quel débit la source devrait choisir. Une solution possible pourrait être d'adapter le débit de la source, à la destination ayant le taux de perte le plus élevé. Ceci revient à dégrader la qualité pour toutes les destinations dès lors qu'une liaison vers une destination particulière est surchargée. Une autre solution est que la source code les données de façon hiérarchique (c'est à dire selon leur importance décroissante), et de faire en sorte que seule l'information importante soit transmise sur les liaisons surchargées. La diversité spatiale des caractéristiques du réseau dans le cas d'une transmission en multipoint a donc un impact important sur le codage source. D'ou la notion de codage conjoint «source/canal» qui constitue actuellement un axe de recherche important pour le support des applications multimédia sur l'Internet.

Certaines applications comme le tableau blanc, les éditeurs de texte partagé ou bien les applications de diffusion de fichiers nécessitent un service de transmission multipoint fiable. Dans ce cas, et contrairement au cas des applications audio ou vidéo décrites plus haut, les paquets perdus doivent être retransmis. Afin d'éviter la surcharge de la source par des demandes de retransmissions d'un grand nombre de destinataires ayant détecté la perte d'un paquet, ces demandes sont transmises à tout le groupe. N'importe quel membre du groupe ayant une copie du paquet pourra alors répondre en le (re)transmettant. Le nombre de réponses est limité par une méthode élégante inspirée de dialogue humain: avant de répondre à une demande de retransmission, chaque membre du groupe attend un temps aléatoire tout en écoutant le réseau. La réponse est annulée si on aperçoit qu'un autre membre du groupe a répondu. La même technique est utilisée afin de minimiser le nombre de demandes de retransmissions.

4.0 Conclusion

Les mécanismes décrits dans cet article permettent aux applications multimédia d'adapter leur comportement en fonction des conditions dans le réseau. Ils ont permis par la même la mise en oeuvre et l'utilisation satisfaisante de ce type d'applications sur un réseau qui ne leur était pas a priori destiné. Le mythe répandu qui consistait à dire que les applications de type vidéoconférence nécessitent des guaranties de performance strictes est donc faux, et il est démenti par les vidéoconférences qui se tiennent régulièrement sur le MBone.
Ces mécanismes permettront également aux applications multimédia de bien tirer parti d'un éventuel service avec garanties de performance sur l'Internet, sans empêcher le partage efficace des ressources du réseau et sans imposer la complexité des mécanismes de réservation de ressources.