Evaluation des Algorithmes de choix des pi` ´ eces et des pairs

Dans [79], nous avons effectu´e une ´etude avanc´ee des algorithmes de s´election des pi`eces (rarest first) et des pairs (choke) dans BT `a l’aide de mesures. Ces algorithmes forment le cœur de BT. La question `a laquelle nous avons cherch´e `a r´epondre est de savoir s’ils

´etaient efficaces ou s’il fallait les am´eliorer ou les remplacer. Plusieurs ´etudes ont, en effet, soutenu que ces algorithmes ´etaient souvent sous-optimaux et devaient ˆetre remplac´es.

Dans [57], les auteurs proposent de remplacer ces algorithmes par une technique dite de codage r´eseau, cens´ee garantir une meilleure entropie des pi`eces dans le torrent. En ce qui concerne l’algorithme choke, plusieurs ´etudes ont soulign´e sa possible in´equit´e [96, 73].

Plutˆot que de simplement classer les pairs en fonction du d´ebit qu’ils offrent et envoyer

`

a ceux qui offrent les meilleurs d´ebits, ces ´etudes proposent que les quantit´es de donn´ees

´echang´ees soient ´egalis´ees, afin d’obtenir une ´equit´e au niveau bit.

Notre ´etude repose sur une collection de traces de niveau applicatif obtenues avec un client BT instrumentalis´e. Ce dernier nous permet de suivre tous les ´echanges de pi`eces et de connaˆıtre les changements d’´etats des diff´erents pairs dans le peer set de notre pair instrumentalis´e. Nous avons travaill´e sur des torrents de toute taille pour des contenus de toute sorte, comme montr´e dans le tableau 4.1.

En ´etudiant une grande vari´et´e qualitative de torrents, nous esp´erons que nos conclusions d´epassent le simple cadre anecdotique et caract´erisent le protocole BT de mani`ere g´en´erale.

Algorithme Rarest First

L’algorithme rarest first cherche `a favoriser les ´echanges de pi`eces entre pairs de mani`ere

`

a ce que deux pairs aient toujours des pi`eces `a s’´echanger. Nous parlons alors d’entropie id´eale. Comme nous n’avons pas acc`es `a tous les pairs d’un torrent, mais seulement

`

a notre pair instrumentalis´e et par son interm´ediaire, `a la connaissance des pi`eces que chaque pair poss`ede `a un instant donn´e⁶, nous avons caract´eris´e l’entropie du torrent du point de vue de notre client en calculant deux ratios :

