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
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,
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.
Le débit est intégralement utilisé par chaque connexion :debit(ri) =debitmax.
Chaque transfert duretf(ri)−td(ri) = volume(rdebit(r i)
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.