Chapitre 6 Conclusion

L'objectif de cette thèse était l'étude des problèmes rencontrés pour la gestion de la qualité de service dans l'Internet, et en particulier dans les réseaux d'interconnexion. Nous avons tout d'abord étudié les mécanismes de qualité de service qui sont actuellement proposés, que ce soit au niveau global (architectures conçues par les groupes de travail IntServ et DiffServ) ou au niveau des mécanismes élémentaires utilisés par ces architectures (garanties de délai, ordonnancement de paquets).

Pour que la qualité de service devienne réellement disponible, ces architectures doivent être déployées dans l'ensemble du réseau. Or, les réseaux d'interconnexion ont des caractéristiques particulières qui rendent difficile l'utilisation des mécanimes de qualité de service tels qu'ils ont été conçus jusqu'à présent. On peut classer ces problèmes en deux catégories :

les problèmes liés au haut débit,
les problèmes liés au facteur d'échelle.

Dans le troisième chapitre, nous avons étudié une des technologies majeures proposées pour les réseaux haut débit, la commutation IP. Les points forts de cette approche sont de pouvoir profiter des capacités de traitement haut débit de moteurs de commutation matériels (typiquement ATM) tout en conservant la flexibilité et la robustesse des mécanismes réseaux implémentés par le protocole IP. Notre 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. Nous avons 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 fait d'utiliser un modèle de gestion par flot rend cependant cette solution sensible au facteur d'échelle. 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 nous 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, nous considérons qu'ils ne se posent réellement que dans une partie limitée du réseau (les backbones) que nous appelons zone centrale. Nous proposons donc d'utiliser l'architecture IntServ/RSVP telle quelle à l'extérieur de cette zone et de mettre en oeuvre 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 :

les mécanismes utilisés dans la zone centrale doivent fournir le même type de garanties que l'IntServ,
l'interfaçage des deux zones doit se faire de manière totalement transparente pour les applications.

Nous avons proposé deux types d'approches pour la fourniture de la qualité de service de manière scalable à intérieur de la zone centrale.

La première, décrite dans le quatrième chapitre, 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. Nous montrons comment calculer ces ressources et réaliser l'interfaçage des deux zones. Nous étudions également 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 scalabilité apportés par les réseaux d'interconnexion. 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.

Dans le cinquième chapitre, nous proposons une approche différente pour fournir la qualité de service dans la zone centrale. L'idée est de gérer les ressources par flot, mais sans maintenir d'état pour chaque flot dans les noeuds. 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 nous appelons stateless VC, peut être mis en oeuvre 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 noeuds. Nous montrons 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 nous montrons 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. Nous proposons également 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.

Perspectives

Le groupe de travail RSVP de l'IETF a récemment annoncé que son travail était terminé, la spécification du protocole étant achevée. Quelques travaux continuent cependant à être menés, notamment (mais pas uniquement) sur des améliorations de la scalabilité du protocole [GDEB99, MH99]. Nous envisageons d'approfondir l'étude menée sur la scalabilité de RSVP et notamment l'effet des améliorations proposées.

Dans le cinquième chapitre, nous pensons avoir montré que l'approche proposée est utilisable. Nous n'avons cependant pas réalisé d'étude approfondie des phénomènes entrant en jeu dans la déformation du trafic et sur les effets que cette déformation peut avoir sur les délais garantis aux flots. Une telle étude permettrait de caractériser plus systématiquement les conditions dans lesquelles la solution est valable. Dans la même optique, un autre travail intéressant serait de déterminer les performances d'un ordonnanceur VC qui ne maintiendrait d'états que pour une petite portion des flots. Nous avons montré que les flots pouvaient être plus ou moins sensibles à l'effet d'agglomération, de la même manière, il est probable que l'effet des flots déformés sur la déviation du service dans l'ordonnanceur dépende des caractéristiques de ces flots. Maintenir un état, et donc empêcher la formation de grumeaux, pour une petite quantité de flots les plus ``malfaisants'' pourrait permettre une très bonne approximation du VC.

Aucune des deux solutions que nous avons proposées pour le problème de scalabilité ne peut traiter facilement le cas du multicast. C'est pourtant un problème important car les applications multicast sont appelées à se développer. Les techniques liées au multicast n'étant cependant pas encore matures, la gestion de la qualité de service devrait être prise en compte dans leur définition.