Durant mon stage de DEA j'ai travaillé sur la gestion du multicast dans le protocole de transport conçu pour les réseaux haut débit XTP (Xpress Transport Protocol). Un algorithme mettant en œuvre une sémantique de fiabilité probabiliste a été intégré dans l'implémentation de XTP réalisée par Sandia Laboratories.
L'Internet est un réseau à commutation de paquets qui ne fournit qu'un service “au mieux” (best effort), c'est à dire qu'aucune garantie d'aucune sorte n'est faite sur le service offert, autre que l'engagement du réseau à faire “du mieux qu'il peut” pour amener les paquets à destination. Ce type de service est tout à fait utilisable par les applications élastiques, qui n'ont pas de contrainte temporelle et peuvent donc accepter de grandes variations de délai et compenser les pertes éventuelles par des retransmissions. Ainsi le réseau ne fournit qu'un service minimal, et c'est au niveau de la couche transport qu'est gérée la fourniture d'un service de bout en bout satisfaisant. Toutes les applications initialement développées sur l'Internet se satisfont d'un tel service.
Cependant, le développement de l'Internet a suscité la création de nouveaux types d'applications, multimédias, qui ne peuvent se satisfaire d'un tel service minimal. Ces applications ont des contraintes du type temps réel et ont besoin de garanties de délai et/ou de débit pour les flots de données qu'elles génèrent. Différents types d'applications auront besoin de garanties plus ou moins strictes. Pouvoir satisfaire les besoins de ces applications, c'est leur fournir une qualité de service adaptée.
Depuis de nombreuses années, des travaux importants sont menés dans le domaine de la qualité de service dans les réseaux à commutation de paquets. En particulier, des techniques d'ordonnancement de paquets (comme par exemple le weighted fair queuing) permettent de garantir un débit et sous certaines conditions un délai à un flot de données. Dans le cadre de l'Internet, une architecture pour fournir la qualité de service a été développée par l'IETF. Basée sur l'intégration de services, l'architecture IntServ/RSVP utilise le protocole RSVP pour gérer des réservations de ressources pour chaque flot de données.
Plus récemment, une approche différente a été proposée par l'IETF : la différenciation de services, DiffServ, repose sur une gestion de trafic par classe et des méthodes de conditionnement du trafic à l'entrée dans le réseau. Cette approche résout certains des problèmes qui se posent à IntServ mais apporte ses propres difficultés. Mon travail de thèse s'est concentré sur l'architecture IntServ.
Pour qu'une telle architecture soit effective, elle doit être mise en place dans l'ensemble du réseau, y compris dans les réseaux d'interconnexion (backbones), de façon à fournir des garanties de service de bout en bout. Ces réseaux d'interconnexion posent cependant des contraintes particulières et sont donc sources de problèmes pour l'architecture IntServ.
La première contrainte est celle du haut débit. Une très grande quantité de paquets devant être traités en un temps très court, il faut obtenir des temps de traitement par paquet extrêmement faibles. Ceci nécessite l'utilisation de technologies particulières pour les éléments d'interconnexion, qui sont capables de traiter les paquets à un rythme très élevé. Dans le cas d'un réseau à intégration de services, le traitement à appliquer à chaque paquet est nettement plus complexe ce qui rend le problème plus difficile à résoudre.
Une approche développée ces dernières années pour atteindre des débits élevés dans le cadre du service au mieux est représentée par les solutions de type “commutation IP” qui permettent d'associer la flexibilité et la robustesse d'IP aux capacités haut débit d'un moteur de commutation ATM. Cette approche au départ proposée par la compagnie “Ipsilon” a été reprise par de grands industriels des réseaux. Elle a été généralisée sous le nom de “commutation par labels”. Le groupe de travail Multi Protocol Label Switching (MPLS) de l'IETF est chargé de standardiser cette technologie.
Ma contribution a consisté à proposer une intégration des mécanismes de qualité de service de l'architecture IntServ à cette technologie. Cette intégration passe par l'ajout des fonctionnalités de distribution de labels au protocole RSVP chargé de mettre en place les réservations. J'ai aussi montré les avantages liés à la fourniture de la qualité de service au niveau cellule et proposé une implémentation des services permettant d'optimiser l'utilisation des ressources. Cette implémentation a été validée par des simulations, et la réalisation d'un prototype a montré la viabilité des mécanismes proposés pour le plan de contrôle. Le prototype est basé sur du matériel de type PC standard avec une version modifiée du noyau Linux et du démon RSVP. Il a été utilisé dans le cadre d'une expérimentation sur la plateforme ATM nationale SAFIR.
Un autre problème est celui du facteur d'échelle (scalabilité). Une architecture telle que IntServ/RSVP qui requiert de maintenir des états par flot pose certains problèmes pour le passage à l'échelle. Une augmentation très importante du nombre de flots à gérer se traduit en un accroissement de la charge de traitement qui peut devenir insupportable. Cette charge se situe aussi bien dans le plan de données, où des états de classification et d'ordonnancement doivent être maintenus par flot et manipulés à chaque paquet, que dans le plan de contrôle où il faut maintenir des états de gestion par flot.
Les progrès réalisés au niveau des moteurs de commutation capables de fournir des mécanismes de qualité de service à un très grand nombre de flots portent à penser que les limitations se situent plutôt au niveau du plan de contrôle, en l'occurence le protocole RSVP. Une étude réalisée sur la seule implémentation librement disponible actuellement a confirmé l'existence probable du problème même si les résultats ne sont pas aussi mauvais qu'on pourrait le croire.
Concernant ces problèmes liés au facteur d'échelle, j'ai considéré qu'ils ne se posent réellement que dans une partie limitée du réseau (les backbones) que j'appelle zone centrale. J'ai donc proposé d'utiliser l'architecture IntServ/RSVP telle quelle à l'extérieur de cette zone et de mettre en œuvre des mécanismes différents, adaptés aux problèmes d'échelle, dans la zone centrale. La viabilité de cette approche est liée à deux contraintes :
J'ai exploré deux types d'approches au problème du passage à l'échelle :
La première est basée sur un changement de granularité dans la gestion des ressources. Les flots applicatifs sont agrégés en b-flots correspondant à des couples de points d'entrée et sortie de la zone centrale pour une qualité de service donnée. À partir de la caractérisation du b-flot, les flots étant contraints à leurs contrats de trafic de manière appropriée, l'allocation de ressources déterminées au b-flot permet de fournir des garanties sur le service reçu par chacun des flots individuels. J'ai montré comment calculer ces ressources, puis proposé des mécanismes d'interfaçage des deux zones. J'ai également étudié brièvement les gains potentiels en efficacité de l'utilisation des ressources apportés par les techniques d'agrégation. Cette approche est satisfaisante dans la mesure où elle permet de fournir les garanties de services définies par l'IntServ de bout en bout, en éliminant les problèmes de facteur d'échelle apportés par les réseaux d'interconnexion. Elle constitue donc une solution complète pour fournir les services IntServ de façon scalable.
Cependant l'agrégation implique une perte de flexibilité dans la gestion des ressources ce qui se ressent par l'impossibilité de gérer le multicast (bien que les problèmes du multicast ne soient pas tous liés au fait d'utiliser l'agrégation) et l'obligation de gérer un b-flot par délai pour fournir des délais hétérogènes aux flots GS.
La deuxième approche étudiée repose sur l'idée de gérer les ressources par flot, mais sans maintenir d'état pour chaque flot dans les nœuds. Le trafic ayant été conditionné en entrée de la zone sans état et chaque paquet transportant sa réservation, un ordonnancement approximant le Virtual Clock, que j'ai appelé stateless VC, peut être mis en œuvre sans maintenir d'état par flot. La déviation du service fourni par stateless VC par rapport à VC dépend de la déformation du trafic introduite par les nœuds. J'ai montré l'existence de bornes théoriques sur cette déformation et sur la déviation du service qui en résulte. Ces bornes correspondent cependant à des cas pires et j'ai montré par des simulations que l'effet réel que l'on peut observer en pratique est très inférieur, ce qui étend considérablement l'usage possible de la solution. Les simulations ont été réalisées à partir du simulateur ns-2 du Lawrence Berkeley National Laboratory et ont été réalisées en grand nombre grâce à la mise en place de procédures hautement automatisées (divers scripts de configuration et d'extraction et présentation de résultats). J'ai également proposé une variante du stateless VC, appelée reduced state VC, qui utilise les états disponibles dans les paquets présents dans la file d'attente pour améliorer l'approximation réalisée dans certaines situations.
Les mécanismes définis dans le cadre de l'architecture IntServ/RSVP sont assez bien connus du point de vue théorique. Des implémentations de ces mécanismes commençant à apparaître, il semble intéressant de procéder à leur évaluation expérimentale. En effet, si beaucoup de matériels réseaux prétendent fournir la qualité de service, pratiquement aucune évaluation expérimentale de ces mécanismes n'a encore été faite. Une étude de RSVP sous cet aspect a été réalisée dans le cadre de ma thèse.
Dans la continuité de ma thèse, j'avais entrepris pendant mon année d'ATER une étude et évaluation des mécanismes de gestion de la qualité de service implémentés dans le noyau Linux (techniques d'ordonnancement de paquets et de gestion de file active), avec l'aide notamment d'un stagiaire du DEA réseaux. Ceci devait compléter le travail fait sur RSVP et fournir une évaluation d'ensemble des performances des architectures à intégration de service en situation réelle. Du fait de mon départ dans l'industrie, ces travaux ont été interrompus et ne se sont pas concrétisé par des publications. Un début d'implémentation de mécanismes d'ordonnancement de paquets pour les noyaux Linux 2.0.x est consultable ici.
Durant la première année de ma présence à Activia, j'ai participé à des travaux de recherche dans le domaine de l'interconnexion de réseaux de distribution de contenu. Cela a inclu notamment la participation au groupe de travail CDNP (Content Distribution Networks Peering) — devenu ensuite CDI (Content Distribution Internetworking) — de l'IETF et la publication d'un Internet draft (mentionné dans la liste des publications). J'ai donné une courte présentation des problèmatiques de l'interconnexion de CDN à l'école d'été RHDM2001. Ces travaux n'ont pas été poursuivis du fait d'une part du désengagement progressif d'ActiVia des aspects recherche et d'autre part du manque d'activité du groupe de travail IETF.
J'ai participé à l'école d'été RHDM2002 où j'ai donné un tutorial sur les réseaux de distribution de contenu (mentionné en 4). J'ai également donné des variantes de cette présentation au LIP6 (mai 2001) et à l'ENST (mai 2002).
Par rapport aux compétence acquises pendant ma thèse, concernant plutôt “l'intérieur du réseau”, ce travail m'a permis de bien mieux connaître les couches hautes des réseaux (DNS et tout ce qui touche le web : HTTP, XML, contenus dynamiques, services web). J'y ai également acquis une meilleure vision de l'architecture “réelle” de l'Internet (routage intra et inter domaine, contraintes non techniques prises en compte par les opérateurs).