Pour étudier des protocoles de transport, les chercheurs disposent de 4 solutions :
– La modélisation et l’évaluation analytique
– La simulation [23] : un seul programme qui simule l’ensemble de l’environnement, généralement sur un seul processeur
– L’expérience grandeur nature
– L’émulation : approche intermédiaire où une partie des éléments sont réels (applica-tions et noeuds d’extrémité), et une partie simulée (les liens longue distance)
L’analyse nécessite souvent des hypothèses simplificatrices, aussi elle ne peut être utilisée seule comme méthode de validation.
Les tests grandeur nature posent rapidement des problèmes pour des expériences con-séquentes : il peut être difficile de trouver une topologie réelle qui corresponde aux besoin de l’expérience (notamment lorsque cette topologie fait intervenir des liens longue distance) et sa flexibilité est souvent limitée (Par exemple, on ne peut pas modifier la latence des liens).
De plus, les aléas des expériences réelles rendent leur reproduction délicate.
Nous présentaons ci-dessous les principaux outils de simulation et d’émulation réseau utilisés.
3.4.1 Simulateurs a. ns
ns [24] est le simulateur le plus répandu dans la communauté scientifique. Il s’inscrit dans le cadre du projet VINT [25] visant à faciliter l’étude des comportements réseaux et l’interaction entre différents protocoles. ns est un simulateur orienté objet, qui travaille avec des événements discrets, par paquets. Il est donc bien adapté aux réseaux à commutation de paquets. ns permet de simuler des algorithmes de routage, des protocoles de transports, de session, d’application (comme HTTP), des politiques de files d’attente... ns était conçu prin-cipalement pour le protocole TCP, mais son extensibilité (basée sur le langage Tcl) permet de rajouter le support d’autres protocoles. Il est courant de voir les auteurs d’un nouveau proto-cole fournir le module permettant de le tester sous ns. Le simulateur dispose par ailleurs de différents utilitaires (nam, outil de représentation graphique du déroulement d’une simula-tion, xgraph, permettant de tracer les résultats obtenus, gt-itm et sgb2ns, facilitant la généra-tion de grands réseaux...)
b. Netscale
Contrairement à ns qui travaille avec des paquets, Netscale [26] est un simulateur util-isant la modélisation de TCP pour travailler avec des flux. Cela permet de réaliser des ex-périences avec énormément de flux, contrairement à ns qui est vite limité. Par contre, cela impose de ne travailler qu’avec TCP. Pour pouvoir utiliser un autre protocole de transport, il faut d’abord le modéliser puis l’implémenter "en dur" dans Netscale. Le simulateur permet de mesurer le débit, de trouver la position des goulots d’étranglement, de calculer les pertes à leur niveau, et d’obtenir la valeur du trafic en chaque lien et routeur.
3.4.2 Émulateurs a. Emulab
Emulab [27] est une plateforme d’émulation réseau très complète s’intègrant dans le pro-jet NetBed [29], qui a pour objectif de fournir un environnement expérimental, aussi bien sous la forme de simulation, d’émulation, que d’expériences réelles.
Emulab utilise le logiciel DummyNet [28] (sous FreeBSD) pour simuler les liens longue dis-tance. L’émulateur permet à l’utilisateur de choisir l’OS à déployer sur les clients ou les routeurs de sa topologie, si une image de cet OS est disponible.
Emulab nécessite du matériel précis et non anodin, et un gros investissement pour l’instal-lation. Classiquement, Emulab est installé une fois pour toute sur une grappe dédiée, et est ensuite utilisable par différentes équipes en simultané (grâce à un mécanisme de réserva-tion). On peut noter que les fichiers de description des topologies utilisées par Emulab sont des fichiers ns.
b. Modelnet
Modelnet [30] est un autre environnement d’émulation, également intégré à NetBed, qui utilise un noyau modifié de FreeBSD. La particularité de cet émulateur est de permettre d’intégrer plusieurs fonctionnalités sur une même machine physique (par exemple plusieurs routeurs et plusieurs liens...). Modelnet se spécialise sur l’émulation de réseaux de grande taille.
3.4.3 Outils orientés grilles de calcul
Les logiciels précédents sont utilisés pour des recherches sur les réseaux en général.
Cependant, les grilles de calcul présentant des caractéristiques particulières, certains outils ont été développés de façon plus spécifique.
Les simulateurs de grilles (SimGrid [31], MicroGrid [32]) permettent de simuler des ap-plications distribuées, notamment l’ordonnancement. Ils sont donc plus spécialisés que les simulateurs généraux (comme ns), et de plus haut niveau (par exemple, l’utilisateur n’a pas un contrôle total sur l’environnement).
EWAN [3], développé au LIP, est un émulateur de réseau longue distance haut débit.
C’est un instrument orienté sur l’étude des protocoles et des logiciels haute performance pour la grille avec un très grand nombre de calculateurs interconnectés. Il doit offrir un haut niveau de performance, une fine maîtrise des paramètres de communication associé à une grande flexibilité d’utilisation de l’instrument d’expérimentation.
a. ÉmulateurEWAN : émulation d’un nuage réseau de grille
EWAN est constitué d’une grappe de noeuds non nécessairement matériellement iden-tiques (avec par exemple un nombre d’interfaces, une capacité mémoire, ou CPU différents), reliés par un ou plusieurs commutateurs et d’un serveur qui s’occupera de configurer ces
noeuds. Ces machines appartiennent donc initialement au même sous-réseau et sont acces-sibles entre elles au niveau 2 de la couche OSI.
Le serveur de configuration va paramétrer les noeuds de la grappe afin d’émuler la topologie souhaitée (Fig 3), notamment en répartissant les différentes fonctions parmi eux.
Ceux-ci sonta priori polyvalents : tous possèdent les logiciels necessaires leur permettant d’assurer tous rôles. Les noeuds seront organisés en différents sous-réseau pour suivre in-stancier la topologie émulée, réalisant ainsi un réseau logiciel de niveau 3 sur une architec-ture matérielle de niveau 2. (c’est le concept d’overlay).
FIG. 3 – Émulation d’une topologie de grille à partir d’une grappe de calcul.
Les fonctions à émuler sont réparties parmi les noeuds grâce à un algorithme qui choisit les machines selon leurs caractéristiques physiques et les contraintes liées à la fonction. (Par exemple, un émulateur ne lien n’a besoin que de 2 interfaces, alors qu’il en faut normalement au moins 3 pour un routeur de coeur)
Puis les noeuds sont répartis dans des sous réseaux afin de representer l’architecture de la topologie. Un réseau de contrôle utilisant des interfaces virtuelles est conservé : il regroupe tous les noeuds et permet au serveur de configuration de s’adresser à n’importequel noeud directement. Ce réseau n’est pas utilisé durant l’experimentation, mais seulement au mo-ment des changemo-ments de configuration, donc il n’a aucune influence sur les performances de la grappe.
Les tables de routage sont calculées par l’algorithme de plus court chemin (Dijkstra) util-isé par OSPF : vu qu’une fois établie la topologie ne subira plus de changements au cours de l’experimentation, il n’est pas necessaire d’utiliser un protocole de routage dynamique qui se maintiendrait à jour en temps réel. Un calcul réalisé avant le début de l’experimentation est donc suffisant.
Enfin, le serveur crée un script de configuration pour chaque noeud utilisé, avant de les déployer et les exécuter dans la grappe qui sera ainsi totalemment configurée.
Dans le cadre de ce stage, j’ai ajouté à EWAN la possibilité d’outrepasser la limite du nombre d’interfaces par machine en utilisant des interfaces virtuelles : une même inter-face physique se voit attribuer plusieurs adresses IP, et réagira (au niveau 3 du modèle OSI) comme si plusieurs interfaces étaient disponibles. Cependant, l’utilisation d’interfaces virtuelles a un coût sur les performances, qui sera détaillé plus bas.
b. Émulateurs de liens
Afin d’émuler les liens, EWAN dispose du choix de plusieurs logiciels dédiés. Ceux-ci doivent permettre de recevoir des paquets par une interface, et de les transmettre en sortie sur une autre, selon certaines conditions correspondant aux caractéristiques du lien. Pour cela, les paquets reçus sont interceptés, stockés dans des files d’attente, et libérés selon divers paramètres.
NIST Net
NIST Net [33] est un logiciel développé par le NIST (National Institute of Standards and Technology). Il se présente sous la forme d’un module du noyau linux.
NIST Net se place juste avant les fonction IP du noyau et stocke les paquets en attente dans des tables, dont les tailles sont donc conditionnées par la mémoire de la machine utilisée.
Mais la facteur vraiment limitant selon diverses études de performances est le CPU. En effet, NIST Net doit régulièrement parcourir ces tables afin de stocker les paquets arrivant. Ainsi, plus la latence que l’on souhaite émuler est élevée, plus les tables seront longues, et plus le CPU devra être puissant.
Ce logiciel peut être utilisé parEWAN.
Netem
Netem est un module du noyau Linux, qui implémente les mêmes fonctionnalités que NIST Net. Cependant, il lui est supérieur en plusieurs points :
– Netem est disponible pour les noyaux 2.4 et 2.6, contrairement à NIST Net qui ne sup-porte que les premiers
– Netem supporte IPv6
– Netem ne fait pas en lui-même de distinction entre les flux. Cela peut ressembler à une limitation, mais en réalité, cette fonctionnalité de NIST-Net l’oblige à parcourir les tables de stockage afin de trouver les paquets d’un certain flux, ce qui entraine, comme dit plus haut, une très forte utilisation du CPU. Netem, lui, ne consomme presque aucune resource processeur.
– Netem bénéficie d’un développement actif, contrairement à NIST Net dont la dernière version date d’il y a 3 ans.
Ces raisons ont entrainé l’ajout du support de Netem dansEWAN durant mon stage.
Lors du développement initial d’EWAN, Netem venait d’être lancé, et restait experimental.
C’est pourquoi il avait été mis de coté momentanément.
c. Comparaison avec d’autres émulateurs
L’émulateur dont les fonctionnalités se rapprochent le plus de celles d’EWAN est Emu-lab. Cependant, ce dernier est d’une dimension radicalement supérieure.EWAN peut s’in-staller simplement et rapidement sur n’importe quel cluster GNU/Linux, alors qu’Emulab nécessite du materiel précis (ex : noeuds de 5 interfaces, switch programmable), et surtout un très gros investissement pour l’installation (jusqu’à deux semaines de travail). Emulab utilise
des VLAN2afin de séparer les diverses expériences pouvant se dérouler sur la grappe. Outre la complexité de la configuration de ces VLAN, ceux-ci ont un léger impact sur les per-formances. Ainsi, classiquemement, Emulab s’installe une fois pour toute sur une grappe spécialement achetée. Par la suite plusieurs équipes de chercheurs peuvent se partager les ressources de l’émulateur grâce à un mécanisme de réservation.EWAN est plutôt destiné à être installé rapidement, et utilisé pour une seule expérience à la fois.
Notons également qu’Emulab utilise Dummynet, qui ne supporte pas encore l’IPv6.
3.4.4 Comparaison simulateurs ou émulateurs
Les simulateurs permettent d’avoir un environnement totalement contrôlé, et un accès à toutes les variables pertinentes durant l’expérience. Cependant, ils ont certains incon-vénients majeurs [34] : Les simulateurs sont limités en terme de taille ou de durée. Une sim-ulation tournant sur un seul ordinateur, la mémoire disponible et la vitesses du processeur entraîne des contraintes sur l’expérience. Les simulateurs ne permettent pas de rendre cer-tains aspects de la réalité, comme les rafales, "burstiness" (phénomène sur lequel portent des travaux récents [35]), les problèmes d’implantation vus précédemment, ou la prise en compte des trafics perturbateurs réels. Les simulateurs imposent également de modéliser les applications, contrairement à l’émulation qui permet de déployer des applications ex-istantes sans aucunes modifications, comme si elles s’exécutaient dans un environnement réel.
Il paraît donc nécessaire de ne pas se limiter aux simulations lors d’une validation d’un protocole, mais également de le tester dans un environnement émulé, beaucoup plus proche de la réalité.
C’est pourquoi il faudrait pouvoir fournir un émulateur disposant de certaines fonction-nalités cruciales des simulateurs : paramétrage et lecture des variables mises en évidence plus haut.