– le ratio ^a_b du temps cumul´e a pendant lequel notre pair instrumentalis´e est int´eress´e⁷ par un autre pair de sonpeer set sur le temps cumul´eb pendant lequel ce pair est dans lepeer setdu pair instrumentalis´e pendant que ce dernier est unleecher(n’a pas encore la totalit´e du contenu `a r´epliquer).

6BT sp´ecifie que chaque pair doit annoncer `a son peer set toutes les pi`eces qu’ils re¸coit - cela sert

`

a d´eterminer les pi`eces les plus rares dans lepeer set.

7un pair int´eress´e par un autre pair signifie que le premier est int´eress´e dans une pi`ece au moins que le second poss`ede et qu’il ne poss`ede pas.

Tab.4.1 – Caract´eristiques des torrents.

Torrent # of seeds # of leechers Size (MB)

1 50 18 600

2 1 40 800

3 1 2 580

4 115 19 430

5 160 5 6

6 102 342 200

7 9 30 350

8 1 29 350

9 12612 7052 140

10 462 180 2600

11 1 130 820

12 30 230 820

13 0 66 700

14 3 612 1413

15 3697 7341 349

16 1 50 1419

17 11641 5418 350

18 11975 4151 350

19 514 1703 349

20 20 126 184

0 5 10 15 20 0

0.5

1 Interest of the Local Peer to the Remote Peers

Ratio a/b

0 5 10 15 20

0 0.5

1 Interest of the Remote Peers to the Local Peer

Torrent ID

Ratio c/d

Fig. 4.24 – Entropie vue du client instrumentalis´e

– le ratio ^c_b o`u c est le temps pendant lequel un pair distant est int´eress´e par le pair instrumentalis´e.

Dans le cas d’une entropie id´eale, les ratios pr´ec´edents doivent ˆetre ´egaux `a un pour tous les pairs dupeer set. La figure 4.24 repr´esente les deux ratios pour les 20 torrents que nous avons ´etudi´e. Pour chaque torrent, on repr´esente tous les ratios et on ajoute un marquage pour le 20 i`eme, 80 i`eme et 50 i`eme percentile de la distribution. On s’aper¸coit que pour la majorit´e des torrents, les 20 i`eme percentiles sont proches de un, ce qui veut dire que l’entropie est proche de l’id´eal.

Nous avons ´etudi´e plus avant les torrents pour lesquels l’entropie ´etait “mauvaise” (les valeurs des ratios ´etaient plus proches de 0 que de 1). Les d´etails de l’analyse sont dans [79]. La conclusion est que les torrents pour lesquels l’entropie n’est pas bonne sont dans un mode transitoire caract´eris´e par le fait que certaines pi`eces ne sont d´etenues que par une seuleseedqui forme alors un goulot d’´etranglement. Au contraire, les pi`eces qui poss`edent quelques copies sont r´epliqu´ees `a une vitesse bien sup´erieure. `A la limite, on se retrouve dans un cas o`u les pi`eces qui ont plus d’une copie sont en fait enti`erement r´epliqu´ees dans le torrent et les pairs n’ont plus d’int´erˆet que pour la seed et non les uns pour les autres.

Algorithme choke

L’algorithme choke a un comportement diff´erent en mode leecher et en mode seed. En mode leecher, un pair classe les d´ebits qu’il per¸coit des autres pairs et envoie des donn´ees aux 4 premiers, sans chercher `a ´equilibrer les quantit´es de donn´ees envoy´ees. D’aucuns ont critiqu´e cette politique et veulent d´efinir une politique o`u les quantit´es de donn´ees

´echang´ees seraient quasi identiques. Nous montrons dans [79] que cette d´efinition n’est pas adapt´ee au cas des ´echanges pair-`a -pair sur l’Internet o`u les d´ebits des pairs sont asym´etriques. De plus, nous montrons que l’algorithme actuel r´esulte en un bon ´equilibre des ´echanges de donn´ees. La figure 4.25 illustre ce point en montrant que les pairs qui re¸coivent le plus de notre pair instrumentalis´e sont ceux de qui on re¸coit le plus (avec des valeurs de quantit´e de donn´ees similaires).

En mode seed, il n’y a des ´echanges que dans un sens. Il faut donc un crit`ere diff´erent.

0 10 20 30 40 0

50 100

Down (MB)

Correlation Download, Upload, and Unchoke

0 10 20 30 40

0 50 100

Up (MB)

0 10 20 30 40

0 1 2 x 10

4

Ordered Peer ID

Time (s)

Fig.4.25 – Quantit´e de donn´ees re¸cues et envoy´ees (les pairs sont ordonn´es toujours dans le mˆeme ordre, celui li´e aux envois)

Deux versions de l’algorithme existent. Dans l’ancienne version⁸, une seed envoyait au 4 clients les plus rapides. Cela avait tendance `a favoriser les free-riders, i.e les pairs qui ne font que recevoir des donn´ees et ne veulent pas “jouer le jeu”. En effet, si un free-rider a un tr`es bon d´ebit de r´eception, il va monopoliser la seed au d´etriment du reste du torrent car il ne renvoie rien aux autres pairs du torrent. Nous avons montr´e dans nos exp´erimentations que la nouvelle version de l’algorithme en mode seed ´evitait cet ´ecueil en ´equilibrant le service offert aux diff´erents clients.

4.5 Conclusions et Perspectives

4.5.1 Conclusions

Nous avons pr´esent´e dans ce chapitre nos contributions dans le domaine de l’analyse de trafic. Nous nous sommes concentr´es sur deux probl`emes.

Le premier est l’analyse passive de connexions TCP. D´eterminer ce qui limite le d´ebit de connexions TCP captur´ees en diff´erents points de l’Internet est essentiel pour com-prendre o`u sont les limitations actuelles. Savoir si la limitation provient de l’application, des couches TCP de l’´emetteur ou du r´ecepteur ou de contraintes li´ees au r´eseau (conges-tion, goulot d’´etranglement) est essentiel pour les concepteurs d’applications reseaux et les op´erateurs d’acc`es ou de cœur. La comp´etition entre ces derniers exige en effet qu’ils aient une vision fine des performances du client. Ils ne peuvent plus seulement se fonder sur des indicateurs globaux, telle l’utilisation de leurs ´equipements physiques au sein de leur r´eseau. Notre premi`ere contribution est un algorithme qui permet de quantifier l’im-pact exact de l’application sur un flux TCP et ce, ind´ependamment de l’application. Cela signifie que notre m´ethode peut ˆetre appliqu´ee sur un flux applicatif sur lequel on a aucun

8Du client BitTorrent ´ecrit en python et maintenu par B. Cohen, l’inventeur de BT. Les autres clients, Azureus, BitComet, etc, ont tendance `a r´epliquer les modifications apport´ees par B.Cohen dans son client

a priori (application client/serveur ou pair-`a -pair, multim´edia ou non). Cette derni`ere propri´et´e est essentielle car de nouvelles applications apparaissent r´eguli`erement sur Inter-net. Il est aussi possible que le flux TCP soit encrypt´e. Notre seconde contribution est une nouvelle m´ethode fond´ee sur l’attribution de scores obtenus `a partir de diff´erentes s´eries temporelles issues de l’observation d’un flux TCP pour inf´erer la cause qui limite le d´ebit.

Cette m´ethode se montre plus pr´ecise et fiable que les m´ethodes pr´ec´edentes. Nous avons

´egalement fait des avanc´ees dans le domaine m´ethodologique en proposant d’utiliser une base de donn´ees pour effectuer des analyses sur des grandes traces (plusieurs Gigaoctets).

Il reste des efforts `a faire pour s´electionner des agr´egats de connexions sur des crit`eres de performance (par exemple, plus de 1% de taux de perte) et/ou g´eographiques (chemin en terme d’AS ´equivalent).

Le second probl`eme d’analyse de trafic auquel nous nous sommes int´eress´es est l’´etude d’un protocole pair-`a -pair particulier, BitTorrent. Cette application est responsable, selon la soci´et´e Sandvine, de la majorit´e des octets observ´es sur certains liens aux ´Etatsd-Unis et en Angleterre (http ://www.sandvine.com/news/article detail.asp ?art id=595). Notre premi`ere ´etude de BT [69] a consist´e `a observer globalement la capacit´e de passage `a l’´echelle de l’application au travers de l’´etude d’un gros torrent (180000 clients cumul´es) sur une p´eriode de 5 mois. Cette ´etude a effectivement montr´e que BT ´etait capable de tirer partie de l’ensemble des ressources (liens montant des pairs) pour offrir un d´ebit de r´eception ´elev´e par pair, mˆeme dans la p´eriode initiale o`u peu de pairs avaient une copie compl`ete du fichier.

Dans un second temps [79], nous avons ´etudi´e BT dans l’objectif de comprendre si ses algorithmes de choix des pairs et des pi`eces ne devraient pas former `a terme l’ossature de toute distribution de contenu dans l’Internet. Ce probl`eme est critique pour la mise

`

a jour d’applications ou d’antivirus `a large ´echelle dans l’Internet et aussi dans les entreprises o`u la gestion de parcs de machine Windows reste un souci majeur des services informatiques. Notre ´etude a abouti aux conclusions suivantes. Tout d’abord, l’algorithme de choix des pairs de BT permet d’´equilibrer au global les volumes re¸cus et transmis. De plus, l’algorithme de choix des pi`eces permet une bonne r´epartition des pi`eces par pair dans le torrent, garantissant ainsi que chaque pair trouve toujours un autre pair avec lequel il peut collaborer. Enfin, nous avons montr´e que les contre-performances que l’on peut parfois observer n’´etaient pas directement imputables aux algorithmes de BT.