Grands domaines d'application

Contrôle d'applications multimédias sur l'Internet

Participants : Jean-Chrysostome Bolot , Walid Dabbous , Sacha Fosse Parisis , Frank Lyonnet , Thierry Turletti , Andrés Vega García

Nous avons étudié, évalué, et implémenté les mécanismes de contrôle de transmission décrits plus haut dans des applications multimédias pour l'Internet. Le travail a porté sur une application audio (FreePhone) et une application vidéo (RendezVous). L'application de jeu distribuée (MiMaze) est décrite dans la section . Les applications audio et vidéo utilisent des mécanismes de contrôle pour fournir la meilleure qualité possible aux récepteurs, quel que soit l'état (plus ou moins congestionné) du réseau. La qualité de telles applications multimédias dépend essentiellement des caractéristiques de délai, des variations de délai, et des pertes entre la source et les récepteurs. Nous avons donc développé des mécanismes pour minimiser l'impact de chacune de ces caractéristiques. Les résultats les plus visibles ont été obtenus avec les mécanismes de contrôle de pertes, qui utilisent de l'information de redondance envoyée par la source, en plus de l'information « normale », pour reconstruire à l'arrivée les paquets perdus lors de la traversée du réseau. Ces mécanismes permettent maintenant d'obtenir une qualité audio/vidéo acceptable même sur un réseau très chargé.

Nous avons aussi étudié les problèmes de la vidéoconférence sur l'Internet vers des hôtes mobiles. En effet, les solutions de vidéoconférence reposant sur IP multicast, RTP et un codage vidéo au standard h261 tels qu'implémentées dans le logiciel Inria Videconferencing System ne sont pas directement applicables. L'inclusion d'hôtes mobiles dans un tel schéma pose en effet des problèmes à deux niveaux : protocolaire et applicatif.

Les problèmes du niveau protocolaire concernent le support du multipoint sur les réseaux de type Mobile IP ainsi que le support de la mobilité dans le protocole RTP. Nous ne nous impliquons pas dans la conception du support du multipoint sur Mobile IP. Nous suivons les travaux de l'IETF dans ce domaine. Cependant nous prévoyons de participer activement au travail de l'IETF concernant l'extension de RTP pour le support de la mobilité.

Les problèmes au niveau applicatif sont engendrés par la nature du médium physique utilisé par les réseaux mobiles. Les liens sans fil ont en effet des caractéristiques très différentes des liens classiques pour ce qui concerne les erreurs au niveau bit et la bande passante. Ceci nous a amené à étudier de nouvelles méthodes de transmission et de codage vidéo. Ces nouvelles méthodes mettent en jeu l'utilisation de redondance du signal transmis, de codage hiérarchique de la vidéo, associé à une transmission efficace tirant parti des travaux de l'IETF sur le protocole de routage multicast de l'Internet.

Ces nouvelles méthodes de transmission / codage sont en cours d'implantation dans le logiciel de vidéoconférence RendezVous.

Contrôle d'applications temps réel sur l'Internet

Participants : Christophe Diot , Laurent Gautier

Une application est dite temps-réel si elle exécute ses tâches et actions dans un délai défini. On peut distinguer deux familles d'applications temps-réel :

Les applications multimédias (transmission de séquences vidéo et de son) sont caractérisées par une sensibilité plus importante à la variation sur le délai, encore appelée gigue. On utilise d'ailleurs un accroissement du délai pour réduire la gigue.
Les application réactives. Ces applications de type contrôle/commande ou action/ réaction peuvent subir des contraintes de délai très importantes. On y retrouve les jeux distribués et la simulation distribuée.

D'autre part, une application est temps-réel si elle subit des contraintes temporelles. Une contrainte temporelle limite la validité d'une action ou d'une information dans le temps. Toute action temps-réel doit être faite dans un intervalle de temps défini. Avant ou après cet intervalle, l'action ne doit pas se réaliser, ou l'information ne doit pas être délivrée.

Dans le cas d'une application distribuée, la notion de délai est difficilement quantifiable. Elle dépend à la fois de l'application, des techniques de codage de l'information, et des propriétés du réseau et du système de communication. Les variations de délai sont généralement dues à des changements de route, ou à des congestions entraînant soit la bufferisation des données, soit la perte des données (et la retransmission). Nous chercherons donc à concevoir un système de communication se rapprochant du système parfait qui permettrait de transmettre toutes les données avec le délai minimum, ou encore avec une gigue nulle. Ceci fait du délai le paramètre le plus important dans la transmission temps-réel ; alors que dans les applications classiques, il s'agissait d'accroître le débit.

Nous avons étudié différentes applications temps-réel, et en particulier une application de jeux distribués sur Internet. Nous avons alors étudié les différents types de trafic qu'elle génère. Après une analyse des contraintes temps-réel associées à la transmission de ces types de trafic sur le réseau, nous avons mis en évidence les problèmes à résoudre, et proposé des solutions.

En fait, pour ce genre d'application (à contraintes temporelles fortes), le système de communication doit garantir que :

