Analyse de performances et d’interactions de flux hétérogènes de grilles de calcul. Application à la
conception d’expériences sur l’émulateur haute performance eWAN
Cyril Otal 22 Juin 2005
Résumé
Les grilles de calcul haute-performances, agrégation de ressources informatiques autour d’un nuage réseau à très haut débit, utilisent principalement le protocole TCP pour trans- ferer des données entre les différents sites de la grille. Or ce protocole, créé il y a plus de trente ans, et utilisé dans l’Internet, n’est finalement pas adapté au contexte des grilles, et des réseaux haut débit longue distance. D’autres protocoles sont proposés afin de combler les limites de TCP. Ces protocoles nécessitent d’être évalués, et comparés entre eux.
Au cours de ce stage, j’ai étudié les méthodologies de validations utilisés par les auteurs de ces protocoles, notamment les outils employés, et après avoir montré l’intérêt d’une plate- forme d’émulation, j’ai mis en évidence certains facteurs limitants, concernant aussi bien l’émulation que les experimentations réseau en général.
Table des matières
1 Contexte 4
2 Problématique 5
3 État de l’art 5
3.1 Le protocole TCP . . . 6
3.2 Autres protocoles de transport . . . 8
3.2.1 TCP Westwood . . . 8
3.2.2 TCP BIC . . . 8
3.2.3 XCP . . . 9
3.3 Implantation et configuration . . . 9
3.4 Outils d’évaluation de performances . . . 9
3.4.1 Simulateurs . . . 10
3.4.2 Émulateurs . . . 11
3.4.3 Outils orientés grilles de calcul . . . 11
3.4.4 Comparaison simulateurs ou émulateurs . . . 14
3.5 Méthodologie de validation des protocoles de transport. . . 14
3.5.1 TCP Westwood . . . 14
3.5.2 BIC TCP . . . 15
3.5.3 XCP . . . 15
3.5.4 Synthèse . . . 15
4 Modélisation 17 5 Experiences 17 5.1 Première expérience : ordonnancement de transferts TCP . . . 18
5.2 Facteurs généraux . . . 19
5.2.1 Influence de la carte réseau . . . 19
5.2.2 Influence des interfaces virtuelles . . . 20
5.2.3 Influence de la limitation de débit . . . 20
5.3 Facteurs dépendants deEWAN . . . 21
5.3.1 Influence du routage logiciel . . . 21
5.3.2 Influence de netem . . . 22
5.3.3 Outils de capture et d’analyse . . . 22
5.4 Application à l’expérience triviale d’ordonnancement de transferts TCP . . . 23
6 Conclusion et perspectives 23 6.1 Conclusion . . . 23 6.2 Travaux futurs . . . 23
1 Contexte
Les recherches menées dans ce stage s’inscrivent dans le cadre des grilles de calcul.
Une grappe de machines (cluster en anglais) est un groupe d’ordinateurs mis en réseau local, afin de former un ensemble de forte capacité, très utilisé pour les calculs parallèles.
Une grille (Fig 1) est un ensemble d’ordinateurs distribués géographiquement reliés par des réseaux longue distance (Internet, réseaux privés virtuels (VPN), ou réseaux privés réels), qui étend le principe du calcul parallèle des grappes à l’Internet.
FIG. 1 – Schéma d’une grille de calcul et du nuage réseau longue distance
Les grilles de calcul permettent une agrégation de ressources informatiques variées (comme la puissance de calcul ou de stockage de données).
Les premières grilles connues du grand public furent les logiciels de calcul distribué comme SETI@Home [1] puis Genome@Home [2] pour lequels les ordinateurs des particuliers tra- vaillaient et envoyaient au serveur le résultat de leurs efforts.
Puis les grilles se sont affranchies du modèle Client - Serveur afin que chaque ordinateur puisse lancer des calculs ou utiliser la puissance des autres. Dans le but d’obtenir toujours plus de puissance de calcul, des grilles regroupant plusieurs grappes furent créées.
Actuellement, la recherche dans ce domaine prometteur avance notamment grâce à la mise en place de plateformes expérimentales s’appuyant sur des réseaux haut débit (comme RE- NATER, réseau national regroupant des établissements scientifiques et universitaires, ou VTHD, premier réseau optique à multiplexage de longueurs d’ondes français).
Une grille se différentie d’une grappe de calculateurs par le type d’interconnexion réseau sur lequel elle s’appuie. Alors que dans un cluster, la distance internoeud est très courte, autorisant des latences de communication inférieures à la dizaine de microsecondes, dans
une grille, le "nuage" réseau doit permettre de couvrir des distances importantes. Le type et les caractéristiques du réseau longue distance (WAN) sous-jacent a une incidence directe sur le type d’applications et de performances que l’on peut viser.
L’une des premières utilisations des grilles est faite par certains domaines scientifiques recherche necessitant de lourds calculs (médecine, physique des particules, astrophysique...).
Ces applications scientifiques ont alors à transmettre beaucoup de données entre des sites (de l’ordre du To), reliés par des réseaux haut débit (1 à 10 Gb/s). L’efficacité du protocole de transport utilisé a alors un impact très important sur les performances d’execution de l’application.
Des travaux sont actuellement menés sur des protocoles de transports, et ces recherches nécessitent d’être validées, soit par simulation, soit en utilisant une implantation réelle.
Quelques travaux utilisent une approche hybride : l’émulation.
Par ailleurs on ne repère pas encore de démarche fixe et commune pour l’évaluation experi- mentale de ces protocoles.
2 Problématique
Dans le cadre de cette étude, on cherche d’abord à savoir s’il existe ou s’il est possible de déterminer une méthodologie à suivre dans le cadre de l’évaluation de protocoles. On regardera quels sont les paramètres choisis lors des expériences, quelles sont les métriques mesurées, et quelle sont les propriétés vérifiées. On examinera notamment quel type de val- idation est utilisé (simulation, expériences réelles), et quels sont les outils préférés.
On comparera ensuite l’approche de la simulation avec celle de l’émulation afin de savoir quels sont les avantages et inconvénients de chacunes d’elles, comme les problèmes de l’im- plantation et du parametrage des protocoles et des matériels réseaux pour l’émulation.
Puis on cherchera à identifier quels sont les intérêts et les limites d’un environnement d’é- mulation de réseau longue distance pour l’étude de ces protocoles spécifiques et de leurs usages dans le cadre d’une grille de calcul.
Le reste du rapport se présente de la façon suivante. Un état de l’art commencera par décrire TCP ainsi que d’autres protocoles de transports, puis présentera quelques outils util- isés dans l’évaluation de ces derniers, et terminera par une étude des méthodologies de vali- dations afin d’en déduire des expériences types. La modélisation de l’émulateur utilisé pour les expériences sera réalisée afin d’en extraire les différents composants pour faciliter l’inter- prétation des résultats expérimentaux. Puis, une étude experimentale commencera par une expérience typique qui mettra en évidence certains problèmes qui seront détaillés dans les expériences suivantes. Enfin, une conclusion résumera les travaux et ouvrira des perspec- tives.
3 État de l’art
Les grilles de calculs haute performance sont basées sur des réseaux haut débit (1-10Gb/s), longue distance (jusqu’à 150ms de latence), et s’appuient sur le protocole de transport TCP, utilisé dans l’Internet. Ce dernier présente des limites dans le cadre des grilles, intrinsèques à son fonctionnement. Afin de contourner ces problèmes, d’autres protocoles de transport
sont étudiés.
Ci dessous, nous rapellons les principes de TCP, puis détaillons trois de ces alternatives en montrant premièrement leurs apports par rapport à TCP, puis en regardant les métodologies utilisées.
3.1 Le protocole TCP
TCP [4] est un protocole de transport assurant des fonctionnalités essentielles pour le transport fiable des données au travers des réseaux non fiables (multiplexage de flux, con- trôle d’erreurs, contrôle de séquencement, contrôle de flux, contrôle de congestion) grâce à plusieurs mécanismes relativement complexes.
Premièrement, TCP permet à l’émetteur d’être informé de la bonne réception de ses pa- quets grâce à des messages d’acquittement (ACK) envoyés par le recepteur. Des paquets sont retransmis s’il n’y a pas d’acquittement reçus après un délai donné.
Ensuite, le protocole utilise un concept de fenêtre glissante à anticipation pour synchro- niser l’émetteur et le récepteur (contrôle de flux) : l’idée est que l’émetteur peut envoyer plusieurs paquets sans attendre leur acquittement. La taille de la fenêtre d’émission indique le nombre de paquets dits "en transit". À chaque reception d’un acquittement concernant le premier paquet de cette fenêtre (dite fenêtre de congestion :cwnd), celle-ci est décalée afin d’autoriser l’émetteur à envoyer les paquets suivants.
Par ailleurs, la taille de cette fenêtre est variable (mise à jour à chaque acquittement), ce qui permet d’assurer un contrôle du flux émis, et ainsi de réagir lors de la détection d’une congestion. Lorsqu’on se trouve dans le cas d’une congestion (les resources réseaux sont saturées), TCP va réduire la fenêtre. Dans le cas contraire, il va chercher à l’augmenter afin d’utiliser au maximum la capacité disponible. TCP utilise un algorithme appelé AIMD (Ad- ditive Increase, Multiplicative Decrease) [5] : la fenêtre est augmenté de façon additive, et diminuée de façon multiplicative. TCP dispose aussi d’une phase appelée Slow Start, utilisée pour rechercher rapidement la fenêtre maximale. Durant cette phase, la taille de la fenêtre commence à 1, et augmente exponentiellement (elle double à chaque retour d’acquittement).
Les phases se succèdent de la façon suivante (Fig 2) :
TCP commence en Slow Start, et augmente rapidement sa fenêtre jusqu’à atteindre une con- gestion. Alors, l’émetteur calcule un seuil (Wm) obtenu en multipliant la fenêtre actuelle (W∗)par un certain facteur (dans le cas de TCP, par 1/2) selon la partie Multiplicative De- crease de AIMD, et recommence en Slow Start jusqu’à atteindre cette valeur. À cet instant, TCP va se remettre à chercher la congestion, mais de façon moins aggressive : c’est la partie AI de AIMD : la fenêtre est incrémentée de l’inverse de sa taille multiplié par une constante (1 pour TCP), jusqu’à detecter une congestion, et recommencer en Slow Start.
AI :cwnd=cwnd+cwnd1 MD :cwnd= cwnd2
TCP détecte une congestion à partir des pertes de paquets. Ce n’est pas toujours perti- nent (certaines pertes peuvent avoir d’autres origines), et ce n’est pas immédiat (la detection des pertes se faisant toujours indirectement, par écoulement d’un délai d’attente).
Depuis sa création, des améliorations ont été apportées à cet algorithme.
Par exemple, une optimisation appelée Fast Recovery [6] (introduit dans la variante TCP
FIG. 2 – Évolution de la fenêtre de congestion
Reno [7]) consiste à ne pas repartir de zero lors d’un nouveau Slow Start, mais directement au niveau du seuil calculé, et dans la phase Additive Increase.
L’optimisation Fast Retransmit utilise les DUPACKs (paquets d’acquittement dupliqués), pour detecter plus rapidement une congestion : dans son acquittement, le recepteur indique le numéro de séquence du dernier paquet tel que tous les paquets précédents ont été reçus.
Par exemple si le recepteur a reçu les paquets 1, 2, 3, 5 et 6, il renverra le numéro 3. Lorsque l’émetteur reçoit un DUPACK, cela signifie que le recepteur a reçu un paquet alors qu’il reste un trou dans sa liste. Fast Retransmit considère qu’à partir de 3 DUPACKs, il faut ren- voyer le paquet manquant, sans attendre son timeout. Dans l’exemple précédent, si l’émet- teur reçoit plusieurs fois un DUPACK sur le paquet 3, cela signifie que plusieurs paquets sont arrivés (5, 6 et suivants), mais que le 4 manque toujours. Il sera donc retransmis sans plus attendre.
Des variantes de TCP ont été développées à partir de ces améliorations, et des modifi- cations de l’algorithme de croissance de la fenêtre (utilisation de variables différentes pour l’algorithme AIMD, ou formule totalement distincte).
TCP a été massivement adopté sur Internet grâce à plusieurs propriétés essentielles : – Détection de congestion : contrairement à d’autres protocoles de transports comme
UDP, TCP est capable de détecter une congestion et d’y réagir.
– Utilisation de la bande passante : TCP cherche toujours à utiliser au maximum la bande passante disponible, et il reste réactif lorsque celle-ci varie. TCP présente de très bonnes performances sur des réseaux disposant d’une faible latence ou d’un débit peu élevé.
– Équité : lorsque plusieurs flux TCP se partagent le même lien, l’algorithme TCP en- traine une répartition équitable de la bande passante entre tous ces flux.
Cette équité, communément mesurée à l’aide de l’indice de Jain [8], peut s’appliquer à diverses causes qui pourraient tendre à privilégier certains flux. On parlera par exem-
ple deRTT-fairness, équité entre flux n’ayant pas le même RTT1.
Malheureusement, devant l’augmentation des débits des réseaux actuels, et l’allonge- ment des liens, il est apparu que TCP devenait vite limité dans les réseaux haut débits longue distance[9, 10]. En effet, lorsque le produit débit-délai augmente, TCP devient in- stable et surtout nettement inefficace, avec un débit largement inferieur à la bande passante disponible. Ceci découle des algorithmes utilisés par ce protocole [11].
Aussi, de nouveaux protocoles de transports sont développés pour ces réseaux afin de réduire ces défauts.
En plus d’être performants dans ces environnements, ces protocoles ont comme objectif d’être aussi efficace que TCP dans les réseaux à faible latence ou faible débit, d’avoir les mêmes propriétés que TCP (Détection et adaptation face à une congestion, équité, réactiv- ité), et également d’être amical avec TCP, c’est à dire de permettre à des flux TCP et des flux du protocole rapide de se partager équitablement la bande passante.
3.2 Autres protocoles de transport
Plusieurs protocoles de transports pour réseau haut débit longue distance sont dévelop- pés et étudiés depuis 5 ans [12]. Parmi ceux-ci, citons HightSpeed TCP [14], Scalable TCP [15], FAST TCP [16], TCP Westwood [17], TCP BIC [19], CUBIC [18], XCP [20]...
Nous avons choisi parmi eux les trois qui nous semblaient les plus prometteurs au début de ce stage.
3.2.1 TCP Westwood
L’idée de TCP Westwood [17] est d’estimer la bande passante disponible de façon plus précise que TCP, en se basant sur la vitesse de réception des messages d’acquittement. Cette estimation est alors utilisée pour le calcul du seuil du Slow Start, ce qui permet à l’algorithme de perdre moins de temps à retrouver un régime normal après une congestion. Le protocole utilise également d’autres améliorations apportées à TCP, comme le Fast Recovery et le Fast Retransmit.
3.2.2 TCP BIC
L’objectif de BIC TCP [19] par rapport aux autres protocoles de transports pour réseaux longue distance et haut débit est d’assurer une équité entre des flux ne possédant pas le même RTT. Cela est réalisé par sa fonction d’évolution de la fenêtre de congestion, qui utilise une recherchebinaire pour detecter une congestion : la taille augmente plus vite lorsque le seuil est éloigné, et ralentit lorsqu’il se rapproche. Cette recherche s’ajoute à l’algorithme AIMD (avec toutefois des variables d’incrémentation plus élevées), ce qui permet à la fenêtre d’augmenter plus rapidement lorsqu’il reste beaucoup de bande passante disponible.
1Roud Time Trip : durée d’aller retour d’un message.
3.2.3 XCP
Le but d’XCP (eXplicit Control Protocol) [20] est de fournir un protocole de contrôle de congestion surpassant TCP dans les environnements courants, et restant stable, équitable et performant lorsque le débit ou le délai augmente.
Le protocole généralise l’ECN (Explicite Congestion Notification) [21], et s’éloigne donc de l’argument "End to End" en ne cherchant plus à modifier certains paramètres du protocole TCP, mais en faisant intervenir les routeurs du réseau.
L’idée principale est que contrairement à TCP, XCP n’a pas besoin de se baser sur des pertes pour détecter puis estimer une éventuelle congestion. Le protocole va faire en sorte que la source soit explicitement avertie de cette congestion par les routeurs, et ce de façon quantitative.
XCP utilise deux algorithmes :
– EC (Efficiency Controler) se charge d’éviter les congestions. Son but est de maximiser l’utilisation du lien, tout en minimisant les pertes et la taille des files d’attente. Il ren- voie la variation à appliquer à la fenêtre du ou des émetteurs.
– FC (Fairness Controler) est responsable de l’équité entre les flux. Il intervient après EC et adapte son résultat aux différents flux, en privilégiant les moins favorisés. FC se base sur l’algorithme AIMD.
3.3 Implantation et configuration
La description des algorithmes de TCP dans les différents documents standard Internet (RFC) ne précisent pas de quelles façon ils doivent être implémentés. On observe d’ailleurs d’importantes differences entre les implantations dans les différents systèmes d’exploitation.
Ces implantations ont un impact très important sur les performances du protocole. Kelly montre par exemple une incidence de 50% [15].
De plus, à haut débit, des limitations matérielles imposent diverses optimisations [22] aussi bien chez les constructeurs que chez les concepteurs de logiciels.
Par ailleurs, les algorithmes de TCP disposent de nombreuses variables qui peuvent être paramétrées. Afin d’augmenter les performances de ce protocole, notamment dans le cas problématique des réseaux haut débit longue distance, il est necessaire d’ajuster correcte- ment certaines de ces variables.
Par exemple, lorsque le débit augmente, il convient d’accroitre les tailles des tampons d’émission et de réception. Cependant, si le tampon de récéption est trop élevé, le mécanisme de contrôle de flux de TCP est perturbé.
La valeur optimale des fenêtres est égale au produit du débit par la durée de l’aller retour des messages.
La plupart du temps, ces variables dépendent de paramètres uniquement modifiables par l’administrateur de la machine (comme la limite supérieure de la taille des tampons).
3.4 Outils d’évaluation de performances
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 changements 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.
3.5 Méthodologie de validation des protocoles de transport.
Actuellement, de nombreux protocoles de transports sont à l’étude, améliorés, et com- parés entre eux, comme dans le groupe de travail PFLDnet [13].
Afin de comprendre comment ces études sont menées, nous avons examiné comment les 3 protocoles présentés en 3.2 ont été validés par leurs auteurs dans les articles fondateurs.
3.5.1 TCP Westwood
Comme le fonctionnement de TCP Westwood repose sur la réception d’ACK, il est po- tentiellement très sensible aux pertes. C’est pourquoi ses auteurs ont voulu montrer experi- mentalement sa résistance aux pertes, en plus d’une meilleure performance que TCP.
Les expériences ont été réalisées sur le simulateur ns, en utilisant un réseau ne con- tenant qu’un seul goulot d’étranglement (Topologie H, Fig 4). Un premier groupe d’expéri-
2Virtual Local Area Network : regroupement au niveau 2 de certaines machines sur un même switch, simulant ainsi la présence de plusieurs switchs distincts.
ences étudie le comportement face aux pertes induites par des trafics perturbateurs (des flux UDP), sur un lien à 45Mb/s de débit et 250ms de latence en modifiant le nombre de flux, puis en augmentant le débit jusqu’à 150Mb/s, et enfin en faisant varier la latence entre 10ms et 1s. Le deuxième groupe d’expériences se concentre sur les pertes liées un lien lui-même, en faisant varier les mêmes paramètres.
3.5.2 BIC TCP
Les propriétés de BIC TCP mises en avant par ses auteurs sont l’équité face aux RTT différents, le passage à l’échelle des haut débits, l’équité avec TCP, et la rapide convergence vers ces différents états équitables
Les expériences des auteurs sont réalisées avec le simulateur ns, sur une topologie com- prenant 2 routeurs de part et d’autre d’un lien limitant, et de plusieurs récepteurs et plusieurs émetteurs reliés respectivement aux premier et au deuxième routeur, par des liens aux la- tences différentes (Topologie HE, Fig 5). Les métriques mesurées sont la taille de la fenêtre (nombre de paquets divisé par le RTT), les pertes, l’indice d’équité, en faisant varier la bande passante, le nombre de flux, le trafic perturbateur, et les politiques de queues des routeurs.
3.5.3 XCP
Les études expérimentales de XCP se sont concentrées sur ses performances, comparées à celles de TCP, ainsi que son équité. Elles ont été réalisées avec le simulateur ns.
Les métriques étudiées sont l’utilisation des liens, la taille des queues ainsi que les pertes, en faisant varier le débit, la latence, ainsi que le nombre de flux. Les topologies utilisées sont les "haltères" (Fig 4) et la topologie "arrête de poisson" (Fig 6).
3.5.4 Synthèse
Les topologies utilisées (figures 4, 5 et 6) ont en commun d’introduire une ou des conges- tions à des endroits précis.
Client
Client
Routeur Routeur
Serveur Serveur Lien limitant
FIG. 4 – Topologie Haltere (H), dite"Dumpbell"
Le tableau 1 rassemble les différents éléments relevés précédemment, auxquels s’ajoutent d’autres paramètres interviennant dans les expériences étudiées :
– Les trafics perturbateurs sont utilisés pour étudier la réaction du protocole à certaines congestions. Les plus courants sur Internet sont les flux web, correspondant aux re- quetes des navigateur vers les serveurs web et la réponse de ces derniers. Ce sont des flux courts.
Client
Client
Routeur Routeur
Serveur Serveur
Client Serveur
Lien limitant
FIG. 5 – Topologie Haltere Étendue (HE)
Routeur
Client Routeur Routeur Routeur
Cross Traffic Cross Traffic Cross Traffic
Puit Puit Puit
Puit
Serveur Cross Traffic
FIG. 6 – Topologie Arrete de Poisson (AP)
– Les politiques de queues (AQM : Active Queue Management) déterminent la réaction des routeurs face aux replissage de leur file d’attente. La méthode intuitive (Drop tail), consite à jeter les paquets quand les files sont pleines. Cependant, en utilisant RED (Random Early Detection) certains paquets sont éliminés volontairement lorsque les files sont presque pleines, afin de signaler à TCP qu’une congestion est proche.
On se rend ainsi compte que les expériences sont suffisamment hétérogènes pour ne pas permettre une bonne comparaison entre les différents protocoles. De plus, outre l’étude théorique, ces trois protocoles n’ont été experimentés initialement qu’en simulation, ce qui provient du fait que ce sont trois propositions algorithmiques.
Ces protocoles sont actuellement développés et des implantations existent. Une version Linux de BIC a d’ailleurs été utilisée dans cette étude.
Protocole Métrique Topologie RTT (ms) Débit (Mb/s) Nb de flux Perturbations Autres BIC pertes,
fenêtre, fairness index
HE 40 - 240 20 - 2500 1 - 25 Flux web AQM
XCP Utilisation, queues, pertes
H ou AP 0 - 1400 0 - 4000 1 - 1000 Flux web AQM
Westwood Débit H 10 - 1000 45 - 150 1 - 30 Flux UDP
TAB. 1 – Metriques utilisées dans les validations de protocoles de transport
4 Modélisation
La plateforme d’émulation permet d’intervenir sur différentes files d’attente du réseau (fig 7) : celles des cartes réseau, celles du protocole IP (qdisc), et celles du protocole de trans- port (socket buffer).
L’émulateur de lien netem utilise une qdisc particulière pour stocker les messages.
Socket Buffet qdisc
Carte réseau
Commutateur
Commutateur
Commutateur
Routeur
Carte qdisc qdisc Carte
Commutateur
Routeur
Carte qdisc qdisc Carte
Commutateur
Émetteur Émetteur
Émulateur de lien
Carte qdisc qdisc netem Carte
Récepteur
Récepteur
FIG. 7 – Modélisation de l’émulateur
Les valeurs par défaut dans le noyau Linux sont de 1000 octets pour les qdisc, et de 131071 pour les socket buffers.
5 Experiences
Le but des expériences effectuées est d’étudier l’impact des aspects matériel et des im- plantations, afin de mettre en évidence des problèmes et les calibrer, aussi bien dans le cas général de la grille de calcul que dans celui de l’émumateurEWAN.
Les expériences ont été réalisées sur les grappes de Lyon et d’Orsay de la grille GRID5000 [36]
La grappe de Lyon est composée de bi-opteron (servant de clients) et de 12 bi-xeon (2 fois 2.80GHz) constituant les noeuds réseau qui seront utilisés pour les expériences. Ceux
ci disposent de 3 interfaces réseau, mais le commutateur 1Gb/s devant les relier ne possé- dant pas assez de ports, seuls deux noeuds sont branchés par trois interfaces, les autres se répartissant les ports restant, en allant de deux à une seule interface utilisable.
La grade d’Orsay, appelée Grid Explorer (GdX) est formée pour sa partie réseau de 32 xeons (3GHz) reliés sur un même commutateur à 1Gb/s, par deux interfaces réseau.
Les mesures de débit sont effectuées à partir du logiciel iperf, qui calcule ce débit en envoyant des données depuis l’émetteur vers le recepteur.
5.1 Première expérience : ordonnancement de transferts TCP
Nous avons d’abord réalisé une première expérience simple, et de façon naïve.
La topologie utilisée est celle de l’haltère (Fig 4). Deux clients sont séparés de deux serveurs par le lien limitant, et possèdent chacun la même quantité de données à transmet- tre. Tous les liens ont une capacité de 1Gb/s, et la congestion apparaît donc au niveau du point d’accès des clients.
Deux types de transferts sont étudiés. Le premier consiste à laisser les deux clients émettre en même temps, le deuxième à attendre que le premier ait fini pour laisser le second (Les transferts sont ainsi ordonnancés).
L’analyse suivante prouve que le deuxième solution est plus performante.
Soitr1etr2les deux requêtes.
Le débit ces requêtes,debit(ri) est limité par la capacité des liens d’accès debitmax(ri) = 1Gb/s. Elles ont un volume de données égal à transmettre :volume(r1) =volume(r2) Le début du transfert est notétd(ri)et la fintf(ri), vérifianttf(ri) =td(ri) +volume(rdebit(r i)
i)
Soitfdla fonction d’optimisation du délai, que l’on cherche minimale. C’est le maximum des temps de transferts de chaque connexion.
fd=maxtf(r)−td(r)
Soitfula fonction d’optimisation de l’utilisation, que l’on veut maximale. C’est la somme des utilisations (quotient du débit par la durée de transfert), divisée par la bande passante disponible
fu =
debit(r1)
tf(r1)−td(r1)+tf(rdebit(r2)
2)−td(r2)
Bacc où Bacc est la bande passante du point d’accès des clients (1Gb/s).
– Dans le premier cas, on a :
Date de début :td(r1) =td(r2) = 0
La bande passante est équitablement répartie entre les deux connexions, doncdebit(ri) = debitmax/2.
La date de fin du transfert vauttf(ri) =td(ri) +volume(rdebit(r i)
i)
On a :fd=maxtf(r)−td(r) = 2∗volume(rdebitmaxi) Et :fu = debit(r(t 1)+debit(r2)
f(r)−td(r))∗Bacc = volume∗Bdebitmax2
acc
– Dans le deuxième cas, on a :
Dates de début :td(r1) = 0ettd(r2) =tf(r1)(Le deuxième transfert commence à la fin du premier).
Le débit est intégralement utilisé par chaque connexion :debit(ri) =debitmax.
Chaque transfert duretf(ri)−td(ri) = volume(rdebit(r i)
i)
On obtient donc :fd=maxtf(r)−td(r)= volume(rdebitmaxi) Et :fu = (tdebit(r1)+debit(r2)
f(ri)−td(ri))∗Bacc = volume∗Bdebitmax2
acc
Ainsi, si la fonction d’optimisation de l’utilisation est identique pour les deux solutions de transfert, celle du délai est deux fois meilleure dans la deuxième.
Concrétement, on s’attend à vérifier experimentalement qu’un flux seul va s’achever deux fois plus tôt que deux flux simultanés.
Voici ce qui a été initialement observé :
Le protocole utilisé est BIC, et la quantité de données à envoyer est de 1875Mbyte pour 0ms de latence, et 185Mbyte pour 10ms et 100ms.
Latence (ms) 1 flux seul flux simultanés
0 33.5s 470 Mbits/s 37.1s 424 Mbits/s 39.5s 398 Mbits/s 10 64.2s 24.4Mbits/s 64.6s 24.0 Mbits/s 66.7s 23.3 Mbits/s 100 612.5s 2.53 Mbits/s 612.5s 2.53 Mbits/s 612.5s 2.53 Mbits/s
TAB. 2 – Temps de transfert et débits observés
On constate tout d’abord que l’équité entre les flux simultanés n’est pas respectée. Cela s’expliquera par une accumulation de facteurs limitant du côté d’un des clients.
On remarque également une chute du débit lorsque la latence augmente, jusqu’à n’atteindre que 0.25% de la bande passante disponible.
Les premiers résultats ont mis en évidence plusieurs facteurs du dispositif responsables d’une perte de performances : la virtualisation des interfaces, le routage logiciel, l’émulation de lien par netem, et les cartes réseaux.
5.2 Facteurs généraux
5.2.1 Influence de la carte réseau
La première dissymétrie remarquée dans l’expérience précedente fut l’utilisation de cartes réseau différentes. Nous avons donc tenté de les comparer.
L’expérience consiste à envoyer un flux de données entre deux machines dos à dos, c’est à dire directement, en passant juste par un commutateur. La fenêtre TCP est celle par défaut (16kByte), car nous sommes à faible latence.
Les mesures ont été effectuées sur trois modèles de cartes réseau, deux à Lyon et un à Orsay, et pour deux bandes passantes disponibles : 1 Gbit et 100Mbit, en choisissant le même modèle côté émeteur et côté recepteur.
1 Gbit/s
Lyon eth1-eth1 Lyon eth2-eth2 GdX eth1-eth1 TCP 941 Mbits/s 762 Mbits/s 941 Mbits/s UDP 957 Mbits/s 957 Mbits/s 957 Mbits/s
TAB. 3 – Débit mesuré selon la carte réseau utilisée, pour 1Gbit
100 Mbit/s
Lyon eth1-eth1 Lyon eth2-eth2 GdX eth1-eth1 TCP 97.3 Mbits/s 97.3 Mbits/s 97.3 Mbits/s UDP 98.8 Mbits/s 98.8 Mbits/s 98.8 Mbits/s
TAB. 4 – Débit mesuré selon la carte réseau utilisée, pour 100 Mbit
Ces résultats montre qu’à haut débit (tableau 3), l’une des cartes réseau ne permet pas à TCP d’atteindre le débit souhaité, contrairement au cas d’un débit plus faible (tableau 4).
Cette carte atteint donc ses limites à haut débit.
5.2.2 Influence des interfaces virtuelles
Le nombre d’interfaces réseau des machines étant limité, eWAN est obligé d’avoir recourt à des interfaces virtuelles, c’est à dire d’assigner deux adresses IP (ou plus) à une seule interface physique.
Une première expérience, réalisée avec deux machines dos à dos, ne montre pas réelle- ment d’impact. Dans ce tableau (5), "eth1:" represente l’utilisation d’une interface virtuelle,
eth1-eth1 eth1-eth1: eth1:-eth1: eth2-eth2 eth2-eth2: eth2:-eth2:
1000 941 941 941 762 761 761
100 97.3 97.3 97.3 97.3 97.3 97.3
TAB. 5 – Débits en Mbit/s mesurés entre deux machines dos à dos contrairement à "eth1".
Puis, en utilisant un routeur entre les deux machines, on obtient les résultats suivants : eth1/eth1 eth1/eth1: eth1:/eth1: eth1/eth2 eth1/eth2: eth1:/eth2 eth1:/eth2:
1000 585 578 549 616 616 614 614
100 97.3 97.3 97.3 97.2 97.2 97.2 97.2
TAB. 6 – Débits en Mbit/s mesurés entre deux machines séparées par un routeur Les deux séries d’expériences ont été réalisées à Lyon, avec le protocole TCP et la fenêtre par défaut (16kByte).
On constate donc qu’à haut débit, et en présence d’une machine intermédiaire servant de routeur, l’utilisation des interfaces virtuelles a un impact plus ou moins important, selon le modèle de la carte réseau utilisé.
5.2.3 Influence de la limitation de débit
La limitation de débit consiste à configurer une machine (en intervenant sur la file d’at- tente du niveau IP,qdisc), afin de limiter artificiellement la bande passante utilisable.
La façon classique (et reprise parEWAN) pour réaliser cette limitation est d’utiliser le logicieltcet l’algorithme TBF (Token Bucket Filter).
Nous avons voulu savoir si cette solution était efficace, en comparant notamment ses perfomances avec celles d’un vrai réseau au débit plus faible.
Plateforme Débit UDP TCP
GdX 100 99 97.3
500 500 494
Lyon 100 98.7 97.3
500 500 494
Réseau à 100Mb/s 100 95.8 91.8
TAB. 7 – Débits en Mbit/s mesurés entre deux machines dos à dos
On constate dans ces mesures (tableau 7) que le débit est bien limité correctement, et ce au niveau IP comme souhaité (TCP et UDP sont tous deux limités).
Les résultats sont un peu meilleurs que ceux obtenus dans un vrai réseau à plus faible débit, sans doute car celui ci doit experimenter d’autres limitations (comme par exemple les cartes réseau qui atteignent leur débit maximal dans cette expérience).
5.3 Facteurs dépendants deEWAN
5.3.1 Influence du routage logiciel
EWAN utilise certains noeuds de la grappe afin d’émuler des routeurs. Le routage est dit alors "logiciel", par opposition aux routeurs matériels, qui sont des équipements réseau dédiés.
Afin de mesurer l’impact de ce traitement logiciel, nous avons réalisé l’expérience simple suivante : un émetteur est séparé du récepteur par un routeur, et va tenter de lui transmettre des données avec plusieurs protocoles.
Plateforme UDP TCP BIC
GdX 957 941 941
Lyon à 1Gb/s 957 572 572 Lyon à 100Mb/s 98.7 97.3 97.3
TAB. 8 – Débits en Mbit/s mesurés entre deux machines séparées par un routeur logiciel Les mesures du tableau 8 montre tout d’abord qu’à un débit de 100Mb/s, le routage logi- ciel n’influe pas sur les performances (les chiffres sont à comparer avec ceux du tableau 7).
Par ailleurs, si l’expérience à Lyon montre une chute importante du débit, il n’en est ap- paremment rien sur la plateforme GdX.
Il faut augmenter le nombre de routeurs logiciels intermédiaires pour arriver à constater la limitation apportée par ces routeurs (tableau 9).
UDP TCP BIC
957 498 498
TAB. 9 – Débits en Mbit/s mesurés entre deux machines séparées par 3 routeurs logiciels
5.3.2 Influence de netem
Pour émuler les liens longue distance,EWAN utilise le logiciel netem qui agit au niveau des files d’attente IP (qdisc). Pour étudier son impact sur le débit, nous avons placé, sur la plateforme GdX, un émetteur et un recepteur de part et d’autre d’un routeur sur lequel sera configuré netem pour les latences 0, 1ms, 10ms et 100ms. On comparera les résultats avec ceux obtenus dans la même topologie, mais sans netem.
Les fenêtres de congestions sont adaptées aux différentes latences émulées.
sans netem 0ms 1ms 10ms 100ms
UDP 957 957 957 957 957
TCP 941 600 445 70.5 72
BIC 941 600 445 70.5 72.5
TAB. 10 – Débits en Mbit/s mesurés entre deux machines séparées par un émulateur de lien (netem)
On constate (Tableau 10) que le simple fait d’utiliser netem, même pour ne simuler au- cune latence, a un impact important sur le débit. Et les performances diminuent davantage lorsque la latence émulée augmente.
Ces tests réalisés sur GdX utilisent donc la version de netem fournie avec le noyau 2.6.11.12.
Des expériences similaires, mais avec une version plus ancienne, avaient donné des résul- tats encore moins bon (par exemple 593Mbit/s pour 0ms de latence, 200Mb/s pour 1ms...).
On espère donc que le développement toujours actif de netem parviendra à diminuer ces limitations.
5.3.3 Outils de capture et d’analyse
Une plateforme d’émulation doit être capable de fournir des informations sur le réseau, en temps réel ou dans des journaux.
TCPdump
TCPdump [37] est un puissant outil de capture de paquets, permettant des analyses depuis le niveau ethernet jusqu’au niveau de certains protocoles de transport. En édutiant les journaux sauvegardés, il est ainsi possible de reperer les pertes, les retransmissions de paquets, les duplications...
Cependant, cette capture en temps réel a un coût non négligeable.
sans TCPdump TCPDump en mode direct TCPDump en mode capture
1Gb/s 941 929 938
100Mb/s 93.7 93.7 93.7
TAB. 11 – Débits en Mbit/s mesurés entre deux machines dos à dos
Les mesures du tableau 11 montre qu’à 100Mb/s, TCPdump ne perturbe pas TCP. C’est encore une fois à haut débit que la limitation se fait ressentir.
Une solution pour capturer les paquets en perturbant moins l’expérience serait d’utiliser le concept deport miroring: on configure le commutateur afin qu’il duplique sur un certain port ce qu’il envoie sur un autre. Il suffirait alors de capturer les paquets sur une machine branchée sur ce port miroir.
5.4 Application à l’expérience triviale d’ordonnancement de transferts TCP En reprenant la première expérience, en faisant en sorte d’éviter les cas problématiques soulevés plus haut (interfaces virtuelles, cartes réseau moins performantes), et en configu- rant convenablement TCP, on obtient des résultats plus appréciables.
TCP :
Latence (ms) 1 flux 2 flux
0 31.6s 498 Mbits/s 63.1s 250 Mbits/s 10 61.8s 254 Mbits/s 63.7s 248 Mbits/s 100 109.3s 144 Mbits/s 109.5s 143 Mbits/s
TAB. 12 – Temps de transfert et débits observés avec TCP BIC :
Latence (ms) 1 flux 2 flux
0 31.6s 498 Mbits/s 63.1s 250 Mbits/s 10 61.8s 255 Mbits/s 63.5s 248 Mbits/s 100 109.3s 144 Mbits/s 109.7s 143 Mbits/s
TAB. 13 – Temps de transfert et débits observés avec BIC TCP
Tout d’abord, on observe une vraie équité entre les deux flux simultanés. Puis, les débits, bien qu’étant encore faible, sont cependant nettement plus élevés que dans la première série de mesures.
6 Conclusion et perspectives
6.1 Conclusion
Les résultats obtenus dans cette étude ont montré qu’à haut débit, plusieurs facteurs de- venaient vite limitants et affectaient profondément les performances observées. Les mesures réalisées permettent d’obtenir un premier calibrage de ces impacts, et montre les limites et les difficultés de l’émulation.
6.2 Travaux futurs
Les recherches sur la méthodologie utilisée dans la validation des protocoles de trans- port mettent en évidence des améliorations à apporter à l’émulateur EWAN (Monitoring,
contrôle des files d’attentes...), afin qu’il puisse parfaitement servir de plateforme d’évalua- tion de performance. Par ailleurs, le phénomène de rafales (burstiness), impossible à étudier en simulation, n’a pas encore pu être mesuré dans le cadre d’un émulateur. Il serait donc intéressant de mener des études à ce sujet, notamment en appliquant des solutions dévelop- pées pour réduire ce phénomène (comme lepacing[38]).
Références
[1] David P. Anderson , Jeff Cobb , Eric Korpela , Matt Lebofsky , Dan Werthimer
"SETI@home : an experiment in public-resource computing" in Communications of the ACM, v.45 n.11, p.56-61, Novembre 2002.
Voir aussihttp ://setiathome.ssl.berkeley.edu/
[2] http ://www.stanford.edu/group/pandegroup/genome/
[3] Pascale Vicat-Blanc, Olivier Glück, Cyril Otal, François Echantillac."Emulation of a grid network cloud : eWAN", Rapport de recherche de l’INRIA RR-5449, Décembre 2004.
[4] J. B. Postel,RFC 793, Septembre 1981
[5] V. Jacobson."Congestion avoidance and control". In ACM SIGCOMM ’88 pages 314-329, Août 1988.
[6] M. Allman, V. Paxson, and W. R. Stevens."TCP Congestion Control". RFC 2581, Avril 1999.
[7] Floyd, S. and T. Henderson, "The NewReno Modification to TCP’s Fast Recovery Algo- rithm", RFC 2582, Avril 1999.
[8] Raj Jain."The Art of Computer System Performance Analysis. Wiley", 1991.
[9] Van Jacobson, Robert Braden, and Dave Borman."TCP extensions for high performance", RFC 1323, Mai 1992.
[10] V. Sander, J. Crowcroft, F. Travostino, P. Vicat-Blanc Primet, C. Pham, al. "Networking issues of GRID Infrastructures", http ://forge.gridforum.org/projects/ghpn-rg/document/
draft-ggf-ghpn-netissues-0/en/1/draft-ggfghpn-netissues-1.pdf, GGF Informational Document.
[11] T. V. Lakshman and U. Madhow, "The Performance of TCP/IP for Networks with High Bandwidth-delay Products and Random Loss" IEEE/ACM Transactions on Networking, vol. 5, no. 3, pages 336-350, Juillet 1997.
[12] M. Goutelle, Y. Gu, E. He, S. Hegde, R. Kettimuthu, J. Leigh, P. Primet, M. Welzl, C.
Xiong, M. Yousaf :" A Survey of Transport Protocols other than Standard TCP", work in progress.
[13] http ://www.ens-lyon.fr/LIP/RESO/pfldnet2005/
[14] Sally Floyd. "HighSpeed TCP for Large Congestion Windows", RFC 3649, Experimental, Décembre 2003.
[15] Tom Kelly,"Scalable TCP : Improving Performance in Highspeed Wide Area Networks"Com- puter Communication Review, Volume 33, Issue 2, pages 83-91, Avril 2003.
[16] C. Jin, D. X. Wei, and S. H. Low,"FAST TCP : Motivation, Architecture, Algorithms, Perfor- mance"in Proceedings of IEEE INFOCOM’04, Mars 2004.
[17] C. Casetti, M. Gerla, S. S. Lee, S. Mascolo and M. Sanadidi,"TCP with Faster Recovery", In Proceedings of MILCOM 2000, Los Angeles, CA, Octobre 2000
[18] Injong Rhee, and Lisong Xu."CUBIC : A New TCP-Friendly High-Speed TCP Variant.", in the Third International Workshop on Protocols for Fast Long-Distance Networks. 2005.
[19] L. Xu, K. Harfoush, and I. Rhee."Binary increase congestion control for fast long distance networks"In Proc. of INFOCOM, 2004.
[20] Katabi, Handley, Rohrs ,"Congestion Control for High Bandwidth-Delay Product Networks"
In ACM SIGCOMM 2002, pages 89-102. ACM Press, 2002.
[21] Ramakrishnan, K.K., Floyd, S., and Black, D.RFC 3168, Proposed Standard, Septembre 2001
[22] J. S. Chase, A. J. Gallatin, and K. G. Yocum,"End system optimizations for high-speed TCP"
in IEEE Communications Magazine, pages 68-74, Avril 2001.
[23] L. Breslau, D. Estrin, K. Fall, S. Floyd, J. Heidemann, A. Helmy, P. Huang, S. McCanne, K. Varadhan, Y. Xu, H. Yu, "Advances in Network Simulation", IEEE Computer, vol. 33, No. 5, pages 59-67, Mai 2000.
[24] http ://www.isi.edu/nsnam/ns/
[25] Fall, K."Network emulation in the Vint/NS simulator"in Proceedings of the 4th IEEE Sym- posium on Computers and Communications pages 244-250 (Juillet 1999).
Voir aussihttp ://netweb.usc.edu/vint
[26] F. Baccelli and D. Hong, "Flow level simulation of large IP networks" in Proceedings of IEEE Infocom, pages 1911. Avril 2003.
[27] Brian White, Jay Lepreau, Leigh Stoller, Robert Ricci, Shashi Guruprasad, Mac New- bold, Mike Hibler, Chad Barb et Abhijeet Joglekar :"An Integrated Experimental Environ- ment for Distributed Systems and Networks"in Proc. of the Fifth Symposium on Operating Systems Design and Implementation, pages 255-270, décembre 2002.
Voir aussihttp ://www.emulab.net/
[28] Luigi Rizzo,"Dummynet : a simple approach to the evaluation of network protocols", ACM SIGCOMM Computer Communication Review, v.27 n.1, p.31-41, Janvier 1997.
Voir aussihttp ://info.iet.unipi.it/˜luigi/ip_dummynet/
[29] Brian White, Shashi Guruprasad, Mac Newbold, Jay Lepreau, Leigh Stoller, Robert Ricci, Chad Barb, Mike Hibler et Abhijeet Joglekar "Netbed : an integrated experimental environment"in SIGCOMM Comput. Commun. Rev. volume 32 page 27 (2002).
[30] Amin Vahdat, Ken Yocum, Kevin Walsh, Priya Mahadevan, Dejan Kostic, Jeff Chase, and David Becker :"Scalability and Accuracy in a Large-Scale Network Emulator"in Pro- ceedings of 5th Symposium on Operating Systems Design and Implementation (OSDI), Decembre 2002.
Voir aussihttp ://issg.cs.duke.edu/modelnet.html
[31] H. Casanova. "Simgrid : A Toolkit for the Simulation of Application Scheduling." In Pro- ceedings of the IEEE International Symposium on Cluster Computing and the Grid (CCGrid’01), pages 430-437, Mai 2001.
[32] Xin Liu, Huaxia Xia, and Andrew Chien,"Validating and Scaling the MicroGrid : A Scien- tific Instrument for Grid Dynamics". Journal of Grid Computing, 2003.
[33] Mark Carson and Darrin Santay "NIST Net : a Linux-based network emulation tool" in SIGCOMM Comput. Commun. Rev. volume 33 pages 111-126 (2003).
Voir aussihttp ://www-x.antd.nist.gov/nistnet/
[34] Sally Floyd et Vern Paxson"Difficulties in simulating the internet", in IEEE/ACM Trans.
Netw. volume 9, n◦4, pages 392-403 (2001).
[35] David X. Wei, Sanjay Hegde, Steven H Low :"A Burstiness Control for High Speed Long Distance TCP " , Proceedings of Third International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet’05)
[36] http ://www.grid5000.org/
[37] http ://www.tcpdump.org/
[38] A. Aggarwal, S. Savage, and T. Anderson,"Understanding the Performance of TCP Pac- ing", Proceedings of the 2000 IEEE Infocom Conference, Tel-Aviv, Israel, Mars 2000.
Remerciements
Je tiens tout d’abord à remercier Pascale Vicat-Blanc Primet et Olivier Glück pour leur encadrement. Je remercie ensuite Stéphane d’Alu et Philippe Marty pour m’avoir aidé sur respectivement les grappes de Lyon et d’Orsay. Et je remercie enfin l’équipe RESO du LIP pour m’avoir apporté diverses réponses et conseils, notamment Dino Martin Lopez Pacheco, Brice Goglin, Jingdi Zeng, Jean-Patrick Gelas, et Sébastien Soudan.