les délais d'interaction sont acceptables : le réseau offre des conditions de transmission (en termes de délai minimum et de taux d'erreur par exemple) qui permettent à l'application de fonctionner en mode distribué
l'entité réceptrice est capable de restituer puis délivrer l'information reçue : les variations du délai entre les paquets peuvent être corrigées sans accroître le délai de transmission global dans une proportion inacceptable pour l'application.

Ces deux paramètres se ramènent finalement à la notion de « délai acceptable » (puisque la gigue est transformée en délai), qui est subjective, car elle dépend de l'application et de l'utilisateur. Elle nécessite le contrôle de plusieurs paramètres : le débit de communication, le taux de perte, le délai, et la variation du délai. En outre, le fait qu'une application temps-réel soit multipoint renforce les contraintes temporelles. Ce type d'application pose des problèmes supplémentaires à ceux cités ci-dessus : l'information transmise doit être délivrée en différents points du réseau dans des conditions identiques, ce qui nécessite la synchronisation éventuelle des divers membres du groupe préalablement à la remise des informations. Les informations collectées par un point doivent être traitées dans un ordre défini par l'application afin que chaque point ait la même interprétation de l'information.

Ces études nous ont permis de montrer :

la nécessité d'avoir une horloge globale précise indépendante de l'application,
la nécessité d'anticiper les collisions à la source,
le besoin du Dead Reckoning

Les techniques utilisées permettront de bâtir un système de communication plus efficace que ceux qui sont classiquement utilisés pour assurer l'ordre et la fiabilité dans les systèmes distribués.

Support des liens unidirectionnels dans l'Internet

Participants : Walid Dabbous , Emmanuel Duros

De nombreuses applications distribuées peuvent bénéficier de connexions à haut débit vers l'Internet (Ethernet 10 Mbits, FDDI, etc). Cependant, pour obtenir de bonnes performances de bout en bout, les sites distants doivent être reliés par des liens à haut débit qui sont actuellement très onéreux (ATM, etc).

Une solution asymétrique à faible coût peut être réalisée en utilisant des réseaux satellitaires qui peuvent couvrir de larges zones géographiques. Cette solution est basée sur l'utilisation de récepteurs : la connexion est unidirectionnelle, car ces récepteurs ne peuvent transmettre de données sur le réseau satellitaire. Les protocoles de routage dans l'Internet ne supportant pas les liens unidirectionnels, le but de notre travail est de proposer des modifications à ces protocoles pour intégrer les liens satellitaires unidirectionnels.

Un réseau satellitaire fournit des services à haut débit indépendants de la position des utilisateurs dans de larges secteurs géographiques. Il comprend deux types d'équipement : des stations montantes qui transmettent des données et des récepteurs qui ne peuvent que recevoir des données. Un récepteur est composé d'une antenne satellitaire orientée vers un satellite géostationnaire, connectée à une station utilisateur ou à un routeur. Une station utilisateur a une autre interface, et un routeur une ou plusieurs autres connectées à l'Internet. Les informations sont envoyées des stations montantes à un satellite qui les renvoie à un ensemble de récepteurs qui appartiennent à la couverture satellitaire.

Les problèmes associés à cette configuration sont liés aux protocoles de routages. Chaque routeur dans l'Internet doit régulièrement annoncer à ses voisins quels réseaux il est capable d'atteindre, afin que chaque routeur ait une vue globale de l'Internet. Ce mécanisme est nécessaire pour qu'un routeur qui doit acheminer un paquet IP vers une destination donnée sache vers quel routeur voisin l'envoyer. Dans le cas de réseaux satellitaires de type broadcast, un récepteur ne peut annoncer directement aux stations montantes les réseaux qu'il peut atteindre. Ces dernières croiront alors qu'aucun réseau n'est atteignable par l'intermédiaire du réseau satellitaire et n'enverront donc aucun paquet IP sur leur liaison satellitaire.

Pour remédier à cela, les méthodes d'apprentissage de routes sont modifiées. Un récepteur maintient une liste des stations montantes grâce aux messages qu'elles envoyaient pour annoncer les réseaux qu'elles peuvent atteindre (leur adresse IP est contenue dans l'en-tête des messages envoyés). Les récepteurs ne tiennent pas compte de ces routes, car ils ne peuvent manifestement pas les atteindre par le réseau satellitaire (lien unidirectionnel). Les récepteurs envoient régulièrement des messages contenant les réseaux qu'ils peuvent atteindre à chaque adresse de la liste des stations montantes. Les récepteurs transmettent ces messages par leurs interfaces connectées à l'Internet.

Ces modifications ont été implémentées dans le protocole du routage RIP et DVMRP. L'utilisation d'un réseau de PC nous a permis de simuler des liens unidirectionnels et de vérifier le bon fonctionnement des algorithmes. Nous avons effectué des démonstrations en local ainsi que sur des liaisons satellitaires, en transmettant de la vidéo au dessus de IP en multipoint vers une partie des partenaires du projet européen MERCI.

Précédent : Fondements scientifiques Remonter : Projet RODEO, Réseaux à haut Suivant : Logiciels