Tomographie depuis plusieurs sources vers de multiples

Transcription

Université de la Méditerranée
Aix-Marseille II
Faculté des Sciences de Luminy
Marseille
163, Avenue de Luminy 13288
cedex 9
THÈSE DE DOCTORAT
en Informatique
Tomographie depuis plusieurs sources vers
de multiples destinations dans les réseaux
de grilles informatiques hautes
performances
présentée par :
Laurent Bobelin
en vue d'obtenir le grade de docteur de l'Université de la Méditerranée
soutenue le
12 juin 2008 devant le jury composé de :
Emmanuel Jeannot
Chargé de Recherche INRIA Grand Est, rapporteur
Ibrahima Sakho
Professeur à l'Université de Metz, rapporteur
Frédéric Desprez
Directeur de Recherche INRIA Rhône-Alpes, président du jury
Remi Morin
Professeur à l'Université de la Méditerranée, examinateur
Traian Muntean
Professeur à l'Université de la Méditerranée, directeur de thèse
François Touchard
Professeur à l'Université de la Méditerranée, co-directeur de thèse
N o attribué par la bibliothèque
Année 2008
N'importe quelle sardine peut arriver à avaler une baleine...
A condition, bien sûr, de savoir comment susamment écarter les mâchoires.
Dicton indonésien adapté aux poissons et mammifères de nos contrées.
Remerciements
Voici donc venu le temps des remerciements (ami lecteur encore thésard, sache que ce
moment vient après la soutenance, donc après la bataille nale et l'explosion de l'Etoile
Noire, et que c'est donc le temps de faire le bilan de ces (au moins) 3 années de ta vie).
Donc, je remercie en premier lieu Traian Muntean, mon directeur de thèse, pour la
liberté totale (voire absolue) qu'il m'a laissé tout au long de cette thèse. Merci pour cela,
Traian.
Un autre élément essentiel dans mes orientations et choix scientiques a été la présence
de la physique des particules, incarné par mon co-directeur de thèse, François Touchard.
Malgré son prol non-informaticien, son aide a été plus que précieuse. D'une part, pour
son aide sur toutes les questions logistiques liées à la validation des méthodes et techniques
décrites dans le document ci-après. D'autre part, pour avoir su clairement exprimer (avec
l'aide tout aussi précieuse d'Andreï Tsaregorotsev) les attentes de la part de sa communauté
vis-à-vis des résultats que devaient produire mes recherches. Leur constante exigeance de
performances et d'applicabilité de mes recherches ont été le l conducteur de ma thèse, et
en terme d'écheance, m'ont permis de structurer mon travail.
Je remercie de même les membres de mon jury :
Emmanuel Jeannot, pour avoir accepté d'être un des rapporteurs de ma thèse, malgré
l'austérité de celle-ci (oui, ami lecteur, autant te prévenir : ce document est quand
même sacrément aride, mais accroche-toi, les résultats qu'il contient sont quand
même intéressants),
Pour les mêmes raisons, merci à Ibrahima Sakho d'avoir sacrié un peu de son temps
pour relire le présent document, et par ces commentaires, d'avoir apporté au document nal la rigueur syntaxique mathématique qu'il eusse dû avoir dès le début,
Fréderic Desprez, pour m'avoir fait l'honneur d'être le président du jury lors de ma
soutenance, mais aussi (et surtout) pour m'avoir donné l'occasion de lui montrer
que j'étais capable de faire autre chose que citer Heidegger, Junger et consors, et de
m'interroger sur la signication de la recherche dans un document scientique,
Remi Morin, pour avoir accepté de faire partie de mon jury et d'avoir porté sur mes
travaux un regard neuf.
Merci aussi à deux personnes sans qui ont apporté scientiquement quelque chose à
cette thèse : Léon Mugwaneza et Easter Selvan Suviseshamuthu. Pour le premier (donc
toi, Léon) merci pour ton aide précieuse et ta relecture qui m'ont permis de comprendre
ce que dev(r)ait être la rédaction scientique. Pour le second (so, for you Easter), thank
you for your precious help about understanding, managing and implementing negentropy
approximation. Your experience in teaching spectral analysis has been really usefull to help
someone like me understanding and using tools like this one.
Merci aussi à deux personnes sans qui cette thèse n'aurait jamais pu être : François
Etienne, qui m'a accordé sa conance et a accepté que je fasse cette thèse dans le cadre
d'EGEE, ainsi que Marc Drabik, qui m'a aussi accordé sa conance et m'a permis de
rejoindre l'équipe grille de CSSI (oui ami lecteur, malgré son aspect recte, ma thèse n'a
pas été exempte de péripéties industrielles).
Merci encore à ma moman, pour ses relectures de ma thèse qui ont garanti une bonne
tenue orthographique et grammaticale au présent document (et de ne pas m'avoir renié
malgré les nombreuses fautes du document initial). Merci de même à mon popa pour ces
conseils précieux sur la façon de mieux présenter mon travail oralement.
Nous voici donc venu aux remerciements qui concernent plus ma vie personnelle que
les diérents résultats scientiques présents dans mon document.
Donc, encore une fois, merci popa, merci moman, et bien sûr aussi merci ma soeurette,
et le reste de ma famille : votre soutien m'a permis de continuer sur le chemin pleins
d'embûches qui m'a conduit à ma soutenance. Merci aussi (et bizarrement peut être même
plus), à ceux qui n'ont pas cru en moi : il m'ont donné l'énergie de leur prouver que j'étais
scientiquement capable.
Viennent les remerciements qui s'adressent aux gens dont les apports au quotidien
permettent de survivre dans ce monde de brute. On commencera donc par les collègues (de
bureau) et néanmoins amis qui m'ont aidé à ne pas prendre un café tout seul. Côté ESIL,
Victor, Olivier et Hervé ont été de dèles collègues de bureau (et même plus). De même,
le René et la Fif (qui devraient prendre soin du p'tit Audren plutôt que de lire le présent
document), ainsi que le Ben (toi, prend soin de Monica au lieu de lire ces lignes), ainsi que
tous les autres (Jeremy, merci pour tes cours de stats de première année :) ), ont été du
côté CPPM de précieux collègues de café. Big up enn, comme on dit chez les djeuns, aux
inclassables camarades de café Vince et Cristina :)
Merci aussi à Alaa et Zaid pour leur hospitalité, leur amitié et leur aide pour l'organisation du pot qui a suivi ma soutenance, dont je ne saurai jamais (j'en ai bien peur) leur
rendre la pareille. Merci aussi au (maintenant) Dr. Agung (oui avant c'était juste Agung,
ami lecteur) pour son amitié, ainsi que pour m'avoir appris le sens de "Iwak sepat ngemplok gapuro... Menawi wonten lepat, ojo ngemplok gapuro". Puisqu'on en est aux horizons
lointains, merci à vous tous : Victor (j'ai encore une copie de tes fameux dessins animés
russes qu'il faudrait que je regarde (sous Tranxene)), Agung, Alaa, Zaid, Josip, Salma,
Easter, Khoi, Vanh, Xiao Min, Bouchra et tous les autres, qui m'ont permis d'entrevoir
leur culture, leur façon d'aborder la vie, et par extension, d'appréhender n'importe quel
problème de manière bien plus universelle que d'un point de vue strictement hexagonal.
Le polyculturalisme, tout comme l'interdisciplinarité, ore une possibilité d'acquérir une
ouverture d'esprit formidable, ce que je conseille à tous. Merci encore à vous tous pour
votre simple existence, et d'y avoir laissé une place pour ma présence.
iii
On en vient enn au remerciements exotiques. Merci à Robert Smith, pour Mint car
(The Cure, Wild Mood Swings, ( ... ) ), à la brasserie Heineken (enn, c'est plutôt leurs
actionnaires qui devraient me remercier d'avoir fait une thèse), à Stan Marsh, Kenny
Mc Kormick, Kyle Broslowski et Eric Cartman, aux publicistes qui se sont chargés de la
campagne télévisuelle de l'emmental Coeur de Meule de Président(T M ) (oui, ami lecteur,
sans eux, comment aurait pu exister la méthode du noyau ?) ... la liste pourrait encore être
longue.
Merci aux amis que j'ai délaissé pendant trois années et qui me parlent encore ; merci
enn à tous ceux que j'ai pu oublier.
...
Et dire que je voulais faire court sur les remerciements.
iv
Table des matières
Table des matières
i
Table des gures
x
I Problématique et état de l'art
1
1. Introduction
1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
6
6
2. Du gain apporté par la connaissance des performances du réseau pour
les grilles de calcul
8
2.1 Les grilles de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Les systèmes distribués de type grille . . . . . . . . . . . . .
2.1.2 Les plates-formes de grilles institutionnelles . . . . . . . . .
2.1.2.1 les plates-formes de grille nationales . . . . . . . .
2.1.2.2 les plates-formes de grille internationales . . . . .
2.1.3 Les intergiciels de grilles dédiés aux grilles institutionnelles .
2.2 Le projet EGEE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Le File Transfer Service . . . . . . . . . . . . . . . . . . . .
2.3 Protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Quelques mots sur TCP . . . . . . . . . . . . . . . . . . . .
2.3.2 Améliorations de TCP . . . . . . . . . . . . . . . . . . . . .
2.3.2.1 Modication de la taille maximale de segment . .
2.3.2.2 TCP parallèle . . . . . . . . . . . . . . . . . . . .
2.3.2.3 Augmentation du facteur C . . . . . . . . . . . . .
2.3.2.4 Mise en oeuvre d'un RT T virtuel . . . . . . . . . .
2.3.2.5 Modication autour de loss . . . . . . . . . . . . .
2.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
12
12
13
14
16
16
18
20
20
22
22
22
24
26
26
27
27
i
Table des matières
2.4.2
2.4.3
Contexte d'exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Contexte logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3. Etat de l'art : découverte automatique de topologie des performances
d'un réseau
29
3.1 Reconstruction de topologies . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Problèmes inverses . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Vocabulaire et dénitions . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2.1 Sous-chemin commun maximum . . . . . . . . . . . . . . .
3.1.2.2 Métrique . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 Reconstruction de topologies étiquetées sur les noeuds . . . . . . . .
3.1.4.1 Identication des noeuds . . . . . . . . . . . . . . . . . . .
3.1.5 Reconstruction de topologies étiquetées sur les arcs . . . . . . . . . .
3.1.5.1 Reconstruction de topologies par disjonction de chemins . .
3.1.5.2 Reconstruction de topologies par conjonction de chemins .
3.1.5.3 Reconstruction de topologies par identication de sous-chemin
communs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5.4 Intégration temporelle des topologies . . . . . . . . . . . . .
3.1.6 Reconstruction de topologies non étiquetées . . . . . . . . . . . . . .
3.1.6.1 Reconstruction de topologies par interférences entre chemins
3.1.6.2 Reconstruction de topologies par disjonction de chemins . .
3.2 Découverte automatique des performances du réseau . . . . . . . . . . . . .
3.2.1 Techniques passives . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Techniques actives . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.1 Dispersion de paquets . . . . . . . . . . . . . . . . . . . . .
3.2.2.2 Techniques de trains de paquets . . . . . . . . . . . . . . .
3.2.2.3 Bulk Transfer Capacity . . . . . . . . . . . . . . . . . . . .
3.2.3 Techniques mixtes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Intégration temporelle des mesures . . . . . . . . . . . . . . . . . . .
3.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
29
31
32
32
33
34
34
36
36
37
38
38
39
39
40
41
41
42
42
44
44
45
45
46
46
47
II Tomographie réseau multiples sources, multiples destinations :
modélisation, reconstruction et récupération du jeu de données initial 48
4. Modélisation des performances par une topologie du réseau
49
ii
Table des matières
4.1 Hypothèses et pré-requis sur les réseaux . . . . . . . . . . . . . . . . . . . .
4.1.1 Propriétés des métriques . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1.1 Constance . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1.2 Monotonicité . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1.3 Monotonicité étendue . . . . . . . . . . . . . . . . . . . . .
4.1.1.4 Bornée . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1.5 Borne induite par un lien unique . . . . . . . . . . . . . . .
4.1.1.6 Séparabilité . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1.7 Séparabilité étendue . . . . . . . . . . . . . . . . . . . . . .
4.1.1.8 Symétrie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1.9 k-détectabilité . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Propriétés du routage et de la topologie réseau . . . . . . . . . . . .
4.1.2.1 Consistance, stabilité et unicité . . . . . . . . . . . . . . . .
4.1.2.2 Symétrie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Vue d'ensemble des modèles existants . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Topologie physique et logique . . . . . . . . . . . . . . . . . . . . . .
4.2.1.1 Topologie physique . . . . . . . . . . . . . . . . . . . . . . .
4.2.1.2 Topologie logique . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Topologies issues d'identication d'équipements le long de chemins .
4.2.3 Graphe d'interférence . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Topologie réseau induite par une métrique depuis une source vers
plusieurs destinations (MINT) . . . . . . . . . . . . . . . . . . . . . .
4.2.4.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4.3 Hypothèses de dénition . . . . . . . . . . . . . . . . . . .
4.2.5 Topologie par recoupement d'arborescences . . . . . . . . . . . . . .
4.2.5.1 Recoupement de MINT de même racine . . . . . . . . . . .
4.2.5.2 Recoupement de MINT de racines diérentes . . . . . . . .
4.2.5.3 Recoupement de MINT de racines diérentes dans le cas
symétrique . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Nouveaux modèles pour le cas multiples sources, multiples destinations . . .
4.3.1 Topologie réseau induite par une métrique depuis plusieurs sources
vers plusieurs destinations (MSMDMINT) . . . . . . . . . . . . . . .
4.3.1.1 Dénition par construction . . . . . . . . . . . . . . . . . .
4.3.1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Système partiellement ordonné induit par une métrique (MINP) . . .
49
50
50
50
50
51
51
52
53
53
54
55
55
56
56
57
57
57
58
58
58
59
60
60
61
61
61
61
62
63
63
64
64
66
66
iii
Table des matières
4.3.2.1 Dénition . . . . . . . . . . . . . .
4.3.2.2 Problématique . . . . . . . . . . .
4.3.2.3 k-MINP . . . . . . . . . . . . . . .
4.3.2.4 ∞-MINP . . . . . . . . . . . . . .
4.3.2.5 Hypothèses de dénition . . . . .
4.3.2.6 Relation avec les modèles existants
4.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Modèles existants . . . . . . . . . . . . . . .
4.4.2 Nouveaux modèles . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Algorithmes de reconstruction pour la tomographie réseau
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.1 Propriétés des mesures . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 k-mesure et k-test . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Temps d'exécution . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Exclusion mutuelle . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4 Relations topologiques et reconstruction . . . . . . . . . . . . .
5.2 Algorithmes pour les MINT . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Hypothèse de reconstruction . . . . . . . . . . . . . . . . . . . .
5.2.2 Reconstructions basés sur les pré-ordres . . . . . . . . . . . . .
5.2.2.1 Algorithme de reconstruction . . . . . . . . . . . . . .
5.2.2.2 Compléxité . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Reconstructions basées sur la vraisemblance . . . . . . . . . . .
5.2.3.2 Complexité . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Reconstruction par recoupement d'arborescences MINT pour le
symétrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4.1 Hypothèses de reconstruction . . . . . . . . . . . . . .
5.2.4.3 Complexité . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Algorithme pour les graphes d'interférence . . . . . . . . . . . . . . . .
5.3.1 Hypothèses de reconstruction . . . . . . . . . . . . . . . . . . .
5.3.2 Algorithme de reconstruction . . . . . . . . . . . . . . . . . . .
5.3.3 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3.1 Etapes de calcul . . . . . . . . . . . . . . . . . . . . .
5.3.3.2 Nombre de tests . . . . . . . . . . . . . . . . . . . . .
5.4 Algorithmes de reconstruction pour les MINP . . . . . . . . . . . . . .
5.4.1 Hypothèses de reconstruction . . . . . . . . . . . . . . . . . . .
5.4.2 Propriétés d'un MINP . . . . . . . . . . . . . . . . . . . . . . .
5.4.2.1 Couverture unique . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
cas
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
66
69
70
71
71
72
73
73
74
75
75
75
76
77
77
78
79
79
79
80
80
80
81
82
82
82
82
82
82
83
84
84
84
84
84
84
84
iv
Table des matières
5.4.2.2 Propriété de regroupement . . . . . . . . . . . . . . . . . . 85
5.4.2.3 Propriété de regroupement pour les métriques bornées . . . 85
5.4.3 Un algorithme de reconstruction pour les k-MINP pour des métriques
bornées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.4.3.1 Algorithme de reconstruction . . . . . . . . . . . . . . . . . 86
5.4.3.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4.3.3 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.4 Un algorithme de reconstruction pour les 1-MINP pour des métriques
bornées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.4.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.4.4.3 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.4.5 L'algorithme LTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.5.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.4.5.3 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.6 L'algorithme LTC parallèle . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.6.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4.6.3 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.7 Un algorithme de reconstruction pour les 1-MINP en relaxant l'hypothèse de borne induite par un lien unique . . . . . . . . . . . . . . 104
5.4.7.1 Relaxation de l'hypothèse de borne induite par un lien unique104
5.4.7.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.4.7.4 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.5 Vers des algorithmes hybrides pour la reconstruction de MINP . . . . . . . 107
5.5.1 Algorithmes hybrides utilisant des données complètes . . . . . . . . . 108
5.5.1.1 Données d'entrée . . . . . . . . . . . . . . . . . . . . . . . . 108
5.5.1.2 Quelques propriétés des 1-MINP bornés . . . . . . . . . . . 108
5.5.1.3 Algorithme de reconstruction de 1-MINP borné . . . . . . . 109
5.5.1.4 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.5.2 Algorithmes hybrides utilisant des données partielles . . . . . . . . . 111
5.5.2.1 Données d'entrée . . . . . . . . . . . . . . . . . . . . . . . . 111
5.5.2.2 Algorithmes hybrides pour la reconstruction de 1-MINP
pour une métrique bornée . . . . . . . . . . . . . . . . . . . 112
5.5.3 Vers une utilisation réelle des MINP . . . . . . . . . . . . . . . . . . 113
5.6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
v
Table des matières
6. Techniques de mesures pour les sous-chemins communs étroits
6.1 Techniques existantes . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Méthode par paires de paquets imbriquées . . . . . . .
6.1.1.1 Description . . . . . . . . . . . . . . . . . . .
6.1.1.2 Exploitation des valeurs obtenues . . . . . .
6.1.1.3 Performances . . . . . . . . . . . . . . . . . .
6.1.1.4 Limitations . . . . . . . . . . . . . . . . . . .
6.1.2 Méthode de la "cartouche" . . . . . . . . . . . . . . .
6.1.2.1 Description . . . . . . . . . . . . . . . . . . .
6.1.2.3 Performances . . . . . . . . . . . . . . . . . .
6.1.2.4 Limitations . . . . . . . . . . . . . . . . . . .
6.1.3 Méthode bayesienne . . . . . . . . . . . . . . . . . . .
6.1.3.1 Description . . . . . . . . . . . . . . . . . . .
6.1.3.3 Performances . . . . . . . . . . . . . . . . . .
6.1.3.4 Limitations . . . . . . . . . . . . . . . . . . .
6.1.4 Méthode par agglomération de tests unicasts . . . . .
6.1.4.1 Description . . . . . . . . . . . . . . . . . . .
6.1.4.3 Performances . . . . . . . . . . . . . . . . . .
6.1.4.4 Limitations . . . . . . . . . . . . . . . . . . .
6.1.5 Méthode par mesures d'interférences . . . . . . . . . .
6.1.5.1 Description . . . . . . . . . . . . . . . . . . .
6.1.5.3 Performances . . . . . . . . . . . . . . . . . .
6.1.5.4 Limitations . . . . . . . . . . . . . . . . . . .
6.1.6 Autres méthodes de mesures . . . . . . . . . . . . . .
6.2 Techniques adaptées à la reconstruction de MINP partiels . .
6.2.1 Principe général . . . . . . . . . . . . . . . . . . . . .
6.2.2 Technique utilisant le régime permanent de ux TCP .
6.2.2.1 Description . . . . . . . . . . . . . . . . . . .
6.2.2.3 Performances . . . . . . . . . . . . . . . . . .
6.2.2.4 Limitations . . . . . . . . . . . . . . . . . . .
6.2.3 Technique par envoi de bursts UDP périodiques . . . .
6.2.3.1 Description . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
117
117
117
118
118
119
119
119
120
121
121
121
122
122
123
123
123
123
123
124
124
124
125
125
126
126
126
126
127
127
127
127
128
128
128
128
129
132
vi
Table des matières
6.2.3.3 Performances . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4 Technique par saturation de lien par bursts UDP . . . . . . . . .
6.2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4.2 Exploitation des valeurs obtenues . . . . . . . . . . . .
6.2.4.3 Performances . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.5 Technique basée sur l'approximation de la néguentropie . . . . .
6.2.5.1 Indépendance et néguentropie . . . . . . . . . . . . . . .
6.2.5.2 Description . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.5.4 Performances . . . . . . . . . . . . . . . . . . . . . . . .
6.2.5.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.6 Technique parallèle basée sur l'approximation de la néguentropie
6.2.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.6.3 Performances . . . . . . . . . . . . . . . . . . . . . . . .
6.2.6.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III Implémentation et validation
132
132
133
133
133
133
134
134
134
141
145
146
146
147
147
147
147
147
148
149
7. M.I.N.T.C.a.r : un outil pour la découverte automatique de M.I.N.P. 150
7.1 Présentation générale de l'outil . . . . . . . .
7.1.1 Architecture . . . . . . . . . . . . . . .
7.1.1.1 Vue logique . . . . . . . . . .
7.1.1.2 Vue déploiement . . . . . . .
7.1.1.3 Vue implémentale . . . . . .
7.1.1.4 Cas d'utilisation . . . . . . .
7.1.1.5 Vue architecture . . . . . . .
7.1.1.6 Pré-requis pour l'installation
7.1.2 Technologies mises en oeuvre . . . . .
7.1.2.1 UDPMon . . . . . . . . . . .
7.1.2.2 Galicia . . . . . . . . . . . .
7.1.2.3 Autres . . . . . . . . . . . . .
7.1.2.4 Utilisation du format XML .
7.1.3 Quelques mots sur l'interface . . . . .
7.1.4 Limitations actuelles . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
150
150
151
151
153
153
154
155
156
156
156
156
157
157
157
vii
Table des matières
7.2 Mise en oeuvre des algorithmes et mesures développées
7.2.1 Mesures par envois de bursts périodiques . . . .
7.2.2 Mesures par envois de burts UDP saturants . .
7.2.3 Mesures basées sur la néguentropie . . . . . . .
7.2.3.1 3-mesure 1-test . . . . . . . . . . . . .
7.2.3.2 k-mesure parallèle . . . . . . . . . . .
7.2.4 Algorithmique . . . . . . . . . . . . . . . . . .
7.2.4.1 Mise en oeuvre . . . . . . . . . . . . .
7.2.4.2 Limitations . . . . . . . . . . . . . . .
7.3 Autres caractéristiques de l'outil . . . . . . . . . . . .
7.3.1 Tolérance aux pannes . . . . . . . . . . . . . .
7.3.2 Stockage des MINP . . . . . . . . . . . . . . . .
7.3.3 Evolutivité . . . . . . . . . . . . . . . . . . . .
7.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . .
8. Validation
8.1 Méthodologie de validation . . . . . . . . .
8.1.1 Validation des algorithmes . . . . . .
8.1.2 Validation des techniques de mesures
8.2 Outil de validation . . . . . . . . . . . . . .
8.2.1 Simulateurs . . . . . . . . . . . . . .
8.2.1.1 NS-2 . . . . . . . . . . . . .
8.2.1.2 SimGrid . . . . . . . . . . .
8.2.2 Plates-formes réelles . . . . . . . . .
8.3 Validation des algorithmes de reconstruction
8.3.1 Simulation de haut niveau . . . . . .
8.3.2 Tests sur plate-forme expérimentale
8.3.3 Tests réels . . . . . . . . . . . . . . .
8.4 Validation des méthodes de mesures . . . .
8.4.1 Simulation . . . . . . . . . . . . . . .
8.4.3 Tests réels . . . . . . . . . . . . . . .
8.4.4 Taux d'erreur . . . . . . . . . . . . .
8.5 Synthèse . . . . . . . . . . . . . . . . . . . .
9. Conclusion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
158
158
159
159
159
160
160
160
160
160
160
161
161
161
162
162
162
162
163
163
163
164
164
165
165
166
166
166
166
166
166
167
169
170
9.1 Apport des travaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
9.2 Axes de travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
9.2.1 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
viii
Table des matières
9.2.2
9.2.3
9.2.4
Algorithmique de reconstruction . . . . . . . . . . . . . . . . . . . . 171
Techniques de mesures . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
IV Annexes
173
Description d'une plate-forme
174
Description d'un MINP
176
Liste des options d'udpmon modié
180
Glossaire
182
Acronymes
188
Notations
191
Bibliographie
197
ix
Table des figures
1.1 Vue de la topologie physique de GEANT et de l'organisation en hiérarchie
de Tier d'EGEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organisation par hiérarchie de tier plongée dans la topologie physique . . .
2.1 Les principaux services de gLite . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 vue d'ensemble du File Transfer Service . . . . . . . . . . . . . . . . . . . .
3.1 Reconstruction par identication de noeuds . . . . . . . . . . . . . . . . . .
3.2 Reconstruction par disjonction . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Reconstruction par conjonction . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Exemple de topologie simple . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Liens entre la topologie réelle du réseau et la topologie physique . . . . . . .
4.3 Liens entre les topologies physiques et logiques . . . . . . . . . . . . . . . .
4.4 Eet du paramètre de sensibilité sur un MINT . . . . . . . . . . . . . . . .
4.5 Non transitivité de l'identication . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Liens entre une topologie logique et une topologie induite par une métrique
4.7 Quelques topologies simples et leurs représentations en tant que Metric Induced Network Poset (MINP) . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Exemples d'intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Déroulement de l'algorithme sur un exemple simple . . . . . . . . . . . . . .
5.3 Déroulement de l'algorithme pour les 1-MINP bornés . . . . . . . . . . . . .
5.4 Déroulement de l'algortime LTC . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Déroulement de l'agorithme LTCP . . . . . . . . . . . . . . . . . . . . . . .
5.6 Choix d'un représentant . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Mesure par injection de tests sandwich . . . . . . . . . . . . . . . . . . . . .
6.2 Mesure par la technique de la cartouche . . . . . . . . . . . . . . . . . . . .
6.3 Mesure par injection de stripes . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Collision de trains sur un goulot d'étranglement . . . . . . . . . . . . . . . .
6.5 Méthode du noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Dépendance des distributions . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7 Bursts injectés depuis une source . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Vue d'ensemble de l'outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Déploiement de l'outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Vue implémentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
17
19
35
37
37
55
57
58
60
62
65
68
83
91
95
99
103
113
118
120
124
129
132
140
145
151
152
153
x
TABLE DES FIGURES
7.4
7.5
8.1
8.2
8.3
8.4
Vue d'un cas d'utilisation . . . . . . . . . . . . . . . . .
Capture d'un écran de l'interface . . . . . . . . . . . . .
Vue d'ensemble de ns-2 . . . . . . . . . . . . . . . . . . .
Vue d'ensemble de simGrid . . . . . . . . . . . . . . . .
Déploiement réseau . . . . . . . . . . . . . . . . . . . . .
Néguentropie pour les diérents sous-chemins communs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
155
158
164
165
167
168
xi
Première partie
PROBLÉMATIQUE ET ÉTAT DE L'ART
Introduction
1.1
Problématique
Les liens entre les performances d'une application, ses communications et le placement
de ses données sont connus depuis de nombreuses années dans le domaine des systèmes
distribués. L'émergence des architectures distribuées de type grille ou grappe de grappes
remet en question la modélisation, la gestion et les paradigmes de programmation d'une
application. En eet, l'application est confrontée à une topologie réseau qui n'est plus homogène, contrairement aux environnements de type cluster ou autres machines parallèles ;
de plus, les ressources réseau disponibles étant partagées entre des acteurs provenant d'organisations diverses (locales ou appartenant à un groupe de travail de la grille), leur taux
d'utilisation devient plus dicilement prédictible, rendant plus complexe l'optimisation
des communications lors de l'exécution d'une application.
Au-delà du simple aspect architectural de la plate-forme, les caractéristiques mêmes
des middleware pour les grilles développés dièrent suivant les applications auxquelles elles
sont dédiées. Ainsi une grille ayant pour but d'orir des services interopérables entre des
types d'acteurs et d'applications très diérents ore une architecture logicielle basée sur
des services web étendus, ou grid services [1], [71]. Si le surcoût (CPU (CPU) et transfert)
dû à l'utilisation des technologies utilisées par les web services (SOAP (SOAP) et XML
(XML)) peut être maîtrisé, il reste tout de même non négligeable . De ce fait, les grilles
dédiées au calcul scientique ont tendance à passer par des interfaces propriétaires, pour
permettre une optimisation des performances. De même, une grille dédiée au calcul intensif
pour des applications de type branch-and-bound [42] orira des services pauvres en terme
de stockage de données et malgré un réseau orant une faible bande passante, obtiendra
de bonnes performances d'accélération pour ces applications.
La nature hétéroclite des architectures logicielles et matérielles masquées derrière le
terme de grille incite naturellement à établir une taxonomie des diérents types de grilles
découlant des applications qui ont conduit à leur élaboration telle que celle donnée dans
[91]. Pour n'en citer que quelques types, les grilles peuvent être vues comme un ensemble
de services répartis interopérables, une mutualisation de ressources (disques, CPU), ou
une plate-forme d'exécution de Challenges calculatoires, fortement dépendants ou non de
2
Introduction
données initiales. Ces applications génèrent par leurs exécutions des ux d'informations
très divers, allant de simples messages pour les algorithmes de type branch-and-bound, à
des ux importants pour les applications multimédia multicast, entraînant ou non la mise
en place de backbone performants.
Dans le cadre du projet EGEE (EGEE), les applications (expériences) sont caractérisées
par des ux d'informations importants, car elles traitent des ux produits qui peuvent être
de l'ordre du Gbit/s. Ces ux sont de plus non-uniformément répartis dans le temps (les
déplacements de données se font à l'initialisation de l'application) et dans l'espace (toutes
les données proviennent du même lieu, le LHC (LHC)). Ce type d'application implique
aussi le stockage, la répartition et la réplication des données étudiées. Les forts besoins en
débit d'un tel type d'application a donné lieu à la mise en place d'une structure physique
particulière. Celle-ci est articulée autour d'un backbone réseau capable de répondre à des
besoins en bande passante importants pour réduire les temps de transfert, reliant des
sites qui peuvent être plus faiblement couplés. De plus, le volume de calcul nécessaire à
l'analyse des ux de données produits permet de considérer que les ressources de calcul
seront saturées par l'exécution des applications.
Les grilles actuelles ont souvent pour but d'interconnecter des milliers de ressources de
calcul et de stockage de données réparties mondialement, en utilisant soit l'Internet, soit
des réseaux très haut débit tel que GEANT [15] en Europe ou celui utilisé par Teragrid
[37] aux USA. Ces réseaux interconnectent par des liens haut débit diérents centres de
calcul répartis géographiquement. Ces centres restent eux-mêmes connectés à leurs réseaux
nationaux. Un exemple de topologie de ce type de réseau est donné à la gure 1.1.
Tier−0
UK
Suede
Tier−1
Pologne
Tier−1
Rep. Tcheque
Hollande
Tier−2
Tier−1
Belgique
Allemagne2
Tier−1
Allemagne1
Tier−2
Autriche
France
Tier−2
Tier−2
Suisse
Tier−2
Italie
Tier−2
Tier−2
Tier−2
Tier−2
Figure 1.1. Vue de la topologie physique de GEANT et de l'organisation en hiérarchie de
Tier d'EGEE
Sur de telles plates-formes, les applications déploient habituellement une architecture
logicielle dédiée aux transferts de données massifs. Par exemple le projet EGEE [12] utilise une notion de hiérarchie d'hôtes appelés tiers illustrée par la gure 1.1. Dans cette
3
Introduction
hiérarchie, chaque tier est un centre de stockage de données situé physiquement dans les
locaux d'une institution ou d'un laboratoire membre du projet. Le niveau de chaque tier
correspond à l'importance de la contribution à la plate-forme fournie par le membre du
projet auquel il appartient. Le tier-0 communique avec l'ensemble des tier-1, chaque tier-1
communique avec les autres tier-1 mais aussi avec un sous-ensemble de tier-2, chaque tier-2
communique avec certains tier-2 et un sous-ensemble de tier-3. Le tier-0 est situé au plus
proche du siège de l'expérience (dans le cadre d'EGEE, au CERN). Les tier-1 sont des
centres nationaux ou institutionnels, les tier-2 sont situés dans des centres de calculs importants, les tier-3 dans des laboratoires. Dans une organisation de ce type, le paradigme
de communication n'est plus un simple client/serveur : chaque hôte est soit un serveur, soit
un client, soit les deux, et chaque serveur communique seulement avec un sous-ensemble
des clients.
Cette hiérarchie logique est plongée dans le réseau physique existant, les communications entre tiers circulant suivant le routage en vigueur sur celui-ci, tel qu'illustré par la
gure 1.2. Comme on peut l'observer, ce plongement peut faire apparaître que des liens
logiquement disjoints utilisent le même lien physique, comme par exemple le lien entre les
tier-1 italiens et francais, et celui entre le tier-0 et le tier français. Dans la hiérarchie logique,
ces deux liens sont disjoints, alors qu'ils possèdent un sous-chemin physique commun.
UK
SE
PL
CZ
Tier−2
NL
BE
DE2
DE1
Tier−1
AT
FR
CH
Tier−2
IT
Tier−0
Tier−2
Tier−2
Tier−2
Tier−2
Tier−2
Tier−2
Tier−2
Figure 1.2. Organisation par hiérarchie de tier plongée dans la topologie physique
Dans le but d'optimiser les communications entre ces diérents tiers, il est donc nécessaire de connaître à la fois la capacité des liens physiques les reliant, mais aussi la topologie
4
Introduction
sous-jacente et le routage appliqué sur celle-ci, sous peine de voir deux transferts sensés être
indépendants entrer de manière imprévue en compétition pour la même ressource physique
réseau. Ce problème est loin d'être spécique à EGEE, et se pose dans de nombreux types
d'applications. Or, le plus souvent, on ne connait même pas la topologie physique réelle.
De plus, les outils de monitoring actuels, tels que NWS [120] ou WREN [99] ne proposent
qu'une modélisation basique de ces interférences : soit les ux appartiennent à une même
clique et donc possèdent un lien commun, soit ils font partie de cliques séparées et sont
considérés comme indépendants. Ces outils ne reposent donc pas sur une modélisation de
la topologie susamment ne pour estimer les interactions entre les ux telles que celles
induites par la topologie et le routage de la gure 1.2.
Dans les réseaux traditionnels, il est souvent possible de découvrir la topologie en
utilisant des outils de type traceroute [97], c'est-à-dire en utilisant des informations ne
pouvant être obtenues que si les administrateurs du réseau permettent de les obtenir.
Comme une grille fédère des ressources appartenant à diérentes organisations respectant
diverses politiques de sécurité, l'utilisation de tels outils est la plupart du temps impossible.
Si l'on désire déduire la topologie du réseau sous-jacent et/ou la capacité des liens qui le
composent, il est donc nécessaire d'utiliser des méthodes reposant sur des mesures de
niveau applicatif eectuées de bout en bout. De telles méthodes sont dénommées dans la
littérature tomographie réseau [121].
Depuis une décennie, la tomographie réseau a été largement étudiée. Diérentes approches ont été proposées, en fonction des besoins exprimés, mais aussi des propriétés
intrinsèques du réseau sur lequel ces méthodes sont appliquées (voir [58] pour un état
de l'art). Un domaine largement étudié est celui de la reconstruction d'une topologie logique basée sur les valeurs d'une métrique. Cette métrique peut être la bande passante
atteignable en régime permanent par des ux TCP (TCP), le délai, etc. Dans une telle
topologie, qui est un graphe orienté, chaque arc est étiqueté suivant la valeur de la métrique
correspondant à l'ensemble d'objets physiques qu'il représente. Dans le cas client/serveur,
la topologie logique est forcément une arborescence dont la racine est le serveur, les feuilles
les clients et les noeuds internes les points de disjonction des chemins reliants le serveur
aux clients.
Il a été démontré dans [49] qu'une telle topologie logique ne peut être construite pour
une métrique donnée que si celle-ci possède des propriétés particulières. Or, ce travail ne
prend en compte que les topologies logiques qui sont obtenues dans le cas client/serveur.
Les auteurs introduisent les propriétés de monotonicité et de séparabilité et dénissent les
relations entre topologie physique, topologie logique et la topologie induite par les valeurs
d'une métrique. Ces propriétés, si elles sont respectées, permettent à la fois de reconstruire l'arborescence reliant une source et plusieurs destinations, mais aussi d'étiqueter les
arcs reliant les noeuds de l'arborescence avec des valeurs de la métrique correspondant à
5
Introduction
l'ensemble des équipements physiques qu'ils représentent.
Or, comme mentionné dans [52], une représentation arborescente ne peut caractériser
un réseau quand plusieurs sources et plusieurs destinations sont impliquées. Pour traiter
ce nouveau problème de tomographie réseau depuis plusieurs sources vers plusieurs destinations, il est donc nécessaire de développer de nouvelles représentations des performances
du réseau, ainsi que des méthodes ad hoc pour détecter les relations entre les chemins
considérés, et reconstruire une représentation complète des performances du réseau. La
présente thèse traite de ce sujet.
1.2
Contributions
Les principales contributions de cette thèse sont :
1. Un nouveau modèle pour représenter les performances du réseau.
2. De nouveaux algorithmes de reconstruction permettant de reconstruire ecacement
une telle représentation.
3. De nouvelles méthodes de découverte de topologie permettant de récupérer un jeu
de données initial permettant de reconstruire une représentation du réseau.
4. Un prototype d'outil permettant de valider ces nouvelles méthodes dans le cadre
d'expérimentations réelles.
1.3
Plan de la thèse
La première partie, "Problématique et état de l'art" regroupe l'introduction et les
chapitres suivants dédié à l'état de l'art et la dénition précise de la problématique.
Après cette introduction, je donne une vue d'ensemble des types de plates-formes de
grille, et identie les types de grille qui peuvent tirer un certain bénéce des travaux
eectués dans le cadre de ma thèse dans le chapitre 2.
Le chapitre 3 donne une vue d'ensemble des techniques existantes de découverte automatique des performances réseau, permettant de situer les travaux de cette thèse au sein
du paysage des travaux existants.
Les 3 chapitres suivants, regroupés dans la partie "Tomographie réseau multiples sources,
multiples destinations : modélisation, reconstruction et récupération du jeu de données initial" contiennent les apports essentiels de cette thèse et la résolution de la problématique.
6
Introduction
Le chapitre 4 traite du problème de la modélisation des performances du réseau, en
décrivant de manière approfondie les modèles existants et en introduisant les nouveaux
modèles développés dans le cadre de cette thèse.
Le chapitre 5 traite du problème de la reconstruction de représentation de réseau dans
les modèles dénis dans le chapitre 4 à partir d'un jeu de données initial.
Le chapitre 6 décrit de manière plus approfondie des méthodes de récupération d'un jeu
de données initial à partir de mesures de bout en bout du réseau, et introduit les méthodes
spéciques au modèle introduit au chapitre 4 que j'ai développé dans le cadre de cette
thèse.
La partie "Implémentation et validation" est dédiée aux expérimentations réelles, l'implémentation de l'outil permettant de réaliser ces expériences, et à la validation des diérents algorithmes et techniques développés dans le cadre de cette thèse.
Le chapitre 7 décrit l'outil développé dans le cadre de cette thèse, et met en lumière
les dicultés techniques liées au passage du monde de la théorie au monde réel pour les
méthodes et algorithmes développés dans les chapitres précédents.
Le chapitre 8 rend compte de mes diverses expérimentations tant sur une plate-forme
réelle que par simulation dans le but de valider les méthodes et algorithmes développés
pendant ma thèse.
Le chapitre 9 fait une synthèse des travaux eectués et présente un ensemble d'axes de
recherches restant à explorer dans le cadre de la tomographie multiples sources, multiples
destinations.
Enn, en annexe, gurent les diérents formats de chier XML permettant d'utiliser
l'outil ainsi que les nouvelles options ajoutées à l'outil open source udpmon. L'outil étant
développé sous licence EGEE (licence libre et open source ), la description de l'outil ainsi
que des diérents formats d'entrée/sortie permet à l'utilisateur désirant installer, utiliser
et modier cet outil de le faire.
7
Du gain apporté par la connaissance des
performances du réseau pour les grilles de
calcul
Avoir une connaissance des performances d'un réseau n'est pas toujours utile. En eet,
tirer un bénéce en terme de performances n'est possible que dans certaines conditions,
comme par exemple si il existe une dépendance des applications cibles aux données ou
encore si l'utilisation de protocoles rend possible des optimisations liées aux performances.
Une grille constituée de ressources très volatiles ne communiquant que très peu entre elles,
et n'impliquant que de faibles volumes de communications, utilisant des protocoles autorégulants comme TCP est un exemple de grille dont on peut dire intuitivement qu'elle ne
pourra tirer parti d'informations sur les performances du réseau.
A contrario, une grille impliquant des ressources peu volatiles regroupées en un "petit"
nombre de sites, reliées entre elles par un réseau assez stable, impliquant un grand nombre
de transferts de données massifs et qui utilise un ensemble de protocoles haute performance
qui sont paramétrables pour obtenir des performances optimales en fonction des capacités
du réseau sous-jacent est un exemple de grille pouvant tirer pleinement parti d'informations
sur les performances et la topologie du réseau.
Beaucoup de systèmes aux caractéristiques très hétérogènes sont souvent regroupés
derrière le terme de grille. Il convient donc, en préambule de cette thèse, de dénir les types
de grilles qui peuvent retirer un bénéce de l'extraction préliminaire de connaissances sur
les performances du réseau.
Dans ce chapitre, je situe donc plus précisément le domaine cible pour lequel cette
thèse a été réalisée. Il s'agit des grilles de calcul et plus spéciquement des grilles de calcul
institutionnelles. Nous donnons ici les caractéristiques principales des plates-formes cibles
pour lesquelles les travaux de cette thèse sont pertinents et de l'environnement logiciel dans
lequel s'insère notre travail. Notons que si l'outil développé in ne dans le cadre de cette
thèse est orienté vers le domaine circonscrit ci-après, l'utilisation des méthodes et outils
développés peut ne pas se limiter à celui-ci.
8
Du gain apporté par la connaissance des performances du réseau pour les grilles de calcul
2.1
Les grilles de calcul
La première apparition du terme de grille (grid ) date de l'article de Ian Foster [72].
Le terme de grid est né de l'analogie avec la "grille de distribution de la puissance électrique" constituée du réseau électrique lui-même (câbles et équipements divers dédiés au
transport), de générateurs de tensions ainsi que de consommateurs naux. Dans une telle
grille la puissance est fournie de manière opaque à l'utilisateur, qui n'est plus capable de
discerner la provenance de l'énergie utilisée. L'analogie appliquée au calcul distribué est
assez intuitive : on cherche à fournir de manière dynamique et instantanée une puissance
dont la provenance n'est pas masquée mais sans incidence sur l'exécution de l'application
utilisatrice d'une telle plate-forme. Une telle démarche peut être considérée comme l'inverse (ou le complément) de celle de la virtualisation de ressources : quand la grille cherche
à rendre sans incidence la provenance de l'instance d'une ressource possédant certaines caractéristiques données, la virtualisation cherche à rendre sans incidence les caractéristiques
et particularités de l'instance de ressource considérée. Pour reprendre l'analogie électrique,
si une plate-forme de grille fournit une tension possédant des caractéristiques précises, la
virtualisation quant à elle joue le rôle d'adaptateur universel pour l'application/l'appareil
utilisant cette tension. Les grilles de calcul sont donc formées de 2 entités physiques principales, de deux entités logicielles et de trois acteurs principaux. Les deux entités physiques
sont :
Les ressources qui sont mises à disposition. Ces ressources peuvent être des ressources
de calcul (processeurs), des ressources permettant le stockage plus ou moins volatile
de données (espace mémoire, espace disque, système de stockage hiérarchique allant
de l'espace disque à l'écriture/lecture sur bande, stockage pérenne), ou encore de
ressources de communication (allocation d'une connexion avec une qualité de service
garantie entre un ou plusieurs sites).
Le réseau d'interconnexion permettant de mutualiser ces ressources.
Les deux entités logicielles comprennent quant à elles :
Le système de grille permettant le courtage, le déploiement, l'exécution et la mise
à disposition des utilisateurs des résultats des applications s'exécutant sur la plateforme.
Les applications qui jouent le rôle de consommateurs de ressources, qui doivent être
développées en fonction des paradigmes de programmation et outils mis à disposition
par le système de grille.
Enn, les 3 acteurs principaux sont :
Les fournisseurs de ressources mettant à disposition les diérentes ressources disponibles pour les consommateurs.
Les consommateurs de ces ressources, c'est-à-dire les applications.
9
L'opérateur de la grille, chargé de la maintenance du système de grille.
A l'ombre de l'analogie originelle une forêt de concepts, de paradigmes et d'outils diérents
est apparue au cours des dernières années. La section suivante eectue un passage en revue
qui ne se veut (et ne peut) pas être exhaustif mais tente d'être représentatif des principales
branches de l'arbre généalogique des systèmes de type grille. L'élagage de ces ramications
nous permettra de dégager un cadre précis dans lequel ont été développés les travaux
présentés dans cette thèse.
2.1.1 Les systèmes distribués de type grille
En premier lieu il convient de restreindre le périmètre sur lequel porte cette thèse. De
l'analogie précédemment citée, nous pouvons essayer de réduire à leur plus petit dénominateur commun les divers types de grille :
Les ressources de calcul sont un élément sans lesquel un système distribué ne peut
plus être considéré comme un système de type grille. En leur absence, on est face à
un système de stockage de données, comme par exemple tapestry [48], AlienFS [105],
Gnutella [108].
La distribution sur un réseau (possiblement) hétérogène des ressources mises à disposition qui diérencie un système de grille d'une plate-forme de type cluster où le
réseau est homogène.
Le courtier de ressources, permettant d'allouer des ressources aux utilisateurs, est caractéristique d'une grille, car c'est lui qui permet de rendre transparent pour l'utilisateur la localisation des ressources allouées, diérencie une grille d'un environnement
dédié à une application donnée, ou une plate-forme physique dédiée à une utilisation
"manuelle".
La mutualisation de ressources provenant d'organisations diverses, qui permet de
diérencier une grille d'une plate-forme de calcul distribuée hétérogène telle qu'un
système distribué de calcul constitué en volant des cycles provenant de postes de
travail au sein d'un même organisme.
Le référentiel commun de sécurité nécessaire pour la mutualisation de ressources, qui
s'oppose à la classique centralisation unilatérale de la sécurité, rendue possible dans le
cas d'un Application Service Provider (ASP (ASP)) par exemple, par l'appartenance
des ressources à un seul organisme.
Ce dénominateur commun en apparence plus précis laisse bien des degrés de liberté permettant de regrouper sous le terme de grille bien des systèmes distribués aux fonctionnalités
très diérentes. Les principaux exemples de ces degrés de liberté sont :
La durée de vie des ressources qui peut fortement varier en fonction de la manière
dont sont rendues disponibles celles-ci à la grille (vol de cycle, ressources dédiées à la
grille, ressources partagées entre les utilisateurs locaux de celles-ci et les utilisateurs
10
de la grille).
Le paradigme de programmation des applications qui dépend fortement de la virtualisation des ressources (mise à disposition de machines virtuelles telles que les JVM
de Java ou mise à disposition de ressources caractérisées par leur système d'exploitation et les outils et bibliothèques disponibles localement) mais aussi le paradigme
de communication utilisé (Message-Passing Interface à la MPICH [86] ou Madeleine
[46], Remote Method Invocation, appels à des Grid Services ...).
Le degré de virtualisation des ressources elle-mêmes.
Le système d'information dont dispose le courtier de ressources, et donc l'utilisateur
nal, pour caractériser ses besoins et décrire les ressources qu'il désire utiliser.
La sécurisation de l'exécution par le blocage des accès (ou non) aux ressources utilisées par une application pour les autres utilisateurs.
La sécurisation des communications.
La gestion des données pérennes sur la grille qui peut être absente ou comprendre
des fonctionnalités telles que la gestion de répliquats des données, la possibilité de
migrer les données vers des sites géographiques précis, le placement des exécutions
des travaux de manière à ce que ces exécutions soient proches des sites de stockages
des données utilisées, etc.
Les fonctionnalités de l'ordonnanceur qui peuvent beaucoup varier, et inclure réservation, exécutions simultanées sur un ensemble d'hôtes, etc...
Les fonctionnalités de niveau supérieur pour la gestion des applications, telles que
la mise à disposition d'un système de workow [20], des outils de visualisation en
temps réel des résultats obtenus, etc.
Le terme de grille désigne donc un ensemble hétéroclite de systèmes logiciels. Le travail
présenté ici porte sur la découverte de la topologie d'un réseau et des capacités qui lui sont
propres dans une grille institutionnelle ou grille haute performance. De telles grilles sont
le plus souvent caractérisables autant par leurs plates-formes que par les intergiciels qui
permettent de mettre à disposition leurs ressources.
Ces grilles sont formées par l'apport d'organismes ou d'institutions de ressources de
stockage et de calcul en nombre important, souvent localisées dans des centres de calcul.
Les ressources de calcul sont le plus souvent des noeuds de clusters ou des clusters entiers.
Le type de ressource de stockage de données peut varier, allant de la mise à disposition
de mémoire vive au stockage à long terme en passant par l'espace disque. De telles grilles
présentent souvent des ressources dont la durée de vie est longue et dont la disponibilité
est able. Ces ressources sont nombreuses (de l'ordre de la centaine, ou du millier) et sont
regroupées géographiquement en sites (de l'ordre de la dizaine à la centaine). Les sites sont
réliés entre eux par des réseaux ables et stables, dont le coeur est plus souvent un réseau
high bandwidth-delay, ou encore l'internet. Les caractéristiques de telles plates-formes de
11
grille sont donc :
1. Une volatilité des ressources faible.
2. Un dimensionnement des plates-formes important en terme de ressources.
3. Un réseau reliant les éléments de ces plates-formes comportant un coeur able et
haut débit.
La section 2.1.2 donne une liste (non exhaustive) de plates-formes de type grille institutionnelle, pour donner une idée du dimensionnement de celles-ci.
2.1.2 Les plates-formes de grilles institutionnelles
Les projets dédiés aux grilles sont souvent créés dans le but de former une plate-forme
de grande dimension pour l'exécution d'applications nécessitant des calculs intensifs. Les
grilles instutionnelles sont des grilles constituées par la mutualisation de ressources provenant de diérents organismes, souvent dédiés à des types d'applications ou des communautés d'utilisateurs ayant un certain nombre de besoins communs. Nous donnons ici quelques
exemples représentatifs des dimensionnements de ces plates-formes. Notons que la plupart
de ces projets n'ont pas uniquement pour but de fournir une plate-forme, mais aussi un
intergiciel pour gérer cette plate-forme. L'aspect logiciel est traité en section 2.1.3.
2.1.2.1 les plates-formes de grille nationales
e-Toile [116] Le projet RNTL (Réseau National des Technologies Logicielles) e-Toile est
historiquement le premier projet national français de grille de calcul (2001-2004). Le but
de ce projet était de mettre à disposition des chercheurs une plate-forme expérimentale.
Les applications lancées sur cette plate-forme allaient de la recherche protéïnique à la simulation de fusion de réacteur nucléaire. La plate-forme, hétérogène, comprenait 7 sites
géographiques, 10 noeuds (grappes de serveurs), 200 processeurs avec des systèmes d'exploitation hétérogènes eux aussi. L'interconnexion entre les noeuds était rendue possible
grâce au réseau très haut débit VTHD [39] de France Telecom qui possédait un coeur à 10
Gbit/s et permettait des accès à 1 ou 2 Gbit/s sur chaque site.
Grid'5000 [29] est un projet suivant chronologiquement e-Toile. Son but est lui aussi de
fournir une plate-forme expérimentale de grille, mais de plus grande capacité (en terme
de ressources CPU) que le projet e-Toile. Le projet avait pour objectif initial de rendre
disponible 5000 processeurs, au lieu des 200 d'e-Toile. La plate-forme comprend 9 sites
géographiques (soit 2 de plus qu'e-Toile), chacun comprenant un ou plusieurs clusters.
L'interconnexion entre les sites est réalisée via le réseau Renater ([31]). Ce réseau permet
un accès au site via des liens de capacité allant de 1 à 10 Gbit/s.
12
Das-2 et Das-3 [8] sont des projets néerlandais. L'originalité de Das-2 était qu'il s'agis-
sait en fait d'une seule machine, créée par IBM, comprenant 200 processeurs répartis sur 5
sites géographiques. Les clusters étaient localement réliés entre eux par une interface Myrinet, l'interconnexion inter-site étant réalisée via Surfnet ([36]) l'équivalent néerlandais
du réseau Renater. Ce dernier réseau permet une connectivité inter-site ayant un débit
théorique variant de 1 à 10 Gbit/s. Das-3 reprend les mêmes sites que Das-2, pour cette
fois mettre à disposition plus de 400 processeurs interconnectés par un nouveau réseau,
Starplane ([33]), qui permet de créer des réseaux virtuels privés pour les applications de
type grille.
INFN Grid [19] est la plate-forme italienne de grille, appendice cisalpin du projet EGEE.
La plate-forme contient 30 sites reliés entre eux par GARR [14], l'équivalent italien de
Renater. Ce réseau contient majoritairement des liens à 2,4 Gbits/s, et d'autres liens possiblement redondants dont les capacités varient de 10 Gbit/s à seulement 34 MBits/s pour
les moins puissants. Les sites fournissent plus de 1700 CPUs (très) hétèrogènes.
NareGi Project [23] est le plus grand projet japonais de grille. Il compte 11 sites, pour
3000 CPUs et une puissance d'environ 17 teraops, dont 15 sont fournis par 2 centres de
calculs. Les sites sont reliés entre eux par le réseau Super SINET [35]. Son réseau dorsal à 10
Gbit/s interconnecte une quinzaine d'universités et centres de recherche qui s'y raccordent
par des liens individuels à 1 Gbit/s.
TeraGrid [37] est un des projets américains majeurs de plate-forme de grille. Il inter-
connecte 9 sites répartis géographiquement sur le continent américain par un réseau dédié
dont la bande passante varie entre 10 et 30 Gbits/s. Les 9 sites fournissent un accès à
quelques-uns des plus puissants clusters mondiaux (11 machines du top 500 font partie de
cette grille) pour une puissance de crête de plus de 250 teraops ainsi que d'importants
espaces de stockage de données (30 pétabytes). Il est intéressant de noter que même si les
ressources de calcul mises à disposition sont beaucoup plus importantes que celles mises
à disposition dans les exemples précédents, le nombre de sites inclus dans le projet reste
limité.
2.1.2.2 les plates-formes de grille internationales
La création de plates-formes internationales, constituées soit par le rapprochement de
plates-formes et de logiciels de grilles existantes (Glue [17], DataTag [2]), soit par la mise
à disposition de ressources ad hoc est devenu nécessaire par l'émergence d'applications
ayant des besoins en puissance de calcul sans précédent, comme par exemple le LHC [21]
et le traitement des données résultant des expériences menées à partir de 2008 sur cette
infrastructure. Une autre raison expliquant la mutualisation des ressources est la faible ca13
pacité d'investissement dans certaines régions du monde dûe aux dimensions économiques
modestes de certains états. On se retrouve donc confronté à deux types de projets internationaux, les uns agrégeant des ressources limitées distribuées à travers plusieurs pays, les
autres liant des ressources importantes dans une recherche de puissance maximale.
APGrid [5] est un projet de grille regroupant 19 pays du pacique et de l'Asie. Les 49
organismes regroupés dans ce projet mettent en commun plus de 1500 CPUs très dispersées
géographiquement. Les ressources sont reliées par le réseau APAN (Asia-Pacic Advanced
Network), dont la bande passante varie de quelques Mbits/s à 155 MBits/s.
EGEE II [11] est un des principaux projets de plate-forme de grille nancés par la com-
munauté européenne. Il est aussi certainement l'un des plus anciens et des plus pérennes,
puisque EGEE II est la suite du projet EGEE, lui-même la suite du projet DataGrid,
et que ces projets seront suivis par le projet EGEE III. La plate-forme actuelle regroupe
plus de 240 institutions réparties dans 45 pays mettant en commun plus de 36 000 CPUs
et des ressources de stockage de l'ordre de 5 Petabytes de disque, en plus de nombreuses
ressources de stockage sur bande. L'interconnexion est faite par l'intermédiaire du réseau
GEANT [15], dont les liens ont une capacité allant jusqu'à 10 GBits/s, ainsi que par les
réseaux nationaux auxquels sont reliées les diérentes ressources mises à disposition.
Ce rapide portrait de quelques plates-formes représentatives de celles utilisées de nos
jours permet de mieux entrevoir les topologies classiques de celles-ci. Si le paradigme de
grille laisse spéculer qu'un grand nombre de sites géographiques seront impliqués dans une
plate-forme, on s'apercoit qu'il s'agit, généralement, de plates-formes regroupant un petit
nombre (entre 5 et 150) de sites géographiques, regroupant eux-mêmes une petite quantité
de clusters reliés par un LAN ou un MAN, souvent haut débit, clusters présentants eux un
nombre important de ressources uniformes.
2.1.3 Les intergiciels de grilles dédiés aux grilles institutionnelles
Depuis l'apparition des grilles et plus précisement des grilles institutionnelles, dont
l'émergence a été rendue possible par le besoin de mutualiser des ressources de calcul pour
obtenir une puissance de calcul plus importante pour de plus brèves périodes, l'on a assisté à
une lente convergence des principales fonctionnalités proposées par les intergiciels de grilles
ainsi qu'à une spécication plus nette des composants nécessaires au bon fonctionnement
d'une telle plate-forme. La formalisation des échanges entre les diérents composants a
poussé à l'adoption massive de la norme WSRF (WSRF) (Web Service Resource Framework
[40]) en tant qu'interface pour les diérents composants du système, appelés dans ce cas
Grid Services. Un Grid Service n'est en fait qu'un composant logiciel classique auquel on
a adjoint une interface compatible WSRF, i.e. une interface de type web service à laquelle
14
on a ajouté des extensions concernant la durée de vie du composant. Ces changements
mineurs dans le fond, puisqu'il ne s'agit pour l'essentiel que de changements d'interface,
ont eu peu d'impact sur les principaux composants logiciels présents dans ce type de grille.
Ces principaux composants sont :
Le système d'organisation virtuelle et de sécurité. Le concept d'organisation virtuelle
(Virtual Organization ou VO (VO)) est utilisé par quasiment tous les projets de grille
institutionnelle. L'idée est de dénir des communautés d'utilisateurs partageant les
mêmes centres d'intérêt, les mêmes besoins et outils en dehors de leurs organisations
d'origine. Le système d'organisation virtuelle est la clef de voûte de la sécurité d'une
grille.
L'interface générique/standardisée de soumission locale de travaux pour une ressource de type batch/scheduler. Cette surcouche permet d'avoir une interface unique
de soumission quel que soit le type de batch scheduler coordonnant l'accès aux ressources de manière locale dans le cas d'un cluster (i.e. openPBS [25], SGE [34], BQS
[22] ...). Cette couche permet une certaine virtualisation de l'accès aux ressources.
Elle est fournie par le GRAM [18] de Globus, par SGE (dans une certaine mesure)
...
Le courtier de ressources. Il s'agit par exemple du Scheduler de Condor [55], du
Ressource Broker de DataGrid, du Match Maker Service de Dirac [10]. Son rôle est
de fournir un mécanisme d'ordonnancement des diérentes tâches soumises non plus
au niveau local mais au niveau de l'ensemble de la grille.
Le système d'information sur les ressources permettant au courtier de ressources
de localiser et connaître l'état et les caractéristiques des ressources mutualisées sur
la plate-forme. Cette fonction est assurée par le WebMDS de Globus [41], le SIC
d'e-Toile [116], le R-GMA d'EGEE [30]. Les systèmes de suivi de l'exécution des applications sur la plate-forme sont généralement jumelés aux systèmes d'informations
sur les ressources.
Le système d'indexation et de stockage des données. Ce système permet le stockage
des données, la gestion d'éventuels répliquats, la distribution de volumes de données
importants sur les diérents sites géographiques pour permettre un stockage able
et à long terme de ceux-ci.
Un système de déploiement d'applications. Ce système permet l'acheminement de
l'application à exécuter vers les diérentes ressources sur lesquelles celle-ci s'exécutera. Cette problématique en apparence fort simple, peut devenir relativement
complexe lorsque (par exemple) on a besoin de garantir la protection du code en
lui-même, lorsque le code est de taille importante ou encore lorsque le déploiement
peut se faire de manière dynamique (c'est-à-dire en utilisant de nouvelles ressources
pendant la durée de vie de l'application) [94].
15
Les outils de développement et d'exécution d'applications. Cette dernière catégorie
comprend les outils (souvent pré-déployés) permettant l'utilisation de paradigmes de
programmation comme la mémoire partagée, le parallélisme par passage de messages,
les outils de transfert haut débit sécurisé, en un mot l'ensemble des composants
auxquels fera appel une application, soit en tant que bibliothèque, soit en tant que
service prédéployé. Notons que la place du système d'indexation et de stockage de
données est ambigue, car il peut être accédé aussi bien par l'application en elle-même
que par les fournisseurs de ressources.
2.2
Le pro jet EGEE
Le projet EGEE (Enabling Grids for E-sciencE) [12] regroupe plus de 240 partenaires
scientiques et industriels dans 45 pays dans le but de fournir une infrastructure de grille
utilisable 24 heures sur 24 par la communauté scientique.
Fondé à l'origine autour des besoins de deux domaines applicatifs, la physique des
hautes énergies et les sciences de la vie, le projet a progressivement intégré de nouvelles
communautés scientiques telles que celle des géologues et celle des chimistes. Le dimensionnement de la plate-forme cible est en eet pensé pour des applications dont les calculs
sont intensifs et qui sont fortement dépendantes des données. Le projet EGEE met à
disposition simultanément une quantité de ressources très importante, rendant possible
l'exécution de certaines applications jugées trop coûteuses dans un contexte de calcul parallèle classique. La plate-forme EGEE met à disposition plus de 36.000 CPU utilisables
24h/24, plus 5 Pétabytes de stockage sur disque et des ressources de stockage pérennes. La
plate-forme de production héberge l'exécution simultanée de 30 000 travaux en moyenne.
2.2.1 Vue d'ensemble
gLite (gLite) est l'intergiciel de grille développé au sein du projet EGEE. C'est une
nouvelle mouture du logiciel produit dans le cadre du projet qui le précédait, DataGrid [9].
L'architecture orientée service de gLite a été largement inuencée par le projet LCG (projet
dédié au développement d'applications de type grille pour la physique des hautes énergies)
et surtout les spécications dénies par le groupe de travail Architectural Roadmap for
Distributed Analysis (ARDA) [4]). La gure 2.1 donne une vue d'ensemble de l'architecture
du projet, et regroupe les services en 5 groupes thématiques.
Le déploiement de chaque service peut se faire, au choix, par VO ou pour l'ensemble
du projet.
16
Services d’acces
Services d’acces
a la grille
API
Services d’information & de
monitoring
Service de securite
Autorisations
Information & Monitoring
Authentification
Job Monitoring
Auditing
Service de gestion des donnees
Metadata Catalog
File & replica Catalog
Accouting
Site proxy
Services de gestion des travaux
Job Provenance
Package Manager
Data Management
Computing Element
Storage Element
Workload Management
Figure 2.1. Les principaux services de gLite
Les services de sécurité comprennent les services d'authentication, d'autorisation
et d'audit et permettent l'identication des diérentes entités de la grille (utilisateurs et
ressources), ainsi que l'admission ou l'interdiction des accès aux services et aux ressources.
Enn, le tracage des diérentes actions exécutées permet éventuellement une analyse post
mortem des exécutions.
Les Services d'accès à la grille et l'API proposent un cadre commun par lequel
l'utilisateur peut accéder à la grille. Cela permet de connaître l'état des services de grille
disponibles pour l'utilisateur, ainsi que celui des éventuels travaux que l'utilisateur est en
train d'exécuter sur la plate-forme.
Les services d'information et de monitoring fournissent un mécanisme pour publier
et rendre disponible les informations et les utiliser à des ns de monitoring. Le service
d'information et de monitoring peut être directement utilisé pour publier les informations
concernant les ressources de la grille par exemple. Des services plus spéciques, comme le
Job Monitoring Service, sont basés sur ce service.
Les services de gestion des travaux regroupent des services dédiés à l'exécution ou
à la gestion des travaux. Le Computing Element est un service mettant à disposition une
ressource de calcul élémentaire, le service de courtage permet d'allouer des ressources en
vue d'exécuter une application sur la plate-forme, l'accounting permet le traçage et la
facturation des travaux eectués, le service de gestion des paquetages permet les liaisons
vers les bibliothèques nécessaires à l'exécution d'un travail.
17
Les services de gestion des données Ces services comprennent :
Les Storage Element (ressources de stockage).
Les services d'indexation (service de recherche des données et de gestion des données)
permettant la mise en place d'un espace de nom logique commun à toute la grille.
Les services de gestion de la localisation et du stockage des données, qui permettent
les migrations et le stockage des données.
Les services fournissent la possibilité de grouper les chiers dans des répertoires virtuels.
Plusieurs repliquats (copies gérées) d'un chier utilisateur peuvent être stockés dans des
emplacements physiques diérents. Le service d'ordonnancement des données fournit des
interfaces plus ou moins complexes pour que le placement des données dans l'environnement
distribué puisse être fait par l'utilisateur. De telles requêtes de transferts sont soumises au
service de transfert des chiers. Le File Transfer Service (FTS (FTS)) pour lequel l'outil
réalisé dans le cadre de cette thèse a été développé, est responsable de ces transferts.
2.2.2 Le File Transfer Service
EGEE dispose d'un ensemble d'outils pour la gestion des données. Un de ces outils
est le File Transfer Service (FTS [13]), développé dans le cadre du projet gLite [16]. Ce
service a pour fonction de permettre une copie able d'ensembles de chiers persistants
d'un site vers un autre, dans le cadre de la gestion de repliquats de chiers par exemple.
Il utilise un système de copie par un tiers (3rd party copy ) (reposant par exemple sur
gridftp [43]) pour y parvenir. Ce composant de l'intergiciel présente une interface web
service pour les diérents clients qui souhaitent l'utiliser. Ces derniers peuvent soumettre
grâce à cette interface leurs requêtes de copies de chiers d'un site vers un autre. Une fois la
requête soumise, elle est ajoutée à la base de données de requêtes de transferts (Transfer Job
Database) contenant toutes les requêtes de transferts. Régulièrement, les agents de transfert
vérient si de nouvelles requêtes ont été ajoutées dans cette base. Chaque agent de transfert
ordonnance ses transferts suivant les politiques de la Virtual Organization [72] auxquels les
transferts appartiennent, tout en essayant d'optimiser l'utilisation du réseau (voir gure 2.2
pour une vue d'ensemble de l'architecture du FTS). Le FTS possède une représentation
interne du réseau lui permettant d'optimiser l'ordonnancement des transferts. Elle est
constituée d'un ensemble de channels (canaux), qui sont des liens unidirectionnels entre
deux hôtes. Seuls ces canaux sont utilisés pour transférer des données. Ces canaux étant des
liens logiques, les interactions entre les ux les traversant du fait de la topologie physique
doivent être connus par le FTS pour optimiser les transferts simultanés sur les diérents
canaux.
La répartition géographique mondiale des diérents sites implique qu'un grand nombre
de canaux sont principalement constitués de liens réseau haute performance parcourant
une grande distance, ainsi que de goulots d'étranglement locaux limitant la bande pas18
User application
Transfer request
File
Transfer
Service
Store
request
Transfer
Agent
Ask for transfer
Retrieve
new
requests
Job
Transfer
Database
Data
Storage
System
performing transfer
Data
Storage
System
Figure 2.2. vue d'ensemble du File Transfer Service
sante atteignable. Les channels présentent donc généralement des Round Trip Time (temps
nécessaire pour qu'un paquet eectue un aller/retour entre la source du canal et sa destination) importants. En présence de ce type de liens, l'utilisation de protocole de TCP dont le
débit est ajusté à chaque aller/retour de paquet est assez inecace. On utilise donc le plus
souvent des versions modiées de tels protocoles, comme nous le verrons dans la section
2.3. Or, ces protocoles sont le plus souvent paramétrables pour obtenir des performances
optimales en fonction des capacités du réseau sous-jacent.
Pour ce type de service, il est donc nécessaire d'avoir une vision à la fois réaliste et
adéquate du réseau et de ses capacités si l'on veut optimiser les temps de transferts. Ce
besoin conduit tout naturellement au developpement de modèles représentant le réseau en
terme de performances et de partage de ces performances en cas d'exécutions simultanées
de transferts. L'absence de connaissance de la topologie dûe au déploiement des ressources
en divers lieux géographiques gérés par des organisations diérentes, ainsi que l'absence
de remontées de traces de l'utilisation des ressources réseau déployées pour des raisons de
sécurité, implique l'utilisation de techniques de découverte de performances et de topologie
se basant sur des observations de bout en bout. Ces techniques, appelées techniques de tomographie réseau, sont le sujet de la section 3 ainsi que le sujet de ma thèse. Ces techniques
19
permettent d'extraire des connaissances sur la topologie et les performances du réseau qui
sont exploitables quand on utilise des protocoles spéciques. Les protocoles utilisés sont le
sujet de la section suivante.
2.3
Protocoles
Comme nous l'avons évoqué précédemment, les outils de transferts de chiers dédiés
aux grilles tels que le FTS font le plus souvent appel à des protocoles spéciques tendant
à saturer les liens réseau, comme par exemple gridFTP [43] qui permet de choisir entre
plusieurs protocoles saturants. Si beaucoup de travaux présentent des protocoles basés sur
UDP (UDP), l'immense majorité de ces protocoles saturants utilisés en pratique sont basés
sur TCP, et non sur UDP : en eet, l'utilisation de protocoles saturants basés sur UDP
sur un réseau partagé peut rendre impossibles les communications d'autres applications
coexistantes sur la grille. Après avoir donné un rapide rappel de quelques caractéristiques
de TCP, nous donnons ici les principales modications eectuées sur TCP qui sont couramment utilisées dans les transferts de données massifs pour les grilles.
2.3.1 Quelques mots sur TCP
L'impact de la présence d'une latence importante est grand vis-à-vis d'un protocole de
type TCP. En eet, la bande passante cpBw d'un ux TCP en régime permanent circulant le
long du chemin p est liée à la latence (par l'intermédiaire du Round Trip Time, ou RoundTrip Time (RTT), qui peut être assimilé à deux fois la latence) par la formule classique
dénie dans [101], dite équation de Mathis :
cpBw ≤
M SS ∗ C
√
RT T ∗ loss
(2.1)
où C est un facteur constant dépendant de l'implémentation de TCP utilisée, M SS la
taille de segment maximale envoyée, qui est constante pour une exécution d'un envoi TCP,
et loss la probabilité de perte de paquets sur la liaison point-à-point considérée. Notons
que loss dépend aussi bien de la qualité du lien physique réseau considéré que des autres
ux circulant sur ce lien (les pertes de paquets peuvent survenir par exemple lors de la
saturation de buers sur les routeurs) ; de plus, la répartition de ces pertes de paquets
dépend aussi, dans sa distribution sur l'ensemble des ux circulant sur une liaison réseau
donnée, des politiques de gestion de queues des routeurs déployés le long de cette liaison.
Il est trivial de déduire de cette équation que l'augmentation du RT T va entraîner une
diminution de la bande passante maximale atteignable. De plus, de part le fonctionnement
20
AIMD (AIMD) (Additional Increase Multiplicative Descrease ) de TCP et son fonctionnement d'auto-régulation basé sur la réception des acknowledgment (ACK (ACK)) par
l'émetteur du ux, un ux de RTT plus long que les autres ux concurrents verra sa part
de bande passante diminuer en faveur d'autres ux au RTT plus court [75] (l'augmentation
de la taille de la fenêtre de congestion étant eectuée à la réception des ACK des paquets
déjà transmis). De ce fait, les diérentes solutions proposées visent à modier les valeurs
d'un des paramètres de l'équation 2.1, que ce soit le M SS (en fait cette variation est
faite sur le Maximum Transfer Unit, ouMTU (MTU), qui est lié au M SS par la relation
M SS + Sheader = M T U , où Sheader est la taille du header TCP) (2.3.2.1), C (2.3.2.3),
le RT T dans certains cas (2.3.2.4), ou encore, et c'est la solution la plus souvent utilisée,
multiplier les ux pour additionner les bandes passantes maximales disponibles (2.3.2.2).
Du comportement d'auto-régulation de TCP selon la vitesse d'arrivée des ACK des
paquets transmis et d'un RTT important, découle un second problème qui provient de
l'algorithme de slow start de TCP. Les ACK des paquets étant transmis sur une ligne
ayant une latence forte, la vitesse d'accroissement de la taille de la fenêtre de congestion
est de fait, plus lente que celle observée sur une liaison avec une latence plus faible, surtout
dans les phases d'évitement de congestion (Congestion Avoidance ). Or, le principe du
slow start standard de TCP est de doubler la taille de la fenêtre de congestion à chaque
réception d'ACK, jusqu'à détection de la congestion. A la détection de la congestion, la
taille de la fenêtre de congestion est divisée par 2 (pour TCP dans sa version Reno ),
puis, pendant la phase de congestion, l'accroissement de la taille de congestion devient
plus lente, phénomène amplié par un grand RTT [62]. Le problème est l'entrée en phase
d'évitement de congestion, trop précoce, et surtout avec une fenêtre de congestion de petite
taille. La tendance est à donner au protocole TCP une agressivité plus grande lors de la
phase de congestion et de limiter la phase de slow start. Des études [110] ont été menées
parallèlement à celles sur l'augmentation de l'utilisation de la bande passante en régime
permanent pour les réseaux de type high bandwidth-delay, et sont souvent couplées les unes
aux autres [69].
Cette section traite des diérents protocoles TCP développés pour permettre d'atteindre une grande bande passante sur des réseaux high bandwidth-delay. La classication
introduite ici découle des comportements des diérents protocoles en régime permanent
(phase d'évitement de congestion), et des variables modiés dans l'équation 2.1 ; d'aucun
trouveront d'autres classications pour les divers protocoles évoqués ici suivant la perspective des performances réseaux qui les concernent. Notons que cette classication permet
de dénir des classes de protocoles pouvant être utilisés conjointement sur un même ux
d'information.
21
2.3.2 Améliorations de TCP
2.3.2.1 Modication de la taille maximale de segment
La taille de la fenêtre de congestion TCP est un multiple du MSS (MSS) et le mécanisme
d'une transmission TCP en phase de slow start comme en régime permanent est exprimé
par un algorithme basé sur cette unité. Une simple observation de l'équation 2.1 permet
de mesurer l'eet de l'augmentation de ce facteur sur la bande passante utilisée.
La taille de segment est en eet paramétrable dans une certaine limite pour TCP. La
taille standard du MTU est de 1500 octets. Cette taille provient, historiquement, du taux
d'erreur de la couche Ethernet lors de la transmission de paquets sur des liens physiques
anciens ; elle représentait un bon compromis entre la vitesse de transmission et le nombre
de paquets transmis erronnés. Sur des réseaux plus modernes, on peut raisonnablement
augmenter le MTU pour atteindre les 9000 octets, le taux d'erreurs lors des transmissions
étant plus faible. Hors du simple aspect réseau, cette méthode permet de diminuer la
charge CPU induite par la gestion de paquets plus nombreux lors de l'utilisation de MTU
classiques.
Cette méthode est souvent appelée jumbo frame. Si, analytiquement comme expérimentalement, elle obtient de bons résultats [68], elle est malheureusement limitée dans son
application. Le principal handicap de cette méthode est que les équipements réseaux ne
supportent pas tous les jumbo frame, que ce soit logiciellement (ils ne sont pas congurés
pour le faire) soit physiquement, ce qui limite leur usage. Un autre problème lié à l'utilisation des jumbo frame est l'accentuation du phénomène de burst. Un burst est un envoi
massif dans une très courte période d'un grand nombre de données. Il arrive typiquement
quand une application génèrant un grand volume d'information à envoyer partage le temps
CPU avec d'autres applications : les envois s'eectuent par salves de plusieurs paquets simultanément, les ACK étant reçus de manière asynchrone par la carte réseau. Cet envoi
massif augmente les risque de congestion tant au niveau des routeurs le long de la liaison
réseau que du récepteur du ux de données. Cet eet est tout naturellement amplié par
l'usage d'un MSS important.
2.3.2.2 TCP parallèle
La méthode la plus utilisée pour atteindre un débit important est l'utilisation de plusieurs sockets TCP parallèles. L'envoyeur d'un ux TCP distribue ses données sur les
diérentes sockets ouvertes vers le récepteur. Cette méthode est appelée streaming TCP.
Les premières versions de gridFTP ([43], [90], [95]) étaient basées sur cette méthode, qui est
toujours la méthode de transmission par défaut de cet outil. Cette méthode est par ailleurs
induite par le protocole HTTP (HTTP) sans connexion persistante [47] (une connexion
TCP est ouverte pour chaque objet présent sur une page entre le serveur et le client),
et est appliquée aux réseaux satellitaires [44], ceux-ci exhibant des propriétés proches de
22
celles de l'architecture que traite le présent document, c'est-à-dire un fort RTT et une
bande passante importante.
Le comportement en régime permanent de ce type de protocole vis-à-vis de la bande
passante sur un chemin p peut être décrit par l'équation suivante [76] :
cpBwagg
n
M SS ∗ C X 1
√
≤
RT T
lossi
i=1
(2.2)
où cpBwagg est la bande passante agrégée des n ux parallèles et lossi la probabilité de
pertes de paquets pour chacun des ux. En considérant des conditions idéales (bande
passante mise à disposition par le lien physique considéré et taille des queues de routeurs
le long de cette liaison innie, délai induit par un routeur pour réémettre un paquet xe
quelle que soit la longueur de la queue, etc) on admet un loss commun, et l'on peut réécrire
l'équation 2.2 comme suit :
cpBwagg ≤
M SS ∗ C ∗ n
√
RT T ∗ loss
(2.3)
Cette formule pour abstraite qu'elle soit reète l'esprit de cette méthode : multiplier les ux TCP pour additionner leurs performances en terme de bande passante. Bien
sûr, le nombre de ux augmentant, la congestion entre les diérents ux émis augmente
en conséquence, et rapidement, la bande passante utilisée diminue puisque loss augmente.
Dans l'optique d'obtenir les meilleures performances en terme de bande passante, il convient
donc d'accorder le plus grand soin au choix du nombre de connexions TCP ouvertes (n).
Ce choix est fonction de la bande passante atteignable point à point entre l'émetteur du
ux et le récepteur de celui-ci, entraînant une dépendance forte aux ux concurrents le
long de la liaison point à point dans le choix de n.
Pour illustrer le comportement de sockets parallèles, comparons le comportement de
deux transferts : n sockets TCP Reno ouvertes pour un transfert parallèle pour le premier,
et un transfert via une pile TCP non-parallèle AIMD [76]. Notons W indwagg ,t la fenêtre de
congestion (exprimée en M SS ) agrégée des n sockets à un instant t, W indwi ,t celle d'une
socket TCP i appartenant à la transmission parallèle, W indwT CP ,t celle du ux TCP, et
enn tp l'instant lié à la détection de la perte d'un paquet dans un temps discret. Supposons
que les pertes soient uniformément réparti, et qu'il n'y ait aucun phénomène de congestion
lié au n sockets TCP. Lors de la perte d'un paquet, la transmission TCP Reno diminuera
sa fenêtre de congestion de moitié, i.e. :
W indwT CP ,tp =
W indwT CP ,tp −1
2
(2.4)
De même, la fenêtre de congestion du ux j appartenant aux n sockets diminuera de moitié.
23
Par contre, W indwagg ,t sera égale à :
W indwagg ,tp = W indwagg ,tp −1 −
W indwj ,tp −1
2
(2.5)
En considérant les n fenêtres de congestion égales, le facteur de décroissance de la fenêtre de
1
congestion agrégée des n ux est de 2∗n−1
2∗n , au lieu de 2 dans le cas d'une seule transmission
TCP. Lors d'une perte de paquet, un ux TCP parallèle libère moins de bande passante
qu'un ux TCP traditionnel.
En ce qui concerne la phase d'évitement de congestion, le comportement plus agressif
des TCP parallèles peut être considéré comme similaire à un ux TCP dont le facteur
additionel lors de l'accroissement de la fenêtre de congestion est supérieur à un M SS .
En eet, si l'on considère que les ACK sont reçus de manière synchrone par tous les ux,
l'accroissement de W indwagg ,t sera de n ∗ M SS à chaque RTT au lieu d'un M SS pour un
ux TCP Reno.
Ce sont les limitations même de cette approche qui font l'attrait de cette méthode : son
comportement très aggressif implique de fait un manque de respect de l'équité, un risque
de congestion plus fort, un coût en terme de CPU dû au maintien des n connexions TCP
ouvertes, ainsi que de la distribution des données à envoyer plus important que celui induit
par une simple connexion TCP, même si ce dernier problème reste limité [53].
Pour réduire les eets indésirables de manque d'équité de cette solution, certains réduisent de manière virtuelle le RTT des n connexions parallèles ouvertes [75], [76], de
manière à en diminuer l'agressivité ; la section 2.3.2.4 est consacrée à ce type de modication de TCP.
2.3.2.3 Augmentation du facteur C
q
Le facteur C de l'équation de Mathis (2.1) est égal dans le cas de TCP Reno à 32 .
Dans le calcul de Mathis, cette valeur provient de l'accroissement puis de la baisse de la
bande passante utilisée dans un comportement en dent de scie classique de TCP. C , fondamentalement, est le reet des facteurs d'accroissement et de baisse dans le fonctionnement
AIMD de TCP. Cette section est consacrée aux protocoles proposés pour les réseaux high
bandwidth-delay jouant sur le facteur C , i.e. les protocoles modiant ces facteurs d'accroissement et de baisse.
De nombreux protocoles ([93],[88],[69] par exemple ; des évaluations concurrentes de
plus de protocoles du même type ont été faites dans [98],[53]) ont été développés dans ce
sens, en jouant sur les 3 facteurs dénis par les équations suivantes reprenant la notation
précedemment dénie dans la section 2.3.2.2 [53] :
Réception d'ACK lors de la phase de Slow start :
W indw,tACK = W indw,tACK −1 + c
(2.6)
24
Réception d'ACK lors de la phase d'évitement de congestion :
W indw,tACK = W indw,tACK −1 +
a
W indw,tACK −1
(2.7)
Détection de perte de paquets lors de la phase d'évitement de congestion :
W indw,tLoss = W indw,tLoss −1 − b ∗ W indw,tLoss −1
(2.8)
Dans le cas de TCP Reno, on a : a = 1, b = 21 et c = 1. Cette section étant consacrée
aux modications sur le facteur C , nous n'aborderons ici que les modications faites sur
a et b. Souvent, ces modications sont faites sur les deux facteurs de manière conjointe.
Elles peuvent être associées à un seuil dénissant un type de fonctionnement plus agressif
pour les ux TCP lors de l'utilisation de grandes fenêtres de congestions : HighSpeed TCP
([69]) par exemple, utilise à partir d'un certain seuil une valeur de a qui n'est plus xe,
mais appartient à une table de valeurs prédéterminées ; H-TCP utilise quant à lui un
algorithme dépendant d'indices de congestion pour déterminer les valeur de a au-dessus du
seuil. Scalable TCP exprime a comme une fonction de W indw,tACK −1 , a(W indw ) adoptant
un comportement exponentiel ; la valeur de b est quant à elle de 81 au lieu de 12 [88]. Ces
modications ont pour objet de rendre TCP plus agressif vis-à-vis de l'utilisation de la
bande passante.
D'autres protocoles visent à faire décroître cette agressivité, pour deux raisons principales : (i) le respect de l'équité lors de l'utilisation de plusieurs sockets TCP parallèles, (ii)
lors de transfert long de chier, adopter un comportement assimilable à celui d'un ux de
basse priorité (low priority ). HSTCP-LP [93] par exemple combine l'agressivité de HighSpeed TCP à un facteur b fort, de manière à laisser la priorité aux autres ux concurrents.
Les comportements de ces diérents ux ont été profondément évalués, en jouant sur les
facteurs de distance, de ux concurrents et en mesurant le respect de l'équité aché par
chacun, par rapport à d'autres ux concurrents utilisant ces nouveaux protocoles dans
[53]. Les diérentes implémentations sont sujettes à des comportements diérents suivant
la distance et les ux concurrents, laissant entendre que l'utilisation d'une seule pile TCP
pour les diérents cas d'utilisation possibles ne soit pas la meilleure des solutions. De plus,
l'étude du comportement de certaines de ces solutions vis-à-vis d'une bande passante disponible variable (comme cela peut être le cas pour des réseaux orant de la qualité de service
[51]) montre que l'ecacité de ces piles TCP peut varier suivant les environnements sur
lesquels elles sont appliquées [98].
25
2.3.2.4 Mise en oeuvre d'un RT T virtuel
L'idée de la mise en place d'un RT T virtuel est utilisée dans le cas qui nous intéresse
pour diminuer l'agressivité d'un ux TCP parallèle [75]. Si conceptuellement l'idée de ralentir l'augmentation de la taille de la fenêtre de congestion en simulant un RT T plus
fort pour réduire l'agressivité de sockets parallèles est intéressante, elle est dans l'implémentation qui est proposée dans [75] strictement égale à celle de modier le facteur a de
l'équation 2.7.
Par contre, elle met en lumière dans ce cas d'utilisation la diculté de pouvoir mettre
en place un système d'équité pour le cas de n sockets parallèles : la modication de a
choisie par les auteurs pour respecter l'équité est fonction de n et des capacités de la
liaison physique réseau utilisée pour l'expérience.
2.3.2.5 Modication autour de loss
Les techniques de gestion de queues de routeurs sont traditionnellement soit basées sur
le rejet du dernier message arrivant (on parle de drop tail ) soit sur une gestion dite RED
(RED) (Random Early Detection ). Ce dernier algorithme rejette des messages quand la
taille totale des messages stockés par la queue à sa disposition dépasse un certain seuil en
eectuant un choix sur les ux entrant par un tirage au sort d'un de ceux déjà présents
dans sa queue ; on parle alors d'AQM (AQM) (Active Queue Management ), car le routeur
maintient une connaissance de son propre état. Les politiques d'AQM permettent aux
routeurs de transmettre une indication sur leurs taux de congestion, ce qui permet de
réduire les éventuels rejets de paquets, et donc, loss, si la version de TCP utilisée par un
ux prend en compte les informations transmises par les routeurs, en réduisant les paquets
en circulation le long de la liaison point-à-point considérée. De telles modications sur le
protocole HSTCP [69] ont été étudiées dans [85] : des routeurs RED passent par le biais
d'un champ du header TCP pour prévenir l'émetteur d'une possible future congestion (on
parle d'ECN (ECN) (Early Congestion Notication )), et celui-ci gèle l'augmentation de la
taille de sa fenêtre de congestion jusqu'à une perte de paquets eective, ou l'arrêt de l'envoi
d'ECN. Malheureusement, les routeurs capables d'héberger des AQM sont moins déployés
que les routeurs classiques : de fait, des solutions basées sur des propriétés de ceux-ci
ne peuvent être généralisables sur une grille par nature hétérogène dans son équipement
réseau.
Ce rapide portrait des protocoles utilisés dans le domaine des grilles pour obtenir des
débits intéressants lors des transferts montre que la majeure partie des techniques reposent
sur l'hypothèse qu'accentuer l'aggressivité des ux TCP permet d'obtenir de meilleures
performances. De plus, la technique la plus utilisée est en pratique le streaming TCP.
Or, le choix optimal de n pour ce genre de techniques dépend de la connaissance que
l'on a de la capacité du lien considéré ainsi que de la bande passante disponible. Pour un
26
n trop grand, les performances de ce type de protocole vont se dégrader naturellement,
même en l'absence de trac interférent. Le problème apparaît encore plus nettement si l'on
est en présence de trac interférent. Il convient donc, pour utiliser de tels protocoles de
manière ecace, de posséder une connaissance des performances du réseau, mais aussi de
sa topologie, pour paramétrer ecacement les diérents ux et les ordonner de manière à
maximiser l'utilisation de la bande passante tout en respectant les priorités de chacun de
ces ux.
2.4
Synthèse
Dans ce chapitre, nous avons donné les principales caractéristiques des applications
qui peuvent bénécier de l'extraction de connaissances sur les performances réseau. Nous
résumons ici les principaux points qui permettent de conclure à une adéquation entre cette
extraction de connaissances et les domaines des grilles institutionnelles.
2.4.1 Plate-forme
les plates-formes telles que décrites dans la section 2.1.2 sont caractérisées par un
nombre assez faible de sites géographiques (moins d'une dizaine à 145) qui sont géographiquement très dispersés, contenant un grand nombre de ressources. De plus, les sites,
quant à eux, sont à priori ables et possèdent par essence une longue durée de vie. De telles
caractéristiques peuvent se retrouver dans d'autres types de réseau. Ces caractéristiques
permettent d'envisager une reconstruction de topologie avant l'exécution d'applications.
Comme nous l'avons vu, les plates-formes de grilles possèdent, le plus souvent, leur
propre réseau, ce qui permet d'envisager une certaine stabilité du réseau en terme de bande
passante, délai, .... Ceci renforce l'hypothèse qu'à priori de tels réseaux se prêtent bien à
une détection des capacités et de la topologie du réseau avant l'exécution d'applications
très dépendantes de transferts de données massifs.
2.4.2 Contexte d'exécution
Les grilles institutionnelles, et à fortiori le projet EGEE, ont souvent besoin de transférer un volume de données très important. Ces transferts se font généralement de manière
massive, de gros volumes de données circulant d'un site à un autre lors d'un seul transfert. De plus, l'utilisation de protocoles aggressifs tels que le streaming TCP renforce la
possibilité de pertes brutales de performances lorsque des transferts simultanés saturent
les mêmes portions du réseau. Enn, le système d'ordonnancement qui est global à toute
27
la grille permet de prévenir de telles saturations par l'ordonnancement des communications. Ces points renforcent le besoin en connaissances sur les performances du réseau et
sa topologie.
2.4.3 Contexte logiciel
Enn, comme nous l'avons vu dans la section 2.1.3 les grilles actuelles fonctionnent
dans leur grande majorité en utilisant un paradigme de service. Il renforce le sentiment
qu'un outil répondant au besoin de connaissances des performances réseau devrait être un
service disponible pour un ensemble d'utilisateurs, interrogeable de manière dynamique, et
qu'il devrait se conformer à la norme WSRF de manière à s'intégrer naturellement dans
cet environnement.
Pour résumer, l'étude menée dans ce chapitre donne les grandes lignes de ce que devra
être et faire l'outil qui a été développé dans le cadre de cette thèse. Il devra être capable
de fournir des connaissances sur les performances et la topologie du réseau, ainsi que de se
fondre dans une architecture orientée service. Pour fournir de telles connaissances, l'outil
doit permettre de mesurer les performances et d'identier les interactions des diérents
chemins parcourant le réseau, ce qui est le sujet du prochain chapitre.
28
Etat de l'art : découverte automatique de
topologie des performances d'un réseau
Comme nous l'avons vu précédemment, certains types de grilles peuvent bénécier de
l'extraction de connaissances sur les performances du réseau. Pour ce type de grille, l'intêret
de ces connaissances dépend de la manière dont celles-ci peuvent reéter les interactions
entre des transferts en provenance de plusieurs sources vers de multiples destinations.
Comme évoqué précédemment, la découverte automatique de topologie des performances
d'un réseau est appelée tomographie réseau. Après avoir déni plus rigoureusement les
limites de ce que j'appelerai tomographie réseau dans ce document, ce chapitre dresse un
portrait des diérents travaux existants dans le domaine.
3.1
Reconstruction de topologies
Le terme de tomographie réseau peut désigner soit l'inférence des capacités d'un réseau
connaissant sa topologie physique, soit la découverte d'une représentation, suivant une
caractéristique donnée, de sa topologie. L'objet de cette thèse est la découverte de topologie
du réseau en prenant en considération la bande passante, sans connaissance (la plupart du
temps) de la topologie réseau physique, en utilisant uniquement des mesures de bout en
bout. Nous utiliserons donc le terme de tomographie réseau pour désigner ce type de
reconstruction.
3.1.1 Problèmes inverses
La découverte de topologie réseau, à partir de données provenant uniquement de mesures de bout en bout, c'est-à-dire depuis des machines n'appartenant pas au coeur du
réseau, appartient à la classe de problèmes dits inverses [87]. Un problème inverse est caractérisé par le fait que l'on ne dispose que d'observations nales (d'observations eectuées
de bout en bout), des conséquences de l'action et du fonctionnement d'une entité pour
déduire tout ou partie de la structure interne des caractéristiques de cette entité. Les problèmes inverses se retrouvent dans beaucoup de champs scientiques tels que la physique,
la biologie, ou l'informatique. Le terme de tomographie réseau est d'ailleurs né de l'analogie
faite avec la tomographie telle que dénie en physique ou en imagerie médicale, où, depuis
29
Etat de l'art : découverte automatique de topologie des performances d'un réseau
l'observation de mesures telles que l'injection de ux de particules au travers d'un objet
ou organe sur un ensemble de tranches de celui-ci, on reconstruit sa structure interne de
manière tridimensionnelle.
La résolution de tels problèmes passe par 3 étapes :
La formulation du problème permettant de dégager un modèle cible reconstructible.
La reconstruction de la solution qui se fait en développant des algorithmes le plus
souvent dédiés au modèle choisi pour dénir la solution du problème.
La récupération d'un jeu de données contenant susamment d'information pour
reconstruire la solution dans le modèle correspondant au problème traité.
Ces trois points sont nécessaires à l'obtention d'une solution, mais relativement distincts : on peut par exemple dénir des algorithmes génériques pour des techniques de
mesures diérentes, mais dont l'expression des résultats peut se faire de manière similaire ;
de même, il est possible, à partir de diérentes mesures, d'appliquer diérents algorithmes
permettant de reconstruire des solutions dans plusieurs modèles.
Dans le cadre des méthodes de tomographie réseau, la première étape, c'est-à-dire la
formulation du problème, peut se réduire au choix de la dénition de la relation mathématique observée entre les chemins considérés et au choix du modèle permettant de représenter
la solution visée. Ce choix de la modélisation de la solution (du type de topologie), et donc,
la bonne formulation du problème est une étape importante, car elle permet éventuellement, et c'est le cas du travail que je présente ici, d'obtenir un problème inverse mal posé,
mais bien déni. En eet, l'immense majorité des problèmes inverses sont mal posés et mal
dénis au sens d'Hadamard [77]. Ils sont donc caractérisés par le fait que :
la solution n'existe pas nécessairement,
la solution n'est pas unique,
la solution ne dépend pas de façon continue des données.
L'étape de modélisation de la solution est donc un point important de la résolution de problèmes inverses. Cette étape est la première du processus classique menant à la résolution
de problème inverse.
L'étape suivante, c'est-à-dire la reconstruction de la solution se fait à l'aide d'algorithmes dédiés au modèle retenu lors de la première étape. Certains algorithmes peuvent
inuencer la récupération des données (comme par exemple celui que nous avons développé
et décrit en section 5.4.5). La barrière entre l'étape de reconstruction et celle d'acquisition
du jeu de données initial est donc plus ou moins lâche. Néanmoins, les 3 étapes nécessaires conduisant à l'obtention d'une solution restent inchangées 1) modélisation de la
solution désirée, 2) récupération de données, 3) reconstruction de la solution. Ces trois
étapes trouvent d'ailleurs leur reet dans ce manuscrit, puisque chacune est détaillée dans
son chapitre respectif, à savoir les chapitres 4, 5 et 6.
Pour établir une taxonomie des diérentes méthodes existantes, il est nécessaire de dé30
nir un axe susamment générique pour englober tous les modèles utilisés par ces travaux
ainsi que les caractéristiques observées lors de la récupération d'un jeu de données initial
en vue d'une reconstruction. J'adopterai ici une description des diérentes méthodes basée
sur les relations dénies entre les chemins.
Dans un premier temps j'introduis les dénitions des termes utilisés dans cette thèse
ainsi que les diérentes notations qui seront employées en section 3.1.2. Puis il est donné
une vue d'ensemble des diérentes méthodes existantes pour découvrir automatiquement
une topologie réseau en sections 3.1.4, 3.1.5 et 3.1.6 suivant une taxonomie donnée en
section 3.1.3. Nous aborderons plus en profondeur en chapitre 4 la problématique liée
à la modélisation et la réprésentation des informations acquises sur la topologie. Dans le
chapitre 5, nous développerons les questions liées aux algorithmes de reconstruction utilisés.
Enn, nous ferons une étude plus approfondie du type de tests et de mesures utilisés dans
le chapitre 6.
3.1.2 Vocabulaire et dénitions
Nous utiliserons le terme de mesures pour désigner l'expérience consistant à injecter
des ux dans le réseau dans le but de déterminer certaines de ses propriétés. On appelera
test l'action atomique d'une mesure consistant à établir un ux entre une source et une
destination. Hormis ces tests, nous considérerons qu'il ne circule aucun autre paquet sur le
réseau, c'est-à-dire qu'il n'y a aucun trac interférent,excepté lorsque cela est mentionné
explicitement.
Dans cette thèse, nous faisons l'hypothèse que le routage est consistant et stable, sauf
lorsque l'on remettra ces hypothèses en cause explicitement. Par consistant, nous supposons
que le routage ne crée pas de chemins qui se rejoignent, se séparent et se rejoignent encore.
Par stable, nous considérons que les chemins ne changent pas durant la totalité du processus
de mesures.
Nous considérons ici le réseau comme un graphe orienté G = (V ∪ S ∪ R, E) où les
sommets V sont les équipements réseau déployés tels que les routeurs, les hub, etc, S
l'ensemble des hôtes sources, R l'ensemble des hôtes destinations, et E les liens physiques
les reliant (E ⊂ V ∪ S × V ∪ R). On notera lij un arc allant d'un noeud i à un noeud j .
Un hôte étant à la fois source et destination sera considéré comme deux hôtes diérents,
l'un source et l'autre destination.
Sur ce graphe, la fonction de routage dénit un ensemble de chemins uniques entre
chaque hôte et chaque destination. En eet, si il existe deux chemins entre un noeud a
et un noeud b, cela signie qu'ils se sont joints en a, séparés puis rejoints en b, ce qui
viole l'hypothèse de consistance. Nous noterons pab le chemin reliant la source a ∈ S et la
destination b ∈ R. Celui-ci est la suite ordonnée pab = (lai , lij , ljk , ..., lqb ) d'arcs lij ∈ E .
Chaque arc de cette suite a pour origine la destination de l'arc le précédant immédiatement
31
(si celui-ci existe). Un sous-chemin de pab est une sous-suite de cette suite qui respecte luimême la dénition d'un chemin pour une source a0 ∈ S ∪ V et une destination b0 ∈ V ∪ R.
On dira que pab contient ce sous-chemin. On appelera longueur d'un chemin le nombre de
liens qui le composent. L'union de l'ensemble des chemins dénis par la fonction de routage
et de l'ensemble sans répétition de leurs sous-chemins sera noté Pall . Le sous-ensemble de
Pall contenant seulement les chemins entre chaque source s ∈ S et chaque destination
r ∈ R, soit les chemins de bout en bout, sera appelé Pe2e . Nous appelerons ux de données
les paquets circulant sur un élément de P suite à un test.
Lorsque le contexte ne nécessitera pas explicitement la mention des points d'arrivée et
de départ d'un chemin, on notera un chemin pi . On appellera arc inverse d'un arc lij l'arc
lji . Dans le cas d'un chemin pij on appellera chemin inverse d'un chemin pij = (l1 , ..., ln )
le chemin pji = (l10 , ..., ln0 ) tel que tout lk0 est l'inverse de l'arc ln−k pour 0 ≤ k ≤ n − 1.
3.1.2.1 Sous-chemin commun maximum
On appellera sous-chemin commun à un ensemble de chemins Ps un chemin contenu
dans chacun des éléments de Ps . On appelera sous-chemin commun maximum d'un ensemble de chemins Ps le sous-chemin commun le plus long de l'ensemble des sous-chemins
communs de Ps . De par l'hypothèse de consistance du routage, celui-ci est unique pour un
Ps
ensemble donné de chemins. On notera ce sous-chemin pmaximum
. On dira que les chemins
de l'ensemble Ps admettent un sous-chemin commun maximum, ou encore que les chemins
Ps sont couverts par leur sous-chemin commun maximum. On appellera l'ensemble Ps la
s
couverture de pPmaximum
.
L'ensemble des sous-chemins communs maximum non nuls admis par au moins un des
sous-ensembles de cardinalité supérieure ou égale à 1 d'un ensemble de chemins P sera
noté M axP .
Soit un ensemble Ps de chemins appartenant à Pe2e qui admettent un sous-chemin
commun maximum. On notera fpPijs le ux transmis entre les hôtes i et j le long du chemin
pij ∈ Ps lors de tests concomitants sur l'ensemble des chemins appartenant à Ps .
On désignera par point de conjonction pour un ensemble de chemins Ps le sommet
s
de départ du premier arc de pPmaximum
. On désignera par point de disjonction pour un
s
ensemble de chemins Ps le sommet destination du dernier arc de pPmaximum
.
On appellera arcs propres à un chemin p vis-à-vis d'un ensemble de sous-chemins P 0
de p les arcs appartenants à p qui n'appartiennent à aucun des éléments de P 0 .
3.1.2.2 Métrique
Nous appellerons métrique une fonction dont l'ensemble de départ est l'ensemble des
ux et celui d'arrivée les réels. Nous noterons cpm la capacité d'un chemin p suivant la
métrique m. Par exemple si la métrique m est le délai, la capacité cpm d'un chemin p sera
égale à la somme des délais de chacun des liens et routeurs qu'il contient. Nous appellerons
32
paramètre de sensibilité s la valeur minimale qui peut être déduite des résultats de tests.
Dans certains cas, on pourra associer à certaines métriques une relation d'ordre ≤ dans
l'ensemble des réels. On parlera de relation d'ordre ≤ associée à la métrique m.
La capacité d'un chemin sera détectable si il existe un ensemble de chemins contenant
ce chemin qui permet d'exhiber cette capacité par l'injection de tests. Par exemple, pour
la métrique de la bande passante atteignable par des ux TCP en régime permanent, la
capacité d'un sous-chemin commun à un ensemble de chemins n'est détectable que si l'on
arrive à saturer ce sous-chemin. Un chemin de capacité indétectable est par exemple un
chemin de délai nul si la métrique est le délai, ou encore si la métrique est la bande passante
un lien de capacité innie.
Une métrique m sera constante par rapport aux mesures si la capacité cpm déduite des
mesures est indépendante des chemins utilisés par les tests pour la détecter. Par exemple,
si la métrique est le délai induit par un lien, la capacité d'un sous-chemin commun pcommon
sera la même, quel que soit l'ensemble de chemins admettant pcommon comme sous-chemin.
Le ratio entre la bande passante atteignable par 2 ux TCP concurrents sur un même lien
est un exemple de métrique non-constante : celui-ci est fonction du round trip time de
chacun des ux. Donc, deux ensembles de ux TCP diérents admettant le même souschemin commun ne partageront pas forcément la bande passante suivant le même ratio.
On notera m(fpPij ) la mesure de l'eet de l'injection du ux fpPij vis à vis de la métrique
m.
3.1.3 Taxonomie
Le problème plus spécique de la reconstruction de topologies réseau est un sujet qui
a été largement étudié ces 20 dernières années [58]. De nombreuses techniques ont été développées pour constituer un jeu de données permettant de reconstruire diérents type de
solutions. Plusieurs axes permettent de classer ces techniques, soit en se basant sur l'observation des caractéristiques du modèle de la solution produite, soit sur l'observation des
caractéristiques des techniques de mesures utilisées. En faisant abstraction de la structure
du modèle utilisé (pré-ordre, système partiellement ordonné, etc) on peut observer que les
modèles sont soit :
Etiquetés sur les arcs. C'est le cas de la plupart des modèles basés sur des techniques
de mesures de métrique le long de l'ensemble de chemins participant à la mesure.
L'étiquette correspond alors à la valeur de la métrique sur la portion du chemin
étiquetée.
Etiquetés sur les noeuds. C'est le cas par exemple dans un modèle où les recoupements
entre les diérents chemins sont basés sur les adresses IP des équipements réseau
déployés le long des chemins observés.
33
Non-étiquetés. C'est le cas de certaines solutions reconstruites à partir de méthodes
basées sur des métriques dans lesquelles les étiquettes ne peuvent être attribuées à
des sous-chemins précis, ou encore dans le cas de certaines techniques de mesures
permettant d'identier les sous-chemins composant un chemin par l'évaluation de
sa capacité par rapport à une métrique n'ayant pas de signication précise pour
l'utilisateur.
Ces diérentes représentations sont aussi le reet de besoins divers : par exemple les
auteurs de [96] désirent construire une topologie pour eectuer des mesures régulières sur
celui-ci. Ce type de représentation est utile pour des outils tels que NWS ou WREN. Ces
outils utilisent en interne une représentation du réseau pour mener des tests réguliers sur
certaines portions de celui-ci, dans le double but de monitorer ces portions mais aussi de
les archiver pour réaliser des prédictions de performances. Ces représentations internes du
réseau isolent des portions du réseau sensées être indépendantes. Elles n'ont par dénition
pas d'étiquettes. Les auteurs de [49] désirent faire une estimation des capacités du réseau
dans le but d'optimiser son utilisation par une application dont les communications vont
le saturer ; c'est aussi le cas de l'utilisation de la topologie par le FTS. Ces derniers cas
nécessitent donc de connaître les performances des entités du réseau identiées dans le but
d'optimiser leur utilisation.
Les techniques de mesures quant à elles sont toutes basées sur le même principe : l'évaluation porte sur un ensemble de chemins appartenant à Pe2e , permettant d'obtenir une
mesure, le plus souvent dans les réels, sur laquelle est appliquée un seuil, pour obtenir une
relation à partir de l'évaluation. A partir de cette relation, l'algorithme de reconstruction
permet de dénir d'éventuels nouveaux noeuds et arcs correspondant à cette relation. La
valeur de la mesure peut éventuellement servir d'étiquette. Les diérentes techniques de
reconstruction peuvent donc être caractérisées par la formalisation de la relation qui est
tirée de la technique de mesure utilisée. Cette relation, par les relations qu'elle implique
entre les éléments de la solution générée, implique le modèle de solution qui sera utilisé.
Nous donnons donc ici une taxonomie des diérentes méthodes existantes basées sur les
caractéristiques des modèles utilisés pour représenter les solutions puisque de ces relations
découlent la modélisation, l'algorithmique et les techniques de mesures. Pour cela on introduit les diérentes méthodes en redénissant les méthodes de mesures utilisées en terme
de relation produite entre les chemins.
3.1.4 Reconstruction de topologies étiquetées sur les noeuds
3.1.4.1 Identication des noeuds
Les méthodes de reconstruction basées sur la relation d'identication de noeuds ([97][63],
[79], [73],[102]) requièrent que les noeuds appartenant au coeur du réseau puissent être identiés par des mesures de bout en bout. Les mesures demandent donc une collaboration de
34
la part des noeuds identiables, puisqu'ils doivent répondre à des requêtes SNMP (SNMP)
ou ICMP (ICMP). Les topologies résultant de reconstructions à partir de cette relation
ne présentent pas une structure d'ordre, contrairement à toutes les autres méthodes existantes. Ce sont des graphes (orientés ou non) dont les arcs représentent les liens utilisés
par le routage à l'instant où les mesures sont eectuées. Les principales dicultés de la reconstruction de topologies proviennent de l'éventuelle non-réponse des noeuds aux requêtes
ICMP et de l'existence de plusieurs interfaces IP pour un même équipement réseau.
Dénition La fonction
id(Pprobe ) dont l'ensemble de départ est l'ensemble des sous-
ensembles de Pe2e et l'ensemble d'arrivée les réels peut être dénie par :
(
id(Pprobe ) =
1 si∃v ∈ V, v répond ICMP ∀p ∈ Pprobe ∃l ∈ p, ∃x ∈ V tel que l = lvx ou lxv
0 sinon
(3.1)
La relation n-aire × en résultant peut être dénie trivialement par :
(3.2)
× (Pprobe ) = id(Pprobe ) > 0
La vision d'un réseau par l'utilisation de la relation d'identication est illustrée à la
gure 3.1. Dans l'exemple illustré, les noeuds 5 et 6 sont congurés pour ne pas répondre.
Les chemins passant par ces noeuds ne portent donc pas de traces de ces noeuds. Ainsi,
les chemins paw et pcw ne partagent apparemment pas d'autres noeuds que le noeud destination.
A
B
3
C
1
(
(
(
'((
'
'
'
(
(
(
'
'
'
'
(
(
('(' '(
'(
'(
*)(
&
&%*
' *
' *
' *
%*
))& &%*
)&%*
)
)
)
)*
*
*)*)*) )%)& &%*
)&%*
)
)
)
)
)*
*
*
*
*
))& &%*
)
)
)
)
)
*
*
*
*
)+ &*
)
)
)
)
)
%*&%
*%
*
*
*
*
*
)&&%,
),
),
),++ *
) *
) *)*)
*
*
*
++ %,
+
+
,%
+,
+
+
,+
,
,
,
,
,
,
,,++,+
+,
++,
++,
++,
,
,
,
,
+,+
+,
+,
+,
++ ,
+
+
,+,+,+
+,
+
+
,+
,
,
+,
+
+
,+ ,
,
+,
+,
+
+
,
,
,
+ ,
+ ,
+ ,+,+ A
X
6
!"
!"
!!! "
!!! "
!"
!"
"
"
"
"!"!"! !"
!"
!"
!"
!"!"
!"
!"
!"
"
"
! "
! "
! $#$
!# $#$
!# $#$
"
"
"! $# # $#
2
5
4
Y
B
333 44333
4
4
421 4
11 2
12
1
1
212
2
2
2
11 2
1
1
2
2
11 2
11 2
11 212121
2
1 2
1 2
1 21
212
2
2
2
3+4
C
1
56
6
56
56565656565
6565 ..-87
87
87
87
7787878877
80/ 8
0
9
9:
9:
:
9: :
9 :9
9 :
9 :9:9 /
:
X
2
<;<;
W
Y
W
Figure 3.1. Reconstruction par identication de noeuds
La reconstruction de topologie consiste à placer et ordonner les points communs entre
deux chemins, qui n'existent que dans le cas où ×(Pprobe ) est vrai. La problématique ici
n'est donc pas la reconstruction de la topologie en elle-même, puisque tous les arcs et
noeuds la composant sont assez facilement identiables (excepté dans le cas d'équipement
réseau présentant plusieurs interfaces réseau, qui peuvent demander d'eectuer des fusions
de noeuds entre les diérentes interfaces de ces équipements). Une des dicultés est ici
d'employer un minimum de mesures, en évitant de tester des chemins partageant de très
35
longs chemins communs. En pratique, ces représentations, combinées avec des outils de
monitoring, permettent de visualiser l'état du réseau, comme par exemple avec l'outil
Hypviewer GUI de Skitter (CAIDA) [70] et ses versions postérieures.
3.1.5 Reconstruction de topologies étiquetées sur les arcs
Les reconstructions de topologies étiquetées sur les arcs sont toujours faîtes par rapport
à une métrique m donnée. De fait, comme nous le verrons plus tard dans la section 4 les
métriques doivent posséder certaines propriétés, sous peine de soit ne pas pouvoir valuer
les étiquettes, soit de ne pas être en mesure de reconstruire le modèle cible.
3.1.5.1 Reconstruction de topologies par disjonction de chemins
Ce type de reconstruction est le plus répandu, puisqu'il s'appuie sur le paradigme
client/serveur : il semble en eet intuitif de penser que les chemins partant d'un seul serveur
se séparent progressivement pour former un arbre vers l'ensemble de ses clients. Cette
propriété est vraie quand le routage est consistant. La représentation d'une telle topologie
est donc un arbre dont les arcs sont orientés et valués. Il existe beaucoup d'exemples de
telles reconstructions ([52], [113], [100], [65], [58]). Les métriques traitées par ces outils sont
nombreuses (taux de perte de paquets, bande passante, délai ...).
Dénition La fonction disj(Pprobe ) repose sur une fonction d'évaluation de la capacité
d'un ensemble de liens cLm . La fonction disj(Pprobe ) a pour ensemble de départ l'ensemble
des sous-ensembles de Pe2e dont chacun des éléments possède la même source source, et
pour ensemble d'arrivée les réels. Elle peut être dénie par :
P
disj(Pprobe ) = m(fL probe ), L ⊂ E t.q. l ∈ L ↔ l ∈ p,
∀p ∈ Pprobe
(3.3)
La valeur de la fonction donne la valeur de l'étiquette de l'éventuel arc induit par cette
mesure, soit cLm . Usuellement cette fonction est transformée en relation par l'utilisation
de l'ordre ≥ associé à la métrique, ainsi que par l'utilisation d'un seuil, souvent appelé
paramètre de sensibilité que nous noterons ici s. La relation n-aire (Pprobe ) peut être
dénie simplement à partir de la fonction disj(Pprobe ) par :
(Pprobe ) = (disj(Pprobe ) ≥ s)
(3.4)
La vision d'un réseau par l'utilisation de la relation de disjonction est illustrée à la
gure 3.2 pour tous les chemins partant de a. (Pprobe ) est vraie quand le sous-chemin
commun des diérents chemins de Pprobe est détectable, c'est-à-dire que l'on est capable de
dénir que les chemins appartenant à Pprobe possèdent un sous-chemin commun à tous, qui
se termine par le point de disjonction commun à cet ensemble de chemins.
36
A
B
3
C
1
$#$#$#$#$#$#
$#$#
!"!"!"! "!"! "!"! "!"! $# $#
"
A
('('
X
&% &% &% &% &% &% &% &%
2
5
4
X
/
/
/
/
/
/
/
/0/0/ *)*)
0/
0
0
0
0
0
0
/
/
/
/
/
/
0/
0
0
0
0
0
0
/
/
/
/
/
/
0/
0/
0/
0/
0/
0/0/0
001 0/
0/
0/
0/
0/
0/
0/
..- 0/
0
0
0
0
0
0
1
1
1
1
2
2
2
2
2
- /
12
12
12
12
2
2
2
21211
1212
12
12
12
1
1
1
2
1
1
1
21
2
2
2
12
12
12
21
111 2
11 2
11 2
11 212122111 ,
2
1
1
1
2
2
2
2
2
1 2
1 2
1 221 +,+
212
2
2
2
6
Y
Y
5
W
W
Figure 3.2. Reconstruction par disjonction
Notons que l'évaluation de cLm est elle-même fonction de l'évaluation de celle-ci par
l'injection de ux au travers de l'ensemble de liens L. La relation (Pprobe ) est donc évaluée,
source qui ont une cardinalité
dans les cas réels, pour l'ensemble des sous-ensembles de Pe2e
donnée. Cette cardinalité est dans le cas de mesure unicast le plus souvent de 1 ou 2, mais
est arbitraire dans le cas d'injection de ux par transmission multicast ([52], [61]).
3.1.5.2 Reconstruction de topologies par conjonction de chemins
Ce type de reconstruction est utilisé dans le cas où plusieurs sources communiquent
vers une seule destination. Elle peut être vue simplement comme l'inverse de la méthode
par disjonction. Elle a été utilisée par exemple pour analyser les performances d'un réseau
ou encore optimiser l'ordonnancement d'uploads de chiers vers un serveur. La fonction
conj(Pprobe ) a pour ensemble de départ l'ensemble des sous-ensembles de Pe2e dont chacun
des éléments possède la même destination, et pour ensemble d'arrivée les réels. Elle peut
être dénie par :
P
conj(Pprobe ) = m(fL probe ), L ⊂ E t.q. l ∈ L ↔ l ∈ p
∀p ∈ Pprobe
(3.5)
La vision d'un réseau par l'utilisation de la relation de conjonction est illustrée à la gure
3.3 pour tous les chemins ayant pour destination W . La valeur de la fonction donne la valeur
A
B
$#$#$#$#$#$#
$#$# $#$#
3
C
1
5
4
X
"! "! "! "
!
!
!
!
"
"
"
"
!"
!
!
!
!
"!"!"!"!"!"! "!"!"! !"
"
"
"
"
!!! "
!"
!"
!"
"
"
"!"!"!
!"
!"
!"
!
!
!
"! "! "! "
"
6
2
A
Y
B
)**
*)*)*)
)*
)
+,
+,
+,
,
,
,
,+
,+,+,+
+,
+,
+,
,+
+,
+
+
+
,
+,
+
+
+
,
,
,
+ ,
+ ,
+ ,
+ ,+,+
1
C
W
('(' -.
-.
-.
-.
.
.
.
.-.-.-.
-.
-.
-.
-.
-.
.
.
.
.-.-.-.
-.
-.
-.
.
.
.
-.
-.
.
.
.
.-.
-.
-.
-.
-.
-.
-.
-.
-. .
- .
- .
- .-.-.- &%&%
5
W
Figure 3.3. Reconstruction par conjonction
37
de l'étiquette de l'éventuel arc induit par cette mesure tout comme les reconstructions
par disjonction. Usuellement cette fonction est transformée en relation par l'utilisation
de l'ordre ≥ associé à la métrique, ainsi que par l'utilisation d'un seuil, souvent appelé
paramètre de sensibilité que nous noterons ici s. La relation n-aire (Pprobe ) peut être
dénie simplement à partir de la fonction conj(Pprobe ) par (Pprobe ) = (conj(Pprobe ) ≥ s).
3.1.5.3 Reconstruction de topologies par identication de sous-chemin communs
Ce type de méthode de reconstruction est utilisé par exemple dans [107] dans le but
de combiner plusieurs arbres étiquetés provenant de reconstructions partielles utilisant la
disjonction. La technique ne comporte donc pas d'étapes permettant de valuer l'étiquette
d'un arc, mais tente d'identier des arcs communs à deux arbres obtenus par une des méthodes précédemment décrites. Nous reviendrons dans la section 4 sur les inconvénients
de telles méthodes. Cette technique ne s'applique qu'à deux paires de chemins, correspondant aux chemins produits par la combinaison de deux sources et deux destinations (i.e.
pax , pbx , pay , pby ).
Dénition La technique peut être décrite comme suit : chaque source émet vers la
première destination (x) puis vers la seconde (y ), dans des intervalles réguliers susamment grands pour éviter les interférences entre les émissions provenant d'une même source.
Chaque paire de paquets est envoyée à un intervalle aléatoire, très inférieur à la période
d'émission. L'ordre d'arrivée de chaque paquet est enregistré sur les noeuds destinations.
Puis les deux noeuds destinations calculent l'ordre d'arrivée de chaque émission. αx = ±1,
1 si le paquet de la source a est arrivé avant celui de la source b, et −1 sinon. On obtient
de manière similaire αy . Puis on dénit l'ordre d'arrivée statistique z = {αx 6= αy }. Ceci
est utile, car z n'est à priori égal à zéro (ce qui signie que les ordres d'arrivées sont similaires sur les deux destinations) que dans le cas où les 4 chemins partagent un sous-chemin
commun. La fonction de valuation est donc z ; la relation I(Pprobe ) correspondante peut
être dénie par :
I(Pprobe ) = (z = 0)
(3.6)
La topologie produite est une conténation d'arbres qui partagent deux à deux un lien
commun.
3.1.5.4 Intégration temporelle des topologies
Dans le cas de topologie étiquetée, il est à noter que les topologies induites ne sont formellement valables qu'à l'instant de la mesure. De fait, diérentes topologies peuvent être
trouvées, au cours du temps, pour un même réseau. Dans le cas des topologies induites par
des métriques, certains auteurs [58] [52] ont développé des techniques permettant d'agréger
38
les diérentes topologies arborescentes étiquetées partageant la même racine et les mêmes
feuilles en une seule topologie étiquetée. L'idée générale de cette agrégation est que chaque
point induit à un instant t est valide à condition que cela ne soit pas inconsistant avec
les mesures précédentes. Par inconsistant, les auteurs entendent que les points induits ne
respectent pas la couverture dénie par les précédentes arborescences. Si cela n'est pas le
cas, les diérents noeuds possibles sont alors triés par couverture et les arborescences sont
concaténées en une seule et même arborescence non étiquetée.
3.1.6 Reconstruction de topologies non étiquetées
Les topologies non-étiquetées sont souvent utilisées comme un cadre général dans lequel
des tests actifs permettront de donner une estimation des capacités du réseau. C'est le
cas par exemple de NWS qui utilise une notion de hiérarchie de cliques pour mesurer la
disponibilité de la bande passante.
3.1.6.1 Reconstruction de topologies par interférences entre chemins
Ce type de topologie introduit dans [106], [96] repose sur une identication de chemin
similaire à celle utilisée lors de l'établissement de topologies par disjonction de chemins,
excepté que les auteurs cherchent à identier des topologies issues de ux provenant de
plusieurs sources et plusieurs destinations. Les topologies résultant de leur reconstruction
sont, quand elles existent, des forêts d'arbres, dont la racine peut être considérée comme
le sous-chemin commun maximum des ux traversant l'arborescence. Les racines de ces
arbres peuvent être ensuite liées par des cliques, ce qui donne une structure hybride.
Dénition Les auteurs dénissent une fonction d'interférence
mes (pi , pj ) basée sur le
partage de bande passante de ux de type TCP en régime permanent traversant le réseau.
Cette fonction est dénie entre deux chemin pi et pj (pi ∪ pj = Pprobe ) comme étant :
P
m(fpiprobe )
mes (pi , pj ) =
{p }
m(fpi i )
(3.7)
où m est la bande passante obtenue par un ux sur le chemin pi ou pj . Cette fonction dénit
donc le ratio entre la bande passante obtenue lors de tests indépendants et lors de tests
concomitants. Il faut noter ici un point important : dans le cas, par exemple, où pi et pj
sont des chemins de RTT très diérents, le ux de RTT le plus court obtiendra quasiment
toute la bande passante. Les auteurs dénissent donc une première relation binaire mes
qui est asymétrique. Le passage de la fonction à la relation se fait de manière classique par
un seuil s (établi à 0.7 par des méthodes empiriques).
(pi )
mes (pj ) = (
mes (pi , pj ) < s)
(3.8)
39
La relation d'interférence réelle est donc vraie quand l'une des deux interférences mesurées
est vraie. Cette nouvelle relation rl peut être écrite comme suit :
pi rl pj = ((pi )
mes (pj ) ∨ (pj )
mes (pi ))
(3.9)
A partir de cette relation, les auteurs sont en mesure de déduire quels ensembles de
noeuds sources partagent un chemin commun quel que soit le noeud de destination, en
faisant certaines assertions sur le comportement et la topologie du réseau. Nous reviendrons
plus en détail sur cette technique de reconstruction au chapitre 5. D'autres travaux portant
sur l'analyse de traces de ux TCP [45], où l'auteur, analysant les traces de ux TCP ayant
déjà été eectués, infère des classes de ux partageant le même sous-chemin commun étroit,
partagent une certaine philosophie commune au graphe d'interférence.
3.1.6.2 Reconstruction de topologies par disjonction de chemins
Certains types de reconstruction de topologies par disjonction ne permettent pas de
valuer les étiquettes des noeuds [113], [50]. Ces techniques sont le plus souvent basées
sur des notions similaires à celles des méthodes permettant de reconstruire des topologies
étiquetées par disjonction. Deux congurations peuvent empêcher l'étiquetage. Un premier
cas est que la valeur de la fonction d'évaluation n'a pas de sens pour l'utilisateur nal.
Une autre possibilité est que la métrique considérée ne permet pas de valuer la topologie
reconstruite ; nous reviendrons plus en détail sur ce problème en section 5. Un intéressant
exemple est celui de la bande passante disponible : dans [49], article posant les fondations
des Metric Inducted Network Topology (MINT), les auteurs considèrent la bande passante
disponible comme permettant de valuer la topologie reconstruite, au contraire de leur article
[50] écrit plus tard. La raison tient à la dénition de la bande passante disponible ; si l'on
considère que la bande passante disponible est celle disponible pour n'importe quel ux en
provenance de la source utilisée pour les mesures, alors on peut valuer les étiquettes des arcs
de la topologie reconstruite ; si par contre on considère la bande passante disponible comme
celle disponible pour n'importe quel ux, quelle que soit sa provenance alors, la mesure
depuis la source utilisée pour les mesures ne peut valuer les étiquettes de la topologie
reconstruite. Néanmoins, les points de disjonctions identiés par les mesures provenant
de cette source sont toujours identiables, et permettent donc une reconstruction d'une
topologie du réseau du point de vue de la source utilisée pour les mesures.
Dénition Comme discuté précédemment, la dénition de la fonction d'évaluation disj(Pprobe )
dans le cas où l'on n'étiquette pas les arcs est identique à celle du cas étiqueté, de même que
la dénition (Pprobe ). La diérence principale entre les 2 cas est que l'on n'a pas l'égalité
Pprobe
cL
). On en trouve des exemples dans [50], [113].
m = m(fL
Comme nous l'avons vu au travers de ce rapide état de l'art, les étiquettes produites
par les reconstructions dépendent de la métrique utilisée, ainsi que de la façon dont les
40
performances du réseau sont évaluées ; dans la section suivante, nous brossons un rapide
portrait des principales techniques utilisées pour estimer les capacités de liens de bout en
bout.
3.2
Découverte automatique des performances du réseau
L'évaluation des capacités d'un chemin vis-à-vis d'une métrique donnée est le socle
sur lequel reposent les techniques de reconstruction de topologies étiquetées sur les arcs
précédemment citées.
L'option la plus répandue dans le domaine est celle du monitoring point à point (endto-end performance monitoring ), essentiellement pour les protocoles de type TCP ; nous
ne traiterons ici que de celles ne nécessitant aucun accès spécique sur les équipements
réseaux mis en oeuvre le long de la liaison considérée. La notion la plus utilisée est la bande
passante disponible, qui admet plusieurs dénitions [83]. Dans la suite de ce document, nous
adopterons la dénition suivante comme celle de la bande passante disponible sur un lien
réseau i appartenant à un chemin p = {l0 , . . . , ln } de longueur n contenant n − 1 hops
(noeuds) :
i
i
(3.10)
(1 − uli )
clBw
= clbw
disp
i
est la capacité du lien li , et uli son taux d'utilisation (le paramètre temporel
où clbw
est ici ignoré). Notons que cette notion ne tient pas compte du protocole utilisé pour
i
consommer cette bande passante. Cela signie que clBw
ne sera pas égale à la bande
disp
passante utilisée par un ux TCP au comportement agressif tels que Scalable TCP [88] ou
encore HSCTP [83] (voir [53] pour une évaluation de divers protocoles) si il est créé sur
le lien i. De plus, des spécicités induites par un backbone high bandwith delay peuvent
i
rendre l'estimation de clBw
dicile voire fausse avec les méthodes classiques [115]. En
disp
eet, certaines techniques de déduction de mesures voient leur marge d'erreur grandir du
fait des propriétés spéciques d'un réseau de ce type. De plus, le choix d'eectuer des
mesures dites actives, passives ou d'utiliser une méthodologie qui soit à la fois active et
passive, peut inuer de manière importante sur la pertinence des données obtenues.
3.2.1 Techniques passives
Les mesures passives se basent sur les données obtenues lors du traçage des communications déjà eectuées sur une plate-forme ; cela est souvent utilisé pour les systèmes
de prédiction de performance tels que NWS, par le biais d'une historisation des données
obtenues. De telles techniques sont utilisées par exemple dans [45] ,[122], [109]. Le manque
de maîtrise des informations obtenues entraîne trois problèmes majeurs.
41
Premièrement, le traçage par une application ou une couche système sous-jacente a un
coût en terme de performances, variant suivant le grain de traçage eectué (par exemple,
traçer les varations de fenêtre de congestion d'un ux TCP peut être plus coûteux qu'estimer la bande passante obtenue par un transfert en cours en employant une méthode de
type BTC (BTC) (3.2.2.3). De plus, les informations recueillies lors du traçage d'un ux
peuvent être sans intéret vis-à-vis de la mesure de performance souhaitée, par exemple, si
les ux ne circulent pas le long de la liaison point à point désirée, si le ux n'est pas de la
même nature que le ux que l'application projette d'injecter (messages dispersés alors que
l'application a besoin d'évaluer le coût d'un transfert massif de données). Enn, l'absence
de ux circulant sur un lien rend impossible une quelconque évaluation des performances
de celui-ci.
3.2.2 Techniques actives
Si les capacités du réseau sous-jacent peuvent être connues d'une application s'exécutant sur une architecture de type cluster (l'architecture de la machine cible est souvent
connue dans ce cas) il n'en va pas de même pour un environnement de type grille, où
l'application est ordonnancée sur un ensemble de machines à priori inconnues, machines
qui sont elles-mêmes reliées entre elles par une topologie inconnue elle aussi. Dans le but de
connaître les caractéristiques de cette dernière topologie, il est donc nécessaire de dénir
des métriques applicables à une topologie générique, ainsi qu'à ses performances. Nous
i
i
, et de leurs liens avec la bande passante qui
traiterons essentiellement de clBw
et clbw
disp
peut être obtenue par un protocole de type TCP circulant sur le lien considéré. Diérentes
i
i
; une page Web [111] dresse
techniques existent pour tenter de déterminer clBw
et clbw
disp
une liste de plus d'une centaine d'outils de monitoring existants, et nous ne prétendrons
donc pas ici être exhaustif quant aux diérentes approches utilisées.
3.2.2.1 Dispersion de paquets
Les techniques de déduction de capacité et de bande passante à base de dispersion
de paquets ont fait l'objet de nombreuses études ces dernières années [65], [83], [64]. Ces
techniques visent à détecter les goulots d'étranglements le long d'un chemin p, qu'ils soient
dûs à un phénomène de congestion ou à une faible capacité de la liaison physique elle-même.
Le principe de base de ces méthodes est de mesurer la dispersion (i.e. le ∆) lors de la
réception de messages envoyés dos à dos. Dos à dos signie que l'écart entre l'envoi du
dernier bit du premier message et l'envoi du premier bit du deuxième message doit être
négligeable. Dans le cas de la découverte de la capacité d'une liaison, cette technique repose
sur le fait qu'un message de taille q transmis sur une liaison physique élémentaire i sera
transmise en un temps τ tel que :
42
τi =
q
(3.11)
i
clbw
Supposons un chemin p composé de 3 liens réseau p = (l1 , l2 , l3 ) de capacités respectives
3
2
1
2
reliant l'envoyeur et le destinataire de messages
< clbw
et clbw
< clbw
tels que clbw
dos à dos pour mesurer la capacité du chemin les reliant, et supposons ces liens libres (sans
trac interférent) et les hops (noeuds) le long de p ayant un délai de transmisssion nul (i.e.
les messages reçus sont retransmis sur la liaison physique suivante sans délai). Supposons
que lors de l'injection de 2 messages dos à dos sur le lien l1 de taille identique q , ces
messages arrivent dos à dos sur le lien l2 . La transmission du premier message m1 sur le
lien l2 prendra τ2m1 = Ll2 , avant d'être transmis sur le lien l3 en un temps τ3m1 qui sera
3
2
1
, clbw
, clbw
clbw
cbw
inférieur à τ2m1 et τ2m1 par hypothèse. Notons le début de la transmission de m1 t0 . Par
hypothèse m2 sera reçu et retransmis à la n de sa transmission sur le lien l2 à l'instant t1
tel que : t1 = t0 + τ2m2 ce qui donne la dénition de ∆ suivante :
∆ = t1 − t0 = τ2m2 =
L
2
clbw
(3.12)
La dispersion ainsi mesurée à l'arrivée des messages au destinataire entre la transmission
du premier bit de m1 et le premier bit de m2 est donc liée à la capacité de la liaison la
plus faible le long du chemin de transmission considéré. Ce résultat peut être étendu à un
chemin p de longueur n si aucun trac extérieur n'est présent [64]. On obtient :
∆p = max τi =
i=0...n
q
i
mini=0...n clbw
(3.13)
Par contre, ce n'est pas le cas lorsque la liaison point à point considérée rencontre un
autre trac. En introduisant d1i et d2i le délai induit par les queues des hops le long d'un
chemin p, d1i étant le temps d'attente en queue de m1 pour le hop i et d2i le délai en queue
de m2 après que m1 ait été transmis, on obtient :
(
∆i =
τi + d2i
si τi + d1i ≥ ∆i−1
∆i−1 + (d2i − d1i ) sinon
(3.14)
Dans certain cas (d1i < ∆i−1 et d2i − d1i < 0), ∆i décroitra, et ne sera plus lié à la liaison
physique de plus faible capacité. Le trac interférant est donc critique pour l'estimation
de la capacité d'un lien avec la technique de dispersion de paquet.
Un autre désavantage de cette technique est son inecacité sur les liens multi-channel
(les paquets émis peuvent être tranmis sur deux canaux indépendants sur le goulot d'étranglement), rendant impossible toute estimation. De plus, la technique de dispersion de paquet est aussi dépendante de la taille des paquets eux-mêmes. Des paquets de trop faible
taille peuvent provoquer un ∆ trop court pour être mesurable ; augmenter la taille des
43
paquets augmente la probabilité qu'un ux concurrent s'immisce entre les deux paquets et
fausse la mesure de ∆. De plus, de petits paquets induisent que le temps passé au traitement de ceux-ci augmente par rapport au temps de transfert des données. Le choix de q
est souvent fait de manière empirique, suivant la liaison considérée [64].
3.2.2.2 Techniques de trains de paquets
Pour pallier à ces problèmes, il existe une dérivée de cette technique, la technique des
trains de paquets (packet train ). Au lieu de n'envoyer que 2 paquets dos à dos, on envoie des
paquets successifs à des débits variants. Cette technique est utilisée par des outils répandus,
tels PathLoad [27] et PathRate [28] du projet BW-meter [6] basés sur l'algorithme SloPS
[82]. A partir des dispersions observées pour les trains, diérentes techniques déduisent la
bande passante disponible. Notons qu'il a été démontré dans [64] que la technique utilisée
dans cprobe ou pipechar en se basant sur l'assertion que la bande passante disponible est
inversement proportionnelle à la dispersion des paquets d'un train de paquets ne mesure
pas la bande passante disponible mais une autre métrique, dénommée ADR (Asymptotic
Dispersion Rate ) par ses auteurs.
Dans SloPS [83], l'hypothèse est que l'envoi de paquets à un débit supérieur à celui
atteignable entrainera un accroissement du ∆ entre les paquets. On fait donc varier le débit
d'envoi pour faire converger ∆, en injectant itérativement des trains de paquets. Notons
que la valeur obtenue par dichotomie dépend d'un facteur w intervalle de précision, qui ne
peut être choisi de bonne manière que par un ranement de l'utilisateur, sous peine de ne
jamais converger.
3.2.2.3
Bulk Transfer Capacity
La technique dite de Bulk Transfer Capacity (BTC) [119] consiste à réaliser l'envoi d'un
jeu de données de tests de manière à calculer la bande passante atteinte lors de cet envoi.
C'est une technique souvent utilisée par NWS ou SPAN. NWS envoie un premier paquet
pour déterminer la latence du transfert, puis calcule la bande passante atteinte de manière
simple après avoir eectué l'envoi par TCP de son jeu de données le long du chemin p :
cpBw
ef f ective
=
Q
T emps de transf ert − Latence
(3.15)
Où Q est la taille du jeu de données de test, T emps de transf ert le temps de transfert
observé et Latence la latence estimée grâce au premier envoi d'un paquet eectué. Notons
que cette estimation de la bande passante simple est celle qui est la plus souvent incluse
dans des systèmes d'information visant à fournir des prédictions de performances du réseau ;
de plus, le choix de la taille du jeu de données tests n'est pas anodin, les bandes passantes
atteintes par des transferts de petits volumes n'étant pas les mêmes que celles atteintes par
des transferts plus importants, par exemple si la pile TCP utilisée n'atteint pas la phase
d'évitement de congestion, ce qui peut souvent être le cas avec des réseaux hauts débits.
44
L'outil UDPMon [38] peut être utilisé de la même façon ; ce dernier utilise par contre des
ux UDP.
3.2.3 Techniques mixtes
Les techniques mixtes sont par exemple utilisées dans WREN et ont été plus récemment intégrées dans NWS. Elles consistent à utiliser à la fois des données provenant du
traçage d'une application, et, si besoin est, d'utiliser des techniques actives pour pallier
aux éventuels problèmes évoqués dans la section précédente ou raner certaines mesures.
Notons que cette approche est le plus souvent utilisée pour la prédiction de performance,
en utilisant des méthodes statistiques.
3.2.4 Intégration temporelle des mesures
Une fois les performances d'une topologie inférées à un instant t, il peut être nécessaire,
dans un système de prédiction de performances par exemple, d'inférer leur comportement
le long du temps. Ce type de travail, basé sur une méthodologie statistique, appelé lui aussi
tomographie réseau, consiste à estimer les caractéristiques statistiques d'un lien connaissant
la matrice de routage du réseau, ainsi qu'un vecteur de mesures de diérentes métriques à
un instant t. La problématique, dans ce cas, est classiquement formulée comme suit :
Yt = AXt + (3.16)
où Yt est un vecteur de mesure de la fonction disj(Pprobe ) à un instant t, A est la matrice de
routage un vecteur de bruit, et enn Xt un vecteur de paramètres dépendants du temps
inuant sur les mesures, tels que les taux de pertes, les délais induits par les liens, etc. La
matrice de routage est généralement une matrice binaire (dont les valeurs de chaque élément
sont soit 0, soit 1) qui donne la topologie du réseau considéré. La plupart du temps, une
telle formulation est utilisée pour retrouver Xt , qui représente donc les capacités des liens
existants du réseau vis-à-vis d'une métrique, ainsi que la fonction de densité de probabilité
correspondant aux valeurs de Xt tout au long du temps des mesures. Dans cette optique,
les algorithmes traitant ce problème sont fondés sur la maximisation de la valeur d'une
fonction de coût. En quelques mots, on omet le plus souvent et on considère alors que les
composants de X sont indépendants les uns des autres, et l'on considère le problème sur
l'intégralité des mesures eectuées au cours du temps :
Y = AX,
(3.17)
où Y est la matrice composée des diérentes mesures (i.e. des vecteur Yt de dimension J )
au cours du temps. X quant à lui contient un ensemble d'éléments Xj = gj (θj ) où gj est
une fonction de densité de probabilité de paramètre θj .
45
La plupart des algorithmes permettant de résoudre cette problématique sont basés
sur l'observation de la fonction de vraisemblance de cet ensemble de fonction de densité
de probabilité. A cause du coût énorme induit par l'estimation de la vraisemblance, et
plus encore du coût de la recherche du vecteur de paramètre pour lequel la fonction de
vraisemblance atteint un maximum, des méthodes moins coûteuses ont été développées.
Le plus souvent, on décompose ce problème général en un ensemble de sous-problèmes
plus simples, pour obtenir une approximation moins complexe à calculer. Par exemple, nous
donnons ici la méthode d'estimation du pseudo-likelihood que l'on pourrait traduire par
"pseudo-vraisemblance", qui est donc une approximation de la fonction de vraisemblance.
La décomposition du problème général se fait en découpant le problème général en un
ensemble de sous-problèmes Z en prenant chaque paire de lignes de la matrice de routage
A : Z = {s = (i1 , i2 ) : 1 ≤ i1 < i2 ≤ I} où I est la dimension de Y . Pour chaque
sous-problème s ∈ Z , le problème reste similaire : Y s = As X s , X s étant le vecteur de
paramètres impliqué dans le sous-problème s, c'est-à-dire les fonctions de densité de la
métrique considérée correspondant à chacun des liens des 2 chemins considérés, As étant
donc les deux lignes du problème s issus de la matrice de routage A et Y s = {Yi1 , Yi2 }
les mesures correspondant à s. Soit θs le vecteur paramètre de s, et p(Y s ; θs ) sa fonction
de vraisemblance marginale, c'est-à-dire la fonction de vraisemblance des valeurs de Y s
connaissant θ. En considérant les sous-problèmes comme indépendants (ce qu'ils ne sont pas
généralement) on peut écrire une fonction de pseudo-vraisemblance logarithmique comme :
p
L (y1 , . . . , yT ; θ) =
T X
X
ls (yts , θs )
(3.18)
t=1 s∈S
où ls = log ps (Y s , θs ). Cette fonction de coût est à la base d'algorithmes développés spéciquement pour maximiser sa valeur, et donc, retrouver la valeur de θ, ou plus précisément,
une estimation de celle-ci, appelée Maximum Pseudo Likelihood Estimate [59], [60] [58].
3.3
Synthèse
Dans cette section, nous donnons un résumé de ce chapitre introductif, de manière à
identier à la fois le contexte général dans lequel se positionnent mes travaux, ainsi que les
besoins et caractéristiques spéciques à ce contexte.
3.3.1 Existant
Comme nous l'avons vu, la plupart des travaux existants portent sur la reconstruction
de topologies étiquetées qui ont une structure arborescente, où une unique source transmet
46
des données vers de multiples destinations. Les grilles de calculs rendent de tels travaux
caducs, de par la nature même des transferts qu'elles impliquent, provenant de multiples
sources et de multiples destinations.
3.3.2 Besoins
Le relatif manque de travaux portant sur un paradigme multiples sources/ multiples
destinations, et dans le cas où de tels travaux existent, l'important socle d'hypothèses plus
ou moins réalistes et contraignantes sur lequel reposent ces travaux rend nécessaire les
travaux eectués dans le cadre de cette thèse.
47
Deuxième partie
TOMOGRAPHIE RÉSEAU MULTIPLES SOURCES,
MULTIPLES DESTINATIONS : MODÉLISATION,
RECONSTRUCTION ET RÉCUPÉRATION DU JEU
DE DONNÉES INITIAL
Modélisation des performances par une
topologie du réseau
La tomographie étant un problème inverse, les formulations de problèmes sont souvent
mal posées (au sens de Hadamard) et mal dénies. Une part importante du problème de la
tomographie est donc liée au modèle que l'on désire utiliser pour représenter les connaissances que l'on souhaite avoir du réseau. Il est en eet dicile de bien poser le problème.
Dans cette section, un rapide état de l'art des diérents modèles et des diérents problèmes
posés est fait, puis le modèle Metric Induced Network Poset (MINP) (Metric Induced Network Poset) est présenté. Ce modèle est reconstructible (comme nous le verrons dans la
section suivante) et permet d'obtenir une formulation du problème de la tomographie qui
est bien dénie.
4.1
Hypothèses et pré-requis sur les réseaux
Dénir une topologie des performances du réseau en vue de sa reconstruction est l'étape
initiale menant à la reconstruction de celle-ci. Or, pour mener à bien cette reconstruction,
il est le plus souvent nécessaire de bien poser le problème de manière à avoir une solution
unique et qui existe. Prouver l'unicité et l'existence d'une représentation du réseau dans
un modèle donné permet d'aboutir à un problème bien déni. Pour prouver ces propriétés,
la totalité des travaux imposent d'accepter certaines hypothèses sur le réseau, son comportement et sa topologie. Nous donnons ici une liste exhaustive des hypothèses utilisées
dans l'ensemble des travaux décrits dans cette thèse. Notons que l'ensemble des hypothèses nécessaires pour prouver que le problème est unique peut diérer de celui exigé
pour reconstruire la topologie.
Notons par ailleurs que tout l'intérêt de dénir de nouveaux modèles tient au fait de
réduire les hypothèses nécessaires à la dénition du problème ainsi qu'à la reconstruction.
En eet, certaines hypothèses peuvent être très fortes et rendre l'application des travaux
se basant sur celles-ci irréaliste.
Nous avons rangé les hypothèses en deux catégories :
Les hypothèses portant sur les propriétés de la métrique considérée. Cette première
catégorie d'hypothèses, si elle ne remet pas en cause la faisabilité de la mise en
49
Modélisation des performances par une topologie du réseau
oeuvre des solutions aux problèmes dénis, réduit de facto la portée de la résolution
de celui-ci. En eet, plus les hypothèses de ce type sont nombreuses, plus est réduit
le périmètre sur lequel les solutions à cette problématique s'appliquent.
Les hypothèses portant sur le routage et la topologie du réseau, qui, elles, réduisent
fortement l'applicabilité d'une solution à la problématique dans le cas réel. En eet, la
variété de comportement des réseaux actuels ne permet pas de présupposer facilement
de leur respect d'hypothèses, ni non plus de vérier la validité des hypothèses.
4.1.1 Propriétés des métriques
4.1.1.1 Constance
Dans la section 3.1.2.2 nous avons déni la constance d'une métrique. Cette propriété
est quasiment toujours nécessaire pour la reconstruction d'une topologie.
4.1.1.2 Monotonicité
Dénition Une métrique est monotone si tout sous-chemin d'un chemin est de capacité
inférieure ou égale (selon la relation associée à la métrique) à la capacité du chemin complet,
soit :
m
m est monotone ⇐⇒ ∀pi , pj tel que pi ⊆ pj ,
cm
(4.1)
pi ≤ cpj
Exemples La plupart des métriques usuelles sont monotones, par exemple le taux de
perte, le délai, le RTT, la bande passante atteignable en régime permanent par un ux
TCP depuis une source donnée. Pour toutes les métriques liées au temps (délai, RTT) il
est assez simple d'intuiter que la capacité d'un chemin complet est plus importante que
la capacité d'une portion de celui-ci. Le taux de perte a un comportement similaire. Dans
le cas de la bande passante atteignable depuis une source donnée, la valeur atteignable
étant la capacité la plus basse de l'ensemble des liens constituant un chemin, soit le souschemin considéré est de capacité égale à celle du chemin complet, soit sa capacité est
supérieure. La bande passante atteignable depuis une source donnée est donc bien une
métrique monotone.
4.1.1.3 Monotonicité étendue
Pour permettre une adaptation du modèle Metric Induced Network Topology (MINT)
au cas multiples sources multiples destinations, nous avons dû étendre la notion précédente,
ce qui a donné naissance à la monotonicité étendue.
Dénition Considérons l'ensemble Ps∗ d'ensembles de chemins Ps où chacun des Ps ad-
s
met un sous-chemin commun maximum non nul pPmaximum
. Soit ≤ la relation d'ordre
associée à la métrique m. On peut dénir la motonicité comme suit :
50
0
0
m est monotone étendue ⇐⇒ ∀Ps ∈ Ps∗ , ∀Ps tel que Ps ⊆ Ps , alors
0
m(f
Ps
P
0
s
pmaximum
) ≤ m(f PPss
pmaximum
)
(4.2)
Exemple Considérons à nouveau la métrique dénie comme la bande passante en régime permanent pour des ux TCP ; l'ordre associé à cette métrique est ≤. Comme tout
0
Ps
s
s
pmaximum
⊇ pPmaximum
, si pPmaximum
contient un lien de capacité plus basse que toutes les
0
0
Ps
s
s
valeurs des liens de pPmaximum
, alors le goulot d'étranglement pPmaximum
est égal à pmaximum
.
0
s
Sinon, cela veut dire que les ux passent par un lien dans pPmaximum
qui a un cpm plus petit
s
que la valeur minimum de pPmaximum
et ces ux auront une bande passante accumulée qui
Ps
sera inférieure à celle possible sur pmaximum . Donc, si la métrique m est la bande passante
de ux TCP en régime permanent, alors elle possède la propriété de monotonicité étendue.
4.1.1.4 Bornée
Pour permettre d'utiliser certaines propriétés des métriques pour la reconstruction
d'une représentation du réseau, nous avons dû formuler de nouvelles propriétés, ce qui
a donné naissance à la notion de métrique bornée.
Dénition Une métrique
m est bornée si la capacité de tout chemin est identique à
celle de son/ses sous-chemin(s) de capacité la plus petite/la plus grande selon la relation
associée à la métrique. Soit plus formellement :
m est bornée ⇐⇒ ∀p = (l1 , ..., ln ),
∃p0 ⊆ p, tel que ∀p00 ⊆ p
p0
p00
∀n > 0,
0
cm ≤ cm et cpm = cpm
(4.3)
Exemples Les métriques basées sur la bande passante (capacité, bande passante dispo-
nible, bande passante atteignable par un ux TCP en régime permanent) sont des métriques
bornées. En eet, la capacité d'un chemin dépend toujours de la capacité la plus basse disponible le long du chemin considéré, soit la capacité du bottleneck aussi appelé sous-chemin
commun étroit. Notons que si une métrique est bornée, elle doit être monotone et possède
la propriété de monotonicité étendue.
4.1.1.5 Borne induite par un lien unique
Pour permettre d'utiliser certaines propriétés des métriques pour la reconstruction
d'une représentation du réseau, nous avons dû formuler de nouvelles propriétés, ce qui
a donné naissance à la notion de métrique admettant une borne induite par un lien unique.
51
Dénition Une métrique m possède une borne induite par un lien unique si la capacité
de tout chemin est identique à celle d'un unique lien logique de capacité la plus petite/la
plus grande.
m admet une borne induite par un lien unique ⇐⇒ ∀p = (l1 , ..., ln )∀n > 0
0
∃!li ∈ p tel que ∀p0 ⊆ pclmi ≤ cpm et clmi = cpm
(4.4)
Exemples La capacité d'un chemin dépend toujours de la capacité la plus basse dispo-
nible le long du chemin considéré, soit la capacité du bottleneck aussi appelé sous-chemin
étroit. Dans le cas où plusieurs liens appartenant au chemin possèdent la même capacité, la
borne induite par un lien unique peut être considérée comme la première (dans l'ordre du
chemin considéré) ressource de plus basse capacité. Notons que si théoriquement il n'existe
pas à priori de métrique unique bornée dans les réseaux, cette notion est en pratique vraie
dans certains cas.
En eet, les ressources limitant une métrique bornée, sont, la plupart du temps, localisées sur des bottlenecks locaux, des sous-chemins communs étroits tels que les accès à
un MAN ou un WAN partagés par des chemins en provenance d'un même site. De plus,
l'existence de trac interférant (cross-trac) rend improbable que la bande passante allant
d'un site à un autre soit limitée par deux sous-chemins communs étroits situés chacun en
entrée (resp. sortie) de site.
La détermination du nombre de liens ayant un eet sur la capacité atteinte par un ux
a été traitée dans [118]. Le nom donné par les auteurs pour désigner le lien responsable de
l'unicité de la borne est "lien dominant pour la congestion" (dominant congested link ). De
manière à établir la présence d'un tel lien le long des chemins, les auteurs développent une
méthodologie basée sur les chaînes de Markov. L'idée générale est de déterminer grâce à la
distribution de tests injectés le long de ce chemin si celle-ci se rapproche de la distribution
que l'on pourrait observer si il existait un lien dominant pour la congestion ou non, en
utilisant le théorème de Bayes. Dans le cadre de ces travaux, les expériences menées sur
des réseaux réels et partagés semblent conrmer la croyance généralement établie qu'il
existe le plus souvent un lien dominant pour la congestion, renforçant l'hypothèse que
la capacité d'une métrique bornée basée sur la bande passante présente eectivement la
caractéristique d'avoir une borne induite par un lien unique.
4.1.1.6 Séparabilité
Dénition Une métrique m est séparable si pour tout chemin p composé de l'union de
m m
deux sous-chemins disjoints pi et pj , cm
pj = g(cp , cpi ) pour une certaine fonction g on a :
m m
m est séparable ⇐⇒ ∀p = pi ∪ pj , cm
pj = g(cp , cpi ) pour une fonction g
(4.5)
52
Exemples La propriété de séparabilité est plus rare : les métriques telles que le délai et
le taux de perte sont séparables. Par exemple, le délai le long d'un chemin étant la somme
m
m
des délais induits par les liens le composant, cm
pj = cp − cpi . Le raisonnement est similaire
pour le RTT si l'on considère que le routage et le délai de propagation sont symétriques. La
bande passante, elle, est un cas un peu plus spécique. Si l'on considère la bande passante
atteignable par n'importe quel ux dont la source est la racine du MINT, alors, on peut
m
m
m
m
dénir cm
pj par cp si cp < cpi , et dans le cas contraire, considérer que cpj est indétectable.
Si l'on considère la bande passante atteignable par n'importe quel ux, quelle que soit sa
source, elle ne possède pas la propriété de séparabilité telle que décrite précédemment.
4.1.1.7 Séparabilité étendue
Pour permettre une adapatation du modèle MINT au cas multiples sources multiples
destinations, nous avons dû étendre la notion précédente, ce qui a donné naissance à la
séparabilité étendue.
Dénition Considérons l'ensemble Ps∗ d'ensembles de chemins Ps où chacun des Ps adPs
. Soit les couples d'ensembles
met un sous-chemin commun maximum non nul pmaximum
0
s
Ps , Ps ⊂ Ps tels que Ps ∪ Ps = Ps , et leurs sous-chemins communs maximums pmaximum
0
00
0
P
00
00
s
et pPmaximum
. Une métrique m est séparable si il existe une fonction g telle que :
m est séparable étendue ⇐⇒ m(f PPss
pmaximum
0
) = g(m(f
00
Ps
0
Ps
pmaximum
0
), m(f
00
Ps
P
))
00
s
pmaximum
0
00
∀Ps , Ps ⊂ Ps tel que Ps ∪ Ps = Ps
(4.6)
Exemples Considérons à nouveau la métrique bande passante en régime permanent. La
s
bande passante atteinte sur pPmaximum
est la somme des bandes passantes atteintes par les
s
diérents ux circulant sur pPmaximum
. Nous avons donc m(fpPPss
0
) = m(f
maximum
00
m(f
Ps
P
00
s
pmaximum
Ps
P
0
)+
s
pmaximum
). Donc, si la métrique est la bande passante en régime permanent atteignable
par des ux TCP, alors elle possède la propriété de séparabilité étendue.
4.1.1.8 Symétrie
Dénition Une métrique est symétrique si la capacité d'un chemin vis-à-vis de la métrique considérée est constante suivant le sens de parcours de ce lien par les ux injectés
pour le détecter.
m
m symétrique ⇐⇒ ∀lij , cm
(4.7)
lij = clji
Exemple La bande passante disponible est un exemple de métrique non-symétrique dans
la plupart des réseaux : les liens en full-duplex seront parcourus par des tracs interférents
diérents suivant le sens de parcours de ce lien. Il en va de même pour la capacité maximale
53
en bande passante d'un lien : l'ADSL (ADSL) ou le câble, par exemple, ont des débits
asymétriques. L'asymétrie peut aussi provenir de la conguration par les administrateurs
des équipements réseau lors de leur déploiement.
Un exemple de métrique à priori symétrique est le délai dans le cas d'un réseau exempt
de tout trac interférent. Le délai sera en eet à priori le même suivant le sens de parcours
d'un chemin donné. Or, ce ne sera plus le cas dès que le routage ne sera plus symétrique,
i.e. dès que le chemin entre deux hôtes de a vers b sera diérent de celui de b vers a.
Un autre exemple de métrique à priori symétrique est le RTT. Le réseau doit être
exempt de tout trac interférent pour espérer avoir un même temps de parcours pour la
boucle pab ∪ pba et pba ∪ pab . De plus le temps de réponse à la requête (habituellement un
ping ) doit être similaire sur les deux hôtes pour avoir une valeur symétrique pour cette
mesure : cela induit que cette métrique est dépendante de la charge sur l'hôte cible du
ping.
4.1.1.9 k-détectabilité
Pour permettre d'utiliser certaines propriétés des chemins pour la reconstruction d'une
représentation du réseau, nous avons dû formuler de nouvelles propriétés, ce qui a donné
naissance à la notion de k-détectabilité.
Dénition La détectabilité telle que nous l'avons dénie en section 3.1.2 est une propriété
d'un (sous)-chemin p. p est détectable par rapport à une métrique m si il existe un sousensemble P de Pe2e tel qu'une mesure eectuée sur P peut faire s'exprimer la capacité de
p vis-à-vis de m.
Nous aurons besoin d'une dénition plus restrictive de la détectabilité dans les cas
pratiques, pour montrer les possibilités de reconstruire des représentations de performances
basées sur des mesures de bout en bout. Nous donnons donc ici une dénition de la kdétectabilité :
p est k-détectable vis-à-vis de m ⇐⇒ ∃P 0 ⊆ Pe2e ,
|P 0 | ≤ k tel que m(fpP ) = cpm
(4.8)
Exemple La gure 4.1 illustre cette notion. Les noeuds sources sont représentés par les
cercles blancs et les noeuds destinations par des cercles noirs ; nous ne considérons que les
chemins allant de a vers a0 , b vers b0 et ainsi de suite. Considérons que la métrique m soit
la bande passante atteignable en régime permanent par des ux de type TCP. Les valeurs
représentées sur les gures correspondent aux diérents cpm des diérents liens. Supposons
que nous utilisons une procédure de mesure dénie pour chaque P probe , où P probe ⊆ Pe2e ,
et |P probe | = k. On peut remarquer que les liens qui ont un cpm de 1 sont 1-détectables,
car ils représentent des goulots d'étranglements pour tous les ux les traversant. Le lien e
54
quant à lui est 2-détectable puisqu'il a un eet sur la bande passante atteinte par les ux
uniquement quand des ux circulent simultanément entre a et a0 et b et b0 . Enn, le lien
f est 4-détectable puisqu'il est nécessaire que tous les ux circulent simultanément sur les
4 chemins tracés pour que le lien e ait une inuence sur la bande passante atteinte par
ceux-ci.
C'est une notion importante, car des algorithmes pratiques ne peuvent se baser sur des
mesures impliquant tous les chemins de Pe2e .
a
b
1
1
c
d
1
1
1.5
e
f
1
a’
1
3
1
1
b’
c’
d’
Figure 4.1. Exemple de topologie simple
4.1.2 Propriétés du routage et de la topologie réseau
4.1.2.1 Consistance, stabilité et unicité
Dans la section 3.1.2.2 nous avons déni les propriétés du routage : consistance, stabilité
et unicité de chemin entre deux hôtes. Ces hypothèses sont quasiment toujours faites lors
de la modélisation du réseau.
La condition d'unicité, prise au sens de celle de l'existence d'un chemin unique pour
un paquet donné, peut être facilement considérée comme vraie. Elle peut être remise en
cause, dans certain cas, lorsqu'on la considère couplée avec l'hypothèse de stabilité. La
condition de stabilité signie que le routage dénit un chemin stable (et donc unique)
pendant la durée de l'expérience. Elle peut être mise à mal par des réseaux qui font de
l'équilibrage de charge par exemple. Il en va de même pour l'hypothèse de consistance.
L'hypothèse de consistance, c'est-à-dire le fait que deux chemins ne peuvent se joindre, se
séparer et se rejoindre ensuite est une hypothèse qu'il convient de discuter. Dans un système
55
autonome où les chemins de routage sont dénis comme étant les plus courts chemins (ceux
utilisant RIP [78] par exemple), elle reste par dénition correcte. Elle est souvent remise
en cause dans les réseaux qui font de l'équilibrage de charge (ceux utilisant OSPF [103]
par exemple). Cependant il convient de considérer le fait que, le plus souvent, les réseaux
de types grilles sont constitués de sites représentant une topologie arborescente, ce qui,
par dénition, fait que les communications circulant dans ce site respectent l'hypothèse
de consistance, sites reliés entre eux par des liens haut débit à priori indétectables. Les
fonction de routages permettant l'équilibrage de charge, sont, elles, souvent utilisées sur
des réseaux plus puissants, qui ne renferment pas par dénition de sous-chemins communs
détectables. On peut donc dire que d'une manière générale, l'hypothèse de consistance est
respectée sur les sous-chemins communs détectables, ce qui rend possible l'utilisation de
propriétés propres à des réseaux respectant cette hypothèse dans le cadre de nos travaux.
4.1.2.2 Symétrie
Dénition Le routage est symétrique si le chemin allant de n'importe quel hôte a vers
un hôte b est le chemin inverse de celui allant de b vers a, i.e. :
pab chemin inverse de pba ⇐⇒ ∀i ∈ (1, . . . , |pab |), li i-ème élément de pab
q j j-ème élément de pba s(l) = x ⇐⇒ l = lxy d(l) = y ⇐⇒ l = lxy
s(li ) = d(q (|pab |−i) ), d(li ) = s(q (|pab |−i) )
(4.9)
Cette propriété, simple, est bien souvent irréaliste. Elle est pourtant utilisée comme
nous le verrons par la suite dans beaucoup de travaux pour permettre une reconstruction
de topologie contenant de multiples sources et de multiples destinations.
4.2
Vue d'ensemble des modèles existants
La représentation du réseau est un problème aussi ancien que les réseaux informatiques
eux-mêmes. Les réseaux combinent en eet plusieurs caractéristiques : si un observateur
du réseau s'intérèsse au délai, un autre s'intérèssera plus à la bande passante, etc. Cela
rend un réseau impossible à représenter de manière unique et gée, puisqu'une topologie
dièrera suivant le point de vue que l'on considèrera.
Dans cette section, nous donnons un ensemble de modèles existants pour représenter
le réseau ainsi que le routage qui lui est associé.
56
4.2.1 Topologie physique et logique
4.2.1.1 Topologie physique
La topologie physique interconnectant un ensemble de sources S à un ensemble de
destinations R est un sous-ensemble de G, G0 (V 0 ∪ S ∪ R, E 0 ) tel que e ∈ E 0 ⇐⇒ ∃p ∈
Pe2e tel que e ∈ p et a ∈ V 0 ⇐⇒ ∃p ∈ Pe2e tel que lai ∈ p ou lia ∈ p, i étant un
sommet appartenant à V ∪ S ∪ R. Comme illustré par la gure 4.2, une telle topologie ne
représente pas l'intégralité des équipements et liens réseaux déployés, mais uniquement le
sous-ensemble impliqué dans la transmission des tests entre S et R. Ici S = {A, B, C},
R = {X, Y, W }. Les arcs pointillés représentent les chemins empruntés par des paquets à
destination de Y et W , les pleins les chemins empruntés par des paquets à destination de
X.
A
B
12121 1
1
12121 22
22
11 2
11 2
1
1
2
214321
14
3214
3214
0/650/0/ ""! 0/650/0/ ""! 65 432143243 6
4
434343 65 324
324
324
4
5
5
5
56
6
6
6
3
3
33
5
5
5
5
5
5
5
6
!
6
!
6
6
6
6
"
"
/
/
3
3
3
34433 656565 46
4
4
&%&%&% &%&%&% $#$#$# $#$#$# $#$#$# $#$#$# $#$#$# $#$#$# $#$#$# 6500/650/"!"! 6500/650/ "!"! 6565 44343 6
5
5
5
5
6
6
6
3
3
3
4
4
4
56
55 6
56
65.- 6
66
33 6
34
3
45.- 44
4
56
5
5
5
3.
3
3
4
4
& %&%&% &%&%&% $#$# $#$# $#$# $#$# ,+,+ $#$# ,+,+ $#$# ,+,+ $#$# ,+,+ 650/650/.-.- "!"!"! 650/065/.-.- "!"!"! 6565.-.- 434343 56
5 4434343 6565
6
3
3
4
4
.
3
3
3
4
4
4
+
+
+
+
,
,
,
,
.
!
.
!
.
.
.
" " -.
34
34
34
4
3 .-.-.- 4
3 4
3 4343 -.
(' (' (' (' (' *)*)*) *)*)*) *)*)*) *)*)*) *)*)*) .-.-.-.- !"!"!.-.-.-.- !"!"! .-.-.-.- 4343 .
.
.
--- .-.-- .-.-.- .-.-.- .-.-.- .
.
- ..- .- .- .- .
.
3
C
1
X
6
2
?@@
@?@?@?
?@
?
?
@
KL
KL
KL
L
L
L
LKLK
LKLKLK @? >>==>=
KK L
KL
K
KKL
KL
K
K
L
L
KK
KK
LLKKK
LL
LL
LL
K L
K L
K LKKLLK
A
Y
B
5
4
FE
OP
OP
OP
OP
P
OP
OP
OP
OP
O P
O P
O P
O POPOPO FEFE
3
Z
C
7
D
W
MN
N
NMNMNM
MN
MNMM
NNMNMMNNM DCDC
STS
QQQ R
QR
QR
QR
QR
QR
T
TSTSTS DC R
QR
QR
QR
QR
QR
QQQ R
QQQ R
QQQ XW R
QQQ XW R
QQQ XW RQRQRRQQQ XW
TTSS
R
SS TSS R
QR
TT
R
R
R
R
R
R
Q
TS
R
R
R
R
WW XX
WW RXX
WW R XXWW
U V
U V
U VU HGHGHG XX
VU TV
1
2
4
8787
[\\
[\
[
[
\[ \
\
[JI \
[[ \
[
[
\
\
[\
[\
\
\[\[[\ :
[[
[[
\
JIJI ^]
[
\ ^
\ ^
\ ^
]^
]^
]
]
]
]^
^] ^
^
^]^]^] 9:9
]] ^
]^
]
]
]
]
]^
^
^
^
^
]] ^
]
]
]
]
]
^
^
^
^
]^
]
]
]
]
]
^AB ^
^
^
^
^
]^
]^
]^
]^
]^
]^
^
]ZYZ
]ZYZ
]ZYZ
]ZYZYY ^
] ^
] ^]^]^]
ABAB ^]ZY
YY YY ^
YY
YYY ^
YYY ^
ZZ
ZZ
Z
Z
Z
Z
Z
Z
ZYZYZY
YZY
YZ
YZ
YZ
Z
Z
Z
Z
YY Z
Y
Y
YZ
Y
Y
ZY
Z
Z
ZYZYZY
YZ
YZ
YZ
Z
Z
Z
YY Z
YZ
Y
Y
Z
YZ
YZ
Y
Y
Z
Z
Y Z
Y Z
Y ZYZY <;<;
X
6
Y
5
Z
7
D
W
Figure 4.2. Liens entre la topologie réelle du réseau et la topologie physique
4.2.1.2 Topologie logique
La topologie logique G00 (V 00 ∪ S ∪ R, E 00 ) correspondant à une topologie physique est un
graphe formé à partir de G0 . Dans un premier temps, chaque noeud i de V 0 est remplacé
par une paire de noeuds (iin , iout ) reliée par un arc allant de iin à iout ; les arcs entrants de i
sont reliés à iin et ses arcs sortants à iout . Cette première phase permet de faire apparaître
un arc pour chacun des routeurs, switches, etc. déployés. Puis chacun des noeuds internes
avec seulement un parent et un enfant est confondu avec son père. La gure 4.3 illustre
une telle transformation pour l'exemple précédemment utilisé.
Ces topologies ne sont pas usitées pour représenter les connaissances induites grâce à
l'injection de tests dans un réseau ; en eet, de tels modèles ne sont constructibles qu'en
ayant connaissance des équipements réseaux déployés. Comme nous le verrons par la suite,
les modèles classiques permettant de reconstruire des topologies à partir de mesures eectuées de bout en bout sont quasiment tous basés sur une structure d'ordre, la plupart du
temps, un pré-ordre, i.e. l'arborescence. Quand la topologie présente une structure d'ordre,
celle-ci permet de reconstruire la solution. Or, les topologies physiques et logiques ne présentent pas une telle structure.
57
A
B
3
1
6
2
5
4
A
C
X
Y
B
1
"!
"!"!"!
"!
" !
" !
! "!"!
"
X
2
5
Y
3
C
W
W
Figure 4.3. Liens entre les topologies physiques et logiques
4.2.2 Topologies issues d'identication d'équipements le long de chemins
Ce modèle est celui utilisé lors de reconstruction de topologies à partir d'informations
recueillies par l'utilisation d'outils tels que traceroute [97]. Ce type de topologie est la seule
(à notre connaissance) qui puisse être reconstruite à partir de mesures de bout en bout et
qui ne présente pas d'autres structures d'ordre que les ordres totaux induits par les chemins
Pe2e . Cela peut être attribué au fait que cette reconstruction identie les noeuds du réseau
eux-mêmes et permet donc une reconstruction simple de sa topologie.
4.2.3 Graphe d'interférence
4.2.3.1 Dénition
Ce modèle est celui utilisé par l'outil AlNeM ([96]). La dénition de ce modèle est basée
sur la notion d'interférence entre chemins. A partir de l'ensemble des mesures entre deux
chemins pour la relation dénie dans la section 3.1.6.1, les auteurs tentent de résoudre
le problème suivant. Dans un premier temps, ils construisent une matrice d'interférence
Interf telle que :
(
Interf (S, R)(pi , pj ) =
1 si (pi )
rl (pj )
0 sinon
(4.10)
De ce postulat, les auteurs construisent en fait, quand cela est possible, une forêt
d'arbres remplissant cette condition. Ceci est rendu possible par l'utilisation d'une relation
d'interférence totale ⊥ pour la reconstruction elle-même qui peut être dénie comme suit :
a, b ∈ V, a ⊥ b ⇐⇒ ∀(u, v) ∈ R, pau rl pbv
(4.11)
Cette relation signie concrètement que tous les chemins partant de a ou de b vers n'importe
quelle destination appartenant à R sont en interférence. Cela permet aux auteurs de dénir
des points qu'ils nomment séparateurs qui peuvent être considérés comme des points de
conjonction de l'ensemble des chemins partant de a et b. Un séparateur q peut être déni
58
comme suit :
∀a, b ∈ Sa ⊥ b ⇐⇒ ∃q/∀z ∈ R : q ∈ (paz ∩ pbz )
(4.12)
La relation 4.11 étant une relation d'équivalence, elle leur permet de construire un
graphe représentant les diérentes classes d'équivalence qui peuvent être identiées, et de
les remplacer par leurs séparateurs respectifs. Ensuite, les auteurs itèrent en utilisant les
séparateurs comme des représentants des noeuds appartenant à une classe d'équivalence et
forment de nouvelles classes d'équivalence. Par construction, on obtient une forêt d'arbre.
Un traitement spécique quand on ne peut plus trouver d'interférence totale entre les diérents éléments, construit une clique entre les racines des diérentes arborescences trouvées,
donnant ainsi une structure hybride (en terme d'ordre).
Dans des travaux plus récents [67] les auteurs introduisent deux algorithmes de reconstruction. L'un, appelé IMPROVING, n'est pas à proprement parlé un algorithme de
reconstruction. En eet il nécesite d'avoir une première construction d'une topologie du
réseau, puis en fonction de mesures sur les chemins, corrige certaines routes en rajoutant
des liens plus directs entre les noeuds source et destination des chemins dont la capacité
a été mal estimée. Le second, appelé AGGREGATE, est dédié à la latence. En partant
d'un ensemble de noeuds connectés, il ajoute gloutonnement le noeud le plus proche, en
rajoutant un lien entre le noeud et le lien par lequel il peut être connecté en maximisant
le nombre de route entre les noeuds appartenant déjà au graphe et le noeud ajouté pour
lesquelles les routes introduites par l'adjonction de ce noeud sont susamment proches de
la réalité. Le principe de choix du lien à ajouter est donc proche d'un choix glouton d'un
séparateur convenant au noeud ajouté. La complexité en terme de nombre de mesures est
par contre grandement réduite par rapport au premier algorithme mais au détriment de
la métrique considéré (la latence et non plus l'interférence). En terme de modélisation,
la structure reconstruite n'est pas spéciquement dénie, mais se rapproche du graphe
minimal recherché par le premier algorithme présenté (voir section 4.2.3.2).
4.2.3.2 Problématique
Dénition La problématique posée par les auteurs peut être formulée comme suit :
b = (Vb ∪ R ∪ S, E)
b tel que :
trouver un graphe G
(
Gb
Interf (S, R)(
G
rl ) = Interf (S, R)(rl )
|Vb | est minimal.
(4.13)
b
G et où G
rl
rl représentent respectivement les interférences rl constatées pour les graphes
b . Le problème revient à essayer de retrouver un graphe de taille minimale présentant
G et G
les mêmes interférences que le graphe réseau réel.
Les auteurs prouvent dans [96] que ce problème est bien déni.
59
Hypothèses de dénition Les hypothèses de dénition utilisées sont la consistance, la
stabilité et la symétrie du routage. La métrique elle est non contrainte, ce qui est en partie
dû au fait que la topologie n'est pas étiquetée.
4.2.4 Topologie réseau induite par une métrique depuis une source vers
plusieurs destinations (MINT)
Ce modèle est utilisé par des outils tels que PERISCOPE ([56]). Le terme de MINT est
apparu et les notations et termes utilisés dénis formellement pour la première fois dans
[49]. Le terme de MINT est formellement déni dans le cas d'une source vers plusieurs
destinations, ou bien dans le cas d'une destination contactée par de multiples sources.
De manière informelle, une topologie réseau induite par une métrique représente un sousgraphe de la topologie logique représentant l'ensemble des liens (ou les ensembles de liens)
détectables.
4.2.4.1 Dénition
Une topologie induite par une métrique (Metric Induced Network Topology, MINT)
pour une valeur s de son paramètre de sensibilité et pour une métrique m est la topologie
étiquetée formée quand tous les noeuds internes i d'une topologie logique dont le lien parent
lxi est étiqueté par une valeur cm
lxi ≤ s ont été confondus avec x.
La gure 4.4 représente un ensemble de topologies pour la métrique du taux de pertes de
paquets. La topologie (a) est la topologie physique du sous-réseau considéré. La topologie
(b) représente la MINT correspondante à ce réseau quand le paramètre de sensibilité est
xé à zéro ; enn, la topologie (c) représente la MINT induite pour le même réseau, mais
cette fois avec un paramètre de sensibilité xé à 0.005.
s0
(a)
s0
s0
(b)
(c)
dr
Figure 4.4. Eet du paramètre de sensibilité sur un MINT
60
Cette illustration nous montre que la structure d'une topologie induite par une métrique
dépend non seulement de la métrique considérée, mais aussi fortement du paramètre de
sensibilité choisi. Le choix de la valeur de ce paramètre de sensibilité reste un compromis :
plus sa valeur est haute, plus les éventuels non regroupements de liens sous un père commun
dûs à la marge d'erreur de la mesure sont rares ; néanmoins, augmenter trop la valeur de
ce paramètre fait courir le risque de regrouper sous un même père des noeuds ayant en fait
2 pères distincts.
La problématique de la reconstruction d'une topologie induite par une métrique peut
être énoncée comme suit. Etant donné une technique de mesure permettant d'évaluer
m
m
disj({pi , pj }) et cm
pour une métrique m donnée pour tout chemin partant
pi , cpj et c {pi ,pj }
pmaximum
d'une source unique s0 et allant vers deux destinations a et b ∈ R, reconstruire la topologie
MINT correspondant au réseau entre s0 et R.
Cette problématique est assez trivialement bien dénie, de par la construction de celleci. La solution existe et est unique.
4.2.4.3 Hypothèses de dénition
Cette dénition de problématique portant sur la reconstruction d'une topologie étiquetée, la métrique est plus contrainte que dans le cas précédent : elle doit être monotone et
séparable. Le routage, quant à lui, doit être consistant et stable. Dans le cas où la topologie
n'est pas étiquetée, la métrique doit uniquement être monotone.
4.2.5 Topologie par recoupement d'arborescences
Les MINT précédemment dénis n'ont plus de dénitions valides lors du passage d'une
seule source à de multiples sources. De manière à faire évoluer le modèle MINT, plusieurs travaux ont donné lieu à une modélisation de topologies multiples sources, multiples
destinations construites à partir de concaténations d'arborescences MINT précédemment
construites.
4.2.5.1 Recoupement de MINT de même racine
Il est plus que fréquent que des MINT induites à diérents instants ne correspondent
pas entre elles ; les auteurs de [50] introduisent une méthode, proche de celle utilisée lors
du recoupement d'arbres multicast, pour reconstruire une vue unique du réseau sousjacent. L'idée principale est qu'un noeud détecté est à priori valide ; seules les conditions
du réseau font que les disjonctions de chemins deviennent détectables. Les auteurs se
basent donc sur la couverture des noeuds feuilles par un noeud interne pour recouper les
diérentes arborescences trouvées. En eet, si le routage est consistant, alors la couverture
des diérents noeuds présents dans l'arborescence doit être similaire. La problématique est
61
similaire à celle des MINT, et est donc bien dénie.
4.2.5.2 Recoupement de MINT de racines diérentes
Dénition Dans [107] les auteurs introduisent ce qui, à ma connaissance, est la première
tentative de reconstruction de topologie contenant de multiples sources et de multiples
destinations. Leur méthode est basée sur la relation dénie en section 3.1.5.3, à savoir la
relation I(Pprobe ). Cette relation permet d'identier, entre deux arbres, quels sont les liens
partagés les uns par les autres. Le modèle reconstruit est donc une forme de concaténation
d'arbre : chaque lien est identié comme partageant un sous-chemin commun avec celui
d'un autre arbre. C'est le principal problème de cette modélisation : l'identication de liens
en provenance de diérents arbres n'est pas transitive.
En eet, comme on le voit à la gure 4.5 la relation "avoir un sous-chemin commun"
n'est pas transitive. En eet, le fait qu'un chemin paa0 ait un sous-chemin commun avec
un chemin pbb0 , de même que pbb0 avec un chemin pcc0 n'implique pas que paa0 ait un souschemin commun avec pcc0 . De plus, même si paa0 a un sous-chemin commun avec pcc0 , cela
n'implique pas qu'il existe un sous-chemin commun à paa0 , pbb0 et pcc0 . Cela implique que
les points de rencontre entre les arborescences ne sont dénis formellement que pour une
paire d'arbres, empêchant toute exploitation utile de cette connaissance.
Problématique La problématique que vise à résoudre les auteurs dans [107] n'est pas
explicite ; si l'on considère que la problématique est celle d'apparier les arbres deux à
deux, le problème est trivialement bien déni. De même, si l'on considère que l'on souhaite
reconstruire un graphe réprésentant les points de conjonctions et de disjonctions qui sont
ceux du graphe logique, on peut considérer, au vu de la gure 4.5, que le problème est
mal déni, puisqu'il existe plusieurs représentations et congurations correspondant aux
informations que l'on peut retirer de la relation I(Pprobe ).
a
b
a
c
u
b
c
u
w
w
v
c’
a’
b’
a’
c’ b’
Figure 4.5. Non transitivité de l'identication
Hypothèses de dénition Dans le cas où le problème est celui de l'établissement de
relations entre toutes les paires d'arbres, alors les hypothèses de dénition sont identiques
à celles de la reconstruction d'un seul MINT. Dans le cas contraire, le problème est mal
déni.
62
4.2.5.3 Recoupement de MINT de racines diérentes dans le cas symétrique
Dénition Par cas symétrique, nous entendons que le routage est symétrique, i.e. que
le chemin emprunté d'une source a vers une destination b contient exactement les mêmes
noeuds que le chemin emprunté depuis b vers a, mais aussi que la métrique est symétrique.
Les auteurs de [50] donnent un algorithme permettant la reconstruction d'une représentation de la concaténation des diérentes arborescences MINT obtenues depuis chacun
des noeuds considérés. Chaque noeud i, tour à tour joue le rôle du serveur, et une MINT
enracinée par ce noeud ayant un ensemble de feuilles R \ {i} est reconstruite. Puis la symétrie permet une identication des noeuds en se basant sur les points de conjonction et
de disjonction de chaque chemin.
Problématique L'identication des points de disjonction et de conjonction laisse tri-
vialement apparaitre un problème qui est bien déni. Les auteurs se basent sur la couverture des points inférés lors des diérentes constructions d'arbres pour reconstruire une
vue unique et consistante du réseau. Cette méthode n'est valide que par le fait que les
hypothèses de symétrie, sur le routage mais aussi sur la métrique, sont respectées. Ces
hypothèses sont fortes, voire totalement irréalistes dans le cas de la bande passante.
Hypothèses de dénition Les contraintes pour avoir une représentation unique sont
particulièrement nombreuses, puisqu'elles regroupent les hypothèses de dénition traditionnelles des MINT (consistance, stabilité du routage, monotonicité et séparabilité de la
métrique) plus de nouvelles (symétrie de la mesure et du routage).
4.3
Nouveaux modèles pour le cas multiples sources, multiples destinations
Comme nous l'avons vu dans les exemples précédents, les diérents modèles existants
pour le cas multiples sources, multiples destinations, jusqu'à présent, soit :
reposent sur des assertions relativement fortes sur le réseau, son comportement, voire
sa topologie physique (comme les dénitions reposant sur la symétrie du routage par
exemple),
ne sont pas vraiment spéciés de manière à traduire le comportement du réseau
(comme les dénitions basées sur l'identication de sous-chemins communs).
Nous avons donc développé de nouveaux modèles pour caractériser le comportement du
réseau et sa topologie pour le cas multiples sources, multiples destinations permettant de
réduire le nombre d'hypothèses initiales nécessaires. Dans un premier temps, nous avons
63
élargi les notions propres au MINT pour qu'elles puissent traduire le comportement du
réseau en présence de multiples sources. Nous appelons ce nouveau modèle Multiple Source
Multiple Destination MINT (Multiple Source Multiple Destination Metric Induced Network Topology (MSMDMINT)). Malheureusement, comme nous le verrons en section 4.3.1,
l'extension naturelle de la notion de MINT pour ce cas-ci ne permet pas d'exhiber une problématique bien dénie, car la représentation d'un réseau n'est pas unique. Nous avons donc
déni un modèle plus pratique, le système partiellement ordonné induit par une métrique
ou Metric Induced Network Poset (MINP), qui est, lui, bien déni (voir section 4.3.2). C'est
pour reconstruire des topologies de ce type que nous avons développé les algorithmes de
reconstruction décrits en section 5 ainsi que les méthodes de mesure décrites au chapitre
6.
4.3.1 Topologie réseau induite par une métrique depuis plusieurs sources
vers plusieurs destinations (MSMDMINT)
4.3.1.1 Dénition par construction
Topologie induite par une métrique Une topologie induite par une métrique m
avec un paramètre de sensibilité s est une topologie étiquetée sur les arcs formée à partir
de G00 (c'est-à-dire la topologie logique). Elle peut être construite en 2 étapes : après avoir
établi si la capacité d'un chemin est détectable, on réduit le graphe en supprimant les
sous-chemins ne l'étant pas.
1. Etablissement de la détectabilité : On dénit une application G(p, psub ) qui fait
correspondre à chaque chemin p ayant un sous-chemin psub un nouveau chemin p0 . p0
est obtenu en supprimant psub dans p. On supprime le sous-chemin en confondant le
noeud de départ de psub et son noeud destination en un seul et même point.
On dénit l'application H(Pi , psub ) faisant correspondre à tout sous-ensemble Pi de
Pe2e un ensemble de chemins constitué de toutes les images des p ∈ Pi par l'application G(p, psub ).
On dénit l'application I(pi ) qui fait correspondre à chaque pi ∈ M axPe2e l'ensemble
Ps dont les éléments sont les ensembles de chemins appartenant à Pe2e admettant pi
comme sous-chemin commun maximum.
Pour chaque pmax ∈ M axPe2e on établit si :
H(P ,p
i max
∃Pi ∈ I(pmax ), pj ∈ Pi tel que m(fpPji ) 6= m(fG(pj ,p
) ± s (1)
max )
)
Cela revient à vérier si il existe parmi toutes les diérentes possibilités d'injections
concomitantes de tests une conguration où le chemin pmax inue sur les mesures,
et possède donc une capacité détectable.
Si la métrique est constante, alors on peut déterminer la valeur de l'étiquette à
appliquer sur le sous-chemin considéré. En eet, cela signie que quels que soient les
64
Pi et leurs éléments pj satisfaisant la condition (1), les valeurs déduites pour cpmmax
seront similaires. L'étiquette pourra donc être par exemple la moyenne des valeurs
trouvées.
Si la condition n'est pas respectée, cela signie que la capacité des liens de ce pmax
est indétectable.
2. Réduction du graphe : On dénit une application G 0 (p, Psub ) qui fait correspondre
à chaque chemin p ayant un ensemble de sous-chemins Psub un nouveau chemin p0 .
p0 est obtenu en supprimant tous les arcs n'appartenant à aucun élément de Psub
dans p. On supprime ces sous-chemins en confondant leurs noeuds de départ et de
destination respectifs en un seul et même point. Cela revient à supprimer tous les
liens propres à p vis-à-vis de ses sous-chemins appartenant à Psub .
De même, on dénit une application H0 (Pi , Psub ) faisant correspondre à tout sousensemble Pi de Pe2e un ensemble de chemins constitué de toutes les images des p ∈ Pi
par l'application G 0 (p, Psub ).
On classe tout d'abord les pmax ∈ M axPe2e par cardinalité croissante. Ainsi les souschemins communs maximum les plus courts seront considérés en premier.
Puis on procède comme suit pour chaque pmax :
Si la capacité du pmax considéré est détectable, alors on étiquette par la valeur
détectée un de ses liens propres vis-à-vis de l'ensemble des liens déjà étiquetés
contenus par ce pmax .
Si la capacité pmax est indétectable, alors on remplace les éléments de l'ensemble
I(pmax ) par leurs images par H0 (Pi , Psub ), où Psub est l'ensemble des sous-chemins
détectés de pmax . Notons que si de tels chemins existent, ils ont déjà été étiquetés,
puisque nous traitons les pmax par cardinalité croissante.
La gure 4.6 donne un exemple de ce type de changement pour l'exemple précédent
si la métrique est le délai et s = 1ms.
A
3ms
1
4ms
B
3ms
Oms 3
C
4ms
0ms
2
4ms
4ms
5
4ms
A
X
2ms
Y
B
4ms
4ms
3ms
4ms
2
4ms
5
4ms
X
2ms
Y
3ms
2ms
2ms
C
2ms
2ms
W
W
Figure 4.6. Liens entre une topologie logique et une topologie induite par une métrique
65
Comme nous l'avons évoqué précédemment, l'extension intuitive du problème de la
reconstruction d'un MINT au cas multiples sources, multiples destinations ne permet pas
de dénir un problème bien déni. En eet, la représentation des eets des capacités et de
la topologie physique d'un réseau vis-à-vis d'une métrique donnée en posant uniquement
les conditions établies précédemment n'est pas unique. Cela tient au fait de la nécessité de
choisir un lien à étiqueter parmi ceux représentant le sous-chemin commun lors de la phase
de réduction du graphe décrite en section 4.3.1.1. Une illustration pratique et simple de
deux modèles MSMDMINT correspondant au même réseau est donnée à la gure 4.7 (1).
De manière à avoir une problématique plus aisée à résoudre, bien dénie, nous avons dû
dénir un nouveau modèle du réseau, le MINP, que nous présentons à la section suivante.
4.3.2 Système partiellement ordonné induit par une métrique (MINP)
4.3.2.1 Dénition
Un MINP (Metric Induced Network Poset ) est un système partiellement ordonné M m =
(N, ) formé à partir de l'ensemble M axPe2e .
N est déni par la relation ∀i ∈ M axPe2e , i détectable pour la métrique m ⇐⇒ i ∈
N,
≺ est déni par la relation ∀i, j ∈ N, i ⊂ j ⇐⇒ j ≺ i,
Chaque élément de p ∈ N est étiqueté par sa capacité cpm .
Pour des raisons pratiques, nous pouvons ajouter un noeud de jointure supérieur ainsi
qu'un noeud de jointure inférieur au système partiellement ordonné. Le noeud de jointure
supérieur (le supremum) est un élément de N que nous noterons Ω qui est un chemin
détectable de longueur 0 et qui est lié aux autres éléments de N par la relation ∀i ∈
N
Ω ≺ i. Si l'on considère la métrique de la bande passante atteignable en régime
permanent pour un ux TCP, l'étiquette de ce chemin pourrait être cΩ
m = ∞. De par la
dénition d'un MINP, le système partiellement ordonné obtenu par l'ajout du noeud Ω
et des relations qui le lient aux éléments de N est un demi-treillis supérieur, puisque ce
nouveau noeud représente un sous-ensemble de toutes les partitions de chaque chemin de
M axPe2e en sous-chemins. Nous ne représentons habituellement pas ce noeud.
De même, nous pouvons ajouter un inmum p∞ pour obtenir une structure de treillis
complet, structure plus simple à représenter et à utiliser qu'un simple système partiellement
ordonné. Cette borne inférieure peut être dénie comme l'ensemble E contenant tous les
liens réseaux. Nous ne représentons habituellement pas ce noeud.
Pour résumer, le modèle MINP ne représente plus vraiment la topologie physique, mais
les relations entre les diérents chemins du réseau. Les noeuds représentent les chemins
et sous-chemins communs détectables pour tous les sous-chemins de Pe2e et les relations
66
représentent les relations d'inclusion pour l'ensemble de ces chemins et sous-chemins.
Représentation De manière classique, nous utilisons une représentation sous forme de
diagramme de Hasse pour représenter un MINP. Nous représentons le système partiellement ordonné via la relation de couverture du MINP en utilisant une orientation implicite
vers le haut. Dans un diagramme de Hasse, chacun des éléments de N est représenté par un
point, et des arcs sont dessinés entre deux points si les conditions suivantes sont respectées :
si x ≺ y dans le système partiellement ordonné, alors le point correspondant à x doit
apparaître plus bas dans le diagramme que celui réprésentant y .
L'arc entre deux éléments x et y du système partiellement ordonné est dessiné si et
seulement si x couvre y ou y couvre x.
Nous représentons donc les éléments de Pe2e en bas du diagramme, et si l'on désire le
représenter, plus bas encore, l'inmum p∞ ; quand il est représenté, le noeud Ω est le point
le plus haut du diagramme.
Quelques exemples A des ns didactiques, nous donnons ici quelques topologies et
leurs représentations en tant que MINP. Dans la gure 4.7, les cercles blancs représentent
des noeuds sources et les noirs, des noeuds destinations. Les carrés sont des routeurs ou
des équipements physiques qui sont des points de conjonction ou de disjonction pour les
0
0
chemins de Pe2e . Les paramètres cem , cem , cfm , cfm , cgm , chm et cim sont les étiquettes des arêtes
correspondantes. Les lignes pointillées représentent les chemins de Pe2e pris par les ux
entre les noeuds sources et les noeuds destinations. Nous considérons que l'organisation
logique des transferts ne permet que les communications de a vers a0 , b vers b0 et c vers
c0 . Comme nous nous intéressons plus spéciquement dans cette thèse à la bande passante
atteignable en régime permanent par des ux de type TCP, nous considérerons ici cette
métrique.
MINP et bande passante disponible La gure 4.7 (1) représente deux topologies
contenant chacune 3 sources et 3 destinations. Nous considérerons ici que tous les liens
autres que e et f ont une capacité plus grande que ceux-ci et sont donc indétectables.
Ces topologies vont avoir un impact similaire sur les performances des communications si
0
0
ceBandwidth = ceBandwidth et cfBandwidth = cfBandwidth . Ceci est dû au fait que les chemins paa0
et pbb0 vont partager dans les deux cas un lien commun étroit de capacité ceBandwidth et que
le lien étroit commun à tous les chemins (f ou f 0 ) a une capacité de cfBandwidth dans les
deux cas.
Les deux MINP possibles représentés sur la droite de la gure correspondent à deux
relations diérentes entre les valeurs de ceBandwidth et cfBandwidth . Le MINP sur la gauche
représente le cas où ceBandwidth < cfBandwidth . Le noeud le plus haut représente le souschemin f , celui du milieu le sous-chemin commun formé par e et f , et les noeuds les plus
67
a
b
e
(1)
a’
c
a
f
c
c’
a’
f
f’
e’
b’
a
b
b’
e
c’
a−>a’
b−>b’ c−>c’
u
w
a−>a’
b−>b’ c−>c’
b
c
u
(2)
v
w
u
w
v
c’
f
a’
b’
a−>a’
b−>b’
c−>c’
a−>a’
b−>b’
u
c−>c’
a−>a’
b−>b’ c−>c’
Figure 4.7. Quelques topologies simples et leurs représentations en tant que Metric Induced Network Poset (MINP)
bas représentent respectivement de gauche à droite les chemins paa0 , pbb0 et pcc0 . Le MINP
sur la droite représente le cas où ceBandwidth ≥ cfBandwidth . Dans un tel cas, le sous-chemin
e n'est pas détectable puisque aucun sous-ensemble de Pe2e ne peut saturer ce lien par
l'injection simultanée de ux/tests/mesures sur ces chemins. La diérence entre ces deux
possibles sous-cas peut dans des cas réels être causée par le trac interférent, quand on
considère la bande passante atteignable par un ux de type TCP en régime permanent. Si
nous considérons que la bande passante physique du cable e est une constante, le premier
cas correspond au fait que le trac interférent fait baisser la bande passante disponible sur
le chemin e au point que la capacité de celui-ci devient détectable. Cet exemple permet
d'illustrer une caractéristique d'un MINP : un MINP ne dépend pas uniquement de la
topologie du réseau, des chemins inclus dans Pe2e et de leurs capacités, mais aussi du trac
interférent.
La gure 4.7 (2) représente une situation intéressante : chaque paire de ux partage
un lien commun étroit, mais il n'existe aucun chemin commun étroit partagé par tous les
ux. Cela signie qu'une représentation de type arborescente ne peut être susante pour
cette topologie réseau. Si u, v et w sont des liens étroits avec des capacités similaires (cum =
cvm = cw
m ), alors le MINP correspondant à ce cas est celui immédiatement sur la gauche, car
chaque lien étroit est détectable. Le MINP central représente le même réseau pour cvm > cw
m
u
w
et cm = cm . Dans un tel cas, aucune injection de ux ne va permettre de saturer le lien v ,
68
et nous avons donc uniquement deux sous-chemins communs détectables. Enn, le MINP
v
w
u
de droite représente le cas où cvm et cw
m ne sont pas détectables, car cm > cm > cm par
exemple.
Dénition Nous dénissons le problème de reconstruction d'un MINP de la manière la
plus simple qui soit : reconstruire un MINP représentant le comportement du réseau à un
instant t, étant donné des mesures sur Pe2e .
Ce problème précédemment posé est bien déni si :
1. La solution existe
2. Elle est unique
Prouver que le problème est bien déni revient donc simplement à prouver que la représentation d'un réseau existe et est unique, quel que soit le réseau cible. Le plus simple
est de partir du réseau cible et de reconstruire le MINP représentant ses propriétés. Nous
donnons donc ici les preuves de l'existence d'une telle représentation, ainsi que celle de son
unicité, sous des hypothèses relativement faibles vis-à-vis du comportement du réseau ou
des propriétés de la métrique considérée.
Existence Une représentation MINP d'un réseau peut toujours être reconstruite à partir
d'un réseau, sous certaines conditions. Les chemins doivent être stables pour pouvoir être
décomposés en sous-chemins détectables. Ces derniers ne pourront être étiquetés que si
la métrique est constante. Sinon, la décomposition en sous-ensembles de liens n'est bien
sûr pas faisable. Les auteurs de [54] assurent que les chemins traversant Internet sont
hautement stables. Si nous considérons que le réseau Internet a des propriétés similaires
à celles de notre réseau cible, cela implique que les chemins qui le traversent sont assez
stables. Sous ces conditions, on peut conclure à l'existence d'un MINP pour un réseau
quelconque.
Considérons le réseau cible comme un graphe orienté V (G, E) muni d'une fonction de
routage associée dénissant des chemins stables. La fonction de routage est donc un mapping
entre l'ensemble des chemins de bout en bout Pe2e et les ensembles de liens consécutifs de
E . Chaque image de chaque élément de Pe2e par la fonction de routage dans E peut
être décomposée en sous-ensembles de liens adjacents. De tels ensembles d'éléments de E
sont soit détectables, soit ils ne le sont pas. Les ensembles détectables qui appartiennent à
l'ensemble M axPe2e sont par dénition contenus dans l'ensemble des parties de l'ensemble
E (i.e. le power set de E noté P owerSet(E)). L'ensemble des parties de l'ensemble E existe
suivant l'axiome de l'ensemble des parties. Puisqu'un tel ensemble existe, les éléments qu'il
contient aussi. Le système partiellement ordonné formé par dénition de l'ensemble des
parties de l'ensemble P owerSet(E) et la relation ⊂ est un treillis, où l'ensemble vide est
69
le suprémum et l'inmum l'ensemble E . Le sous-ensemble de P owerSet(E) ne contenant
que les sous-chemins détectables inclus dans M axPe2e plus l'ensemble vide et l'ensemble E
lui même, muni de la relation ⊂ est, par dénition, un MINP.
Unicité Comme nous l'avons mentionné précédemment, des MINP diérents peuvent
être reconstruits pour le même réseau, suivant la nature du trac interférent circulant sur
le réseau cible. Donc, dire qu'il existe un unique MINP pour un réseau donné muni d'une
fonction de routage générant des chemins stables sur celui-ci n'est une assertion viable que
si les conditions réseau (i.e. le trac interférent) ne changent pas signicativement durant
la période où des ux sont injectés pour permettre une reconstruction.
Puisque le trac interférent change peu, la détectabilité est une propriété qui dénit une
injection depuis l'ensemble P owerSet(E) vers l'ensemble des chemins détectables. Donc,
puisque la dénition d'un MINP est basée sur une injection de M axPe2e vers l'ensemble
N d'un MINP et d'une injection depuis l'ensemble des relations ⊂ vers ≺, un MINP est
unique pour un M axPe2e et une relation ⊂ donnée. Pour prouver qu'un MINP est unique
pour un réseau donné, il faut prouver l'unicité de l'ensemble M axPe2e et de l'ensemble des
relations ⊂ pour tout réseau G(V, E) et sa fonction de routage associée produisant des
chemins stables. Puisque M axPe2e contient par dénition tous les sous-chemins communs
maximum pour l'ensemble Pe2e on ne peut trouver deux M axPe2e diérents pour un Pe2e
donné. Puisque les chemins de routage sont supposés être stables, il existe un unique Pe2e
pour un G(V, E) donné et une fonction de routage associée générant des chemins stables.
Puisque la relation ⊂ ne depend pas de l'état du réseau, mais des propriétés des ensembles,
il existe donc un unique MINP pour un réseau cible donné.
4.3.2.3 k-MINP
Prenons maintenant le cas où l'on recherche des chemins et sous-chemins k-détectables.
Un point intéressant est que la détectabilité reste toujours une injection depuis l'ensemble
des éléments de P owerSet(E) vers l'ensemble des chemins et sous-chemins. En appliquant
le même raisonnement que précédemment, on peut ainsi prouver que la reconstruction
d'un MINP ne représentant que les chemins k-détectables est toujours un problème bien
déni. On peut donc aisément donner la dénition d'un k-Metric Induced Network Poset
(k-MINP) comme étant la représentation MINP d'un réseau en reprenant la dénition
donnée plus haut et en changeant la détectabilité par la k-détectabilité :
Dénition Un k-MINP (k - Metric Induced Network Poset) est un système partiellement
ordonné M m = (N, ) formé à partir de l'ensemble M axPe2e .
N est déni par la relation ∀i ∈ M axPe2e , i k-détectable pour la métrique m ⇐⇒
i ∈ N,
70
Chaque élément de p ∈ N est étiqueté par sa capacité cpm .
Le MINP peut être considéré comme un k-MINP où k = |Pe2e |.
4.3.2.4
∞-MINP
De même, il pourra être utile comme nous le verrons dans le chapitre 5 consacré à
la reconstruction de MINP d'avoir une représentation en MINP de la vue logique d'un
réseau. Dans ce cas-là, on considèrera tout lien logique comme détectable et l'on parlera
∞-MINP. De même que pour les autres types de MINP et pour les mêmes raisons, il existe
une unique représentation MINP d'un réseau logique. De manière formelle on peut dénir
le ∞-Metric Induced Network Poset (∞-MINP) comme suit :
Dénition Un ∞-MINP (∞ - Metric Induced Network Poset) est un système partielle-
ment ordonné M m = (N, ) formé à partir de l'ensemble M axPe2e .
N est déni par la relation ∀i ∈ M axPe2e ⇐⇒ i ∈ N ,
Les éléments de p ∈ N ne sont pas étiquetés.
L'∞-MINP peut être considéré comme le MINP représentant les sous-chemins communs
de l'ensemble des sous-ensembles de Pe2e , que ces sous-chemins soient détectables ou non.
k-MINP et nombre de sous-chemins communs détectables Un point intéressant
de la structure d'un k-MINP est que le nombre de sous-chemin communs k-détectables
est directement lié à k. Par exemple, un chemin 1-détectable sera mis en valeur par tous
les sous-ensembles de Pe2e de cardinalité 1. Si n = |Pe2e | il y aura donc, au plus, dans un
1-MINP n noeuds induits en plus des noeuds représentant les chemins de Pe2e . De même,
un 2-MINP ne pourra contenir que des chemins 1-détectables et des chemins engendrés
par tous les couples de chemins, soit n chemins 1-détectables plus n(n − 1)/2 chemins 2détectables, soit en tout n2 + n/2 noeuds. D'une manière générale, le nombre m de noeuds
induits dans un k-MINP peut être exprimé par :
m≤
k
X
Cni
(4.14)
i=1
Cette propriété, qui permet de borner le nombre de noeuds dans un k-MINP, peut être
utile lorsque l'on tente d'en reconstruire un. En eet, le nombre de noeuds présents dans
un MINP permet de dénir des assertions sur les noeuds à découvrir, par exemple.
4.3.2.5 Hypothèses de dénition
De par l'existence d'un unique (k-)MINP pour tout réseau cible respectant les contraintes
évoquées plus haut, on peut dire que le problème de la reconstruction d'un MINP est bien
déni. Les hypothèses sous lesquelles ce problème est bien déni sont donc :
71
1. La stabilité. Si les chemins ne sont pas assez stables pour permettre d'avoir une forte
probabilité que ceux-ci ne changent pas lors de la phase de l'injection de ux pour
reconstruire le réseau, alors de multiples représentations MINP peuvent être trouvées
pour un même réseau. Comme cité précédemment, puisque les chemins parcourant
l'Internet sont assez stables, cette assertion ne paraît pas irréaliste.
2. La stabilité du trac interférent. Si le trac interférent change signicativement, la
détectabilité d'un lien peut changer. La notion de changement signicatif est cependant très variable suivant le type de procédure de tests du réseau ainsi que la métrique
considérée.
4.3.2.6 Relation avec les modèles existants
Relation entre MINPs et topologies issues d'identications d'équipements le
long de chemins La topologie par identication d'équipements le long de chemins
n'étant valuée que par les adresses des équipements, la seule structure MINP utilisable
pour retranscrire les informations obtenues par ce biais est l'∞-MINP. Le passage de cette
topologie à un ∞-MINP peut se faire très simplement si l'on considère que tous les équipements réseaux ont répondu aux requêtes d'identication. Dans un premier temps, on
peut retranscrire la topologie obtenue en tant que topologie logique en suivant la méthode
décrite en section 4.2.1.2. Depuis ce graphe il est trivial de reconstruire M axPe2e , puis, en
utilisant la dénition d'un ∞-MINP, de reconstruire la représentation de cette topologie.
Notons que la reconstruction inverse n'est pas possible, puisque nous avons perdu les
identications des diérents noeuds dans ∞-MINP correspondant.
Enn, dans le cas où l'on ne dispose que d'identications partielles du réseau, on peut
tout de même construire des MINP partiels eux-aussi en utilisant la méthode décrite cidessus. Les MINP partiels obtenus, et la manière de les représenter dépendent de l'utilisation de ceux-ci. Nous reviendrons dans le chapitre 5 sur la façon d'utiliser ceux-ci.
Relations entre MINPs et MINTs Un MINT étant déni comme une représentation
des disjonctions détectables entre un ensemble de k chemins partant de la même source
s0 , chaque arête correspond à un sous-chemin commun k -détectable pour un ensemble de
chemins. Un k-MINP M m = (N, ) peut donc trivialement être reconstruit : en partant
de la racine du MINT, on construit l'ensemble de N en y ajoutant un élément par arc
du MINT. La valuation du nouvel élément de N est celle de l'étiquette de l'arc du MINT
considéré. La relation est elle construite à partir de l'adjacence des arcs. On aura ∀x, y ∈
N, x y si l'arc correspondant à x a pour destination le point origine de l'arc y .
La représentation obtenue peut être considérée comme une forêt, si l'on ne tient pas
compte de l'inmum et du supremum du treillis, de par sa construction. Les feuilles des
arbres obtenus sont les chemins complets de Pe2e .
Il est simple de constater que si on dispose d'une représentation MINP d'un ensemble de
72
chemins Pe2e ayant tous une source commune s0 on peut de manière inverse et en utilisant
la même méthode que celle décrite précédemment construire un MINT correspondant à ce
MINP.
Relations entre MINPs et topologies issues de recoupement de MINT Dans le
cas de recoupement de MINT autrement qu'en utilisant la symétrie, il ne peut exister de
dénition formelle des relations entre MINP et ces recoupements de MINP, ceux-ci n'étant
pas formellement une représentation du réseau, mais plutôt une représentation des liens
entre les diérentes arborescences MINT. Dans le cas de recoupement par symétrie, la
topologie obtenue présente les mêmes caractéristiques que la topologie logique. Les liens
entre ces topologies et les MINP sont donc identiques à ceux décrits en section 4.3.2.6.
Relations entre MINPs et graphes d'interférences Les graphes d'interférences
étant non étiquetés, la seule relation pouvant exister entre ce modèle et les MINP est
la reconstruction d'un ∞-MINP. Le graphe d'interférence peut aisément être transformé
en topologie logique, en utilisant la techique de reconstruction de celle-ci dénie à la section 4.2.1.2. Les relations entre ces deux modèles sont donc identiques à celles décrites en
section 4.3.2.6.
Relations entre MINPs et MSMDMINTs Les MSMDMINT tels que dénis à la
section 4.3.1 ont les mêmes propriétés qu'une topologie logique qui serait étiquetée. Les
liens entre ces topologies et les MINPs sont donc identiques à celles décrites en section
4.3.2.6.
4.4
Synthèse
Nous donnons ici une rapide synthèse de l'apport de nos travaux par rapport aux
travaux existants.
4.4.1 Modèles existants
Les modèles existants, sont, la plupart du temps, basés sur des paradigmes de communication client/serveur, et ne sont donc pas adaptés au problème plus spécique posé par
le fait d'avoir de multiples serveurs et de multiples destinations. Dans le cas de modèles
prenant en compte ces problèmes, on peut distinguer soit :
1. des modèles à la signication sémantique faible (ou en tout cas inutile dans notre cas
où la métrique considérée est la bande passante), comme le couplage d'arborescences
73
par identications de branches communes, ou encore le recoupement d'arborescences
dans le cas symétrique, cas irréaliste.
2. des modèles sémantiquement plus forts, mais reposant sur des hypothèses fortes sur
le réseau ou son comportement, comme par exemple les graphes d'interférence.
4.4.2 Nouveaux modèles
Les nouveaux modèles présentés ici répondent aux problèmes posés par les modèles
existants :
1. Le problème du manque de signication de la dénition formelle de ce qu'est un
MINT dans le cas Multiple Source Multiple Destination (MSMD), rendait nécessaire
la dénition d'un MSMDMINT. La redénition formelle de ce modèle permet d'entrevoir que le modèle visé doit être plus souple, car certains ordres, en particulier ceux
induits par les chemins, sont indiérenciables sans hypothèses fortes sur le réseau
(symétrie du routage ou de la métrique par exemple).
2. Le problème des hypothèses fortes pour les modèles existants pour le cas multiples
sources, multiples destinations, rendait nécessaire la dénition d'un nouveau modèle,
nécessitant moins d'hypothèses, pour permettre une réelle mise en oeuvre de la tomographie réseau multiples sources, multiples destinations. L'existence d'un MINP
ne reposant que sur des hypothèses simples et réalistes (stabilité des chemins, consistance des métriques) répond à ce besoin.
Enn, l'utilisation d'un (k-)MINP pour représenter les caractéristiques d'un réseau
permet de dénir le problème de la tomographie réseau pour le cas multiples sources,
multiples destinations de manière réaliste ; restent les problèmes de la reconstruction et de
la mesure des relations topologiques sur le réseau, qui sont le sujet des chapitres suivants.
74
Algorithmes de reconstruction pour la
tomographie réseau
Dans ce chapitre, nous traitons de la reconstruction de topologie réseau d'un point de
vue algorithmique. Comme nous l'avons évoqué précédemment, les diérentes techniques
de reconstructions sont intimement liées aux modèles que nous voulons reconstruire, ainsi
qu'aux interactions entre un ensemble de chemins que permet d'établir la relation dénie
à partir de la fonction de valuation lors des mesures. Ces mesures, qui sont donc à la
base du jeu de données utilisé lors de la reconstruction, peuvent être classées suivant une
taxonomie basée sur les propriétés des mesures elles-mêmes. Par exemple, certaines mesures
nécessitent la saturation des chemins testés, comme par exemple les mesures décrites dans
[96]. D'autres types de mesures au contraire, ne sont que peu intrusives, comme celle utilisée
dans [107] pour l'identication de sous-chemins communs. Certaines mesures ne pourront
donc pas être eectuées en parallèle, à moins de connaître une partie de la topologie du
réseau, alors que d'autres pourront s'eectuer en parallèle sans introduire de biais entre
mesures concomitantes. Cet aspect des tests est un exemple qui démontre que la complexité
et l'écriture des algorithmes de reconstruction peuvent dépendre de l'ordonnancement de
ceux-ci. La suite du chapitre est donc découpée comme suit : dans un premier temps,
nous donnons les principales propriétés des tests qui inuent sur l'algorithmique employée
pour la reconstruction des topologies. Puis, nous faisons un état de l'art des principales
méthodes existantes pour reconstruire les modèles de la littérature, pour donner une échelle,
en terme de complexité, tant en nombre d'étapes de tests, de tests, ainsi qu'en complexité
de l'algorithme, par rapport à laquelle estimer les algorithmes développés dans le cadre
de cette thèse. Enn, nous décrivons les algorithmes implémentés dans notre outil, ainsi
que les algorithmes pouvant améliorer les performances de l'outil dans le cadre de travaux
futurs.
5.1
Propriétés des mesures
5.1.1 k-mesure et k-test
Les mesures, telles que nous les avons évoquées jusqu'à présent, sont donc des techniques nous permettant de retrouver des relations entre les diérents chemins appartenant
75
Algorithmes de reconstruction pour la tomographie réseau
à l'ensemble de chemins Pprobe sur lesquels ces mesures sont eectuées. De manière à aner
cette dénition, pour permettre de dénir plus précisément les caractéristiques de celles-ci,
nous introduisons ici deux notions diérentes et complémentaires : la k-mesure et le k-test.
Une k-mesure est une mesure qui s'eectue sur un ensemble de chemins de cardinalité k,
c'est-à-dire en injectant des ux sur ces k chemins, par exemple, (Pprobe ). Intuitivement,
on pourra penser qu'utiliser une k-mesure nécessitera pour reconstruire l'intégralité d'une
topologie d'eectuer cette mesure sur l'ensemble des sous-ensembles de cardinalité k de
Pe2e (ce qui n'est pas forcément le cas en pratique, comme nous le verrons par la suite).
Un autre aspect important d'une mesure est la cardinalité de la relation qui est établie
par le test eectif. Cette cardinalité correspond à la k-détectabilité du sous-chemin commun
que l'on teste. On nommera un test un k-test si il permet d'établir une relation k-détectable.
Prenons par exemple la métrique de la bande passante et la relation nécessaire à la reconstruction le fait d'établir si "un ensemble de k chemins possède un goulot d'étranglement
commun 2-détectable". Supposons que l'on dispose d'informations pré-établies sur un ensemble P de n chemins et que l'on sache qu'ils ne possèdent pas de sous-chemin commun
deux à deux, ainsi qu'un chemin p dont on ne connaisse que la bande passante disponible
quand un ux est injecté le long de celui-ci. Un exemple de n-mesure 2-test simple serait
le suivant. On établit une saturation des n chemins, puis l'on évalue la bande passante sur
le chemin p ; une baisse de la bande passante disponible le long de p indiquerait l'existence
d'un sous-chemin commun 2-détectable. Si par diérentes méthodes, on arrive à déterminer
quels sont les chemins de P qui ont aussi subi des baisses de performances, on obtiendrait
à priori une mesure d'une propriété 2-détectable sur (n + 1) chemins, en utilisant donc une
(n+1)-mesure 2-test.
En général, la cardinalité de k-mesures k-tests est de 2. Cette cardinalité n'est pourtant
pas la règle : nos mesures pour les MINP dénissent le plus souvent une relation entre 3 ux
à l'aide d'un 1 ou 3-test, c'est-à-dire qu'elles identient des sous-chemins 1 ou 3-détectables
pour un ensemble de 3 chemins. Les mesures d'identication de sous-chemins communs à
2 arborescences sont des 4-mesures 4-tests, puisque l'ensemble des chemins Pprobe a une
cardinalité de 4 et qu'elles établissent le fait que "les 4 chemins ont une section commune",
soit une 4-détectabilité, et ne permet pas l'établissement des relations 2 ou 3-détectables.
Les tests incluant des recoupements d'arbres multicast impliquent un nombre arbitraire
de chemins. Certains tests, modiés, comme ceux utilisés pour la reconstruction du jeu de
données initial de notre algorithme 5.4.6, peuvent impliquer un nombre croissant de ux.
5.1.2 Temps d'exécution
Un aspect très important des mesures est le temps nécessaire pour eectuer un test sur
l'ensemble des chemins impliqués par la mesure. Ce temps est très souvent long, soit pour
des aspects statistiques (récupération d'un ensemble de données susamment grand pour
76
être signiant statistiquement) soit pour des aspects pratiques (par exemple lors de mesures
reposant sur l'évaluation de propriétés de ux TCP en régime permanent). D'autres types
de tests, par contre, ont des temps de réponse très courts (comme par exemple l'établissement de traces de route par envoi de requêtes ICMP). Par exemple, le test d'identication
de sous-chemins communs à plusieurs arborescences par répartition statistique des ordres
d'arrivées sur les noeuds cibles prend environ 2 minutes par quadruplet de chemins. Certaines procédures de mesures, comme par exemple celles reposant sur les propriétés de ux
TCP en régime permanent telle que celle utilisée dans [107] sont uniquement théoriques
dans un cadre de grille : en eet, les grilles possèdent le plus souvent des réseaux high
badwidth.delay, rendant l'attente de la stabilisation de la bande passante utilisée par un
ux dépendant du RTT (comme par exemple les ux TCP) prohibitive (temps d'attente
supérieur à la demi-heure pour un seul ux). La partie la plus coûteuse en pratique lors de
la reconstruction d'une topologie sera le plus souvent non pas la complexité algorithmique
du traitement du jeu de données, mais bien le nombre d'exécutions de mesures séquentielles
nécessaire à la terminaison de l'algorithme, c'est-à-dire la cardinalité du jeu de données.
De plus, l'exécution de tests peut être de temps xe (comme par exemple quand on
récupère un jeu de n données statistiques à intervalles xes), variables (comme quand
par exemple on établit un régime permanent pour un ux) ou bornables (dans le cas
de la récupération d'un ensemble de n données statistiques basées sur des établissements
d'équilibre ou des valeurs de métrique du réseau). Il est donc nécessaire pour évaluer la
diculté de mise en oeuvre d'un algorithme d'avoir une évaluation précise du coût d'une
mesure.
5.1.3 Exclusion mutuelle
Si certains types de tests peuvent être eectués en parallèle car ils ne sont pas très
intrusifs, certains autres, comme ceux basés sur la saturation par exemple, ne peuvent être
menés en parallèle. Cela entraîne de lourdes conséquences sur la complexité de la mise en
oeuvre des tests. A contrario, un exemple de tests pouvant être exécuté en parallèle est la
reconstruction de traces de routes par traceroute ou bien encore une estimation du RTT.
5.1.4 Relations topologiques et reconstruction
Chaque type de mesure repose sur une relation topologique particulière. Cette relation
topologique entre les chemins permet alors, dans la majorité des cas, une reconstruction
d'un modèle dédié à ce type de mesure. Néanmoins, les diérentes relations topologiques
peuvent se recouvrir, tout du moins partiellement, rendant possible la réutilisation de tout
ou partie d'un jeu de données de mesures pour la reconstruction d'une topologie pour
laquelle elle n'était pas initialement destinée. Par exemple, les techniques de mesures déve77
loppées dans le cadre de cette thèse tendent à mesurer l'inclusion de sous-chemins communs
à un ensemble de ux dans un autre sous-chemin commun à un autre ensemble de ux. Ce
type de mesure recouvre donc par exemple, les méthodes par identication de sous-chemins
communs, qu'elles soient basées sur la distributions d'arrivées de paquets [107] ou sur la
saturation de chemins pour détecter l'existence des sous-chemins en question [96]. Il existe
donc une hiérarchie sémantique entre les diérentes relations topologiques utilisées, qui se
répercute directement sur les méthodes de reconstruction, permettant certains passages
d'un modèle vers un autre. Comme nous l'avons vu précédemment dans le chapitre 4 il est
tout à fait possible, à partir d'un MINP, de reconstruire des MINT. L'inverse n'est pas toujours vrai. De plus, certaines opérations qui sont attractives car peu coûteuses donnent en
fait des indications très faibles sémantiquement sur les caractéristiques du réseau, comme
par exemple la technique d'identication de sous-chemins communs qui ne permet que de
coupler des arbres de type MINT deux à deux. Au-delà du simple aspect de modélisation, la
relation topologique issue de la mesure possède ainsi une vraie valeur sémantique donnant
une description plus ou moins forte du réseau.
L'intêret que l'on porte aux diérentes mesures inue bien sûr fortement sur le type de
relation établie : par exemple, le modèle MINP peut faire disparaître l'ordre total des points
de disjonction que l'on trouve entre un serveur et ses clients. Or, ces informations sont
inutiles quand on cherche à évaluer la bande passante atteignable commune à l'ensemble
des ux, puisque cette métrique est basée sur la valeur minimum présente le long du chemin,
et non sur l'ordre de traversée des diérents sous-chemins.
5.2
Algorithmes pour les MINT
Les algorithmes existants pour la reconstruction de MINT ne dièrent que très peu
lorsque l'on parle de MINT basé sur des relations de conjonction ou de disjonction. Nous
traiterons donc ici uniquement des reconstructions de MINT basées sur la disjonction. De
même, l'étiquetage des arcs des arbres ne fait que très peu diérer l'algorithme de reconstruction ; nous ne développerons donc pas de manière spécique le cas de la reconstruction
de topologie non étiquetée, mais regrouperons les deux manières de résoudre le problème
en une seule section.
Nous donnons ici les conditions nécessaires et susantes pour la reconstruction d'un
MINT pour un réseau et une métrique donnée ; puis nous introduisons les deux grandes
familles d'algorithmes pour la reconstruction de MINT : celle basée sur les pré-ordres, et
celle basée sur l'estimation de la vraisemblance.
78
5.2.1 Hypothèse de reconstruction
Les hypothèses de reconstruction pour un MINT sont la séparabilité (voir section
4.1.1.6) et la monotonicité (voir section 4.1.1.2).
5.2.2 Reconstructions basés sur les pré-ordres
Par reconstruction basée sur les pré-ordres, nous désignons les algorithmes ne faisant pas
appel à des méthodes d'optimisation statistique pour la reconstruction. Historiquement,
le premier algorithme pour reconstruire des MINT est de ce type [49]. Quelques nouveaux
algorithmes ont été depuis développés [50] [113].
5.2.2.1 Algorithme de reconstruction
Rappelons que la dénition d'un MINT ne porte que sur des chemins ayant tous la
même source, que nous noterons s0 . Nous noterons Pe2e l'ensemble de ces chemins partant
de s0 . Nous noterons l'ensemble des noeuds destinations de ces chemins partant de s0
D0 ⊆ R. Cet ensemble est de cardinalité n, tout comme Pe2e .
Ce premier algorithme de reconstruction de MINT, parfois appelé Deterministic Binary
Tree (DBT (DBT)) nécessite d'avoir le jeu de données initial suivant :
1. La valuation de la fonction disj(Pprobe ) pour tout sous-ensemble de Pe2e de cardinalité
P
), où j est le point de disjonction des chemins de Pprobe .
|Pprobe | = 2, soit m(fpsprobe
0j
2. Le paramètre de sensibilité s.
Lors de sa terminaison, il produit une arborescence de type MINT étiquetée sur les
arcs par la valeur de la métrique considérée, si la métrique permet de le faire, c'est-à-dire
si la métrique est monotone et séparable. Notons que seule la monotonie est nécessaire
pour reconstruire une topologie MINT non-étiquetée. L'algorithme peut être scindé en
trois étapes principales :
Réduction Dans un premier temps, on trie suivant la relation d'ordre ≤ associée à la
métrique m l'ensemble des valuations de la fonction disj(Pprobe ) de cardinalité 2. Puisque
cette valeur correspond à la capacité du sous-chemin commun aux éléments de Pprobe , cette
étape revient à trier les sous-chemins communs à toute paire de ux suivant leur capacité.
Si ces capacités sont supérieures au paramètre de sensibilité s alors le sous-chemin commun
est détectable ; dans le cas contraire, les chemins ne possèdent pas de sous-chemin commun
détectable. Puisque la métrique est monotone, le sous-chemin placé le premier dans cette
liste ne peut être contenu dans aucun autre sous-chemin commun à n'importe quelle autre
paire de ux. Il convient donc de créer le sous-chemin ; on peut donc créer l'arc reliant
s0 et le point de disjonction r entre les deux sous-chemins. Etant donné qu'aucun autre
chemin partant de s0 vers n'importe laquelle des destinations ps0 i et ps0 j ne peut contenir
79
r, l'arbre enraciné par r est complètement déni. On donne temporairement aux deux arcs
constitués les valeurs des sous-chemins pri et prj .
Récursion On procède ensuite par récursion grâce à r. Ce nouveau point peut en ef-
fet remplacer les points destinations des éléments de Pprobe . Chacune des valuations de
disj(Pprobe ) dont un des éléments px ∈ Pprobe est ps0 i ou ps0 j peut être réexprimé en remplacant le chemin px par le sous-chemin ps0 r . Après chaque étape i, le problème se réduit
à trouver la topologie entre s0 et Dk+1 = Dk \ {i, j} ∪ {r}. La cardinalité de D est donc
réduite de 1 à chaque étape.
Compression et étiquetage Une fois l'arbre binaire reconstitué à la terminaison de
la récursion, on peut procéder à la compression et à l'étiquetage des arcs. En partant
(l )
des feuilles, on confond chaque noeud interne r avec son noeud père r0 si cmr0 r ≤ s, soit
¬ (Pprobe ). Les étiquettes de liens reliant les anciens enfants de r doivent être mises à
p 0
p
jour. Puisque la métrique est séparable, la nouvelle valeur doit être égale à g(cms0 r , cms0 r ).
5.2.2.2 Compléxité
Etapes de calcul Les auteurs prouvent que la complexité de l'algorithme est polynomiale et bornée par O(|Pe2e |2 ).
Nombre de tests Ce type de reconstruction implique des tests sur l'ensemble des
ensembles Pprobe ∈ Pe2e de cardinalité 2, soit l'ensemble des paires de chemins, donc,
|Pe2e |(|Pe2e |−1)
mesures.
2
5.2.3 Reconstructions basées sur la vraisemblance
Ce type de méthode est issu de la communauté statisticienne qui traite souvent l'intégration temporelle de mesures, connaissant la topologie du réseau cible. Leur méthode
d'optimisation de la fonction de vraisemblance utilisée lors de l'intégration temporelle est
transposée au problème de l'inférence de la topologie. Si le but change, le principe général est similaire : à partir d'une fonction de coût, il s'agit d'estimer quel arbre parmi
les arbres possibles est l'arbre possédant l'estimation de vraisemblance la plus grande. La
problématique peut être formalisée comme suit :
Soit un arbre inconnu T (V ∪ R ∪ {s0 }, L), contenant un ensemble V de noeuds internes,
un ensemble R de feuilles (i.e. de noeuds destination), une source s0 et un ensemble L d'arcs.
Soit X ≡ {Xij : i, j ∈ R, i 6= j} où Xij est une variable aléatoire dénie par les valeurs
des mesures disjT ({ps0 i , ps0 j }) = {disjt0 ({ps0 i , ps0 j }), . . . , disjt |T |({ps0 i , ps0 j })}. Soit un
échantillon provenant d'une paire ij de X , soit x ≡ {xij : i, j ∈ R, i 6= j}. Soit p(x|δ) la
80
probabilité de x sachant que la capacité du chemin menant de s0 au point de disjonction
(si il existe) entre ps0 i et ps0 j est δ . La probabilité de tous les xij sachant δ connaissant
l'ensemble des mesures peut être considéré comme la fonction de vraisemblance de l'arbre
T . L'arbre T ∗ ayant la vraisemblance maximale est exprimable par :
T ∗ = max log sup p(x|δ),
T ∈F
δ
(5.1)
où F est l'ensemble des arbres possibles ayant pour source s0 et pour feuilles les éléments
de R. T ∗ est donc l'arbre recherché. L'approche brute-force consistant à générer toutes
les arborescences possibles, pour estimer leur vraisemblance, n'est jamais employée. En
eet, on peut dans un premier temps réduire l'ensemble F à l'ensemble des arbres binaires
possibles, puisqu'il est toujours possible de reconstruire un arbre n-aire à partir d'une
représentation binaire, comme on l'a vu dans la description du DBT lors de la phase de
compression de l'arbre. On peut aussi limiter la valeur de δ grâce à la monotonicité. A
partir de cela, diérents algorithmes ont été développés.
Le Lilekihood Based Tree de [58] reprend par exemple le même fonctionnement général
que le DBT, avec la diérence bien sûr que l'inférence est faite pour un ensemble de mesures
dispersées dans le temps. L'équivalent de la topologie produite par cet algorithme est le
résultat de l'intégration temporelle de topologies déterminées par le DBT telle que décrite
dans la section 3.1.5.4.
On peut aussi baser la recherche de la topologie sur des méthodes relativement complexes basées sur les méthodes de Monte Carlo à chaînes de Markov [58], ce qui permet
d'éliminer l'eet de seuil de l'étape de compression, ou encore sur des méthodes de clustering hiérarchique.
5.2.3.2 Complexité
Etapes de calcul Une borne générale, mais très large, du problème de reconstruction
de MINT par l'utilisation de la vraisemblance est le nombre d'arbres possibles dans la
forêt F , soit |R|!
2 . La plupart des techniques, cependant, ont une complexité similaire ou
inférieure à celle de la construction et de l'intégration temporelle de plusieurs MINT pris
à des instants diérents, soit O(|T ||R|2 log(|R|).
Nombre de tests ce type de reconstruction implique le même nombre de tests que le
DBT, soit
mesures.
|R|(|R|−1)
2
mesures répétées |T | fois soit le nombre d'échantillons temporels de
81
5.2.4 Reconstruction par recoupement d'arborescences MINT pour le
cas symétrique
5.2.4.1 Hypothèses de reconstruction
Les hypothèses de reconstruction sont les mêmes que celles induites par la dénition du
modèle, à savoir la symétrie du routage, sa consistance et sa stabilité ainsi que la symétrie
de la métrique.
L'algorithme présenté dans [50] consiste à regrouper plusieurs arborescences MINT
préexistantes partageant le même ensemble de machines hôtes (source et destination).
L'étape initiale de cet algorithme est la génération de l'ensemble des arbres enracinés par
les noeuds sources F ∫ , soit |S| arbres, ainsi que la génération de F ∇ qui contient |R|
arbres enracinés par un des noeuds destination décrivant l'ensemble des chemins entre un
élément de R et l'ensemble des sources S . L'algorithme prend ensuite en compte chaque
paire d'arbres (Ti , Tj ) appartenant à T ∫ . Pour chacun de ces couples, on intègre chacun des
arbres de F ∇ en préservant la couverture des noeuds. Par couverture, nous entendons que
l'intégration des noeuds est faite en conservant la relation de descendance de chacun de
ceux-ci ; puis on eectue une phase de compression similaire à celle décrite dans la section
5.2.2.1 pour obtenir une intégration cohérente des diérentes arborescences vis-à-vis du
seuillage de la métrique.
5.2.4.3 Complexité
Etapes de calcul Les étapes de construction des forêts F ∫ et F ∇ ont des complexités
diérentes suivant l'algorithme utilisé ; dans le cas du DBT, cette première étape est une
reconstruction en O(|S||R|2 ) et O(|R||S|2 ) pour chacune des forêts respectivement.
La deuxième étape de fusion d'arbres, se fait, elle, en O(|R||S|2 ).
Nombre de tests le nombre de tests induit par cette reconstruction est basiquement
celui demandé par la reconstruction de tous les éléments des forêts F ∫ et F ∇ , soit |S||R|2 +
|R||S|2 .
5.3
Algorithme pour les graphes d'interférence
5.3.1 Hypothèses de reconstruction
Les hypothèses de reconstruction sont les mêmes que celles induites par la dénition
du modèle, à savoir la symétrie du routage, sa consistance et sa stabilité.
82
5.3.2 Algorithme de reconstruction
La dénition de la structure induite par l'algorithme utilisé par les auteurs du graphe
d'interférence étant basée sur sa construction, nous avons déjà donné les grandes lignes de
cet algorithme à la section 4.2.3 ; la seule diérence entre l'algorithme donnant la structure
de la topologie reconstruite et celui utilisé par les auteurs est l'éventuel recourt à un
ordonnancement des tests. Cet ordonnancement est possible si l'on sait que deux chemins
ne partagent pas de sections communes à travers lesquelles ils pourraient inuer l'un sur
l'autre. C'est le cas lorsque la relation rl implique l'absence de sous-chemin communs à
deux ux. Ainsi, l'on pourra continuer à saturer simultanément les deux liens lorsque l'on
tentera d'évaluer les interférences d'un troisième avec ceux-ci. Notons que ce raisonnement
ne fonctionne que dans le cas où il n'existe que des sous-chemins communs étroits 1détectables.
Pour mieux illustrer les problèmes de telles mesures, prenons des exemples. Considérons
par exemple la topologie de gauche de la gure 5.1. Si le ux passant par pa sature le souschemin commun de pa et pc , l'intersection entre pb et pc ne sera soit pas détectée, ou alors,
seulement par pc . Plus génant, ce fonctionnement, en cas de détection d'un conit entre
le chemin pc testé et des chemins saturés pa et pb par la fonction mes (pc , x) > s mais
mes (x, pc ) < s ne permettra pas de déterminer si x est le chemin pa ou pb , ce qui implique
de tester à nouveau l'ensemble des paires constituées de pc et des chemins considérés comme
indépendants. De plus, si les ux pa et pc partagent la bande passante de manière équitable,
si l'intersection entre pc et pb est 2-détectable ou plus, elle ne sera pas détectée, car pc ne
pourra pas atteindre la bande passante nécessaire pour saturer ce lien. Dans ce cas, le
raisonnement sus-cité ne peut être appliqué.
Considérons encore la topologie de droite de la gure 5.1. Si l'intersection entre pc
et pb est 3-détectable ou plus, elle ne sera pas détectée, ou alors, seulement quand les 3
ux interagiront ensemble. Cette technique de mesure induit donc que les sous-chemins
communs détectés sont i-détectables, où i est la cardinalité du test.
pb
pa
pa
pc
pc
pb
Figure 5.1. Exemples d'intersections
83
5.3.3 Complexité
5.3.3.1 Etapes de calcul
La complexité en nombre d'étapes de calcul n'est pas explicitement calculée dans les
diérents articles publiés sur cet algorithme. En eet, les auteurs considèrent (à juste titre
dans ce cas) que c'est le nombre de tests qui est déterminant pour les performances de
l'algorithme.
5.3.3.2 Nombre de tests
Le nombre de tests dépend ici du nombre de chemins impliqués dans les tests. Pour le
cas le plus simple, c'est-à-dire 2, on doit mesurer l'ensemble des paires de chemins, ce qui
implique un nombre de tests quadratique suivant le nombre de chemins, soit |Pe2e |2 . Ce
nombre peut être un peu réduit dans le cas de tests simultanés, suivant la topologie et les
capacités du réseau cible.
5.4
Algorithmes de reconstruction pour les MINP
Je présente ici les diérents algorithmes que j'ai développés durant cette thèse pour la
reconstruction de topologie de type MINP. Les algorithmes se basent sur les propriétés du
modèle décrites ci-après ; les algorithmes sont classés par ordre décroissant de complexité
en nombre de tests et requièrent tous un sous-ensemble d'hypothèses de reconstruction qui
leur est propre.
5.4.1 Hypothèses de reconstruction
Les hypothèses de reconstruction utilisées par tous les algorithmes présentés ici sont
la monotonicité étendue, la séparabilité étendue et la bornation pour la métrique, et la
consistance et la stabilité pour le routage. Rappelons que les conditions utilisées pour
prouver la bonne dénition du problème de reconstruction d'un MINP sont uniquement
les hypothèses (faibles) sur le routage.
5.4.2 Propriétés d'un MINP
5.4.2.1 Couverture unique
Une propriété utile d'un MINP est que, si un supremum existe pour un ensemble de
chemins P 0 , il est unique. Dans le cas général, de par l'hypothèse de consistance du routage,
on peut considérer qu'un ensemble de chemins possède un unique sous-chemin commun.
Dans le cas contraire, cela signierait qu'au moins deux chemins se sont croisés, ont partagé
84
un chemin commun, se sont séparés et ont partagé à nouveau un sous-chemin commun, ce
qui viole l'hypothèse de consistance. Dans le cas des métriques bornées telles que celles liées
à la bande passante, c'est-à-dire dont la valeur est déterminée par une capacité minimum
le long de l'ensemble de chemins, on peut considérer qu'il existe un unique sous-chemin
commun étroit, de par l'hypothèse de constance de la métrique. Ceci renforce l'hypothèse
de l'existence de cette couverture unique.
5.4.2.2 Propriété de regroupement
Soit deux ensembles de chemins P = Pnoyau ∪ {pa } ∪ Ppivot , P = Pnoyau ∪ {pb } ∪ Ppivot ,
|Pnoyau | ≥ 0. Supposons que P et P 0 et Ppivot possèdent tous trois un sous-chemin commun.
Si {pa , pb }∪Ppivot possède un sous-chemin commun, alors P 00 = Pnoyau ∪{pa }∪{pb }∪Ppivot
possède un sous-chemin commun unique.
0
Preuve Quand
|Pnoyau | = 0, cette propriété est triviale. Prenons le cas |Pnoyau | = 1,
i.e. Pnoyau = {pd }. Pour plus de simplicité, appelons le sous-chemin commum maximum
de Ppivot pc . Les propriétés énoncées ci-dessus signient que {pa , pb , pc }, {pa , pc , pd } et
{pb , pc , pd } possèdent chacun un sous-chemin commun. On a donc {pa ∩ pc } ∩ pd et {pa ∩
pc } ∩ pb non nul. L'intersection entre chemins étant unique, le sous-chemin commun de
{pa , pc } possède deux intersections respectivement avec les chemins pd et pb . Soit ces deux
intersections {pa ∩pc }∩pb et {pa ∩pc }∩pd sont disjointes, soit elles partagent un sous-chemin
commun. Puisque {pb , pc , pd } possède un sous-chemin commun non nul, les intersections
de {pa ∩ pc } avec pb et pd possèdent un sous-chemin commun. Sinon, il existerait plusieurs
intersections {pb , pc } et {pc , pd }. Il existe donc un sous-chemin commun à l'ensemble des
chemins {pa , pb , pd } ∪ Ppivot . Pour tous les cas où |Pnoyau | > 1, il sut de remplacer
les chemins de Pnoyau par le sous-chemin commun de Pnoyau . Le raisonnement ci-dessus
s'applique. Il existe donc un sous-chemin commun à {pa , pb } ∪ Pnoyau ∪ Ppivot .
Notons au passage que si Pnoyau = Pnoyau0 \ {px }, on peut appliquer le même raisonnement en utilisant {px } à la place Ppivot et reprendre la même démonstration. On obtient
donc une méthode de construction par récursion d'un sous-chemin commun maximum pour
un ensemble P de chemins.
5.4.2.3 Propriété de regroupement pour les métriques bornées
Si la métrique considérée est bornée, alors on peut pré-ordonner les diérentes intersections de chemin issues de la propriété de regroupement si celles-ci sont au plus 3-détectables
(i.e. 1 ou 2-détectables). De plus, 2 sous-chemins communs sur les 3 peuvent être confondus
car ils ont la même capacité, celle du sous-chemin commun à l'ensemble des ux.
Preuve Considérons à nouveau le cas simple où |Pnoyau | = 1, i.e. Pnoyau = {pd }. Puisqu'il
existe un sous-chemin commun pz pour {pa , pb , pc , pd }, chaque triplet de chemin a pour
85
borne supérieure (dans le cas de bande passante par exemple où la relation associée est ≤)
(resp inf.) la capacité de ce sous-chemin commun, puisque par dénition, il est contenu dans
chacun de ces chemins-là (les sous-chemins communs maximum de {pa , pb , pc }, {pa , pb , pd },
{pa , pc , pd } et {pb , pc , pd }). Si la capacité d'un (ou plusieurs) de ces sous-chemins px est
inférieure ±s(toujours pour la bande passante) (resp. sup.) (s paramètre de sensibilité) à la
capacité de ce sous-chemin, alors cela signie qu'il contient un lien de capacité inférieure au
sous-chemin des 4 chemins pz . Le chemin px contient donc le sous-chemin pz , permettant
de pré-ordonner les diérents sous-chemins par une arborescence où pz est la racine. Si la
capacité d'un sous-chemin est similaire à pz , alors il peut être confondu avec ce dernier, pz
étant par dénition 3-détectable. Puisque pz est 3-détectable, cela signie qu'il est au moins
la borne de l'un des triplets sous-ensembles du quadruplet {pa , pb , pc , pd }. Or, si plus de
2 strictement de ces triplets ne permettent pas de détecter pz , alors on ne peut appliquer
la règle de regroupement. Parmi les trois sous-chemins communs, 2 ont forcément comme
borne inférieure pz . Pour tous les cas où |Pnoyau | > 1, comme précédemment, il sut de
remplacer les chemins par le sous-chemin commun de Pnoyau .
5.4.3 Un algorithme de reconstruction pour les k-MINP pour des métriques bornées
Nous donnons ici un premier algorithme polynomial pour la résolution du problème
de reconstruction d'un MINP à partir de mesures eectuées sur l'ensemble de Pe2e tel
que décrit à la section 4.3.2.2. L'algorithme repose sur les propriétés d'un MINP énoncé
ci-avant ; l'idée générale est de reconstruire une représentation complète du réseau à partir
de mesures eectuées sur des sous-parties du réseau cible. Une fois obtenu l'ensemble des
mesures nécessaires, l'algorithme applique itérativement les propriétés de regroupement et
de couverture unique pour reconstruire une topologie complète. Cet algorithme est proche,
dans l'esprit, du DBT s'appliquant sur les MINT décrit dans la section 5.2.2.
L'algorithme comprend trois parties principales. Une première phase de tri, une boucle
centrale sur les MINPs partiels eectuant une recherche des cas où l'on peut appliquer
la règle de regroupement, et enn les parties responsables de la fusion des informations
contenues dans l'ancien MINP et les nouvelles informations que produit l'ajout du MINP
partiel courant, que ce soit par l'application de la règle de regroupement, celle de couverture unique, ou par ajout simple. Notons que la propriété de regroupement ne peut être
appliquée que sur des k-mesures pour lesquelles k ≥ 3. Dans nos travaux, nous utilisons
d'ailleurs le plus souvent des 3-mesures, le choix de k devant être le plus petit possible
k
pour minimiser le nombre de sous-ensembles possibles (C|P
).
e2e |
86
Tri initial La première étape consiste en un tri des diérents MINP partiels de
eectué suivant l'ordre
R≤
Mk
déni comme suit :
∀x = (X, ≤), y = (Y, ≤), x, y ∈ Mk
xR≤ y = (Supr(X) 6= {0} ∧ Supr(X) détectable , Supr(Y ) = {0} ∨ Supr(Y ) indétectable )
∨((Supr(X) = {0} ∨ Supr(X) indétectable ) ∧ (Supr(Y ) = {0} ∨ Supr(Y ) indétectable)
∨(Supr(X) 6= {0} ∧ Supr(X) détectable ,
)
Supr(Y ) = {0} ∨ Supr(Y ) détectable cSupr(X)
≤ cSupr(Y
)
m
m
(5.2)
Où Supr(X) est le supremum c'est-à-dire le noeud couvrant tous les éléments d'un ensemble
X (i.e. l'équivalent dans le MINP du sous-chemin commun maximum de l'ensemble de
chemins appartenant à Pe2e qui sont représentés dans X ). Cette relation peut être vue
comme un tri croissant par les valeurs des suprema des éléments de Mk quand ils en ont
un. Quand ils n'en ont pas, les éléments sont considérés comme supérieurs à tous ceux qui
ont un supremum.
Ce tri est utile dans le cas où la métrique m considérée possède la propriété de monotonicité étendue. Dans ce cas, en eet, on peut prouver le lemme suivant :
1 Si la métrique
considérée possède la propriété de monotonicité étendue, alors le
plus petit élément xmin de Mk par rapport à l'ordre R≤ est complètement déni. Il ne peut
exister d'autres sous-chemins k-détectables communs à l'ensemble des chemins de xmin .
m
Preuve De part la monotonicité étendue, le sous-chemin commun de plus petite capacité
ne peut, par dénition, être inclus dans aucun autre sous-chemin commun.
Boucle principale La partie centrale est une boucle sur l'ensemble des MINP partiels
Mk obtenus à partir des k-mesures eectuées sur chacun des sous-ensembles de Pe2e de
cardinalité k. On recherche trois couples de noeuds, qui, avec le supremum éventuel intro-
duit par le MINP courant, sont susceptibles d'être regroupés tous les quatre en utilisant la
règle de regroupement. Elle est décrite de manière formelle par l'algorithme 1.
87
Algorithme 1 Algorithme principal
Paramètre de sensibilité s, la liste sortMk contenant les éléments de Mk triés
par rapport à l'ordre R≤ .
Sorties : reconstruction d'un MINP pour l'ensemble du réseau.
Entrées :
M IN P total ← sortMk [0]
i←1
tantque i ≤ length(sortMk ) faire
M IN P courant ← sortMk [i]
si M IN P courant possède un supremum entre au moins 3 de ses chemins alors
Recherche parmi les sous-chemins déjà présents dans M IN P total de sous-chemins com-
muns pour appliquer la reconstruction par la règle de regroupement pour les métriques
bornées (algorithme 2), i.e. deux noeuds x et y . Cela signie rechercher l'existence d'un
supremum pour chacun des triplets couverts par x, y et le supremum de M IN P courant.
nsi
si règle de regroupement non applicable alors
fusion de M IN P courant et M IN P total en respectant la propriété de couverture unique
(algorithme 3).
nsi
i←i+1
n tantque
Ajout des noeuds Ω et p∞ à MINPtotal
retourne M IN P total.
Ajout des nouvelles informations Les deux algorithmes de fusions sont donnés ci-
après : l'algorithme de fusion des MINP basé sur la règle de regroupement est l'algorithme
2 et celui sur la règle de couverture unique est l'algorithme 3.
88
Algorithme 2 Fusion des MINP par utilisation de la règle de regroupement
M IN P total,x, y sous-chemins communs de M IN P total, M IN P courant et
son sous-chemin commun z , paramètre de sensibilité s
Entrées :
fusion des MINP
trier les sous-chemins communs suivant la relation ≤ associée à la métrique.
Créer un noeud w dans MINPTotal de capacité égale à la capacité du chemin de plus
grande (au sens de ≤) capacité dans la liste de sous-chemins communs.
Sorties :
pour tout chemin ∈ {x, y, z} faire
si cchemin
− cw
m
m = 0 ± s alors
confondre chemin et w.
sinon
Ajouter un nouveau noeud v ls de w couvrant les mêmes chemins que chemin dans
M IN P T otal.
nsi
n pour
Notons qu'il n'est pas nécessaire, normalement, de conserver les noeuds du MINP partiel
x = (X, ≤) ajouté soit par la règle de couverture unique soit par celle de regroupement ;
en eet, les sous-ensembles de X doivent appartenir au M IN P total pour que l'on puisse
trouver les sous-chemins communs nécessaires à l'application de la règle de regroupement
pour les k-MINP bornés.
Algorithme 3 Fusion respectant la règle de couverture unique
Entrées :
Sorties :
M IN P courant, M IN P total, paramètre de sensibilité s.
Fusion des MINP respectant la règle de couverture unique.
si M IN P T otal ⊇ M IN P courant alors
Ne rien faire (les relations décrites dans le M IN P partiel sont déjà représentées).
sinon
insérer les noeuds n'étant pas dans M IN P total suivant leurs couvertures.
nsi
Retourne x.
5.4.3.2 Exemple
La gure 5.2 donne un exemple d'exécution pour une topologie simple. Dans cette gure,
et les suivantes illustrant l'exécution d'algorithmes, nous avons adopté les conventions
suivantes. Dans le premier cadre en haut à gauche, entouré d'une ligne solide, gure la
topologie logique. Sur cette même ligne, gurent les MINP partiels correspondant aux
mesures qui doivent être eectuées avant le début de l'exécution de l'algorithme. Dans
89
notre exemple, ici, on doit lancer des 3-mesures 3-tests de manière à établir les MINP
partiels correspondant aux sous-ensembles de cardinalité 3 de l'ensemble Pe2e . Ces MINP
partiels gurent donc dans les cadres de la première ligne. Notons que lorsqu'une mesure
est eectuée, le MINP résultant est entouré de tirets. Quand un MINP partiel provient
de l'exécution de l'algorithme (application de la règle de regroupement, ajout simple par
exemple ou utilisation de MINP déjà établis dans une phase précédente) le MINP résultant
est entouré de pointillés.
Les lignes qui suivent la première sont les étapes de déroulement de l'algorithme. La
règle appliquée pour obtenir le nouveau MINP partiel (ajout simple, regroupement ou
couverture unique) est indiqué au-dessus de chaque "=". les étapes d'ajout simple sont
ignorées (et donc, non représentées) quand elles ne présentent pas d'intérêt particulier.
Lors de la première étape, aucune correspondance particulière n'est trouvée, et les MINP
font donc l'objet d'un ajout simple. Lors de la seconde étape les 3 sous-chemins communs
les plus hauts permettent d'appliquer la règle de regroupement, ce qui donne le MINP
correspondant à la totalité des Pe2e testés. Notons que l'information contenue dans le
4ième et dernier MINP partiel de la première ligne est redondant par rapport aux autres.
Cela n'aurait pas été le cas, par exemple, en l'absence totale de sous-chemin commun
3-détectable.
5.4.3.3 Complexité
Etapes de calcul Le nombre d'étapes de calcul est quadratique suivant le nombre de
MINP partiels obtenus. Néanmoins, c'est ici le nombre de tests qui est le principal écueil
à l'utilisation de cet algorithme.
Nombre de tests Le nombre de tests requis pour l'utilisation de ce test est prohibitif :
d'une part, la construction "o-line" du MINP implique que chaque k-uplet ( k ≥ 3) de
sous-chemins soit mesuré. Pour le cas où k = 3, on doit donc faire un nombre cubique de
mesures les unes à la suite des autres ( 61 n(n − 2)(n − 1) où n = |Pe2e |), rendant l'utilisation
de cet algorithme impossible pour des plates-formes de taille même modeste. Il semble donc
logique de modier en conséquence l'algorithme pour permettre de réduire le nombre de
mesures et/ou de rendre ces mesures indépendantes dans le but d'exécuter simultanément
plusieurs mesures.
5.4.4 Un algorithme de reconstruction pour les 1-MINP pour des métriques bornées
Comme nous l'avons dit précédemment, le premier algorithme est trop coûteux en
terme de mesures pour être utilisé dans des plates-formes de dimensions raisonnables. L'algorithme présenté ici tend à diminuer le nombre de mesures dans certains cas, au détriment
90
a
b
c
d
a’
b’
c’
d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
Ajout simple
couverture
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
Regroupement
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
Figure 5.2. Déroulement de l'algorithme sur un exemple simple
de la généricité de l'algorithme présenté auparavant : on ne peut plus reconstruire que des
1-MINP au lieu de k-MINP précédemment. La réduction du problème à celui de la reconstruction de 1-MINP peut être considérée comme relativement justiée si l'on considère
que le réseau est exempt ou contient peu de trac interférent inuant sur la mesure. En
eet, les équipements actuels déployés ont des capacités variant les uns par rapport aux
autres le plus souvent par un facteur 10 (ethernet 100 ou gigabit par exemple). De fait,
la reconstruction de k-MINP ne serait justiée qu'à partir du moment où k ≥ 10, ce qui
rend la procédure de mesure complexe à réaliser. La piste suivie ici pour réduire le coût
de l'algorithme initial est de le rendre "on-line", c'est-à-dire de rendre dépendante des
propriétés des MINP partiels les mesures à eectuer. Par exemple, comme nous l'avons vu
dans l'exemple pour l'algorithme donné à la section 5.4.3, l'acquisition du dernier 3-MINP
représenté était en fait inutile. L'algorithme que nous présentons ici cherche donc à minimiser le nombre de mesures à faire tout en restant identique dans sa forme à l'algorithme
précédent.
91
La principale diculté pour rendre l'algorithme précédent dépendant des résultats déjà
obtenus est la phase de tri, qui dépend des suprema des diérents MINP partiels, et qui
donc, nécessite d'avoir acquis une connaissance sur ceux-ci. Ce point est celui qui motive
l'augmentation des contraintes, à savoir le passage à des 1-MINP ainsi que l'utilisation de
métriques bornées. On peut en eet dénir le lemme suivant :
2 La capacité vis-à-vis d'une métrique bornée d'un supremum (si il existe) d'un 1-MINP
représentant un ensemble de chemins P est égale à la capacité d'un de ces chemins. Ce
chemin aura la capacité la plus grande (vis-à-vis de la relation associée à la métrique) de
l'ensemble P .
Preuve Trivialement, si un supremum existe dans un 1-MINP borné, la capacité de
celui-ci est celle d'un des chemins P , par dénition. De plus, un sous-chemin commun 1détectable étant par dénition un sous-chemin qui peut être saturé par un des chemins de
P , ce sous-chemin est forcément une borne pour l'un des chemins.
Cette propriété permet de contourner le problème de la pré-obtention des MINP, en
utilisant simplement des mesures de la capacité chemin par chemin. Comme on peut le
deviner, cette mesure de capacité, faite individuellement, est de coût beaucoup plus réduit
que l'obtention de mesure d'interactions entre chemins.
De même que précédemment on peut prouver cette fois que :
3 Si un sous-chemin commun 1-détectable a une capacité inférieure vis-à-vis de la rela-
tion d'ordre associée à la métrique m considérée, il ne peut appartenir à aucun chemin de
capacité supérieure quand la métrique est bornée.
Les lemmes précédemment prouvés en section 5.4.3 étant valides pour tous les k-MINP
bornés, ils le sont aussi pour ce cas particulier, et en particulier le lemme 1. L'ordre donné
par l'équation 5.2 est toujours valide dans ce cas. On peut donc aisément pré-trier les
MINP partiels potentiels selon la capacité des chemins qu'ils contiennent.
L'algorithme principal reste donc assez similaire au précédent. En triant les chemins
selon leurs capacités respectives, on peut donc exclure que tout ux dont la capacité est
supérieure partage les sous-chemins communs de capacité inférieure qui sont détectés auparavant ; ceci étant, cela n'est pas forcément réciproque. On itère sur les chemins ; on
maintient donc une liste des chemins communs déjà induits, et pour chaque sous-chemin
déjà induit on recherche si le chemin courant possède un sous-chemin commun avec lui.
Sinon, on doit mesurer toutes les combinaisons avec tous les (sous)-chemins déjà testés.
L'algorithme est décrit de manière formelle ci-après 4.
De part le lemme 3, le MINP partiel constitué après chaque tour de boucle principale
est bien déni.
92
Algorithme 4 Algorithme principal pour la reconstruction d'un 1-MINP borné
Paramètre de sensibilité s, la liste sortPe2e contenant les éléments de Pe2e
triés par rapport à l'ordre ≤ associé à la métrique m, couv(x) fonction donnant la liste
des chemins couverts pour un sous-chemin commun x donné trié par capacité suivant la
relation ≤ associée à la métrique.
Sorties : reconstruction du 1-MINP pour l'ensemble du réseau pour une métrique bornée.
Entrées :
M axList = {0}
i←1
tantque i ≤ length(sortPe2e ) faire
cheminCourant =← sortPe2e [i]
j←1
nouveauxSousChemins ← {0}
tantque j ≤ length(M axList) faire
cheminM axCourant ← M axList[j]
nouveauxSousChemins
←
nouveauxSousChemins
ChercherSousChemin(cheminM axCourant, cheminCourant) (algorithme 6)
∪
n tantque
M axList ← nouveauxSousChemins ∪ M axList
n tantque
Recréer M IN P T otal à partir des éléments de M axList et des relations de couverture
de chacun des éléments.
Les deux autres parties de l'algorithme concernent pour l'une la recherche de souschemins communs, et pour l'autre, la règle de création de nouveaux sous-chemins.
Algorithme 5 CreerSousMax
Paramètre de sensibilité s, cheminM axcourant, cheminCourant.
reconstruction du 1-MINP pour l'ensemble du réseau pour une métrique bornée
Entrées :
Sorties :
unique.
axcourant = ccheminCourant ± s alors
si ccheminM
m
m
ajouter cheminCourant à la liste de chemins couverts par cheminM axCourant
sinon
Sinon, créer un nouveau chemin maximum cheminCourant de capacité ccheminCourant
m
couvrant couv(cheminM axCourant) ∪ {cheminCourant}.
nsi
93
Algorithme 6 ChercherSousChemin
Les nouveaux sous-chemins
Entrées :
Sorties :
si |couv(cheminM axCourant)| == 1AN D{cheminM axCourant, cheminCourant}
admet un sous-chemin commun détectable
alors
nouveauxSousChemins
←
nouveauxSousChemins
creerSousM ax(cheminM axCourant, cheminCourant) (algorithme 5)
∪
sinon
Sinon, ajouter cheminCourant dans la liste nouveauxSousChemins
nsi
si |couv(cheminM axCourant)| == 2
AN D({couv(cheminM axCourant)[1], couv(cheminM axCourant)[2], cheminCourant})
possèdent un sous-chemin commun détectable
alors
nouveauxSousChemins
←
nouveauxSousChemins
∪
sinon
Sinon, ajouter cheminCourant à la liste nouveauxSousChemins
nsi
si |couv(cheminM axCourant)| ≥ 3 alors
∀i, j, k < |couv(cheminM axCourant)|, i 6= j, j 6= k, i 6= k
si {couv(cheminM axCourant)[i], couv(cheminM axCourant)[j], cheminCourant},
{couv(cheminM axCourant)[i], couv(cheminM axCourant)[k], cheminCourant} pos-
sède un sous-chemin commun détectable
alors
nouveauxSousChemins
←
nouveauxSousChemins
∪
sinon
nsi
nsi
retourne nouveauxSousChemins.
5.4.4.2 Exemple
La gure 5.3 montre l'exécution de l'algorithme sur une topologie simple. Les conventions graphiques sont similaires à celle de la gure 5.2.
Les mesures sont donc d'abord eectuées le long de chaque chemin, de manière à déduire
la capacité de chacun. Puis on tente de détecter si le chemin de plus basse capacité possède
un sous-chemin commun avec le chemin de capacité le plus faible, puis on procède de
94
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d
a’
b’
c’
d’
a’
b’
c’
d’
a’
b’
c’
d’
a’
b’
c’
d’
a’
b’
c’
d’
a−>a’
b−>b’
c−>c’
d−>d’
regroupement
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
Figure 5.3. Déroulement de l'algorithme pour les 1-MINP bornés
même pour le troisième. La cardinalité du sous-chemin courant étant de 3, on procède à
l'évaluation de l'applicabilité de la règle de regroupement.
5.4.4.3 Complexité
Etapes de calcul La complexité de cet algorithme est, de par sa nature, variable suivant
la topologie du réseau. Les mesures sur les diérents sous-ensembles du réseau étant faites
"on-line", la principale composante, en terme de coût, provient des mesures. L'algorithme
possède une complexité similaire au nombre de tests requis.
Nombre de tests L'étape initiale permettant d'ordonner les chemins par la capacité de
ceux-ci demande que chaque chemin soit testé séquentiellement pour éviter les interférences,
soit n mesures si n = |Pe2e |. Les étapes suivantes dépendent de la topologie du réseau
sous-jacent ; les deux cas extrêmes sont apparaissent quand il existe un seul sous-chemin
commun 1-détectable pour tous les ux, ou quand il n'en existe aucun. Dans le premier cas,
la complexité sera égale à celle de l'algorithme précédant. Dans le cas contraire, c'est-à-dire
quand tous les chemins de Pe2e sont indépendants, la taille de la liste M axList augmentera
P
de 1 à chaque fois, entraînant en tout O( ni i) mesures, soit O(n2 ) mesures, qui doivent
être eectuées séquentiellement pour éviter les interférences entre mesures.
Cet algorithme est donc moins coûteux que le précédent, même si cela se fait au détri95
ment de la généricité (l'algorithme ne porte que sur la reconstruction de 1-MINP pour les
métriques bornées). Sa complexité reste néanmoins importante, réduisant les possibilités
de mise en oeuvre de celui-ci. Cela est dû à la phase de récursion de l'application de la
règle de regroupement, qui oblige à tester tous les triplets de l'ensemble somme des ensembles couverts par les noeuds regroupables. L'algorithme que nous présentons dans la
section suivante permet de diminuer la complexité (en terme de nombre de mesures) de
cet algorithme.
5.4.5 L'algorithme LTC
L'algorithme précédent peut rester très coûteux en terme de nombre de mesures, du fait
de la phase de récursion nécessaire pour prouver que la règle de regroupement s'applique.
L'algorithme présenté ici coupe cette phase de mesures, en utilisant une propriété propre
aux métriques possédant une borne induite par un lien unique.
L'algorithme reprend le principe général de l'algorithme précédent, et reprend les 3
principaux éléments précédents. Ils ne sont modiés que par l'application du lemme suivant :
4 Soit un ensemble de chemins
P = Pnoyau ∪ {pa , pb , pc }, |Pnoyau | ≥ 0, P
possédant
un sous-chemin commun détectable pour une métrique possédant une borne induite par un
lien unique de capacité α et un chemin pe ∈/ P . Si {pa , pb , pe } et {pa , pc , pe } possèdent
chacun un sous-chemin commun détectable de capacité α pour une métrique possédant une
borne induite par un lien unique, alors P 00 = Pnoyau ∪ {pa } ∪ {pb } ∪ {pc } ∪ {pe } possède
un sous-chemin commun détectable pour une métrique possédant une borne induite par un
lien unique de capacité α .
Preuve Cela signie concrètement qu'en choisissant trois représentants (trois chemins
pa , pb , pc ∈ P ) pour un sous-chemin commun de P , on peut facilement s'assurer, étant
donné un chemin pc que soit P 00 admet un sous-chemin commun, soit non. De manière
similaire à précédemment, on peut constater que la propriété est triviale quand |Pnoyau | =
0, puisqu'elle se réduit à la condition de regroupement.
Intéressons nous au cas où |Pnoyau | = 1, i.e. |Pnoyau | = {pd }. Dans ce cas, on sait de par
les hypothèses ci-dessus et par la règle de regroupement que les ensembles {pa , pb , pc , pd } et
{pa , pb , pc , pe } possèdent chacun un sous-chemin commun de capacité α. Puisque la borne
est unique, les bornes des deux ensembles sont incluses dans le sous-chemin commun de
{pa , pb , pc }, qui par dénition, contient une borne induite par un lien unique. Les bornes
des deux ensembles sont donc en fait la même, celle de l'ensemble {pa , pb , pc }. Il y a donc
une borne induite par un lien unique pour l'ensemble {pa , pb , pc , pd , pe } de capacité α. De
96
même que précédemment, le raisonnement est identique quand |Pnoyau | > 1 en remplacant
pd par le sous-chemin commun étroit détectable de l'ensemble Pnoyau . La diérence ici est
que l'hypothèse de borne induite par un lien unique nous évite de passer par l'étape de
récursion qui implique de tester si le lien est partagé avec tous les éléments de Pnoyau . Il en
résulte qu'en se servant de cette règle pour la reconstruction il n'est plus nécessaire qu'un
grand nombre de triplets soient testés.
L'algorithme principal reste donc assez similaire au précédent en utilisant cette fois ci
la condition de regroupement pour les métriques possédant une borne induite par un lien
unique. En triant les chemins par leurs capacités respectives, on peut donc exclure que
tout ux dont la capacité est supérieure ne partage les sous-chemins communs de capacité
inférieure qui sont détectés auparavant ; ceci étant, cela n'est pas forcément réciproque. On
itère sur les chemins ; on maintient donc une liste des chemins communs déjà induits, et
pour chaque sous-chemin déjà induit on recherche si le chemin courant possède un souschemin commun avec ceux déjà induits. La seule modication par rapport à l'algorithme
précédant est donc la coupure de la procédure de recherche de sous-chemin commun, telle
que décrit de manière formelle ci-après 7.
97
Algorithme 7 ChercherSousCheminLTC
Les nouveaux sous-chemins pour le cas borne induite par un lien unique
Entrées :
Sorties :
alors
nouveauxSousChemins
←
nouveauxSousChemins
creerSousM ax(cheminM axCourant, cheminCourant)
∪
sinon
nsi
alors
nouveauxSousChemins
←
nouveauxSousChemins
∪
sinon
nsi
si {couv(cheminM axCourant)[1], couv(cheminM axCourant)[2], cheminCourant},
{couv(cheminM axCourant)[1], couv(cheminM axCourant)[3], cheminCourant}
alors
nouveauxSousChemins
←
nouveauxSousChemins
∪
sinon
nsi
nsi
5.4.5.2 Exemple
La gure 5.4 montre l'exécution de l'algorithme sur une topologie simple. Les conventions graphiques sont similaires à celles de la gure 5.2.
Les mesures sont donc d'abord eectuées le long de chaque chemin, de manière à
déduire la capacité de chacun. Puis on tente de détecter si le chemin de plus basse capacité
possède un sous-chemin commun avec le chemin de capacité le plus faible, puis on procède
de même pour le troisième. La cardinalité du sous-chemin courant étant de 3, on procède
98
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d
a’
b’
c’
d’
a’
b’
c’
d’
a’
b’
c’
d’
a’
b’
c’
d’
a’
b’
c’
d’
a’
b’
c’
d’
a−>a’
b−>b’
c−>c’
d−>d’
regroupement
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
a−>a’
d−>d’
b−>b’
c−>c’
d−>d’
regroupement
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
b−>b’
c−>c’
d−>d’
a−>a’
a−>a’
b−>b’
c−>c’
b−>b’
c−>c’
d−>d’
d−>d’
Figure 5.4. Déroulement de l'algortime LTC
à l'évaluation de l'applicabilité de la règle de regroupement pour les métriques de borne
induite par un lien unique.
5.4.5.3 Complexité
Etapes de calcul La complexité de cet algorithme est, de par sa nature, variable suivant
la topologie du réseau. Les mesures sur les diérents sous-ensembles du réseau étant faites
"on-line", la principale composante, en terme de coût, provient des mesures. L'algorithme
possède une complexité similaire au nombre de tests requis.
Nombre de tests L'étape initiale permettant d'ordonner les chemins par la capacité de
ceux-ci demande que chaque chemin soit testé séquentiellement pour éviter les interférences,
soit n mesures si n = |Pe2e |. les étapes suivantes dépendent de la topologie du réseau sousjacent ; les deux cas extrêmes apparaissent trivialement quand il existe un seul sous-chemin
commun 1-détectable de capacité minimale pour tous les ux ou quand il n'en existe aucun.
Dans ce cas, chaque adjonction à l'ensemble de chemins déjà couverts par le sous-chemin
commun detecté demandera l'exécution d'un test établissant la couverture par un même
99
sous-chemin commun de deux ensembles de ux, soit 2n mesures de ce type. Dans le cas
contraire, c'est-à-dire quand tous les chemins de Pe2e sont indépendants, la taille de la
P
liste M axList augmentera de 1 à chaque fois, entraînant en tout O( ni i) mesures, soit
O(n2 ) mesures, qui doivent être eectuées séquentiellement pour éviter les interférences
entre mesures.
Cet algorithme est donc moins coûteux que le précédent, même si cela se fait au détriment, encore une fois, de la généricité (l'algorithme ne porte que sur la reconstruction de
1-MINP pour les métriques possédant une borne induite par un lien unique). Sa complexité
reste néanmoins importante, réduisant les possibilités de mise en oeuvre de celui-ci. Cela
est dû à l'absence de possibilité de procéder à des mesures simultanément. L'algorithme
que nous présentons dans la section suivante permet de diminuer la complexité (en terme
de nombre de mesures séquentielles) de cet algorithme.
5.4.6 L'algorithme LTC parallèle
L'algorithme LTCP présenté ici repose sur le lemme simple décrit ici :
5 Soit un ensemble de sous-chemins communs 1-détectables tous indépendants les uns
vis-à-vis des autres et un chemin px pour une métrique bornée unique. Il est possible de
tester simultanément si tous les sous-chemins communs partagent un sous-chemin avec le
chemin px sans interférer sur les mesures.
Si le postulat est simple, et assez simple à prouver (puisque les sous-chemins sont
indépendants et que le lien limitant est unique, il ne pourra exister qu'un lien limitant
entre px et les sous-chemins partageant celui-ci), il se heurte à plusieurs problèmes dans la
réalité :
Chemins n-détectables. L'assertion donnée dans 5.4.5 concernant la pertinence de
tenter de reconstruire des k − M IN P où k > 1 permet de même de justier qu'il
faudra un nombre assez grand de chemins mesurés en parallèle pour avoir à traiter
ce problème. Ce problème est aussi très lié à la mesure en elle-même, qui peut être
capable, éventuellement, de déterminer quel est l'ensemble des chemins couverts par
un sous-chemin commun détecté (ou en tout cas sa cardinalité).
Sous-chemins communs partageant une partie de leur couverture. La procédure impliquant des représentants d'un sous-chemin permet de résoudre une partie du problème. En eet, choisir seulement deux représentants d'un sous-chemin donné permet d'établir le partage de sous-chemin. Néanmoins, on sera confronté à un problème
d'ordonnancement plus ou moins complexe des mesures dans le cas où certains chemins sont couverts par de nombreux sous-chemins. Ceci étant dit, le fait que nous
détections des sous-chemins 1-détectable rend cette hypothèse moins probable.
100
Extensibilité de la mesure à n ux. Si il peut être simple d'intuiter des méthodes de
mesures génériques à n ux, il peut s'avérer infaisable de les mettre en oeuvre pour
des raisons pratiques. Nous considérerons néanmoins ici l'extensibilité réaliste, pour
au moins j ux. Si la méthode de mesure n'est pas extensible à n ux mais à j , il
conviendra de résoudre ce problème par un ordonnancement ad hoc des mesures. Ce
problème d'extensibilité des mesures peut rendre plus simple le problème de souschemins communs partageant une partie de leur couverture cité précédemment.
Le principe de l'algorithme reste, en dehors des problèmes sus-mentionnés, très proche
de l'algorithme LTC. Nous donnons dans la gure 5.4.6 la description formelle de l'algorithme. On retrouve toujours les 3 étapes principales de celui-ci :
la mesure faite en amont des capacités de chaque chemin appartenant à Pe2e puis le
tri de la liste de ceux-ci suivant la relation ≤ associée à la métrique m considérée,
La mesure "on-line" de l'existence de sous-chemin commun est identique, sauf que la
boucle interne sur les sous-chemins communs déjà détectés à l'étape i est cette fois
rendue parallèle par l'utilisation de mesures parallèles.
La reconstruction du treillis en utilisant la liste des sous-chemins communs détectés
et leurs relations de couverture.
101
Algorithme 8 Algorithme principal LTC parallèle
Paramètre de sensibilité s, la liste sortPe2e contenant les éléments de Pe2e
triés par rapport à l'ordre ≤ associé à la métrique m, couv(x) fonction donnant la liste
des chemins couverts par un sous-chemin commun x donné trié par capacité suivant la
relation ≤ associée à la métrique.
Sorties : reconstruction du 1-MINP pour l'ensemble du réseau pour une métrique bornée
unique.
Entrées :
M axList = {0}
i←1
tantque i ≤ length(sortPe2e ) faire
cheminCourant =← sortPe2e [i]
j←1
Mesurer si les éléments de M axList ont un sous-chemin commun détectable avec
cheminCourant. Le sous-ensemble de sous-chemins de M axList admettant un souschemin commun avec cheminCourant sera noté cheminsDetectes, l'inverse de celui-ci
cheminsIndependants.
pour j ≤ |cheminsDetectes| faire
cheminM axCourant ← cheminsDetectes[j]
nouveauxSousChemins
←
nouveauxSousChemins
∪
n pour
pour tout cheminsIndependants faire
Chercher si les sous-ensembles des ensembles contenus dans cheminsIndependants privés de leurs représentants présentent des sous-chemins communs avec cheminCourant.
n pour
nouveauxSousChemins ← nouveauxSousChemins ∪ M axList
Réduire éventuellement l'ensemble M axList en utilisant le principe de couverture
unique.
n tantque
Recréer M IN P T otal à partir des éléments de M axList et des relations de couverture
de chacun des éléments.
5.4.6.2 Exemple
La gure 5.5 donne un exemple d'exécution de l'algorithme pour une topologie simple.
Dans la gure, pour des questions de place, nous avons omis les phases de mesures ne
trouvant pas de sous-chemins communs entre les chemins qui amènent à la construction
102
des deux sous-chemins existants. La dernière ligne illustre le cas où les deux sous-chemins
communs sont déjà trouvés, et où on évalue si le dernier chemin ne partage pas de souschemins communs avec eux.
a
b
c
d
e
a
b
c
d
e
a
b
c
d
e
a
b
c
d
e
a
b
c
d
e
a
b
c
d
e
a’
b’
c’
d’
e’
a’
b’
c’
d’
e’
a’
b’
c’
d’
e’
a’
b’
c’
d’
e’
a’
b’
c’
d’
e’
a’
b’
c’
d’
e’
ajout simple
a−>a’
b−>b’
c−>c’
d−>d’
e−>e’
a−>a’
b−>b’
c−>c’
d−>d’
e−>e’
a−>a’
b−>b’
c−>c’
d−>d’
e−>e’
a−>a’
b−>b’
c−>c’
d−>d’
e−>e’
ajout simple
a−>a’
b−>b’
c−>c’
d−>d’
e−>e’
a−>a’
b−>b’
c−>c’
d−>d’
e−>e’
Figure 5.5. Déroulement de l'agorithme LTCP
5.4.6.3 Complexité
Etapes de calcul De même que pour l'algorithme LTC, l'algorithme LTCP possède une
complexité en étape de calcul liée à l'exécution des mesures. Il est, lui aussi, polynomial,
de complexité en terme de calcul négligeable par rapport à la complexité nécessaire en
nombre de tests.
Nombre de tests Le nombre de tests est ici variable suivant la topologie du réseau
sous-jacent ainsi que l'extensibilité de la mesure utilisée lors des tests parallèles. Notons
que dans le cas où tous les ux partagent un unique sous-chemin commun, celle-ci reste
linéaire suivant le nombre de ux (toujours 3n). Dans le cas le plus coûteux précédemment
cité, i.e. le cas où aucun sous-chemin commun n'existe celui-ci reste maintenant aussi
linéaire (n fois des mesures dont la cardinalité varie entre 1 et n). Le cas le plus coûteux
devrait être celui où les chemins partagent plusieurs sous-chemins communs les uns avec
les autres, forçant un ordonnancement des mesures sur plusieurs étapes. Notons ici que les
performances réelles de cet algorithme dépendent des capacités de l'ordonnancement des
j-mesures.
103
5.4.7 Un algorithme de reconstruction pour les 1-MINP en relaxant
l'hypothèse de borne induite par un lien unique
La condition d'unicité de borne sur les métriques peut sembler une hypothèse forte ; en
contrepartie, elle permet de diminuer drastiquement le nombre de mesures à eectuer en
limitant le nombre de triplets à tester pour assurer l'application de la règle de regroupement
classique. On peut intuitivement se demander si il ne serait pas rentable de relaxer cette
hypothèse en ne testant qu'un sous-ensemble des triplets contenant le nouveau chemin,
plutôt que l'ensemble de ceux-ci, tout en acceptant un risque de détection d'un faux-vrai.
Il convient donc d'analyser les conditions pour lesquelles on peut avoir ce faux-vrai.
5.4.7.1 Relaxation de l'hypothèse de borne induite par un lien unique
Dans la plupart des cas que nous avons décrit dans le chapitre 2, les plates-formes de
grilles sont constituées de sites reliés entre eux par des réseaux haut débit. Si l'on considère
que les points de saturations sont à l'entrée et à la sortie de ces sites, cela signie que les
chemins présentent au plus deux liens 1-détectables, l'un à la sortie du site hébergeant
l'hôte à l'origine du chemin, l'autre à l'entrée du site hébergeant l'hôte à la destination
dudit chemin. Si les capacités de ces liens étroits sont assez également réparties, on peut
considérer qu'un couple de chemins partagera au plus deux liens étroits dans les cas réels,
et, si l'hypothèse de consistance du routage est vériée, d'un seul lien faisant oce de
sous-chemin commun maximum 1-détectable.
Hormis des hypothèses telles que celles-ci sur la nature de la topologie du réseau et
ses propriétés, rien ne permet de spéculer sur le nombre de sous-chemins communs à des
ensembles de chemins. Supposons que l'on ait, à un moment donné de la reconstruction, un
ensemble P de chemins de cardinalité n partageant un sous-chemin commun détectable.
Supposons qu'un chemin pc partage un sous-chemin commun détectable avec pa , pb ∈ P .
Par dénition, soit il existe un sous-chemin commun détectable à tous les chemins de
P ∪ {pc }, soit il existe un sous-chemin commun entre les chemins d'un P 0 ⊂ P et de pc ,
ainsi qu'un ensemble de chemins P 00 = P \ P 0 pour lesquels il n'existe pas de sous-chemins
communs entre pc et pa , pb ∈ P 00 .
Si l'on considère qu'il n'existe pas de propriétés particulières au réseau sous-jacent,
les ensembles P 0 et P 00 sont donc une partition de l'ensemble P . Cette partition étant
quelconque, on peut en déduire que la probabilité qu'un chemin appartienne à P 0 ou P 00
est donc de 21 . La détection d'un faux vrai se faisant lorsqu'au moins l'un des deux chemins
de P tiré au hasard parmi les n − 2r chemins restant à la r-ième mesure conrmant la règle
de regroupement appartient à l'ensemble P 00 , on peut donc estimer la probabilité P rob(A)
104
de n'avoir pas détecté un faux vrai à la r-ième mesure comme suit :
P rob(A) =
r−1
Y
C 2n −2i
i=0
2
Cn−2i
2
r−1
Y
( n2 − 2i − 1)( n2 − 2i)
(n − 2i − 1)(n − 2i)
i=0
r
1
≈
4
=
(5.3)
Grâce à cela, on peut, pour un degré de conance donné d, xer le nombre de mesures
optimales pour estimer si la règle de regroupement est applicable, ou non, simplement en
r
choisissant r tel que 14 ≤ 1 − d.
Cette technique reste cependant très dépendante d'une certaine homogénéité de la
répartition des chemins ainsi que de celles des sous-chemins communs 1-détectables sur
ceux-ci. Cependant, il faut aussi garder à l'esprit que cette technique est appliquée à des
1-MINP pour des métriques bornées : cela signie que les deux sous-chemins communs
détectables de P 0 et P 00 respectivement ont la même capacité (à un paramètre de sensibilité
s) ce qui rend moins probable l'existence de ceux-ci.
L'algorithme de reconstruction est donc similaire à celui présenté en section 5.4.5,
excepté pour la procédure de recherche de sous-chemins. Celle-ci fait donc r mesures au
lieu de 1. Dans le cas où la présence de deux sous-chemins communs est détectée, on
procède à la détermination de l'appartenance à chacun des ensembles P 0 et P 00 , puis, le
noeud correspondant à P 0 est ajouté. La procédure de recherche de sous-chemins communs
est donnée à la gure 9. La procédure en cas de faux-vrai détecté est elle décrite à la gure
10.
105
Algorithme 9 ChercherSousChemin - Relaxation de la borne unique
Paramètre de sensibilité s, cheminM axcourant, cheminCourant, r.
Les nouveaux sous-chemins
Entrées :
Sorties :
alors
nouveauxSousChemins
←
nouveauxSousChemins
∪
sinon
nsi
alors
nouveauxSousChemins
←
nouveauxSousChemins
∪
sinon
nsi
l←1
si
{couv(cheminM axCourant)[1], couv(cheminM axCourant)[2], cheminCourant},
{couv(cheminM axCourant)[1], couv(cheminM axCourant)[3], cheminCourant}
possède un sous-chemin commun détectable
alors
booleanf auxvraidetecte = f aux
tantque l ≤ rOR!f auxvraidetecte faire
Choisir deux chemins couv(cheminM axCourant)[i] et couv(cheminM axCourant)[j]
non précédemment testés dans la couverture de cheminM axCourant
si {couv(cheminM axCourant)[i], couv(cheminM axCourant)[j], cheminCourant} ne
possède pas de sous-chemin commun détectable alors
f auxvraidetecte = vrai
nsi
l ←l+1
n tantque
nsi
si fauxvraidetecte alors
fauxVraiDetecte(cheminCourant, cheminM axCourant) (alogrithme 10).
nsi
nsi
106
Algorithme 10 fauxVraiDetecte(cheminCourant, cheminM axCourant) : Cas de faux
vrai - Relaxation de la borne unique
Entrées :
Sorties :
cheminCourant, cheminM axCourant
Nouveau sous-chemin correct créé
Créer un nouveauSousChemin
couv(nouveauSousChemin) = couv(nouveauSousChemin) + cheminCourant
∀i, j, k < |couv(cheminM axCourant)|, i 6= j, j 6= k, i 6= k
si {couv(cheminM axCourant)[i], couv(cheminM axCourant)[j], cheminCourant},
{couv(cheminM axCourant)[i], couv(cheminM axCourant)[k], cheminCourant} pos-
sède un sous-chemin commun détectable
alors
couv(nouveauSousChemin) = couv(nouveauSousChemin) + {i, j, k}
sinon
nouveauxSousChemins
←
nouveauxSousChemins
∪
nsi
5.4.7.3 Exemple
Vu le peu de diérences entre les exécutions de cet algorithme et celui donné pour les
1-MINP bornés uniques, nous ne donnons pas ici d'exemple.
5.4.7.4 Complexité
Etapes de calcul Le nombre d'étapes de calcul reste toujours négligeable par rapport
aux nombre de mesures à eectuer ; il est cependant similaire au nombre de mesures à
eectuer, puisque l'algorithme fonctionne de manière "on-line".
Nombre de tests La complexité de cet algorithme est plus importante que celle de l'algorithme LTC mais il reste moins coûteux que l'algorithme le précédent pour les métriques
bornées. Elle est, hormis le facteur r, similaire à celle de l'algorithme LTC.
5.5
Vers des algorithmes hybrides pour la reconstruction de
MINP
Comme nous l'avons vu au travers des algorithmes décrits précédemment, les techniques
de reconstruction sont coûteuses, surtout en terme de mesures. Il semble naturel de se tourner soit vers des heuristiques pour améliorer le temps de reconstruction de représentations
MINP du réseau, ou encore vers l'utilisation de données provenant de sources diérentes.
107
Une limite théorique simple permet de s'en persuader. Considérons une relation quelconque
entre les chemins (conjonction, disjonction, "avoir un sous-chemin commun") et supposons
que nous disposions d'une technique de mesure qui nécessite que les ensembles de chemins
testés soient testés séquentiellement pour éviter les interférences entre mesures, et qu'elle
puisse, comme celle utilisée dans l'algorithme LTCP, parvenir à évaluer les interférences
entre un chemin et un ensemble de chemins indépendants entre eux. Pour un ensemble Pe2e
de chemins tous indépendants entre eux, l'évaluation des relations liant les chemins les uns
avec les autres, nécessite que l'on teste une paire de chemins, puis, si ils sont indépendants,
3 chemins, et ainsi de suite, ce qui implique |Pe2e | étapes de mesures. Si les chemins ne sont
pas tous indépendants, cela conduit à une augmentation du nombre de mesures. Notons
que le nombre de mesures minimal est de plus celui où il n'y a aucune interférence entre les
chemins, ce qui laisse supposer que l'éventuel utilisateur de la méthode n'aura rien gagné
à l'appliquer. Ceci implique donc que l'on peut au mieux être linéaire par des méthodes
de ce type si l'on ne connaît rien des chemins de Pe2e . L'utilisation de quelque méthode
que ce soit reste donc coûteuse, à moins d'être capable d'utiliser des informations sur les
chemins provenants de sources extérieures.
5.5.1 Algorithmes hybrides utilisant des données complètes
5.5.1.1 Données d'entrée
Nous considérons ici que nous pouvons connaître entièrement la topologie physique du
réseau grâce à un outil tel que traceroute, c'est-à-dire qu'aucun des points existants dans
le réseau n'est ignoré (modulo certains appareils tels que les hubs, mais ceux-ci sont de nos
jours de plus en plus rare). Ce type d'information est celui que l'on obtient lorsque l'on
utilise la technique d'identication d'équipement réseau telle que décrite en section 3.1.4.1.
Nous avons présenté, en section 4.3.2.4 le modèle d'∞-MINP, et en section 4.3.2.6, comment
reconstruire une telle représentation du réseau en ayant à disposition des informations de
type traceroute.
Nous considérerons donc, dans cette section, que nous disposons de l'∞-MINP correspondant au réseau sous-jacent, puisqu'on peut l'obtenir par les transformations simples
citées ci-avant. La reconstruction de MINP consistera donc à établir quels sont les souschemins communs qui sont détectables, et quels sont ceux qui ne le sont pas, à partir de
de cet ∞-MINP.
5.5.1.2 Quelques propriétés des 1-MINP bornés
Quelques transformations dans le cas des 1-MINP bornées peuvent être eectuées sans
même procéder à une mesure de manière à simplier l'∞-MINP. Ces transformations reposent sur la règle de couverture unique. Dans l'∞-MINP obtenu, la topologie peut avoir
engendré des noeuds ayant la même couverture. On peut donc, en partant du supremum,
108
parcourir l'∞ − M IN P et confondre les noeuds possédant la même couverture, de manière
à réduire le nombre de noeuds.
Une deuxième transformation repose sur la propriété suivante :
6 Soit un ∞-MINP utilisé pour reconstruire un 1-MINP borné. Si un noeud x de l'∞-
MINP ne représentant pas un chemin complet (i.e. un chemin de Pe2e ) et n'ayant pas de
ls qui soit un chemin de Pe2e , possède un ls y de même capacité que x qui ne représente
pas non plus un chemin complet de Pe2e et qui n'a qu'un père (i.e. x), alors le ls peut être
confondu avec son père (x et y peuvent être confondus).
Preuve La couverture du noeud y est un sous-ensemble de celui de x. De plus, ces deux
noeuds ayant la même capacité, ils sont indiscernables les uns des autres, sauf si le noeud
y présente un lien vers une autre couverture. Puisque ce noeud n'a qu'un père, cela n'est
pas le cas, et on peut donc confondre x et y .
Cette propriété peut être utile lors de la phase de reconstruction. En eet, de par cette
étape, nous obtenons un MINP pré-étiqueté ne contenant plus de noeud qui ne puisse être
1-détectable. En eet, les noeuds 2-détectables ou plus sont des noeuds dont la capacité
(pour les métriques bornées) est supérieure à la capacité de son ls qui possède la plus
importante (par rapport à la relation associée à la métrique) capacité. Il ne reste donc,
dans ces topologies que des noeuds potentiellement 1-détectables.
5.5.1.3 Algorithme de reconstruction de 1-MINP borné
Un algorithme de reconstruction permettant d'utiliser un ensemble complet de données
provenant de traceroute peut être construit comme suit.
La première étape de reconstruction, est de reconstruire l'∞-MINP en suivant la procédure décrite en section 4.3.2.6.
Un moyen peu coûteux de réduire encore le MINP non valué est d'utiliser la propriété
simple donnée en section 5.5.1.2. Pour cela on évalue la capacité de chaque chemin de
Pe2e . Cela permet de réaliser un pré-étiquetage des chemins, puisque tout noeud de N
est soit indétectable, soit étiqueté par la capacité de son ls de plus grande capacité. Une
fois ce pré-étiquetage fait, ce qui est simple à réaliser en partant de l'inmum, on doit
réévaluer le respect de la règle de couverture unique. Notons qu'à la n de cette étape,
tous les sous-chemins communs existants dans le MINP résultant de ces transformations
possèdent une couverture diérente les uns des autres. Notons aussi, que par dénition,
cet ∞-MINP respecte l'inégalité 4.14, c'est-à-dire que le nombre m de sous-chemins du 1MINP pré-étiqueté est inférieur ou égal à la cardinalité de Pe2e , n, et ce de par l'application
des transformations 6 et 5.5.1.2.
Quand tous les noeuds du MINP pré-étiqueté ont une couverture diérente, on peut
utiliser la propriété suivante :
109
7 Soit un 1-MINP pré-étiqueté dont chacun des noeuds a une couverture diérente des
autres. Soit un noeud x et un noeud y de ce MINP ne représentant pas un chemin complet
de Pe2e , tels que couv(x) ⊂ couv(y), |couv(x)| ≥ 2. Il est toujours possible de trouver
un ensemble P et un ensemble P 0 de cardinalité supérieure ou égale à 2 tels que P ⊆
couv(x), P 0 ⊆ couv(y), pa ∈ P, pb ∈ P 0 , pa ∈
/ P 0 , pb ∈
/ P, |P | = |P 0 |, P = {pa } ∪ |P 0 | \ {pb }.
Preuve Cette propriété est triviale de par la dénition des ensembles. Soit
couv(x) =
en choisissant P = {px , py }
{px , py }, et couv(y) = {px , py , pz }. On peut construire P et
et P 0 = {py , pz }, et donc pa = px et pb = pz . On obtient donc bien les ensembles désirés.
On peut généraliser en prenant couv(x) = {px , py } ∪ Q et couv(x) = {px , py , pz } ∪ Q ∪ R
où Q et R sont des sous-ensembles de Pe2e quelconques.
P0
Cette propriété est utile quand on cherche à éliminer des chemins du MINP valué
obtenu : cela signie qu'on est capable, en 2 mesures, l'une sur P et l'une sur P 0 d'estimer,
en cas de sous-chemin commun détecté, si on a détecté x ou bien y . Si on établit que x et
y sont detectés tous les deux, alors on peut confondre x avec y si ils possèdent la même
capacité, excepté si x possède plusieurs pères. Si ils n'ont pas la même capacité, alors on
peut conserver x et y . si l'on détecte x et non y , alors y est indétectable.
L'étape suivante consiste à établir quels sont les sous-chemins communs qui sont 1détectables. Notons ici que la condition de regroupement, qui étayait nos précédents algorithmes, n'a plus d'utilité ici, puisque la couverture des diérents sous-chemins communs
possibles est déjà connue. Elle sera remplacée par l'estimation de l'existence de x ou de y
basée sur la propriété sus-citée.
Plusieurs approches sont possibles, entre autres :
Une approche où l'on présuppose que les sous-chemins communs ayant les couvertures
les plus grandes ne sont pas détectables, et où on élague donc le MINP des noeuds
superus en cherchant à éliminer d'abord les liens de couverture les plus grandes.
Une approche où l'on présuppose que les sous-chemins communs ayant les plus petites couvertures ne sont pas détectables, et où l'on élague le MINP par le bas, en
supprimant les noeuds de couverture les plus petites en premier.
Une approche où l'on cherche à réduire le plus vite possible le nombre de noeuds du
MINP, en prouvant que certains ensembles de noeuds ne sont pas couverts par des
sous-chemins détectables.
Pour chacune de ces méthodes, on peut procéder comme suit. Supposons que nous
disposions d'une 1-mesure k-test, c'est-à-dire que l'on puisse évaluer l'existence de souschemins communs 1-détectables pour un ensemble de k chemins. La première étape est de
générer la liste des sous-ensembles de cardinalité inférieure ou égale à k et supérieure ou
égale à 2 d'éléments de Pe2e , puis à évaluer le critère suivant lequel on désire traiter en
priorité les chemins. Par exemple, pour réduire le plus vite possible le nombre de noeuds du
110
MINP pré-étiqueté, on évalue le nombre d'ancêtres communs que ces ensembles partagent.
Puis on peut ordonner la liste de ces ensembles suivant le critère évalué.
Puis on teste l'existence d'un sous-chemin commun pour un premier ensemble x. Deux
cas se présentent :
On n'a pas réfuté l'existence de sous-chemin commun détectable pour cet ensemble de
chemin. On passe à l'ensemble père (ou ls) suivant pour évaluer y . Comme explicité
précédemment, cela nous permet de conrmer ou d'inrmer l'existence de x, de y ou
de l'un de ses ls.
On a réfuté l'existence de sous-chemins communs détectables pour cet ensemble :
cela signie qu'aucun des ancêtres n'existe. On peut donc supprimer ces ancêtres
dans N . Il est nécessaire de réévaluer le nombre d'ancêtres des ensembles restants,
puis de les réordonner comme précédemment.
5.5.1.4 Complexité
La complexité des diérentes techniques dière suivant la topologie du réseau sousjacent. Cependant, elle est en terme de mesures nettement inférieure aux algorithmes basés
uniquement sur les données issues de mesures.
Etapes de calcul Les étapes de calcul sont ici nombreuses, de par l'application de la
règle de couverture unique, de la règle de confusion du père et du ls pour les 1-MINP
bornés, ainsi que pour le tri et la réévaluation des couvertures des diérents noeuds et
sous-ensembles des couvertures de ceux-ci, et elles impliquent une utilisation mémoire
importante. Néanmoins comme précédemment on estime que ce temps de calcul reste
toujours négligeable devant le temps de mesure.
Nombre de tests Le nombre de mesures dépend beaucoup de la topologie sous-jacente.
Celui-ci peut néanmoins être borné. On a de toute facon un ensemble de |Pe2e | mesures
à eectuer pour construire le 1-MINP pré-étiqueté. Puisque l'opération de comparaison
de x et y permet à chaque fois de conrmer l'existence ou l'inexistence d'un sous-chemin
commun détectable du 1-MINP pré-étiqueté, on peut conclure, puisque le nombre de souschemins communs du 1-MINP est borné par n, que ces techniques ont une complexité au
pire linéaire suivant le nombre de noeuds représentants des sous-chemins dans le MINP, et
donc, n.
5.5.2 Algorithmes hybrides utilisant des données partielles
5.5.2.1 Données d'entrée
Nous considérons ici que nous disposons d'un ensemble d'∞-MINP partiels correspondant à des sous-parties du réseau P ⊂ Pe2e . Cette fois-ci, les données peuvent donc
111
provenir d'outils de type traceroute, si certains noeuds n'ont pas répondu, ou bien encore
de données locales connues d'un utilisateur souhaitant utiliser ce type d'algorithme, comme
par exemple les liens existants entre certaines machines d'un même site appartenant à la
plate-forme de grille.
Un autre type de données partielles que l'on peut obtenir de mesures par traceroute est
un ensemble de données parcellaires, c'est-à-dire qui ne portent que sur un certains nombre
de points d'un chemin logique. On procédera de même pour ces données, en vériant
la détectabilité des éventuels sous-chemins communs existants. On obtiendra de fait un
ensemble de relations entre chemins, ce qui n'est pas génant pour la méthode proposée ici
pour travailler avec des données hybrides.
Dans un premier temps, on appliquera les transformations données en section 5.5.1.2
de manière à simplier ces données.
5.5.2.2 Algorithmes hybrides pour la reconstruction de 1-MINP pour une
métrique bornée
De manière à exploiter les données d'entrées transformées, il n'est plus possible d'utiliser la première approche cité en section 5.5.1.3, c'est-à-dire de présupposer que les souschemins communs détectables de plus grande couverture ne sont pas détectables, car nous
ne connaissons pas ceux-ci. Il convient donc, dans ce cas, d'utiliser la deuxième ou la troisième approche de la section 5.5.1.3. Elle est en eet applicable à tous les MINP partiels
qui ont été donnés en entrée.
A la n de cette étape, on obtient donc un ensemble de MINP partiels complètement
dénis. Des modications simples peuvent être faites sur les algorithmes que nous avons
donnés précédemment pour les 1-MINP bornés (section 5.4.3, 5.4.4, 5.4.5, 5.4.7 ou encore 5.4.6) de manière à tirer partie de ces MINPs partiels. Ces modications portent sur
l'évaluation lors de la recherche de sous-chemins communs : plutôt que de recourir à des
mesures pour connaître l'existence de sous-chemins communs, il sut de vérier d'abord
si cette connaissance peut être établie en utilisant les MINP partiels déjà obtenus. Une
formalisation de cette technique est donnée à la gure 11.
Algorithme 11 évaluer le MINP partiel x, y et z
Entrées :
x, y, z chemins.
MINP partiel pour {x, y, z}
si {x, y, z} appartiennent à un MINP partiel connu
Renvoyer MINP partiel {x, y, z}
Sorties :
alors
sinon
Mesurer le MINP partiel {x, y, z}
nsi
112
Notons que cette méthode permet tout aussi simplement d'intuiter des méthodes permettant d'agglomérer les données issues de MINP partiels déjà obtenus, ou encore de
modèles dont les données peuvent être simplement transformées en 1-MINP suivant les
méthodes décrites en section 4.3.2.6.
5.5.3 Vers une utilisation réelle des MINP
D'une manière générale, un utilisateur nal désirera mettre le moins de temps possible pour reconstruire une topologie complète. Dans le cadre d'une utilisation réelle de ces
méthodes, et comme dans beaucoup de domaines, il peut être très utile d'avoir une intervention humaine intelligente sur les données initiales, de manière à minimiser le nombre
de mesures.
Un point crucial est le choix des chemins qui feront partie de l'ensemble Pe2e . Plus
cet ensemble de départ sera réduit, plus petit sera la nombre de mesures nécessaires à la
reconstruction de MINP.
Par exemple, un moyen simple et ecace de réduire le nombre de mesures est de choisir
un hôte représentant d'un site, d'où partira/arrivera chacun des chemins inclus dans Pe2e
pour ce site.
En eet, si cet hôte est judicieusement choisi, il sera simple d'aggréger les données
connues localement sur le réseau et sa topologie et la représentation MINP du réseau
général. La gure 5.6 illustre un tel choix.
Figure 5.6. Choix d'un représentant
Pour chaque site (isolé par un cercle) on choisit un représentant (la machine à la fois
113
source et destination colorée dans la gure). Il sut, si l'on peut connaître de manière
simple la topologie menant au lien sortant du site de la machine, d'eectuer une construction du MINP local reliant chacune des machines, puis de concaténer ce MINP avec le
MINP reliant chacun des représentants de sites. Un moyen pour élire automatiquement un
représentant de site, qui, à priori, devrait être au plus près de la sortie de celui-ci peut être
par exemple le suivant. On mesure le RTT et la capacité de chacun des chemins appartenant à Pe2e ayant comme source des hôtes appartenant à un site Ss et destination un hôte
appartenant à un autre site Sd . L'estimation de la capacité étant requise pour l'application
de tous les algorithmes présentés ici, et les mesures de RTT pouvant être eectuées en
parallèle, ce processus est peu coûteux. Le chemin parmi ceux ayant la meilleure bande
passante disponible et ayant le plus court RTT devrait être à priori le chemin reliant les
meilleurs représentants de Ss et Sd , ceux-ci étant physiquement les plus proches de la sortie de chaque site. On peut donc, en formant des couples entre sites, élire un représentant
pour chacun d'eux. La reconstruction de MINP peut se faire, une fois des représentants
choisis, et dans l'hypothèse où chaque site possède une sortie (resp. entrée) unique vers
l'extérieur, en 2 étapes distinctes de mesures, à savoir l'établissement du MINP inter-site
pour la première étape, et pour la deuxième, l'établissement d'un MINP local pour chacun
des sites. Pour chaque site Ss , le MINP local représentera les interactions entre les chemins
Ss
Ss
appartenant à Pe2e internes au site et un ensemble de chemins P Ss = Pentrant
∪ Psortant
,
Ss
Pentrant étant l'ensemble de chemin ayant pour origine le représentant et pour destination
Ss
les noeuds du site, et Psortant
l'ensemble de chemins ayant pour destination le représentant
et pour origine les noeuds du site. Ces deux ensembles représentent donc les sous-chemins
communs locaux aux éventuels chemins sortant du site, ou y entrant. La concaténation
des MINP locaux avec le MINP total inter-site peut se faire relativement simplement, en
considérant que le chemin partant du représentant de Ss à destination du représentant du
site Sd est le sous-chemin commun de l'ensemble Psd des chemins plus longs appartenants
à Pe2e ayant pour origine des noeuds du site Ss et pour destination des noeuds du site
destination Sd . De même, on considère que les chemins intra-site ayant pour origine le
représentant de Sd et destination les noeuds du site Sd sont des sous-chemins des chemins
de Psd (et inversement, ceux ayant pour origine les noeuds de Ss et pour destination le
représentant de Ss ). Dans ce cas, la concaténation se fait en 2 étapes : la première consiste
à ajouter au MINP total un noeud x père du chemin ayant pour origine le représentant
de Ss et pour destination celui de Sd , de même capacité que ce chemin, puis à lui donner comme ls le chemin entre représentants (si celui-ci fait partie de Psd ) ainsi que les
Ss
sous-chemins les plus courts (i.e. les sous-chemins ls directs de Ω) de l'ensemble Psortant
Sd
et Pentrant
, formant par concaténation avec le chemin inter-site représenté par le noeud x
les chemins de Psd .
Il ne reste plus qu'à éliminer les éventuels doublons, ainsi que les sous-chemins indé114
tectables sur la totalité du chemin introduits par cette concaténation. On confond dans un
premier temps tous les noeuds ayant une capacité plus grande que (ou égale ±s à) celle
de leur père, puisque par dénition ils ne sont plus détectables dans le chemin complet.
En appliquant la règle de couverture unique, on peut ensuite confondre les noeuds entre
eux. Dans le cas où deux noeuds à confondre ont des capacités diérentes, on étiquette le
noeud né de cette confusion par la capacité la plus basse.
Dans le cas où plusieurs sorties (resp. entrées) de sites existent, on peut procéder de
même que précédemment, en utilisant un représentant par sortie (resp. entrée) de site,
qui peut être élu de même que précédemment, à condition, bien sûr, de savoir quelles
sont les sorties (resp. entrées) utilisées par les chemins de Psd . Notons que dans ce cas,
Ss
Ss
l'ensemble P Ss = Pentrant
∪ Psortant
n'augmentera pas suivant le nombre de représentant,
S
Ss (ri )
Ss (ri )
Ss
car si on q représentants ri , on aura Pentrant
= qi=0 Pentrant
, où Pentrant
est l'ensemble de
chemins entrants reliant le représentant ri aux noeuds de Ss qui sont des noeuds destination
Ss
de chemins de Pe2e qui passent par l'entrée représentée par ri . L'ensemble Psortant
sera
constitué de même.
D'une manière générale, l'utilisation de représentants fera que certaines méthodes seront
plus ecaces. Par exemple, la relaxation de l'hypothèse de borne induite par un lien unique
est très dépendante de l'ensemble de Pe2e . Or, si Pe2e est constitué de l'ensemble de chemins
d'un graphe complet sur une topologie en étoile, alors on peut démontrer que la probabilité
qu'un chemin appartienne à P ou P 0 est exactement 1/2, ce qui rend cette méthode d'autant
plus sûre.
Enn, utiliser réellement les MINP implique d'être capable d'inrmer ou de prouver
l'existence d'un sous-chemin commun détectable à un ensemble de chemins. Ceci est le
sujet du chapitre suivant.
5.6
Synthèse
Comme nous l'avons vu dans ce chapitre, nombre d'algorithmes existent pour reconstruire une représentation des connaissances que l'on a des performances du réseau, tous
plus ou moins dédiés à la modélisation pour laquelle ils ont été pensés. De même que les
travaux existants, ceux eectués dans le cadre de cette thèse ont porté sur l'algorithmique
de reconstruction pour le nouveau modèle introduit au chapitre précédant. Après avoir
donné un premier algorithme démontrant avec succès la faisabilité de cette reconstruction,
un ensemble d'algorithmes a été donné, ayant pour but de réduire le temps total de reconstruction, en s'appliquant à réduire le nombre de mesures à eectuer, en jouant sur
les hypothèses portant sur les métriques, le facteur de détectabilité k, la conance sur le
115
résultat obtenu ainsi que sur le type de techniques de mesures utilisées.
Puis un ensemble d'algorithmes hybrides, utilisant des informations provenant de sources
diverses ont été donnés de manière à réduire encore la complexité en terme de mesure des
méthodes considérées, amenant à des algorithmes qui peuvent avoir une complexité, en
terme de mesures, au maximum égal au nombre de chemins, soit |Pe2e |. Enn, un ensemble
de conseils pour la mise en oeuvre dans des cas réels de ces algorithmes a été donné.
116
Techniques de mesures pour les sous-chemins
communs étroits
Ce chapitre traite des diérentes techniques de mesures pour évaluer l'existence et
les performances d'un sous-chemin commun détectable entre plusieurs chemins. La vue
d'ensemble des techniques de mesures existantes porte sur les techniques de mesures actives,
qui représentent la majorité des techniques développées ; cependant il faut noter que des
techniques de mesures passives existent [45] [104]. Notons que nous traitons ici des cas où
les sous-chemins communs sont communs à plus d'un chemin. Nous avons au chapitre 2
section 3.2 dressé un rapide portrait des techniques existantes pour le cas de l'estimation
de la bande passante disponible ou bien encore de la capacité en bande passante d'un seul
chemin.
Notons aussi que les techniques sont souvent extrêmement dépendantes de la mesure
pour laquelle elles ont été conçues. La majeure partie des travaux dans ce domaine porte
sur le délai [89][60] ou le taux de perte [49], [66] qui possèdent des propriétés intéressantes
pour la reconstruction de MINT (monotonicité, séparabilité, symétrie dans le cas du délai
quand le routage est lui aussi symétrique). De nombreux travaux présentent des techniques
de mesures basées sur des mesures multicast ; notre travail se basant sur les techniques de
mesures unicast, nous porterons une emphase particulière sur ceux-ci.
6.1
Techniques existantes
L'immense majorité des techniques de mesures de sous-chemins communs étroits est
basée sur une notion d'entrelacements de paires de paquets, proche des techniques de
mesures de la bande passante pour un seul chemin basées sur des paires de paquets dos
à dos. C'est le cas des techniques par paires de paquets imbriquées, de la technique de la
cartouche ou de l'approche bayésienne par exemple. Nous donnons ici quelques exemples
de ces méthodes.
6.1.1 Méthode par paires de paquets imbriquées
Ces techniques dites packet-pair probes [60] sont les techniques les plus souvent utilisées
lorsque l'on veut reconstruire une représentation MINT du réseau dans le cas où une source
117
Techniques de mesures pour les sous-chemins communs étroits
communique vers plusieurs destinations. Le principe général n'est pas sans rappeler les
techniques de mesures de bande passante par injection de paquets dos à dos présentés dans
la section 3.2.
6.1.1.1 Description
Comme la plupart des techniques de mesures existantes, cette technique est une 2mesure 1-test. L'idée générale est illustrée par la gure 6.1.1.1. Cette technique est souvent
utilisée pour estimer le délai. Elle n'implique aucune synchronisation entre les diérents
noeuds participant à la mesure. Un paquet de grande taille (q ) est destiné au noeud d1 ,
p2
s0
p2
d
p1
q
p2
p1
p2
d + ∆q
p1
p2
p1
p1
d1
d2
Figure 6.1. Mesure par injection de tests sandwich
tandis que les autres paquets (p1 et p2 ) sont destinés au noeud d2 . Le paquet p2 et le
paquet q sont envoyés dos à dos. Tous les paquets sont émis depuis la source s0 . Si l'on
considère qu'il n'y a aucun trac interférent, l'écart temporel entre les petits paquets
destinés à d2 augmente progressivement le long du chemin jusqu'au point de disjonction
des chemins ps0 ,d1 et ps0 ,d2 , car le second paquet p2 est ralenti par le temps de queue induit
par le grand paquet q . A l'arrivée, l'intervalle de temps entre les paquets p1 et p2 permet
d'estimer le délai ∆q induit par q , puisque l'intervalle de temps initial d est connu. Notons
qu'en l'absence de trac interférent, la valeur ∆q est directement liée à la bande passante
atteignable sur le sous-chemin commun aux deux chemins. d est choisi de manière à être
susamment grand pour éviter que le paquet p2 ne rattrape son retard sur la paquet p1
pour des raisons de trac interférent.
6.1.1.2 Exploitation des valeurs obtenues
On considère que le trac interférent est stationnaire, c'est-à-dire qu'il varie peu temporellement. On itère régulièrement le test décrit ci-avant dans le temps, en prenant soin
que ces itérations soient indépendantes (c'est-à-dire que l'injection d'une preuve a n'induise
pas de queue pour une preuve b envoyée plus tard).
118
On obtient par ces itérations des valeurs bruitées des capacités du sous-chemin commun
vis-à-vis de la métrique considérée, que l'on peut considérer comme une variable aléatoire
Xij où i, j ∈ R. Dans des conditions de trac interférent raisonnables, les diérents échantillons des valeurs de Xij sont statistiquement indépendants les uns des autres et ont un
écart type ni.
Dans les cas les plus simples, comme par exemple dans [49], la valeur retenue sera la
moyenne arithmétique des valeurs de cette variable aléatoire, et l'évaluation de la relation
de disjonction est équivalente à celle donnée en chapitre 2.
Dans certains travaux utilisant une approche statistique basée sur la vraisemblance
telle que décrite en section 5.2.3, on utilise plutôt les propriétes de cette variable aléatoire.
6.1.1.3 Performances
Bien sûr, ce type de preuve est sujette à des perturbations de ses performances en présence de trac interférent, et se trouve donc fortement bruitée. Elle est donc à priori plus
ecace dans le cas où l'on mène une reconstruction par un algorithme basé sur la vraisemblance, qui est par nature moins sujet à des erreurs induites par des mesures bruitées.
6.1.1.4 Limitations
Ces techniques étant basées sur la disjonction de chemin partant d'une même source
vers plusieurs destinations, elles ne peuvent être utilisées que dans ce cas-là. De plus, elles
sont sujettes aux eets de la dispersion dûe au trac interférent ; il est donc nécessaire
d'itérer un grand nombre de fois les injections de paquets pour obtenir un échantillon
statistique signicatif.
Enn, un problème plus profond vient compromettre l'avenir de ce type de tests lorsqu'ils sont eectués sur des réseaux haut débit (qui ont des débits de l'ordre du Gigabit/s).
Les cartes Gbit sont quasiment toujours équipées d'un buer d'entrée assez grand, qui empêche une mesure précise de l'écart de temps d'arrivée de paquets successifs. De fait, ces
techniques sont inutilisables pour des réseaux haut débit. On est alors obligé de choisir un d
initial grand, ce qui met en péril le respect de l'hypothèse de trac interférent stationnaire,
et, lors d'expérimentations réelles, doit donner une estimation très bruitée. De plus il faut
un q de taille importante pour induire un ralentisement du deuxième paquet.
6.1.2 Méthode de la "cartouche"
Cette méthode [89] est une variante plus ancienne de la technique précédente, cette
fois-ci adaptée au cas où l'on désire mesurer la capacité d'un ensemble de liens précis
contenus dans deux chemins ayant une même origine. Elle a donc été pensée pour dénir
la capacité d'un sous-chemin commun aux chemins considérés, et se comporte donc comme
une 3-mesure 1-test.
119
6.1.2.1 Description
La technique repose elle aussi sur l'injection de paquets et la mesure de l'intervalle de
temps qui sépare leur arrivée sur le noeud destination. La gure 6.1.2.1 donne une vue
d'ensemble du type de motif de paquets qui est injecté.
q
pb
{pq}r
pc
pa
pcible
enregistreur
loupe
p
enregistreur final
Paquet cadenceur
loupe
Paquet cadenceur
enregistreur
loupe
enregistreur final
∆t
Figure 6.2. Mesure par la technique de la cartouche
La technique repose sur quatre types de paquets : un paquet dit paquet cadenceur
(pacer ), des paquets dits enregistreurs (marker ), de 2 paquets enregistreurs naux et enn
des paquets dits loupe (magnier ).
Ces diérents types de paquets sont utilisés dans un contexte bien précis. Soit deux
chemins pa et pb ayant une même origine. Soit le chemin pcible t.q. pcible est un sousa ,pb }
chemin du sous-chemin commun maximum à pa et pb , soit p{p
maximum se nissant au point
de disjonction de pa et pb . Soit les noeuds i et j respectivement les noeuds source et
destination de pcible . Soit enn un dernier chemin pc ayant la même origine que les chemins
pa et pb et ayant comme point de disjonction avec ces deux chemins le noeud source de
pcible i.e. i.
Dans le cas décrit ici, la technique de mesure de la cartouche permet de calculer la
bande passante le long du chemin pcible . Le train de paquets initial est constitué de la suite
de paquets suivants envoyés dos à dos : tout d'abord le cadenceur, suivi d'un paquet loupe,
d'un enregistreur nal, puis de r paires de paquets constituées d'un paquet loupe et d'un
paquet enregistreur, et enn, d'un paquet loupe et du dernier paquet enregistreur.
Le paquet cadenceur est de grande taille, et doit servir à ralentir le trac qui le suit
120
immédiatement. Le paquet cadenceur suivra le chemin pc . Il permet, en ayant soigneusement choisi la taille de ce paquet, de faire en sorte qu'à l'arrivée au noeud i (soit au début
du chemin pcible ), les paquets le suivant soient encore dos à dos.
Puis ce paquet continue sur un chemin diérent des autres paquets qui le suivent.
Ces paquets parcourent ensuite le chemin pcible . Les paquets loupes, plus grands que les
paquets enregistreurs, ralentissent les paquets marqueurs le long du chemin à chaque queue
de routeur plus lente que les autres rencontrées. A la n du parcours de pcible les paquets
enregistreurs et loupes se sont comportés comme un train de paquets (voir la section
3.2.2.2). Tous les paquets, à l'exception des enregistreurs naux, nissent leur route le
long du chemin pb . Enn, les enregistreurs naux arrivent sur l'hôte destination de pa .
L'intervalle ∆t séparant leurs arrivées sur l'hôte destination permet d'évaluer le temps de
parcours le long de pcible du train de paquets. La raison pour laquelle seuls les paquets
enregistreurs naux arrivent à cet hôte est simple : si le train de paquets continuait jusqu'à
lui, il pourrait être ralenti par les liens appartenant à la n du parcours. En évitant cela,
les deux paquets arrivent susamment espacés pour que leurs parcours n'interfèrent pas
l'un avec l'autre.
L'estimation de ∆t obtenu en mesurant la diérence entre les temps d'arrivées des
deux enregistreurs naux permet d'estimer le délai induit par le sous-chemin pcible pour le
train de paquets constitué des diérentes paires de paquets enregistreurs et loupes. Tout
comme les techniques précédentes, l'itération de l'injection de tests à des intervalles de
temps susamment grands pour que les tests n'inuent pas les uns sur les autres permet
d'obtenir des mesures statistiquement ables.
Cette méthode est une des seules permettant de cibler un sous-chemin commun précis
du réseau. En cela, c'est celle qui, parmi l'existant, se rapproche le plus de d'une mesure
nécessaire à la reconstruction d'un MINP.
6.1.2.4 Limitations
Tout d'abord, le sous-chemin cible doit pouvoir être déni par 3 chemins, tel que décrit
précédemment, sous peine de ne pouvoir être testé. Ceci ne sera pas forcément le cas
dans un schéma de communication partiel. De plus, il faut recourir à une autre méthode
pour estimer la position des diérents points de disjonction de ces chemins. L'utilisation
de cette technique nécessite donc soit d'avoir une connaissance de la topologie du réseau,
soit de l'acquérir préalablement. Enn, le dimensionnement des diérents paquets ainsi
que le nombre de paires d'enregistreurs et de loupes nécessite d'avoir une estimation des
{pa ,pc }
{pa ,pb }
capacités des diérents sous-chemins pmaximum
, pa \pmaximum
. Cela rend plus que complexe
121
l'utilisation de ce type de méthode sans connaître à l'avance les capacités du réseau.
Enn, la techique soure de la même vulnérabilité au trac interférent que les techniques de mesures de bande passante par trains de paquets, excepté que cette vulnérabilité
est double : les paires de paquets enregistreurs et loupes peuvent subir des ralentissements
{pa ,pc }
dûs au trac interférent soit le long de pcible soit sur pmaximum
, sans qu'il soit possible
d'estimer la provenance des perturbations. De plus, le facteur r destiné à atténuer l'impact
a ,pb }
de la bande passante de la portion pa \ p{p
maximum peut, si il est grand, faire en sorte que
les perturbations deviennent probables.
6.1.3 Méthode bayesienne
Cette méthode est adaptée au cas où l'on désire mesurer la capacité d'un lien précis
contenu dans deux chemins ayant une même origine. Cette méthode permet d'évaluer,
comme la plupart des techniques de mesures, la capacité vis-à-vis du taux de perte d'un
sous-chemin commun à deux chemins ayant la même origine.
6.1.3.1 Description
Soit pa , pb deux chemins ayant la même origine sur lesquels on désire eectuer cette
mesure. Le principe général de cette méthode est assez simple : on procède à une estimation
de la capacité des deux chemins séquentiellement, puis on estime la capacité atteinte lors
d'injections simultanées sur les deux chemins, permettant, en cas de métrique séparable,
l'estimation de la capacité du sous-chemin commun. La technique de mesure étant destinée
à l'évaluation du taux de perte, la métrique considérée est donc celle-ci.
Dans le but d'estimer le taux de perte du premier chemin (pa ) on injecte un à un
des paquets en laissant un intervalle de temps entre les envois aléatoire mais supérieur ou
égal à un seuil ∆ permettant de supposer l'indépendance entre les diérents tests, et l'on
observe les éventuelles pertes de paquets. En recueillant un echantillon statistique susant,
on obtient une variable aléatoire X pa décrivant les pertes sur le chemin pa . On procède
ensuite de même pour pb .
Enn, on tente d'estimer les pertes dûes au sous-chemin commun de pa et pb en envoyant
des paires de paquets composées d'un paquet allant vers pa et d'un allant vers pb . Les envois
des deux paquets sont séparés par un intervalle de temps . L'intuition qui prévaut ici est
que plus les paquets sont temporellement proches, plus ils ont de chances d'être sujets
aux mêmes évènements tels que la perte dûe au trac interférent. En pratique, les auteurs
de [49] obtiennent d'ailleurs les meilleures performances avec un nul (c'est-à-dire qu'ils
envoient les paquets dos à dos). On observe ici les évènements de perte de la paire complète,
qui est à priori dûe à une perte sur la section commune aux deux chemins, et l'on recueille
un échantillon statistique susant pour obtenir une estimation du taux de perte.
122
L'exploitation des valeurs obtenues est simple : les auteurs [49] se contentent d'établir le
pourcentage de pertes observées pour les trois estimations (sur pa , pb et sur le sous-chemin
{pa ,pb }
{pa ,pb }
commun de pa et pb ). L'estimation des valeurs de pa \ pmaximum
et de pb \ pmaximum
(soit
les sous-chemins des chemins pa et pb partant du point de disjonction des deux chemins
jusqu'à leurs destinations respectives) est faite en utilisant la fonction g propre à la métrique
séparable considérée.
Cette technique relativement simple permet d'évaluer de manière relativement able le
taux de pertes sur un sous-chemin commun à deux chemins ayant la même origine.
6.1.3.4 Limitations
La méthode repose sur deux paramètres principaux : l'espacement minimal temporel
entre l'envoi de deux paquets (∆) quand l'estimation est faite sur un seul chemin, ainsi
que sur l'intervalle de temps séparant l'envoi des deux messages lors de l'évaluation du
sous-chemin commun.
Le choix de ∆ ne peut jamais, en pratique, garantir l'indépendance des tests injectés.
Ceci signie que lors des tests réels, il faut choisir une valeur pour ce paramètre de manière
empirique (car un trop grand ∆ augmente sensiblement le temps de mesure). Cela nuit à
l'automatisation de ce genre de techniques.
6.1.4 Méthode par agglomération de tests unicasts
L'idée principale de cette technique [66] est d'adapter les méthodes basées sur les mesures eectuées par des arbres multicasts au cas unicast. Dans ce but, les auteurs agglomèrent diérents tests unicast de telle façon que les propriétés statistiques de ces tests
avoisinent celles des tests eectués grâce aux arbres multicasts. Cela est rendu possible
par l'assertion que des tests temporellement très proches expérimenteront les mêmes évènements de congestion ou de perte de paquets, et donc, permettront une inférence des
caractéristiques du sous-chemin commun à tous les chemins considérés. Cette technique
de mesure est donc une n-mesure, du moins théoriquement. Les auteurs utilisent cette
technique dans le cadre de l'évaluation du taux de perte le long des chemins.
6.1.4.1 Description
Le schéma général du fonctionnement de l'injection de test est représenté à la gure
6.1.4.1. Une stripe de paquets, c'est-à-dire un ensemble de paquets envoyés dos à dos à
un ensemble de destinations {d1 , . . . , dr } ⊆ R est injecté depuis un hôte source s0 . Les
diérents paquets sont ensuite routés à travers l'arbre vers leurs diérentes destinations.
Certains paquets traversent une portion commune de l'arbre induit par le routage car
123
leurs destinations sont proches les unes des autres. De par la proximité temporelle de leurs
passages à travers des sous-chemins communs, ces ensembles de paquets sont soumis à
d'éventuelles pertes, qui sont à priori corrélées les unes avec les autres. Cela permet, en
itérant l'injection de stripes, d'obtenir un ensemble de mesures concernant les diérents
sous-chemins communs à l'ensemble de chemins considérés.
s0
d1
d2
d1
d2
d1
d3
di
une "stripe"
dr−2
dr−1
dr
di
dr−2
d1
d1
dr−1
di
dr
dr−2
dr−1
dr
d1
dr
d1
di
dr
Figure 6.3. Mesure par injection de stripes
Même si le cadre général permet de penser qu'une reconstruction à partir d'arbres
ayant un nombre de feuilles arbitraire est possible, elle se révèle très complexe à mettre
en oeuvre. Les auteurs réduisent donc en pratique le nombre de feuilles à deux. Un autre
paramètre sur lequel les auteurs peuvent jouer est le nombre de messages destinés au même
hôte destination ainsi que leur place dans le stripe.
A partir de l'injection de tests réguliers, les auteurs obtiennent un échantillon statistique
de pertes et d'arrivées de paquets. Les auteurs peuvent ensuite chercher une corrélation
entre les pertes de paquets en direction des deux hôtes.
Les avantages de l'utilisation de techniques de mesures telles que celles-ci sont multiples.
Tout d'abord, elles permettent d'utiliser les algorithmes pré-existants de reconstruction
basés sur les arbres multicasts. De plus, le type de méthodologie employé (l'estimation
de la corrélation d'évènements entre 2 sous-chemins) peut à priori être adapté à d'autres
métriques que la perte de paquets.
6.1.4.4 Limitations
Cette technique de mesure dépend beaucoup des conditions du trac interférent. De
nombreux paramètres, comme la taille du stripe en terme de paquets, la taille des paquets
124
eux-mêmes, l'ordre d'envoi des paquets vers les diérentes destinations ne peuvent être
xés de manière optimale sans connaître l'état du réseau et du trac interférent lors de
l'injection des tests.
Enn, la corrélation entre les évènements tels que la perte de paquets peut être nulle
dans le cas par exemple de routeur utilisant la politique de Random Early Detection (RED),
qui détruit préventivement certains paquets si le taux de remplissage des buers du routeur
dépasse un certain seuil.
6.1.5 Méthode par mesures d'interférences
Cette méthode est celle utilisée par [96] ; notons que cette mesure est utilisée dans le
cadre de simulation utilisant SimGrid [32], un simulateur de grille de haut niveau utilisant
une simulation des performances du réseau non paquet par paquet mais établissant uniquement les propriétés de partage de bande passante entre des ux TCP [57]. Notons que
cette technique n'est pas dédiée à un usage réel, puisqu'elle se base sur l'établissement du
régime permanent dans un ux TCP, ce qui peut, dans le cas de liens high bandwidth.delay
prendre un temps rendant prohibitif l'attente d'un tel état [88].
Cette méthode est une 2-mesure, qui tend à établir non pas la performance du lien
considéré, mais son partage par ces deux chemins.
De part sa construction, elle doit permettre de prendre en compte les interférences dûes
à des liens commun étroits 1 et 2-détectables, puisqu'elle est basée sur l'estimation de la
variation de la bande passante lors d'injection de tests simultanés sur 2 chemins.
6.1.5.1 Description
La méthode est basée sur le fait que le simulateur SimGrid alloue une bande passante
aux diérents ux TCP circulant sur un même lien commun étroit par le modèle dit INVRTT-BOUNDED [57]. Dans ce modèle, si P est un ensemble de chemins traversé par des
ux en régime permanent, et si pPmaximum est un sous-chemin commun étroit pour lesdits
ux, alors la règle suivant doit être respectée :
1/RT T (pi )
pP
× cbwmaximum
∀pi ∈ P, bw(fpPi ) = P|P |
j=0 1/RT T (pj )
(6.1)
où bw(f ) est une fonction donnant la bande passante atteinte par le ux f en régime
permanent, RT T (p) une fonction donnant le RTT correspondant à un trajet suivant p puis
le retour par le chemin correspondant.
Dans le cas où la bande passante est allouée à un ux suivant cette règle, on peut
évaluer simplement si deux chemins pa et pb ont un sous-chemin commun détectable vis-àvis de la bande passante. Pour cela, on établit tout d'abord la bande passante obtenue par
chacun des ux séparément. Puis, l'on tente de saturer le chemin pa , et on estime la bande
125
passante obtenue par pb dans ce cas. On procède de même pour pa lorsque pb est saturé.
Par ces mesures, on obtient les mesures de bande passante nécessaires à l'évaluation de
la relation telle que décrite dans la section 3.1.6.1.
L'exploitation des valeurs obtenues est conforme à celle décrite dans la section 3.1.6.1.
Dans le cadre de son utilisation dans un simulateur, cette mesure atteint parfaitement
son objectif et permet donc d'eectuer des mesures réseau même en utilisant un simulateur
de plate-forme de haut niveau.
6.1.5.4 Limitations
Cette méthode, de par le fait qu'elle repose sur une mesure de la bande passante
atteignable par un ux TCP en régime permanent, est inutilisable dans des cas réels.
6.1.6 Autres méthodes de mesures
Notons enn qu'il existe d'autres méthodes de mesures que celles présentées ici qui
s'attachent à établir une relation entre les chemins plutôt que, comme les techniques précédemment décrites, des méthodes cherchant à évaluer la capacité des chemins considérés
ainsi que la relation les liant.
La méthode par observation de la distribution d'évènements utilisée lorsque l'on souhaite identier des sous-chemins communs entre plusieurs MINT construits à partir d'une
source communiquant vers plusieurs destinations en est un exemple. Elle est utilisée dans
l'outil PERISCOPE [56] pour reconstruire des forêts dans lesquelles les arbres sont plus ou
moins liés deux à deux par ces sous-chemins communs. Elle est basée sur l'observation de
distributions d'évènements sur les noeuds destinations participant aux tests. Nous l'avons
décrite en section 3.1.5.3.
Un autre exemple est l'identication de points communs à deux chemins par l'utilisation
de traceroute que nous avons décrit dans la section 3.1.4.1.
126
6.2
Techniques adaptées à la reconstruction de MINP partiels
6.2.1 Principe général
Les techniques existantes que nous avons précédemment décrites ne permettent pas
d'identier convenablement la topologie et les performances du réseau lorsque l'on désire
reconstruire une représentation du réseau sous forme de MINP. Nous avons donc développé
de nouvelles techniques de mesures spéciques à ce problème.
6.2.2 Technique utilisant le régime permanent de ux TCP
Cette technique est en fait assez proche de celle décrite plus haut à la section 6.1.5,
qui peut être considérée comme un sous-cas de cette technique. Nous n'avons bien entendu
pas développé cette technique pour une utilisation dans des cas réels, mais dans le cadre
de simulations de plates-formes comprenant un nombre de noeuds rendant prohibitive
l'utilisation d'un simulateur de bas-niveau du réseau sur lequel seraient eectuées des
mesures adaptées aux cas réels.
6.2.2.1 Description
Puisque ce type de preuve n'est pas conçu pour être utilisé dans des cas réels, mais
dans le seul but de disposer de MINP partiels pour reconstruire une topologie totale d'un
réseau, nous considérerons qu'il n'y a pas de trac interférent, et que le partage entre les
diérents ux se fait suivant le modèle d'INV-RTT-BOUNDED [57] décrit précédemment
dans la section 6.1.5. La propriété qui nous intéresse est que la somme de la bande passante
attribuée à chacun des ux partageant un sous-chemin commun étroit simultanément est
égale à la capacité de celui-ci.
Considérons l'ensemble de chemins Pprobe = {pa , pb , pc }, et les ux correspondants
injectés le long des éléments de cet ensemble, soit fp{pa a } , fp{pb b } et fp{pc c } . Considérons le cas
où nous établissons les bandes passantes obtenues par fpPji quels que soient les ensembles
Pi ⊆ Pprobe et pj ∈ Pprobe . De manière pratique, cela signie que nous établissons les
bandes passantes atteignables lors du régime permanent pour chacun des chemins, d'abord
individuellement, puis lorsque les injections de 2 ux sont simultanées, puis enn quand
les 3 injections sont simultanées.
Puisque la capacité du lien est égale à la somme des bandes passantes atteintes par
les ux, la somme des bandes passantes pour un ensemble donné décroît par rapport à la
somme des bandes passantes obtenues individuellement par chacun des ux sur les chemins
correspondant pour n'importe quel sous-ensemble de P de cardinalité 2. c'est-à-dire :
127
∀P t.q. |P | = 2,
|P |
X
bw(fp{pi i } )
>
i=O
|P |
X
bw(fpPi ) ⇐⇒
i=O
pPmaximum detectable
et
pP
cbwmaximum
=
|P |
X
(6.2)
bw(fpPi )
i=O
On est donc capable de déterminer si tout couple partage un sous-chemin commun
détectable, et quelle est sa capacité. Pour le triplet {pa , pb , pc }, il n'est détectable que si la
bande passante obtenue par les 3 ux émettant simultanément est inférieure à toutes les
combinaisons possibles d'interférence entre ux deux à deux, c'est-à-dire :
|P |
X
bw(fpPi )
<
i=O
0 ⊂P
PX
P \P 0
0
bw(fpPi )
pi ∈P 0
pPmaximum
+
X
00
bw(fpPj )
∀P 00 ⊂ P ⇐⇒
pj ∈P \P 0
est détectable et
pP
cbwmaximum
=
|P |
X
bw(fpPi )
(6.3)
i=O
En réalisant ces opérations, on a donc établi la détectabilité de chacun des sous-chemins
communs pour tous les ensembles P 0 ⊆ P .
Une fois établie la détectabilité des diérents sous-chemins communs, on peut reconstruire le MINP simplement en utilisant la couverture des sous-chemins communs entre eux
et en étiquetant les noeuds par les diverses capacités obtenues.
Cette technique permet l'établissement de 3-MINP partiels pour le réseau. C'est donc
une 3-mesure. Simple à mettre en place, elle nous a permis de réaliser des mesures sur des
topologies simulées par l'outil SimGrid [32].
6.2.2.4 Limitations
Il est totalement irréaliste d'utiliser cette technique pour des expérimentations réelles.
Néanmoins, cette technique est utile quand on désire simuler une reconstruction de MINP
partiel grâce à un simulateur, ne permettant pas une analyse paquet par paquet du trac
circulant sur le réseau.
6.2.3 Technique par envoi de bursts UDP périodiques
Le passage d'un environnement de simulation à un environnement réel est très souvent
problématique. Nos premières expériences tendant vers une utilisation réelle ont donné
128
lieu à cette technique de mesure réelle, qui, bien que jouissant de résultats probants lors
de simulations de bas niveau (paquet par paquet) s'est révélée être totalement inecace
dans les cas réels.
6.2.3.1 Description
Cette technique, tout comme la suivante, est une 1-mesure basée sur les trains de paquets. Les trains de paquets ont été décrits dans la section 3.2.2.2. Les trains de paquets
sont un moyen bien connu de découvrir les capacités d'un lien par l'évaluation de la dispersion des diérents paquets constituant le train. Un train est constitué de paquets envoyés
dos à dos, ce qui est très similaire à un burst. C'est pourquoi nous parlerons indiéremment
de bursts ou de trains de paquets ici.
Le principal reproche fait à ce genre de technique est simple : plus le train de paquets est
long, plus on a de chances que du trac interférent s'immisce entre les paquets constituant
le train. Cela conduit donc (le plus souvent) à une sous-estimation de la bande passante
disponible ([64]).
L'idée est donc d'utiliser ce défaut comme un avantage, c'est-à-dire permettre la détection de sous-chemins communs par la détection des eets mutuels de trains de paquets
provenant de sources et ayant des destinations pouvant être diérentes.
Le principe général est assez simple. On suppose qu'à défaut d'être nul, le trac interférent est constant. Soit un ensemble de chemins P . Pour chaque pi ∈ P on évalue dans un
premier temps la bande passante disponible sur ce lien. Puis, on injecte simultanément à
intervalles réguliers ∆pi des bursts qui ont pour caractéristique de saturer le sous-chemin
étroit du chemin considéré pendant un temps Ut . ∆pi est un multiple de Ut .
Si des chemins partagent un sous-chemin commun détectable, alors les bursts injectés
se collisionneront sur le chemin, de la manière illustrée par la gure 6.2.3.1.
Figure 6.4. Collision de trains sur un goulot d'étranglement
Burst UDP concurrents sur un sous-chemin commun étroit Les paquets des
bursts UDP entrant en collision s'entremêlent sur le sous-chemin commun étroit, et donc
l'intervalle de temps entre le premier et le dernier paquet de chaque burst croîtra par
rapport à un burst n'expérimentant pas de collisions. A l'arrivée sur leurs destinations
respectives, on peut alors mesurer cet intervalle de temps pour chacun des bursts UDP.
Notons que les bursts arrivant à l'entrée d'un chemin et parcourant un chemin pi sont
sensés arriver à un intervalle régulier ∆pi sur le sous-chemin commun détectable, car, tant
129
que le trac interférent est régulier ou nul, alors seul sera induit un délai dû au parcours
des diérents chemins menant les diérents bursts de l'origine de chaque chemin pi au
sous-chemin commun détectable. Notons que si les diérents tests injectés subissent un
trac interférent le lien de leur sous-chemin commun, ce trac n'aura pas d'incidence sur
nos mesures, car l'on observe l'intervalle de temps entre le premier et le dernier paquet, et
non leur temps d'arrivée absolu.
Dans le double but de faire en sorte que les collisions aient eectivement lieu, ainsi
que pour pouvoir identier quels sont les chemins (pa , pb , pc ) que parcourent les diérents
bursts qui se sont collisionnés, on s'appuie sur une propriété élémentaire : la composition
de deux fonctions périodiques dont les périodes sont premières entre elles est une fonction
périodique de période égale au produit des périodes. On choisit donc des valeurs entières
Tpa , Tpb et Tpc tels que ∆pi = Tpi ∗ Ut tels que tous soient premiers entre eux.
Le choix de la valeur de Ut , soit l'unité de nos intervalles de temps, peut être guidé par
le jitter observé sur les liens : si le jitter n'est pas négligeable par rapport à Ut , alors les
collisions ne seront plus certaines, et les intervalles entre les temps d'arrivées du premier
et du dernier paquet de chaque burst observés ne seront plus périodiques.
Un autre aspect pratique concernant le choix de la valeur de Ut est le rapport entre
le RTT des diérents ux TCP circulant sur le réseau et Ut . On a intérêt à choisir un Ut
très petit par rapport à ces périodes, de manière à diminuer l'impact des délais induits
par ceux-ci sur nos mesures. De plus, l'intervalle de temps d'émission doit pouvoir être
susamment long pour pouvoir avoir une réelle inuence vis-à-vis des autres ux. Par
contre, choisir un Ut petit nécessite de pouvoir résoudre assez ecacement l'absence de
synchronisation entre les hôtes. Un dernier aspect concerne la taille des bursts émis par
rapport à la bande passante du sous-chemin commun étroit. Cela signie que l'on doit
d'abord évaluer la bande passante disponible de chaque lien avant d'injecter les diérents
ux.
Evaluation de la bande passante disponible L'évaluation de la bande passante dis-
ponible doit être eectuée avant l'injection des bursts UDP, de manière à pouvoir déterminer la taille de ceux-ci. Pour cela, nous avons utilisé la technique d'estimation de type
Bulk Transfer Capacity décrite en section 3.2.2.3.
Elimination des problèmes de synchronisation entre les hôtes L'exécution d'in-
jections de tests simultanés et surtout, le passage simultané de paquets provenant de sources
diérentes le long d'un sous-chemin commun est un problème bien plus complexe qu'il n'y
paraît de prime abord.
Problématique Deux problèmes diérents se posent lors de l'utilisation de cette
technique en terme de synchronisation des hôtes :
130
Un problème de synchronisation au niveau de la période, c'est-à-dire que l'on ne doit
eectuer les mesures que dans le cas où tous les hôtes injectent simultanément des
tests le long du réseau.
Un problème de synchronisation au niveau de l'unité de temps, à savoir que l'émission
d'un burst de paquets décalée par rapport aux autres intervalles de temps entraînera
un amoindrissement de son eet pouvant aller jusqu'à réduire de moitié son inuence.
Le second problème ne peut en fait être résolu de manière correcte : en eet, la collision
de bursts entre eux est aussi conditionnée par le délai subi par les diérents paquets
le long du chemin menant au sous-chemin commun. Seule l'analyse ne de la période
des valeurs d'arrivées permet d'obtenir des valeurs correctes. On peut considérer que ce
second problème de synchronisation apporte une contrainte supplémentaire au choix de
Ut , puisque, possiblement, l'eet des bursts de "taille" Ut peut être réduit de moitié. Le
premier, lui, est plus complexe.
En eet, l'estimation du délai se fait le plus souvent par dichotomie. Or, les évaluations
par dichotomie du délai one way (ou aller simple) ne peuvent en pratique être utilisées pour
le genre d'applications que nous avons développées lors de ces travaux. En eet, le temps
d'évaluation peut excéder régulièrement la demi-heure pour un seul chemin observé. Il peut
même arriver que la convergence ne se produise jamais pour cause de trac interférant trop
important. De plus, l'estimation ne d'un délai à un instant t ne garantit rien quant au
délai qu'expérimentera un burst traversant le même chemin, même dans un futur très
proche.
Solution possible Il était donc nécessaire de trouver un moyen de contourner ce
problème en concevant une manière rapide (en terme d'exécution) et relativement robuste.
Ceci nous a conduit à faire un choix des plus rudimentaires : l'utilisation d'une méthode
passablement frustre, mais ecace : la méthode du noyau décrite ci-après.
Méthode du noyau La méthode du noyau consiste à ne conserver lors d'un ensemble
de tests que la partie "centrale" (temporellement parlant) des tests de manière à s'assurer
que les diérents tests ont bien été eectués simultanément. Elle est donc par dénition
plutôt destinée à des tests périodiques. Son principe général est illustré par la gure 6.2.3.1.
Un paramètre important reste celui du dimensionnement du noyau : comment s'assurer
que :
1. Le noyau ne contienne pas d'eets de bords dûs au manque de synchronisation des
hôtes eux-mêmes ?
2. Le noyau ne contienne pas d'eets de bords dûs au temps de transmission entre l'hôte
source et la partie ciblée du réseau ?
3. Le noyau ne contienne pas d'eets de bords dûs aux buers situés le long du réseau ?
131
Pour ce qui est du premier problème, la réponse est assez simple : l'écorce doit être susamment épaisse (i.e. susamment longue temporellement) pour rendre improbable cette
situation ; puisque nous ne pouvons extraire d'information concernant le délai one way, mais
que nous sommes à la recherche d'une borne supérieure, nous pouvons utiliser le round trip
time (i.e. le temps de trajet d'un message faisant l'aller-retour entre deux hôtes). Pour
ce qui est du problème de l'eet du délai entre l'hôte source et la partie du réseau, celuici est résolu par le fait que l'on suppose le trac interférent constant ; le délai introduit
donc une absence de synchronisation entre les arrivées des tests injectés, mais ne remet
pas en cause leur périodicité. Pour ce qui est enn du problème d'eets de bords éventuels dûs aux buers situés le long du réseau, il est nécessaire de prendre en compte leur
dimensionnement. Une "règle" veut que le buer d'un équipement réseau soit capable de
stocker l'équivalent de ce que peut émettre un hôte transmettant à la vitesse maximum de
l'équipement pendant 250 ms [74].
pc
pb
pa
Figure 6.5. Méthode du noyau
Les valeurs obtenues sont exploitées de la même façon que lors de l'utilisation de la
technique reposant sur le régime permanent de ux TCP (section 6.2.2).
En simulation, cette méthode permet, à partir d'une simulation de bas niveau (i.e.
paquet par paquet) de recréer assez simplement un MINP partiel. Malheureusement, cette
technique est inutilisable telle quelle dans un contexte réel.
6.2.3.4 Limitations
Le principal problème de cette méthode vient de sa vulnérabilité aux variations de délai
(au jitter). En eet, si nos expériences en simulation même en cas de trac interférent
donnaient des résultats corrects, nos tests réels ont révélé que des variations de délai même
minimes pouvaient conduire à une absence de périodicité de mesures. Nous avons donc dû
repenser des techniques plus robustes au jitter, qui cette fois ont donné des performances
132
convenables lors d'expérimentations réelles, que nous donnons par la suite.
6.2.4 Technique par saturation de lien par bursts UDP
Cette technique très simple, est une 1-mesure que nous avons développée et testée pour
contourner un des principaux défaut de la technique reposant sur le régime permanent
de ux TCP, à savoir l'attente de l'établissement du régime permanent qui peut être
extrêmement longue.
6.2.4.1 Description
La technique reprend exactement le même principe que la technique basée sur l'établissement du régime TCP, excepté que l'on n'utilise plus de ux TCP mais de longs bursts
UDP pour saturer le lien. Cela nécessite une étape préliminaire par rapport à la précédente
technique, à savoir l'établissement de la bande passante disponible sur chaque chemin de
P.
ponible peut être réalisée de diérentes manières (voir section 3.2). Dans le cadre de cette
technique de mesure, nous avons utilisé la méthode de bulk transfer capacity en envoyant
un important volume de données UDP. Notons que le choix de la technique d'évaluation
de la bande passante est assez arbitraire. Les principaux avantages de cette technique sont
à la fois la durée d'exécution relativement courte de la mesure, ainsi que l'utilisation du
protocole UDP pour celle-ci.
Elimination des problèmes de synchronisation entre les hôtes Nous avons utilisé
la méthode du noyau décrite plus haut (section 6.2.3.1) pour cette technique.
L'exploitation des valeurs obtenues est similaire à celle de la technique de mesure par
injection de ux TCP en régime permanent, hormis que dans ce cas l'on ne peut pas
obtenir de mesure de la bande passante en fonction de l'intervalle de temps séparant les
diérents paquets du burst. On est donc contraint de ne pouvoir inférer que des chemins
1-détectables. L'utilisation d'un seuil pour l'évaluation de la performance des diérents
ux permet (à priori) l'élimination de la détection de chemins 2-détectables.
Cette technique permet de réaliser des mesures dans d'autres conditions que la simulation et de reconstruire des MINP partiels.
133
6.2.4.4 Limitations
La principale limitation de cette technique est la saturation des liens réseau. De plus, la
saturation induite est longue (en terme de temps) ce qui est particulièrement destructeur
pour un trac interférent basé sur un protocole de bout en bout qui gère des fenêtres de
congestion (TCP par exemple).
6.2.5 Technique basée sur l'approximation de la néguentropie
Cette dernière technique est la plus ecace que nous ayons développée. C'est celle-ci
qui est nalement utilisée dans le prototype d'outil M.I.N.T.C.A.R. présenté au chapitre
7. Cette méthode est, tout comme la méthode décrite précédemment basée sur les bursts
UDP périodiques (section 6.2.3.1), basée sur les interactions de bursts provenant de sources
diérentes et à destination d'hôtes diérents. Elle est fondée sur une observation provenant
de la méthode décrite en section 6.2.3 : les diérents signaux circulant sur ce lien vont
avoir chacun un impact sur les autres, dont la nature n'est pas connue, et qui n'est pas
à priori linéaire, mais qui peut être caractérisée. Une étude approfondie des propriétes de
ces sous-chemins communs étroits a été menée dans [64]. Il nous faut donc une technique
qui permette de faire en sorte que les diérents tests injectés interfèrent les uns avec les
autres, mais aussi une technique qui soit capable d'identier quels tests interfèrent les uns
avec les autres. Le principe de cette technique, l'approximation de la néguentropie, a été
utilisé avec succès dans d'autres domaines de l'informatique tels que l'imagerie [112], les
réseaux de neurones [81] ou le traitement de signal. La technique d'approximation de la
néguentropie a été initialement développée par Hyvärinen et E.Oja dans le cadre de la
résolution du problème du cocktail mondain par l'Analyse des Composants Indépendants
(Independant Component Analysis, ICA (ICA)).
6.2.5.1 Indépendance et néguentropie
Les techniques et méthodes que nous utilisons ici sont issues d'un domaine totalement
diérent voué à la résolution du problème du cocktail mondain. Le problème du cocktail
mondain a été formalisé la première fois au milieu des années 1980 par des chercheurs issus
de la communauté des neurosciences et du traitement du signal. Sa formalisation et le
développement de travaux visant à le résoudre ont conduit au développement du problème
de séparation de source aveugle (Blind Source Separation ou BSS (BSS)) [84].
Le problème peut être décrit comme suit : on dispose lors d'un cocktail mondain de
divers micro dans la salle de réception. Lors du cocktail, les diverses conversations qui se
déroulent dans plusieurs langues, les sons extérieurs, comme les sirènes de voiture de police
passant à proximité s'entremêlent. Tous ces sons sont enregistrés par les diérents microphones comme étant un seul signal sonore. La formulation du problème est simple : peut-on,
sans connaître ni les diérentes sources sonores, ni leur nombre, ni leur emplacement, ni
134
les positions des diérents microphones dans la salle, isoler les diérentes conversations
enregistrées ?
Les méthodes pour résoudre ce problème sont le plus souvent basées sur des notions
d'indépendance des diérents composants du signal enregistré. Les diérentes données
provenant des sources sont considérées chacune comme une variable aléatoire qui est une
combinaison de diérents composants aussi indépendants que possible. Le principe général
peut être décrit comme suit :
Dans un premier temps, on décorrèle les données les unes des autres, et on fait en
sorte que leur moyenne soit nulle et leur variance 1. Ce faisant, on approche les
diérents signaux du bruit blanc. Cette étape est appelée whitening.
Ensuite, on essaie de trouver une composante indépendante qui, lorsque les vecteurs
de données sont projetés sur elle, permet de maximiser l'indépendance des signaux
les uns vis-à-vis des autres.
On itère ces étapes jusqu'à l'obtention des diérentes composantes.
La technique décrite ici n'utilise que les deux premières étapes, en rapprochant les
diérents signaux du bruit blanc, puis en évaluant l'indépendance des signaux les uns visà-vis des autres. Si les signaux sont choisis pour être indépendants lors de leur émission,
le fait d'intéragir entre eux le long d'un sous-chemin commun va augmenter l'information
mutuelle qu'ils partagent. Evaluer cette information mutuelle permet donc d'établir si un
ensemble de chemins partage un sous-chemin commun.
Indépendance Le concept d'indépendance peut être bien compris en prenant l'explica-
tion suivante dûe à A.Hyvärinen et E.Oja. Soit deux variables aléatoires y1 et y2 dont les
valeurs sont des réels. Si une information sur la valeur d'une variable ne donne pas d'information sur la valeur de l'autre, alors les variables y1 et y2 sont dites indépendantes. Soit
p1 (y1 ) et p2 (y2 ) les fonctions de densité de probabilités (probability density function, pdf)
des variables y1 et y2 considérées isolément, et p(y1 , y2 ) la fonction de densité de probabilité conjointe (joint probability density function) de y1 et y2 . Si y1 et y2 sont indépendants,
alors l'égalité suivante doit être vraie :
p(y1 , y2 ) = p(y1 )p(y2 )
(6.4)
Pour un nombre arbitraire n de variables aléatoires, la condition d'indépendance peut
être généralisée comme suit : la densité conjointe de n variables aléatoires est le produit
des n densités marginales/isolées des variables. Soit deux fonctions h1 et h2 , la propriété la
plus importante se rattachant à des variables aléatoires indépendantes peut être formulée
comme suit :
E{h1 (y1 )h2 (y2 )} = E{h1 (y1 )}E{h2 (y2 )}
(6.5)
135
Une notion plus faible que l'indépendance est l'absence de corrélation. Deux variables
aléatoires y1 et y2 sont dites décorrélées si leur covariance est nulle :
E{y1 y2 } − E{y1 }E{y2 } = 0
(6.6)
Si les variables sont indépendantes, alors elles sont décorrélées. Ceci est directement déductible de la formule E{h1 (y1 )h2 (y2 )} = E{h1 (y1 )}E{h2 (y2 )} en prenant h1 (y1 ) = y1
et h2 (y2 ) = y2 respectivement. La réciproque n'est par contre pas vraie : la décorrélation
n'implique pas l'indépendance.
Mesurer l'indépendance de variables aléatoires peut se faire par de multiples moyens,
comme la divergence de Kullback-Leibler, le test du χ2 [92], etc. Le choix de la méthode
de mesure de l'indépendance de deux variables aléatoires dépend beaucoup du type de
variables aléatoires ainsi que des distributions des variables. Dans le cas présent, nos expérimentations nous ont montré que l'estimateur le plus able est basé sur l'approximation
de la néguentropie que nous présentons ci-après.
Néguentropie La néguentropie (anglicisme provenant de la contraction de negative en-
tropy, entropie négative) est un concept dérivé de la quantité utilisée en théorie de l'information appelée entropie. En théorie de l'information, l'entropie d'une variable aléatoire
peut être interprétée comme le degré d'information que l'observation du comportement de
cette variable donne. Plus l'entropie est grande, plus la variable est aléatoire ; en d'autres
termes, la variable aléatoire peut être considérée comme non-structurée, imprévisible. Donc,
l'entropie peut être vue comme la longueur du code de cette variable aléatoire. Pour une
variable aléatoire discrète Y , l'entropie H peut être dénie comme suit :
H(Y ) = −
X
P (yi ) log P (yi )
(6.7)
i
où yi sont les diérentes valeurs possibles de Y et P (yi ) = P [Y = yi ]. Si la dénition
est généralisée pour un vecteur de variables aléatoires dont les valeurs sont des réels y avec
une densité f (y), l'entropie diérentielle peut être dénie comme suit :
Z
h(y) = −
f (y) log f (y)dy
(6.8)
Cette valeur tend vers l'inni quand la variable considérée est chaotique. En pratique,
on utilise donc une version légèrement modiée de l'entropie diérentielle appelée néguentropie. Plus la variable considérée est aléatoire, plus la néguentropie tend vers zéro.
Puisqu'une variable aléatoire possédant une distribution gaussienne est "la plus aléatoire"
des variables aléatoires, on utilise une variable aléatoire gaussienne ygauss pour estimer la
néguentropie :
J(y) = H(ygauss ) − H(y)
(6.9)
136
Il faut noter que la néguentropie est invariante pour les transformations linéaires inversibles. De plus, d'un point de vue statistique, la néguentropie est un estimateur optimal
pour la non-gaussianité. Malheureusement, la néguentropie est en pratique très complexe
à calculer. On utilise donc des méthodes pour approximer la néguentropie.
Approximation de la néguentropie Plusieurs approximations de la néguentropie
existent. Classiquement, elle peut être approximée en utilisant les moments de grand ordre
[81]. Par exemple :
J(y) ≈
1
1
E{y 3 }2 + kurt(y)2
12
48
(6.10)
Où y est une variable aléatoire de moyenne nulle et de variance unitaire. Cette méthode
étant soumise aux mêmes problèmes de robustesse que ceux recontrés par le kurtosis, les
auteurs de [81] recommandent d'utiliser l'approximation basée sur le principe d'entropie
maximale :
p
J(y) ≈
X
ki [E{Gi (y)} − E{Gi (γ)}]2
(6.11)
i=1
où ki est une constante positive, et γ une variable de Gauss standardisée. La variable
aléatoire y doit avoir une moyenne nulle et une variance de un, et les fonctions Gi sont
des fonctions non-quadratiques. Même si cette approximation n'est pas toujours juste, elle
possède la propriété de n'être jamais négative et égale à zéro si et seulement si y suit une
distribution gaussienne. Pour une fonction quadratique G :
J(y) ∝ [E{G(y)} − E{G(γ)}]2
(6.12)
La fonction G est souvent dénommée fonction de contraste. Elle permet d'accentuer
l'écart entre des variables "totalement aléatoires" et d'autres. Deux fonctions sont classiquement utilisées :
1
G1 (u) =
log cosh(a1 u)
(6.13)
a1
G2 (u) = − exp(−
u2
)
2
(6.14)
où 1 ≤ a1 ≤ 2 est une constante à choisir, le plus souvent égale à un. Le choix entre
G1 et G2 dépend le plus souvent du type de variables aléatoires. L'expérimentation nous
a permis de constater que dans notre cas la meilleure fonction de contraste est G1 avec
a1 = 1. Le choix de cette fonction et de ces paramètres permet une estimation able de
la néguentropie. La néguentropie, elle, nous permet d'estimer l'indépendance de plusieurs
variables aléatoires par le biais de sa relation avec l'information mutuelle.
137
Information mutuelle On peut dénir l'information mutuelle I entre plusieurs variables
aléatoires yi ∈ y, i = 1 . . . m en utilisant la dénition de l'entropie diérentielle comme suit :
I(y1 , y2 , ..., ym ) =
m
X
H(yi ) − H(y)
(6.15)
i=1
L'information mutuelle est une mesure naturelle de la dépendance (et donc, par contraste,
de l'indépendance) entre des variables aléatoires. Elle est toujours positive, et nulle si et
seulement si les variables sont statistiquement indépendantes. Elle peut être interprétée
en utilisant l'interprétation de l'entropie comme une longueur de code. Les termes H(yi )
donnent les longueurs de code de chacun des yi quand ils sont codés séparément, tandis
que le terme H(y) donne la longueur de code quand tous les composants sont regroupés
dans un même vecteur aléatoire, c'est-à-dire quand tous les composants yi sont codés dans
le même code.
L'information mutuelle montre donc qu'une réduction de la longueur du code est obtenue en codant tout le vecteur plutôt que les composants séparément. En général, de
meilleurs codes sont obtenus quand on code le vecteur en entier. Cependant, si les yi sont
indépendants, ils ne donnent aucune indication les uns sur les autres, on pourrait les coder
tous séparément sans augmenter la longueur du code.
Une propriété importante de l'information mutuelle est que, pour une transformation
linéaire invertible y = W x :
I(y1 , y2 , ..., yn ) =
X
H(yi ) − H(x) − log | det W |
(6.16)
i
Dans le cas où on contraint les yi à être décorrélés et de variance unitaire, cela signie
que E{yy T } = W E{xxT }W T = I , ce qui implique que det I = 1 = (det W E{xxT }W T ) =
(det W )(det E{xxT })(det W T ), ce qui implique que det W doit être constant. De plus, si
yi a une variance unitaire, l'entropie et la néguentropie ne dièrent que d'une constante et
par le signe, on obtient donc :
I(y1 , y2 , ..., yn ) = α −
X
J(yi )
(6.17)
i
Où α est une constante ne dépendant pas de W . Cela donne une relation fondamentale
entre l'information mutuelle et la néguentropie, que nous allons donc pouvoir mettre à prot
pour déterminer le degré d'information mutuelle partagé par les résultats de nos tests ayant
interférés les uns avec les autres le long d'un possible sous-chemin commun détectable. Une
dernière chose à dénir reste l'étape initiale consistant à rendre la moyenne de variables
nulles, puis à décorreler les variables entre elles et rendre leur variance unitaire. La première
étape est appelée centering, centrage. Les deux dernières étapes sont connues sous le nom
de whitening, parfois appelé blanchiment des données. Nous décrivons ces étapes ci-après.
138
Centrage Cette étape consiste à soustraire à chacun des éléments de chaque source de
x sa moyenne.
Whitening
L'étape de whitening (rapprochement du signal vers le bruit blanc) consiste
à transformer linéairement le vecteur de variables aléatoires x pour obtenir un vecteur x̃
qui sera blanc. Par vecteur blanc, on entend un vecteur dont tous les composants sont
linéairement décorrélés et de variance égale à l'unité. En d'autres termes, la matrice de
covariance de x̃ est égale à la matrice identité :
E{x̃x̃T } = I
(6.18)
Cette étape de whitening est théoriquement toujours possible. Une méthode très utilisée
pour le whitening est d'utiliser la décomposition en valeurs propres et vecteurs propres de
la matrice de covariance E{xxT } = BDB T , où B est la matrice orthogonale de vecteurs
propres de E{xxT } et D est la matrice diagonale de ses valeurs propres D = diag(d1 , ..., dn ).
Notons que E{xxT } peut être estimé de manière normale à partir des échantillons de
données x(1), . . . , x(T ). Le blanchiment peut être eectué par l'opération suivante :
x̃ = BD−1/2 B T x
(6.19)
Où la matrice D−1/2 est calculée par une opération simple puisque par dénition on
−1/2
sait que D−1/2 = diag(d−1/2
, ..., dn ). Il est simple de vérier que par ces opérations on
1
a maintenant E{x̃x̃T } = I .
Utilisation de l'approximation de la néguentropie pour l'estimation de l'information mutuelle pour notre cas Comme nous l'avons indiqué, la néguentropie
peut être utilisée comme un estimateur du degré d'information mutuelle entre diérentes
variables aléatoires dont les distributions doivent être non-gaussiennes. L'information mutuelle peut elle être un estimateur able pour l'indépendance. Plus des variables aléatoires
sont indépendantes les unes des autres, plus l'information mutuelle qu'elles partagent tend
vers zéro.
L'application dans notre cas est donc la suivante : il faut faire en sorte d'obtenir des
valeurs à partir d'injections permettant de reconstruire des variables aléatoires avec chacune d'elles dont la distribution est non-gaussienne et qui ne dépendent pas linéairement
les unes des autres. En eet, en cas de dépendance linéaire entre les variables aléatoires,
l'étape de calcul que nous avons choisi d'utiliser, à savoir la décomposition en vecteurs
et valeurs propres de la matrice de covariance va produire des valeurs propres nulles, entraînant l'impossibilité de calculer D−1/2 . Puis, on utilisera le centrage et le blanchiment
pour obtenir des variables permettant d'estimer l'information mutuelle en utilisant l'approximation de la néguentropie décrite plus haut. Enn, une méthode à base de seuils
139
permettra de déterminer quelles variables partagent de l'information, et quelles variables
sont indépendantes. En eet, comme nous le verrons par la suite dans le chapitre 8, les
tests réels prouvent qu'il existe un véritable écart entre les valeurs d'approximation de la
néguentropie pour des variables aléatoires indépendantes et celles qu'on obtient en utilisant
des variables aléatoires partiellement dépendantes les unes des autres.
Pour pouvoir obtenir des valeurs à partir d'injection de tests nous permettant de déterminer les provenances des interactions suivant la source d'où les ux interférents proviennent, nous pouvons nous baser sur l'hypothèse suivante.
Soit deux ensembles de n bursts UDP parcourant deux chemins diérents pa et pb
possédant un sous-chemin commun détectable. Notons s(pa , t) et s(pb , t) la taille des bursts
(en nombre de bits) parcourant respectivement les chemins pa et pb . Supposons que les
ensembles de bursts UDP sont envoyés comme suit : à chaque période ∆t , on envoie un
burst à une date ∆t + δt où 0 < δt < ∆t . On peut prédire qu'à priori :
Des collisions auront lieu pour un n susamment grand.
Les collisions vont induire des intervalles plus grands entre l'arrivée du premier et du
dernier paquet de chaque burst. Soit d(pa ) la variable aléatoire représentant l'échantillon de n mesures correspondant à la mesure de l'intervalle de temps entre le premier
et le dernier paquet de chaque burst sur pa . La distribution de d(p(a)) sera dépendante de la distribution des valeurs de s(pa , t) et de s(pb , t), tel qu'illustré par la
gure 6.2.5.1.
pa
pb
Figure 6.6. Dépendance des distributions
Or, suivant les travaux présentés dans [64] et les expériences menées dans le cadre de
cette thèse, ces assertions peuvent être considérées comme vraies. En eet, l'article précité
traite des techniques de dispersion de paquets et de l'inuence du trac interférant sur les
performances mesurées par de telles techniques. Les performances mesurées par la méthode
des trains paquets est mesurée par la dispersion de celle-ci ; or, cette dispersion, comme le
140
démontre les auteurs de cet article, est dépendante de la distribution du trac interférant.
Les résultats expérimentaux obtenus dans le cadre de cette thèse ne viennent que conrmer
ce fait. Ceci nous donne donc la base de cette méthode de détermination de sous-chemin
commun détectable.
6.2.5.2 Description
Principe général Les sous-chemins communs étroits peuvent être caractérisés par le fait
que si des ux concurrents traversent ces liens, les capacités de ceux-ci vont entraîner des
pertes, dans le pire des cas, ou encore des délais entre les paquets des diérents ux. Une
manière d'obtenir de tels délais lors d'injection de tests sur ce sous-chemin commun étroit,
est de regrouper en train (aussi appelés bursts ) les paquets d'un même ux, et espérer
une collision entre des tests parcourant les diérents chemins sur lesquels sont eectués la
mesure.
Le principe général de cette technique peut être décomposé en 5 étapes :
Dans un premier temps, on estime la bande passante disponible de chacun des chemins.
On choisit une fonction qui donnera pour chaque chemin la taille du burst pour
chaque injection, fonction périodique ayant une distribution donnée diérente des
autres, et ayant une période telle que toutes les périodes soient premières entre elles.
Cela évite d'éventuels eets de phase, et garantit l'indépendance des distributions
des délais d'arrivées pour chacun des chemins.
On injecte un ensemble de tests consistant en des bursts UDP injectés à chaque
période de temps à une date de départ aléatoire dans cette période.
On eectue de tels tests pour tous les sous-ensembles inclus dans l'ensemble des
chemins à tester P . La taille des bursts variant suivant une fonction propre à chaque
chemin et ayant une distribution donnée, les délais perçus à l'arrivée entre le premier
et le dernier paquet de chaque burst va uctuer de manière diérente pour chacun
des chemins. La distribution de ces délais sera donc fonction de la distribution des
injections, mais aussi des collisions avec d'autres bursts dont la taille uctue elle
aussi suivant une fonction donnée. Les délais résultants auront donc une distribution
dépendante à la fois de la fonction de distribution de l'injection des bursts sur le
chemin, mais aussi de la fonction de distribution de la taille des bursts injectés sur
les autres chemins partageant le même sous-chemin commun (voir gure 6.2.5.1).
On analyse la distribution statistique des intervalles de temps d'arrivées entre le
premier et le dernier paquet de chaque burst. Cette analyse basée sur la néguentropie
permet, en croisant la distribution de chacune des arrivées sur chaque chemin, de
statuer sur la dépendance des distributions entre elles, et donc, sur l'existence de
sous-chemin commun étroit.
La façon d'injecter des tests est décrite plus avant dans la section 6.2.5.2. Supposons pour
141
l'instant que nous ayons les résultats de ces tests, qui nous donnent une mesure que nous
pouvons seuiller. Puisque nous avons pour chaque sous-ensemble de chemins inclus dans
P moyen d'estimer l'existence ou non d'un sous-chemin commun, nous pouvons appliquer
la méthode d'exploitation des résultats décrite en section 6.2.2.2.
ponible est une étape préliminaire qui doit être conduite séquentiellement pour chaque
ux, comme pour la méthode basée sur l'injection de bursts UDP périodiques décrite en
section 6.2.3. Nous avons utilisé la technique de Bulk Transfer Capacity décrite en section
3.2.2.3 pour réaliser cette estimation.
Techniques de train de paquets (burst) L'étape d'injection des bursts est faite une
fois évaluée la bande passante disponible de chacun des chemins. Elle repose sur les étapes
suivantes :
La détermination d'un intervalle de temps moyen entre l'injection de deux bursts sur
un même chemin.
La détermination de la taille moyenne des bursts à envoyer le long de chaque chemin.
La détermination d'une amplitude de la variation de la taille des bursts.
Le choix d'une fonction donnant la taille d'un burst lors de l'i-ème émission de burst
pour chaque chemin.
Une fois ces étapes nies, on procède à l'envoi d'un nombre l de bursts simultanément
sur les diérents chemins testés. Les contraintes liées à la synchronisation des hôtes sont
traitées par la méthode décrite en section 6.2.5.2 (la méthode du noyau).
Intervalle de temps moyen Dans un premier temps, on xe un
∆t qui sera la
valeur moyenne de l'intervalle de temps entre l'injection de deux bursts sur un même
chemin. On peut le xer par rapport au temps de circulation moyen d'un burst désiré sur
le lien le plus lent du chemin sur lequel il circule. Le temps d'émission, est lui, soumis
aux mêmes contraintes que l'Ut de la section 6.2.3.1, c'est-à-dire qu'il doit être inférieur
à 250ms pour éviter un débordement de buer du routeur de plus faible capacité le long
du chemin, et supérieur au jitter maximal observé. Il doit aussi être susamment long
pour que les bursts atteignent une taille signicative (des trains trop courts entrainent une
absence d'interférence entre trains provenant de sources diérentes), ni être trop long (ce
qui entraine une sensibilité supérieure au trac autre ainsi que l'augmentation du temps
total de mesure). En pratique nous avons xé ce temps Ut comme étant le maximum entre
4 fois le jitter maximum observé et 2 millisecondes. Dans toutes nos expériences, les 2
millisecondes ont été la valeur maximum.
Un moyen de xer l'intervalle de temps moyen de manière à obtenir une valeur utile,
c'est-à-dire l'obtention d'interactions, est de choisir l'intervalle de temps moyen entre
142
chaque émission comme étant égale à la somme des temps d'émissions des n diérents chemins de P , de manière à ce qu'en moyenne, la capacité du sous-chemin commun éventuel
soit totalement utilisée. Les temps d'émissions étant par dénition les mêmes (puisqu'on
cherche à avoir une période de transmission égale entre les chemins sur leur sous-chemin
de capacité la plus faible), on peut donc xer ∆t = n ∗ Ut .
Taille moyenne des bursts La taille moyenne des bursts est calculée en fonction du
temps qu'ils vont mettre pour être transmis, donc, de Ut . Connaissant la bande passante
disponible sur chaque chemin pi de P , on choisit pour chaque pi une fonction périodique
dont la distribution est non-gaussienne et diérente des fonctions choisies pour les autres
chemins de P , et dont la période est première par rapport aux périodes des autres fonctions
choisies pour les autres chemins. Cette fonction donne pour chaque 0 ≤ tj ≤ m la taille
du burst à injecter le long de pi . Les travaux sur la taille de paquet "idéale" pour nos
expériences montrent qu'une grande taille est à privilégier, elle est donc par défaut de 1500
bytes (MTU maximum standard, voir section 2.3.1). La moyenne des tailles des bursts
injectés doit être choisie de manière à ce que son temps de transfert sur le lien le plus lent
du chemin sur lequel l'injection est faite soit égale à Ut , soit :
smoy =
cpbwi ∗ Ut
MTU
(6.20)
Détermination de l'amplitude La détermination de l'amplitude de la variation de
la taille des bursts a été faite empiriquement. Si on peut déduire qu'elle doit être importante
(pour marquer les diérences de distribution) elle doit aussi être choisie de manière à ne
pas trop diminuer la taille du burst (pour ne pas avoir de burst sans aucun eet trop
souvent). Les expériences ont montré qu'il était convenable de choisir une amplitude de
variation d'environ 1/3 de la taille moyenne des bursts.
Choix de la fonction L'injection de paquets doit être réalisée de manière à remplir
les conditions suivantes pour pouvoir calculer la néguentropie existant entre chaque test :
Les distributions d'arrivées des diérents tests injectés simultanément doivent être
non-gaussiennes.
Les distributions d'arrivées des diérents tests injectés simultanément doivent être
linéairement indépendantes les unes des autres.
De plus, les contraintes suivantes sont imposées par la pratique :
Les diérents tests injectés simultanément doivent être capables d'interagir et de
garder la trace de leurs interactions mutuelles.
Les diérents tests injectés simultanément ne doivent pas conduire à la saturation
totale d'un éventuel sous-chemin commun et entraîner des pertes de performances.
143
On doit être capable de diérencier les interactions dûes aux diérents ux lors
d'injections simultanées de tests le long de plus de deux chemins.
Notons que les contraintes de non dépendances linéaires peuvent être intuitivement reliées,
et conduisent à considérer l'injection de ux possédant des distributions non-gaussiennes
et diérentes les unes des autres. Notons aussi que, si l'on injecte des tests de distributions
linéairement indépendantes dont les distributions d'arrivées sont linéairement dépendantes
les unes des autres, on peut estimer que les chemins considérés partagent un sous-chemin
commun détectable, même si on ne peut calculer leur néguentropie, de par le choix de la
méthode de blanchiement.
Les 2 premières contraintes pratiques, quant à elles, sont respectées de par le choix de la
taille des bursts et de l'intervalle de temps moyen. La dernière quant à elle, est respectée si
l'on choisit des fonctions périodiques dont la distribution est diérente. Il ne reste plus enn
qu'à injecter les bursts le long des diérents chemins. La gure 6.2.5.2 illustre une de ces
injections. La fonction choisie dans cet exemple est une fonction en créneau, représentée
par le graphique du bas. L'unité des abscisses est le numéro du burst, et l'ordonnée la
taille du burst, en bits, le tout découpé en paquets. La ligne pointillée représente donc
la taille moyenne des bursts smoy . La fonction créneau est périodique de période Tc . La
gure du haut représente l'injection des bursts. L'abscisse représente donc le temps, et
sur celle-ci sont représentés les burst envoyés. La gure illustre la période de temps où la
fonction créneau change de taille de burst. Les bursts sont envoyés à un instant δt choisi
aléatoirement, compris dans la période moyenne d'envoi des burst ∆t égale à n fois le Ut
(ici n = 3). Pour chacun des bursts, on enregistre sur l'hôte destination l'intervalle de
temps entre l'arrivée du premier et du dernier paquet de chaque burst (les paquets noirs
sur la gure).
Elimination des eets de bords du trac interférent l'élimination des eets de
bords du trac interférent est rendue possible par deux choix principaux :
Le choix de l'intervalle de temps Ut qui doit être susamment faible par rapport au
RTT moyen des diérents ux reposant sur des protocoles de bout en bout circulant
sur le réseau.
Le choix de ne pas considérer les intervalles de temps entre les bursts (c'est-à-dire
les temps d'arrivées absolus de chaque paquet) mais plutôt les intervalles de temps
séparant l'arrivée du premier et du dernier paquet de chaque burst sur l'hôte destination.
Elimination des problèmes de synchronisation entre les hôtes L'élimination des
problèmes de synchronisation entre les hôtes est rendue possible de la même manière que
pour la technique basée sur l'envoi de burst UDP périodiques, à savoir la méthode du
144
∆t
δt
δt
δt
Ut
#"#"#" !!!
#"##"" !!!
#"#"#" !!!
/././. ,-,-,/.//.. ,--,,/././. ,-,-,-
+*+*+* ()()()
+*++** ())(()
+*+*+* ()()()
'&'&'& $%$%$%
'&''&& $%%$$%
'&'&'& $%$%$%
545454 010110
545454 010101
545454 010110
545454 010101
545454 010110
545454 010101
767676 232332
767676 232323
767676 232332
767676 232323
767676 232332
767676 232323
989898 :;:;;:
989898 :;:;:;
989898 :;:;;:
989898 :;:;:;
989898 :;:;;:
989898 :;:;:;
=<=<=< >?>??>
=<=<=< >?>?>?
=<=<=< >?>??>
=<=<=< >?>?>?
=<=<=< >?>??>
=<=<=< >?>?>?
A@A@A@ BCBCCB
A@A@A@ BCBCBC
A@A@A@ BCBCCB
A@A@A@ BCBCBC
A@A@A@ BCBCCB
A@A@A@ BCBCBC
EDEDED FGFGGF
EDEDED FGFGFG
EDEDED FGFGGF
EDEDED FGFGFG
EDEDED FGFGGF
EDEDED FGFGFG
SRSRSR PQPQPQ
SRSSRR PQQPPQ
SRSRSR PQPQPQ
ONONON LMLMLM
ONOONN LMMLLM
ONONON LMLMLM
KJKJKJ HIHIHI
KJKKJJ HIIHHI
KJKJKJ HIHIHI
efU
abU
fU
eefU
aabU
ee bU
aa fefefefee babababaa
bfeUU
fU
fU
bU
ffefe bbaba
abU
bU
ae bU
feU
e
a
U
f
feffee babbaa
[\U
YZU
WXWU
`_`_`_ \U
^]^]^] ZU
\[\[\[ XU
ZYZYZY VTU
XWXWXW fU
VTVTVT bU
efU
aabU
fU
bU
[_ \U
Y] ZYU
T
U
V
e
a
fefefe bababa
[`_ \[U
W
T
U
X
U
V
e
a
U
f
U
b
YZU
WXU
TVU
VTVVTT bU
ae bU
efU
[[[ ^^^]]] ZU
YYY \[\\[[[ XU
WWW ZYZZYYY VU
TTT XWXXWWW fU
e
a
fefe baba
``_`_`_ \U
Z\U
\U
U
U
X
U
V
fU
VT bU
efU
aabU
[\U
YZU
WXU
TVU
ZU
XU
VU
efU
abU
[ ^^]^] ZU
Y \\[\[ XU
W ZZYZY VU
T XXWXW fU
`_ \U
e VTVT bU
a fefefe bababa
hghghg cdcddc
hghghg cdcdcd
hghghg cdcddc
hghghg cdcdcd
hghghg cdcddc
hghghg cdcdcd
jijiji klkllk
jijiji klklkl
jijiji klkllk
jijiji klklkl
jijiji klkllk
jijiji klklkl
nmnmnm opoppo
nmnmnm opopop
nmnmnm opoppo
nmnmnm opopop
nmnmnm opoppo
nmnmnm opopop
rqrqrq ststts
rqrqrq ststst
rqrqrq ststts
rqrqrq ststst
rqrqrq ststts
rqrqrq ststst
vuvuvu wxwxxw
vuvuvu wxwxwx
vuvuvu wxwxxw
vuvuvu wxwxwx
vuvuvu wxwxxw
vuvuvu wxwxwx

}~}~}~
}~~}}~
}~}~}~
|{|{|{ yzyzyz
|{||{{ yzzyyz
|{|{|{ yzyzyz

smoy
Tc
Figure 6.7. Bursts injectés depuis une source
noyau décrite en section 6.2.3.1. L'utilisation de fonctions périodiques pour déterminer la
taille des bursts rend cette technique pertinente dans ce cas.
On a donc, à la n de la phase d'injections des bursts, pour chaque ensemble de chemins
inclus dans P , les temps d'arrivées pour chaque burst du premier et dernier paquet.
Soit T (Pi ) l'ensemble contenant les résultats de tests injectés simultanément sur chacun
des chemins de Pi . Pour chacun de ces ensembles Pi , on évalue :
La néguentropie negens de l'ensemble T (Pi ), soit la néguentropie obtenue quand les
tests sont eectués simultanément.
La néguentropie negiso de l'ensemble {T ({p1 }), ..., T ({pi }), ..., T ({pn })}, pi ∈ P correspondant à l'injection de tests sur chacun des chemins de Pi séquentiellement (donc,
par dénition, les tests indépendants).
Puis on estime si les chemins de Pi partagent un sous-chemin commun en utilisant deux
conditions :
ens
neg
negiso > 1 + s1 , où s1 est un seuil déterminé empiriquement pour quantier l'augmentation de néguentropie minimum entre l'injection simultanée de tests et des tests
indépendants.
negens > s2 , où s2 est un seuil déterminé empiriquement pour quantier la néguentropie minimum que doivent contenir des résultats de tests simultanés pour que l'on
puisse considérer que l'ensemble des chemins partage un sous-chemin commun.
145
Notons que s2 est choisi empiriquement en observant les résultats de nos expériences,
mais semble conforme aux valeurs observées dans d'autres domaines utilisant la néguentropie comme estimateur [80]. Une fois obtenues les valeurs pour tous les éléments de la
décomposition de P en sous-ensemble, on procède à l'exploitation des valeurs de la même
manière que pour la technique basée sur l'injection de bursts UDP saturants telle que
décrite dans la section 6.2.4.
Cette technique de mesures permet d'évaluer l'indépendance des diérents chemins
appartenant à P sans pour autant arriver à une saturation trop forte préjudiciable au
trac interférent. Comme nous le verrons par la suite, la validation dans des conditions
réelles dans un réseau partagé par d'autres utilisateurs s'est faite sans heurts.
De plus, cette technique est relativement robuste dans le cas où le trac interférent
est important. Ceci est dû au fait que les diérents bursts UDP soumis au même trac
interférent vont tous porter la trace de ce trac, ce qui entraine une dépendance statistique
plus forte des intervalles de temps d'arrivée.
6.2.5.5 Limitations
La limitation principale de cette technique reste l'extensibilité de celle-ci à un grand
nombre n de chemins. Plusieurs facteurs impliquent cette limitation. En premier lieu, le fait
de devoir tester chaque sous-ensemble de P séparément implique que le temps de mesure
grandira factoriellement suivant n. De plus, pour un test impliquant un nombre important
de chemins, la contrainte de non-saturation rend de plus en plus improbable (au sens
probabiliste) la collision entre bursts circulant sur des chemins diérents. Cela implique
une diminution de la dépendance entre les distributions d'arrivées des bursts, et donc une
plus grande diculté à statuer sur l'existence de sous-chemins communs détectables. Un
grand nombre de chemins implique aussi qu'il faut choisir un grand nombre de fonctions
dont les distributions doivent être diérentes ; or, cela peut s'avérer complexe, car le fait
d'utiliser des paquets, et donc, d'avoir une fonction discrète permettant de calculer la
taille d'un burst pour un envoi i fait que les diérences entre les diérentes distributions
peuvent être gommées par cette discrétisation. Enn, l'interaction entre un grand nombre
de bursts provenant de sous-chemins communs atténue peu à peu la possible diérenciation
entre l'inuence des diérents bursts. Les limitations de ce type de techniques proviennent
donc de la mise en oeuvre de la théorie dans un environnement pratique où les bursts
sont constitués d'entités atomiques (les paquets) ayant une granularité moins ne que ce
que l'on pourrait désirer. En eet, étant donné que diviser un paquet en plusieurs petits
paquets entraîne à la fois un surcoût de traitement sur les noeuds d'un chemin, ainsi qu'une
plus faible incidence en cas d'immiscement dudit paquet dans un burst de paquets dos à
dos, pouvant ainsi réduire l'impact de l'interférence de plusieurs bursts entre eux, on n'a
146
qu'une étroite marge de manoeuvre sur laquelle nous pouvons inuer sur la granularité des
opérations. De plus, une limitation sur laquelle je n'ai pu faute de plate-forme adéquate
évaluer dans des conditions réelles les bornes est l'ordre de grandeur des diérents ux qui
sont impliqués dans une relation. En eet, si un test injecte des bursts UDP de très grande
taille par rapport aux autres, il est probable que si les autres porteront une trace importante
de leur interférence mutuelle, il n'en sera pas de même pour les bursts les plus grands. En
théorie - et cela a été conrmé dans une certaine mesure lors de nos expérimentations les intervalles d'arrivées des paquets des bursts de petites tailles devraient développer une
dépendance linéaire par rapport aux tests de grande taille injectés.
6.2.6 Technique parallèle basée sur l'approximation de la néguentropie
6.2.6.1 Description
Cette technique est une variante de la technique basée sur l'approximation de la néguentropie décrite en section 6.2.5 cette fois-ci adaptée à l'évaluation du partage de sous-chemin
commun entre un chemin pa dont les relations avec les autres chemins sont inconnues et
un ensemble de chemins P dont on sait que chaque paire de chemins appartenant à P est
indépendante.
La diérence fondamentale tient au fait que, comme on sait que les chemins appartenant
à P sont indépendants, on eectue une seule phase de tests où sont injectés des bursts
simultanément, suivant des fonctions propres à chacun des chemins, dont les périodes sont
premières entre elles. Les autres phases sont en eet inutiles : puisqu'on sait que les chemins
de P sont indépendants, on établit juste la néguentropie entre pa et les chemins de P . Pour
chacun des couples {pa , pi }, pi ∈ P , on établit leur néguentropie. Un système de seuillage
permet de statuer sur d'éventuels sous-chemins communs détectables.
L'exploitation des valeurs obtenues est similaire à celle décrite en section 6.2.5.3, excepté
que l'on n'a ici que des paires de résultats, et que l'on n'estime que les relations entre les
chemins deux à deux.
Cet algorithme permet de mettre en oeuvre des algorithmes du type de celui décrit en
section 5.4.6. Cela permet donc un gain de temps non négligeable lors d'expérimentations
réelles.
6.2.6.4 Limitations
Les limitations sont similaires à celles de la technique précédente, excepté pour le coût
qui est xe (en terme de tests) quelle que soit la cardinalité de P .
147
6.3
Synthèse
Au travers de l'état de l'art des techniques de mesures existantes, on a pu apercevoir
le nombre de techniques déjà existantes, mais malheureusement intransposables au problème de l'identication de sous-chemins communs k-détectables qui est nécessaire pour
la reconstruction de MINP. Puis, on a donné un ensemble de techniques de mesures permettant de reconstruire des MINP partiels pour des ensembles de chemins, que ce soit
pour une utilisation lors de simulation de bas niveau, de haut niveau, et enn dans des cas
réels. Comme expliqué dans la suite de cette thèse, les techniques de mesures basées sur
la néguentropie se comportent très bien dans des utilisations sur des plates-formes réelles
éventuellement partagées par d'autres utilisateurs.
148
Troisième partie
IMPLÉMENTATION ET VALIDATION
M.I.N.T.C.a.r : un outil pour la découverte
automatique de M.I.N.P.
De manière à tester et évaluer les performances et la faisabilité de la mise en oeuvre
des algorithmes présentés en section 5 ainsi que des techniques de mesures présentées
en section 6, nous avons développé un outil permettant à l'utilisateur de soumettre des
requêtes de reconstruction pour une conguration donnée. Nous donnons dans ce chapitre
une description rapide de celui-ci, tant au niveau des technologies mises en oeuvre que
de l'architecture, puis donnons les principales dicultés liées à la mise en oeuvre des
techniques et méthodes développées pendant cette thèse.
7.1
Présentation générale de l'outil
L'outil en lui-même est séparé en 2 parties principales :
Un outil générique permettant l'injection de paquets le long d'un chemin. Notre outil
est une version étendue par nos soins d'UDPMon [38]. Nous avons rajouté à l'outil
initial développé un certain nombre d'options permettant de jouer sur diérents
paramètres ainsi que de récupérer les données nécessaires à la mise en oeuvre de nos
méthodes. Cet outil est utilisé pour déterminer la bande passante disponible le long
d'un chemin ainsi que pour réaliser les mesures elles-mêmes.
Un ensemble d'outil de soumission et d'exécution de reconstruction comportant des
fonctionnalités de visualisation d'un MINP. Cet outil, possédant une interface de
type web service, est composé d'un ensemble de services codés en Java s'exécutant
au sein d'un serveur Tomcat [3]. Une interface utilisateur de type Web est fournie,
permettant de soumettre des requêtes de reconstruction et visualiser les résultats de
cette reconstruction.
Ces deux parties principales contiennent plusieurs services que nous vous présentons dans
la section suivante.
7.1.1 Architecture
L'architecture de notre outil, M.I.N.T.C.A.R. (Metric Induced Network Topology Construction, Analysis and Retrieval ) peut être vue comme un ensemble de web service
150
M.I.N.T.C.a.r : un outil pour la découverte automatique de M.I.N.P.
distribués géographiquement sur les diérents noeuds S ∪ R appartenant à la plate-forme
réseau sur laquelle sont dénis les chemins.
7.1.1.1 Vue logique
D'un point de vue logique, l'outil comprend 5 services principaux répondant à un
découpage des activités classiques de type architecture 3-tier :
Le serveur de présentation donnant les interfaces de soumission, de visualisation, et
de stockage des reconstructions déjà eectuées.
Le serveur d'application recevant les requêtes de reconstruction et exécutant celles-ci
en ordonnançant les diérentes mesures ainsi qu'en eectuant l'algorithme de reconstruction choisi.
Le serveur de coordination local, permettant l'exécution d'une mesure en coordonnant les diérents tests, c'est-à-dire les diérentes injections de ux.
Le serveur de requêtes permettant de demander un test entre une machine source
sur laquelle il est hébergé vers un noeud où est installé le démon de réception des
requêtes d'évaluation des performances réseau.
Enn, un démon qui est une version étendue de celui d'UDPMon qui traite les demandes de tests en jouant le rôle de noeud destination.
Notons que nous avons mis à disposition une interface de type Applet permettant de
visualiser les MINP produits. La gure 7.1 donne une vue d'ensemble de la répartition des
fonctionnalités entre ces diérents services.
Interface de soumission
Web service de soumission
Service de stockage des MINP
Service de coordination des tests
Service d’execution
Service d’ordonnancement des mesures
Algorithmes de reconstruction
Analyseur des tests
Service d’execution des tests
Senseur
Figure 7.1. Vue d'ensemble de l'outil
7.1.1.2 Vue déploiement
Du point de vue du déploiement, l'outil comporte 6 types d'installations :
Une machine cliente ne nécessitant pas d'installation spécique, si ce n'est celle d'un
navigateur Web qui servira de client léger.
151
Une machine de présentation (MintServer), sur laquelle seront installées les fonctionnalités de présentation (visualisation, stockage, interface de soumission). Notons que
cette machine peut être identique à celle utilisée pour servir de serveur d'application.
Une machine responsable de l'exécution de l'algorithme (MintServer) et par conséquent de l'ordonnancement des mesures nécessaires à la bonne exécution de l'algorithme choisi.
Un service de coordination des tests pour l'exécution des mesures (MintLocalCoordinator) sera déployé sur un ensemble de machines. Cet ensemble peut être le même
que celui de machines de type MintRequester introduit ci-après. Notons que ce service n'est nécessaire que pour l'exécution de l'algorithme de type "o-line" décrit en
section 5.4.3.
Un ensemble de machines sources (MintRequester) hébergera les fonctionnalités permettant d'évaluer un chemin depuis celles-ci. Il héberge un service Web ainsi que la
partie cliente étendue d'UDPMon que nous avons développé.
Enn, un ensemble de machines (correspondant à l'ensemble R) hébergera le démon étendu par nos soins d'UDPMon (udpmon_resp) pour pouvoir jouer le rôle de
machine destination.
La gure 7.2 donne une vue d'ensemble des diérents types de déploiement.
Machines de gestion de MINTCAR
Machines
clientes
Client
MintServer/presentation
MintServeur/execution
MintLocalCoordinator
Machines de la plate−forme
MintRequester
udpmon_resp
Figure 7.2. Déploiement de l'outil
152
7.1.1.3 Vue implémentale
Les principaux paquetages constituant notre application sont les suivants :
Le paquetage d'analyse comprenant les diérents outils statistiques et mathématiques
permettant l'analyse des résultats des tests.
Le paquetage de présentation comprenant les diérentes pages d'interface et les
classes permettant de visualiser les MINP.
Le paquetage d'application contenant les codes des diérents algorithmes implémentés pour la reconstruction des données.
Le paquetage de test comprenant les parties clients et serveurs d'udpmon modiées
par mes soins.
Le paquetage d'interface entre la partie C et la partie java.
Le paquetage de coordination locale des tests.
Le paquetage d'entrée/sortie pour les diérents formats XML.
Le paquetage de modélisation mathématique des treillis.
Le paquetage d'interface web service pour l'exécution des algorithmes.
Le paquetage d'interface web service pour l'interface de soumission de plate-forme.
Le paquetage d'interface web service pour la soumission de tests.
Le paquetage pour l'exécution d'algorithmes en mode applet.
La gure 7.3 donne une vue d'ensemble des diérents paquetages développés.
paquetage IHM
Interface applet
Web service de soumission de plate−forme
Gestion des treillis
Web service d’execution
Entree/sortie XML
Paquetage de reconstruction
paquetage analyse
coordination Locale
Web service interface de soumission de tests
Paquetage d’interface C/Java
UDPMon client
UDPMon server
Figure 7.3. Vue implémentale
7.1.1.4 Cas d'utilisation
Nous donnons ici un cas typique d'utilisation de l'outil pour la soumission de requêtes.
Les autres fonctionnalités (visualisation et récupération des topologies reconstruites) étant
153
relativement triviales et de peu d'intêret, nous ne les décrivons pas ici.
Pré condition L'utilisateur dispose de la liste des adresses des machines ainsi que des
ports sur lesquels sont installés les services propres aux machines sources et destinations,
et connaît une machine où est installé le service d'interface.
Post-condition L'utilisateur dispose d'un MINP pour la plate-forme qu'il souhaite connaître
et peut la visualiser via les outils mis à disposition sur le serveur de présentation.
Scénario nominal
Connexion de l'utilisateur à la machine interface.
Soumission de la part de l'utilisateur du chier XML contenant la description de la
plate-forme sur laquelle doit être menée la reconstruction.
Transfert entre le serveur de présentation et le serveur d'application du chier XML.
Génération du chier dans lequel sera stocké la structure reconstruite et renvoi de son
identiant au serveur de présentation qui renvoie une page Web contenant l'adresse
où le chier sera consultable une fois la reconstruction achevée.
Lancement de l'exécution de l'algorithme choisi par l'utilisateur pour la reconstruction dans un thread.
Envoi des descriptions des mesures aux diérents MintLocalCoordinator.
Le MintLocalCoordinator contacte les diérents MintRequester pour l'exécution de
tests.
Les MintRequester injectent des tests vers le démon UDPMon destination.
Le démon renvoie les données nécessaires à la reconstruction au MintRequester.
Les MintRequester retournent ses données à leur MintLocalCoordinator.
Reconstruction du MINP partiel par les MintLocalCoordinator.
Envoi du MINP partiel des MintLocalCoordinator vers le serveur d'application.
Reconstruction du MINP pour toute la plate-forme à partir des diérents MINP
partiels.
Sauvegarde de la structure reconstruite dans le chier prévu à cet eet.
Envoi d'un mail avertissant de la n de l'exécution à l'utilisateur contenant le MINP
lui-même ainsi que les adresses où il pourra les consulter.
Le diagramme correspondant à ce cas d'utilisation est donné à la gure 7.4. Notons
que dans le cas d'algorithmes autres que celui décrit dans la section 5.4.3, le serveur d'application joue le rôle de MintLocalCoordinator.
7.1.1.5 Vue architecture
La norme en vigueur pour l'interface d'un service de grille est de fournir une interface
dite Grid Service (interface de type web service avec quelques ajouts tels que la durée de
154
Client
serveur presentation
Description de la plate−forme
MintCarServer
MintCarLocalCoordinator
MintRequester
UDPMonClient
UDPMonServer
Description de la plate−forme
Generation du fichier
temporaire sur le serveur
qui contiendra le MINP
Adresse du fichier contenant le MINP sur le serveur de presentation
Thread algorithme
Requete de test local
Coordination des tests
evaluation de la bande passante
calcul des parametres des tests
Description du test
Description du test
test
donnees obtenues
donnees obtenues
donnees obtenues
Calcul du MINP partiel
MINP partiel
Requete de test local
MINP partiel
Calcul du MINP total
MINP total
Courrier electronique contenant le MINP et l’adresse pour la visualisation
Requete de visualisation
Visualisation du MINP par l’applet
Figure 7.4. Vue d'un cas d'utilisation
vie de la ressource) pour permettre une interopérabilité simple entre services provenant
de diérents fournisseurs. Dans un tel contexte, nous avons choisi une architecture nous
permettant d'être compatibles avec une telle norme pour l'interface de soumission ainsi
que celle de récupération des résultats. De plus, pour éviter les éventuels problèmes de
rewall (pare-feu) et ouvertures de ports divers entre les sites, nous avons réutilisé les
ports standards des diérents outils utilisés.
7.1.1.6 Pré-requis pour l'installation
Les diérents types d'installations étant soit uniquement des installations de web service (interface, MintServer, MintLocalCoordinator), soit des installations nécessitant un
serveur de web services et une installation d'UDPMon (MintRequester), soit enn des installations ne demandant que la partie démon d'UDPMon, dont les pré-requis logiciels et
de conguration sont assez simples.
Les pré-requis logiciels sont les suivants :
Pour les web services : il est nécessaire de disposer d'une machine virtuelle java ainsi
que d'une version de Tomcat postérieure ou égale à la version 5.5.
Pour UDPMon : il est nécessaire que la machine ait un système d'exploitation de
type Unix ou Linux. De plus, il est nécessaire que la machine dispose d'un processeur
Intel.
Notons enn que dans le cas du MintRequester, il est nécessaire que la commande udpmon_bw_mon soit disponible dans le chemin accessible par un processus de Tomcat.
155
Les ports par défaut utilisés par les diérents composants sont les suivants (et doivent
donc être ouverts pour pouvoir être utilisés) :
Pour les web service : port 8080 en entrée/sortie pour un trac TCP.
Pour UDPMon : port 14233 en entrée/sortie pour un trac UDP.
Notons que les numéros de ports ne sont pas xés. Nous donnons ici les valeurs par défaut
de ces paramètres.
7.1.2 Technologies mises en oeuvre
7.1.2.1 UDPMon
UDPMon [38] est un outil libre permettant de mesurer diverses informations sur le
réseau à partir de l'injection le long d'un chemin de paquets UDP. Il est assez souple,
permettant des injections de paires de paquets ou encore de trains de paquets suivant
divers motifs temporels. Nous avons dû étendre ces motifs pour pouvoir tester nos propres
méthodes ; la liste des nouvelles options que nous avons développées dans cet outil sont
disponibles en annexe. UDPMon nécessite de disposer d'un environnement logiciel de type
Linux. De plus, il utilise des fonctionnalités du processeur (interruptions) pour obtenir des
mesures nes des écarts de temps ; ceci réduit son utilisation aux machines possédant un
processeur Intel.
7.1.2.2 Galicia
Galicia [114] est un outil libre initialement destiné à l'exécution d'algorithmes de reconstructions de treillis de Gallois ainsi qu'à la visualisation des treillis reconstruits. Il
permet de stocker les treillis reconstruits de manière pérenne sous forme de chier. La version Applet de notre outil est très fortement basée sur ce logiciel, même si j'ai développé un
format propre aux treillis de type MINP et modié l'interface de manière à la brider et ne
permettre l'exécution d'algorithmes que sur ce type de treillis. Notons que seul l'algorithme
"o-line" est disponible dans l'applet.
Dans la version service de l'outil, seul l'interface de visualisation de treillis de Galicia
a été conservée.
7.1.2.3 Autres
Les diérents outils utilisés mais non modiés faisant partie de l'environnement logiciel
de notre outil sont :
Tomcat, de Jakarta, est un conteneur de servlet J2EE. Nous avons utilisé Tomcat
pour y déployer les diérents web service composant l'outil.
Javamail, de Jakarta, est un paquetage libre permettant de gérer des mails depuis
un processus Java. Nous avons inclus une alerte par mail lors de la n de l'exécution
du processus de reconstruction à l'aide de ces outils.
156
Colt du CERN [7] est un paquetage de calcul matriciel rapide pour java. Nous l'avons
utilisé pour coder les phases de reconstruction de MINP partiels à partir des mesures
de néguentropie que nous avons décrites en section 6.2.5.
7.1.2.4 Utilisation du format XML
les web services disposent entre eux d'une interface d'échange en XML. De plus, l'utilisateur utilise ce format pour les deux formats de chiers nécessaires à la soumission de
requêtes de reconstruction ainsi qu'à la récupération du MINP reconstruit. Un des formats
dénit une plate-forme cible sur laquelle vont être eectuées les mesures, sous forme d'un
ensemble de chemins dénis par un couple source (port)/destination (port). L'autre format nécessaire est celui permettant de décrire un MINP. Il est constitué d'un ensemble de
chemins, ainsi que de sous-chemins dénis par leurs relations de couverture des chemins et
sous-chemins qu'ils couvrent. Ces deux formats sont donnés en annexe.
7.1.3 Quelques mots sur l'interface
Pour plus de facilité, nous avons mis en place une interface de type .jsp pour soumettre une requête en soumettant un chier, choisir l'algorithme à utiliser, parcourir la
base contenant les MINP déjà reconstruits, et visualiser ces derniers. L'ensemble de cette
interface peut être hébergé sur un serveur dédié ; néanmoins vu que cette interface n'est pas
énorme, elle fait partie du paquetage serveur. Un exemple de capture d'écran de l'interface
est donné à la gure 7.5. La capture présente la visualisation d'un MINP déjà reconstruit
et stocké sur le serveur. Notons que l'image centrale est la capture de l'achage de l'applet
permettant une visualisation 2D ou 3D du MINP (ici visualisation en 3D, les noeuds rouges
sont l'inmum et le supremum), ainsi que certaines manipulations de celui-ci (rotations en
mode 3D, représentation soumise à des contraintes de forces, déplacement de noeuds, etc).
Cette applet est une version modiée de celle incluse dans le projet Galicia, et est aussi
disponible en standalone.
7.1.4 Limitations actuelles
A l'heure actuelle, l'application ne permet pas à plusieurs utilisateurs de soumettre des
requêtes de reconstruction de manière saine. Un développement ultérieur devrait être fait
pour apporter le support d'une telle fonctionnalité.
Une autre limitation est le nombre d'algorithmes mis en oeuvre : nous n'avons à l'heure
actuelle rendu disponible que l'algorithme décrit dans la section 5.4.3, ainsi que les algorithmes LTC 5.4.5 et 5.4.6. Cependant, l'architecture souple du service d'exécution de requête permet une intégration future assez facile de nouveaux algorithmes (les algorithmes
respectent une interface Java unique de type Thread).
157
Figure 7.5. Capture d'un écran de l'interface
7.2
Mise en oeuvre des algorithmes et mesures développées
Dans cette section nous traitons des aspects pratiques (dicultés de mise en oeuvre et
limitations induites par celles-ci) de la mise en oeuvre des techniques de mesures décrites
au chapitre 6 ainsi que des algorithmes décrits en section 5. Nous ne traitons pas ici des
aspects validation de ces méthodes, mais dans le chapitre 8.
7.2.1 Mesures par envois de bursts périodiques
La technique de mesure par envois de bursts périodiques 6.2.3 n'est plus disponible
par l'intermédiaire de l'interface utilisateur classique. En eet, cette technique, bien qu'efcace théoriquement, s'est montrée en pratique totalement inecace, de par son absence
de tolérance de délais qui peuvent survenir même sur une plate-forme exempte de trac
interférent. Néanmoins sa mise en oeuvre est toujours possible par l'utilisation de notre
client UDPMon modié.
158
7.2.2 Mesures par envois de burts UDP saturants
Cette technique 6.2.4 est disponible via l'interface de soumission de requête du MintRequester. Même si les résultats obtenus sont probants, nous avons décidé de l'abandonner
car elle est, de par sa nature, trop destructrice pour le trac interférent pour être déployée
sur un réseau partagé. Cette méthode donne pourtant de bons résultats et, de par sa
simplicité, est très simple à mettre en oeuvre.
7.2.3 Mesures basées sur la néguentropie
7.2.3.1 3-mesure 1-test
Dicultés de mise en oeuvre Un problème particulier est celui du comportement
d'une mesure quand un noeud est présent plusieurs fois dans l'ensemble des noeuds impliqués dans une mesure. Par exemple, un noeud peut être à la fois source et destination, ou
bien encore source de plusieurs chemins, ou encore destination de plusieurs chemins.
Le problème n'est pas complexe quand le noeud est la source de plusieurs chemins
simultanément, ou lorsque le noeud est simultanément source et destination, puisque les
diérents rôles correspondent à des processus diérents sur la machine ne partageant aucune donnée. Dans le cas où un noeud est destination, nous avons adapté la partie démon
d'UDPMon pour qu'elle puisse admettre plusieurs requêtes de transferts simultanées.
Un autre problème est celui du calcul des paquets ainsi que de la taille (en nombre
de paquets) de chaque train de paquets envoyé. Par défaut, les paquets envoyés sont de
taille maximale (soit 1472 pour un MTU de 1500). En pratique, le calcul du nombre de
paquets à envoyer est basé sur la bande passante disponible. Or, un nombre "susant"
de paquets est nécessaire pour que la dispersion des paquets puisse être observée. Dans
le cas où la bande passante disponible est trop basse, on réduit la taille des paquets. Or,
réduire la taille des paquets, et ainsi en augmenter le nombre si l'on considère un burst
de taille constante, implique un surcoût sur la machine source qui, en pratique, peut faire
que les paquets ne sont plus envoyés dos à dos, rendant inecace l'injection de ceux-ci. Il
existe donc une limite inférieure en terme de bande passante sur laquelle la méthode est
applicable.
Limitations La partie démon d'UDPMon ne peut, à l'heure actuelle, être destination de
plus de 3 chemins simultanément. Cette limitation -arbitraire- est dûe au fait que le démon
stocke, avant de les renvoyer, les délais entre les paquets de l'ensemble de l'échantillon (1000
bursts). Nous avons limité cette capacité manuellement pour éviter de consommer trop de
mémoire.
De plus, comme nous l'avons indiqué précédemment, il existe une limite inférieure pour
laquelle cette méthode n'est plus valide. Elle dépend de plusieurs paramètres, comme la
159
puissance de la machine source ainsi que la bande passante disponible. Lors de nos tests
sur plate-forme réelle, et compte tenu des machines peu puissantes à notre disposition,
nous avons pu mesurer une perte d'ecacité de la détection de sous-chemins communs en
dessous de 5 Mb/s.
7.2.3.2 k-mesure parallèle
Dans le cas de 1-mesure parallèle, nous nous heurtons à plusieurs aspects d'ordre pratique. Si en théorie, il est possible de donner une distribution diérente pour chaque ux
traversant un chemin, en pratique, les problèmes dûs au fait que nous travaillons sur des
variations de taille de bursts constitués de paquets fait qu'il est dicile de donner des
distributions vraiment diérenciables entre un grand nombre de ux. En pratique, nous
avons implémenté seulement 4 types de distributions basées sur des fonctions classiques
(sinusoïdes, créneau, dent de scie, triangle). Le même type de problème se pose lors de la
détermination de périodes diérentes pour chacun des tests devant être simultanés. Des différences trop faibles de période peuvent être préjudiciables. Nous utilisons pour les mesures
supérieures à 4 la même distribution pour tous les ux indépendants.
7.2.4 Algorithmique
7.2.4.1 Mise en oeuvre
La partie algorithmique mise en oeuvre dans cet outil est entièrement développée en
Java. Ne manipulant pas de gros volumes de données, aucune diculté particulière n'est à
signaler pour les algorithmes en eux-mêmes.
7.2.4.2 Limitations
La seule limitation ici est le nombre d'algorithmes que nous avons implémentés dans
cette partie jusqu'à maintenant.
7.3
Autres caractéristiques de l'outil
Cette section donne une vue d'ensemble des autres caractéristiques propres à l'implémentation de nos méthodes dans cet outil.
7.3.1 Tolérance aux pannes
Il n'est pas rare, dans le monde réel, que les services ou les machines soient injoignables.
Il est aussi possible, comme nous le verrons par la suite dans le chapitre 8 que la liaison entre
deux senseurs ne soit pas susante pour permettre de mener à bien nos tests. Dans ce cas,
160
l'outil considère que le chemin défaillant est un chemin de capacité nulle ; de plus, puisque
nous ne pouvons tester les interactions entre ce chemin et d'autres chemins appartenant à
la plate-forme, l'outil le considère comme indépendant de tout autre ux. Il en résulte que
la représentation du chemin dans le MINP produit n'est qu'un noeud uniquement relié à
l'inmum et au supremum du MINP.
7.3.2 Stockage des MINP
Dans le cadre d'une utilisation réelle de l'outil, c'est-à-dire dans un environnement
multi-utilisateurs, il est plus que probable que plusieurs utilisateurs tenteront d'évaluer
une plate-forme semblable. Pour pallier à ce problème, l'outil conserve les MINP déjà
reconstruits dans une base consultable par tous.
7.3.3 Evolutivité
L'implémentation a été réalisée en gardant à l'esprit le fait que l'on puisse rajouter
des algorithmes au cours de la vie de l'outil, ainsi que de nouvelles techniques de mesures.
Les implémentations des diérents services passent donc toutes par des interfaces Java,
permettant aisément de rajouter des algorithmes et des techniques de mesures.
7.4
Synthèse
Dans ce chapitre, on a décrit l'outil développé dans le cadre de cette thèse, permettant
de mettre en oeuvre les techniques de mesures et algorithmes de reconstruction dédiés
au MINP développés dans les chapitres précédants, mais aussi de manipuler les MINP et
les stocker. D'architecture en tier orienté web service assez classique, il donne un cadre
général permettant d'envisager une utilisation réelle et, de par son extensibilité, un socle
solide pour l'implémentation d'algorithmes et de techniques de mesures développés dans
le futur.
161
Validation
Ce chapitre est dédié aux résultats des expériences menées dans le cadre de cette
thèse pour valider les algorithmes et techniques de mesures que j'ai développés. Après
de premières expériences menées par simulation, l'outil a été déployé d'abord dans un
réseau privé fermé et sous contrôle, puis sur un certain nombre de machines dispersées
géographiquement.
8.1
Méthodologie de validation
La validation de nos travaux passe par la validation des deux principales parties nonthéoriques de l'application, c'est-à-dire :
Les algorithmes de reconstruction en validant les MINP reconstruits en vériant la
cohérence de ceux-ci par rapport aux connaissances que l'on a des plates-formes
cibles, en utilisant à la fois la simulation et l'expérimentation réelle.
Les diérentes techniques de mesures, en validant par la simulation puis l'expérimentation réelle les diérents choix implémentés.
Nous détaillons dans les sections suivantes les méthodes et outils utilisés pour parvenir à
cette validation.
8.1.1 Validation des algorithmes
La validation des algorithmes pouvant se faire en l'absence d'implémentation réelle
des techniques de mesures, nous avons développé un environnement de test "o-line" de
ceux-ci sous forme d'une application Java dans le cadre du framework proposé par Galicia
[114]. Pour obtenir les MINP partiels nécessaires à l'exécution des algorithmes, nous avons
utilisé un simulateur de haut-niveau pour générer ces MINP partiels à l'aide de techniques
de mesures spéciques.
8.1.2 Validation des techniques de mesures
Nous avons utilisé trois principales voies pour valider les techniques de mesures :
La validation des techniques par simulation.
162
Validation
La validation des techniques de mesures au sein d'une plate-forme réseau réelle connée.
La validation des techniques de mesures sur une plate-forme réseau réelle (un réseau
public).
8.2
Outil de validation
8.2.1 Simulateurs
Dans le cadre de cette thèse, j'ai dû utiliser plusieurs types de simulateurs :
Des simulateurs bas niveau pour valider théoriquement les techniques de mesures
décrites en section 6.
Des simulateurs de haut niveau pour valider théoriquement les algorithmes de reconstruction décrits en section 5.
La raison pour laquelle je n'ai pas utilisé uniquement des simulateurs de bas niveau est
assez simple : le côut d'une simulation d'une mesure était tel que le temps de simulation
d'une reconstruction complète était prohibitif. J'ai donc eu recours à un simulateur de haut
niveau pour obtenir des résultats similaires à ceux qu'auraient produits les techniques de
mesures de manière plus rapide, dans le but de tester mes algorithmes sur des plates-formes
de dimension plus grande.
8.2.1.1 NS-2
NS-2 [24] est sûrement le simulateur libre de réseau de bas niveau le plus utilisé dans
le monde. Il permet l'étude du comportement théorique des équipements déployés le long
du réseau. On peut intervenir sur deux niveaux d'abstractions : soit en codant en C de
nouveaux modules permettant de simuler le comportement de manière ne soit d'un protocole soit d'un équipement particulier, soit en codant en Otcl [26], un langage de script,
si l'on utilise des primitives de plus haut niveau. Les fonctionnalités déjà implémentées
étant susantes pour nous permettre de tester nos diérentes techniques de mesures, les
simulations que nous avons développées sur NS-2 sont uniquement en otcl. L'architecture
de NS-2 permet d'intervenir à plusieurs niveaux des couches réseau tel qu'illustré à la gure
8.1 :
Trac Pareto, ON/OFF, CBR, FTP, telnet, etc.
Couche Transport TCP, UDP
Couche Réseaux IP, routage dans les réseaux ad hoc (aodv, dsr , dsdv, tora, amodv),
routage dans les réseaux laires (Link state, Distance vector), les réseaux multicast,
IntServ, DiServ
163
Validation
Couche MAC CSMA, CDMA, 802,X, Token ring, MPLS, liens satéllite, etc.
Trafic (WEB, CBR, FTP)
Application
Protocole transport (TCP, UDP)
Agent
Noeud
Delai, debit, file d’attente
Lien
Figure 8.1. Vue d'ensemble de ns-2
8.2.1.2 SimGrid
SimGrid [32] est un simulateur de grille de haut niveau permettant de simuler le comportement d'applications fonctionnant sur une grille. A partir d'une description de plate-forme,
il permet de développer des applications qui gèrent des ux plutôt que des applications. La
gestion de protocoles de haut niveau, tels que TCP, et surtout l'utilisation du paradigme
de partage de la bande passante dit de INV-RTT-BOUNDED déjà décrit en section 6.1.5,
nous a permis de développer la technique de mesure décrite en section 6.2.2.
Pour cela, SimGrid propose un ensemble de bibliothèques logicielles permettant d'interagir à diérents niveaux d'abstractions (voir gure 8.2). Dans notre cas, le plus logique
est d'utiliser la bibliothèque Amok, car elle nous donne les briques de base nécessaires à
l'implémentantation de nos mesures naïves. En eet, Amok met à disposition deux fonctions utiles : l'une permet de saturer un lien réseau, l'autre permet de mesurer la bande
passante disponible sur un chemin compte-tenu du trac interférent. Ainsi, en utilisant ces
deux fonctions, et puisque le partage de bande passante est implémenté dans ce simulateur
en utilisant le INV-RTT-BOUNDED, alors l'implémentation de nos méthodes de mesures
naïves apparaît sans dicultés.
8.2.2 Plates-formes réelles
Dans le but de tester et valider les diérentes techniques de mesures, j'ai eu à ma
disposition une dizaine de machines, peu puissantes, ainsi qu'un ensemble d'équipements
réseau me permettant de tester et d'appliquer les diérentes techniques sur des congura164
Validation
Code utilisateur et contributions
MSG
simulation
de niveau
application
AMOK
GRAS
Framework de dev
d’applications
SMPI
SImulation
de MPI
SIMDag
Framework
pour l’utilisation
de DAG
distribuées
SURF − simulation de plates−formes
XBT − fonctions de base
Figure 8.2. Vue d'ensemble de simGrid
tions réseau variées. 8 de ces machines sont des Optiplex Gx240 de chez Dell de 128 Mo
de RAM, processeurs Intel pentium 4 1.5 Ghz, disposant de cartes réseau Ethernet 100,
ayant comme système d'exploitation Scientic Linux 3. La dernière est un Optiplex Gx110
de chez Dell dotée de 256 Mo de RAM et d'un processeur Pentium III 667 Mhz possédant
aussi une carte Ethernet 100 et dotée du système d'exploitation Fedora Core 4. Malgré
l'âge (et donc la faiblesse des performances) de ces machines, l'exécution de mesures sur
celles-ci était tout à fait faisable.
Ces mêmes machines ont été déployées dans une deuxième phase physiquement le long
du réseau du campus (voir gure 8.3). Notons cependant que ce réseau comprend un lien
d'une trentaine de kilomètres, du fait de la séparation de certains réseaux.
8.3
Validation des algorithmes de reconstruction
8.3.1 Simulation de haut niveau
La validation par simulation des algorithmes de reconstruction a porté sur les algorithmes implémentés dans l'outil M.I.N.T.C.A.R., à savoir ceux décrits en section 5.4.3,
5.4.5 (LTC) et 5.4.6 (LTCP). Nous avons utilisé la technique de mesure décrite dans 6.2.2
pour obtenir les MINP partiels résultant des mesures. Les algorithmes implémentés étant
déterministes, leurs résultats seront par dénition corrects quand les plates-formes cibles
respectent les hypothèses de dénition d'un MINP et que les mesures donnent des résultats
partiels corrects. La validation de l'algorithmique revient donc à valider l'implémentation
165
Validation
de celle-ci, l'apport réel de la validation venant surtout de la validation des techniques de
mesures. L'algorithmique a été testé avec succès sur diérentes plates-formes.
Au vu du faible nombre de machines, l'utilisation de nos machines autour d'une plateforme expérimentale ne présentait que peu d'intérêt, cette technique étant plus dédiée à
la validation des mesures. Nous avons principalement testé nos algorithmes par simulation
de haut niveau et sur des plates-formes réelles.
8.3.3 Tests réels
L'architecture du réseau hébergeant les diérentes machines que nous avons utilisées
pour nos tests est présenté à la gure 8.3. Nous avons utilisé diérentes descriptions de
plates-formes pour dénir des réseaux intéressants à tester sur cette plate-forme.
8.4
Validation des méthodes de mesures
8.4.1 Simulation
Nous avons validé par simulation de bas niveau les techniques de mesures décrites en
section 6.2.3 et 6.2.2.
Nous avons tenté de valider sur plate-forme expérimentale les diérentes techniques que
nous avions validées théoriquement. Rapidement, de nombreux problèmes ont commencé à
apparaître, nous forçant à redévelopper de nouvelles techniques et méthodes. Après cette
étape de test, on n'a gardé que les méthodes les plus ecaces et les moins intrusives,
c'est-à-dire les méthodes basées sur la néguentropie.
8.4.3 Tests réels
Pour tester dans des situations réelles nos mesures, nous n'avons eu recours qu'à celles
décrites en section 6.2.5 6.2.6, les autres techniques s'étant révélées inecaces lors des tests
utilisant la plate-forme expérimentale, ou, dans le cas de celui de l'injection de burst UDP
saturant, trop destructrice pour le trac interférent pour être utilisé sur un réseau partagé.
166
Validation
mintcarX.esil.univ−mrs.fr
numericable 128kb/s
SWITCH 100 Mb/s
SWITCH 100 Mb/s
LIEN DE SORTIE 128Kb/s
LAN ESIL 100 Mb/s
LIEN DE SORTIE 10/100 Mb/s
RESEAU CAMPUS
PHOCEAN
LIEN DE SORTIE 100 Mb/s
LAN CPPM 100Mb/s
SWITCH 100 Mb/s
marconnetX.in2p3.fr
mintcarX.datagrid.cnrs.fr
Figure 8.3. Déploiement réseau
8.4.4 Taux d'erreur
La gure 8.4 nous montre le résultat de 400 tests eectués le long de 8 chemins sur la
plate-forme réelle. Les tests ont été eectués en concurrence potentielle avec des utilisateurs,
mais sur une "période calme" traditionnellement de la vie d'un campus, c'est-à-dire pendant
les vacances d'été. Le trac interférant était donc à priori faible.
Les diérents tracés représentent les valeurs de néguentropie obtenues pour ces 8 chemins ordonnés par ordre décroissant. Les valeurs, basses, sont conformes à celles observées
dans ce cadre dans d'autres domaines (voir par exemple [80]), la néguentropie ne dépassant
pas O.35. Les diérents chemins utilisés expliquent les diérentes valeurs :
Les deux chemins ayant obtenu les valeurs les plus hautes sont des chemins d'origine diérente partageant la même destination. Ceux-ci sont fortement dépendants,
puisque les machines cibles, peu puissantes, constituent un goulot d'étranglement
167
Validation
0.35
0.30
1
Neguentropie
0.25
0.20
0.15
0.10
2
0.05
3
0.00
0
5
10
15
20
25
30
35
40
Nombre de tests
Figure 8.4. Néguentropie pour les diérents sous-chemins communs
majeur.
Les deux courbes intermédiaires sont des courbes de néguentropie entre 2 chemins
partageant aussi des ressources réseau (la liaison CPPM vers ESIL) sans partager la
même origine ni la même destination.
Les autres courbes sont des chemins indépendants les uns des autres.
Ces données permettent de constater que l'estimation de la néguentropie est un critère
able pour déterminer l'information mutuelle partagée par les ux. Les expérimentations
ont consisté en la récupération de 1000 valeurs d'intervalles entre le premier et le dernier
paquet d'un burt pour chaque destination. L'utilisation de la technique du noyau pour
éliminer les problèmes de synchronisation nous a obligé à tripler le nombre de mesure.
L'intervalle Ut choisi était de 2 millisecondes. L'obtention d'un MINP partiel pour un triplet
de chemin impliquait donc environ 42 secondes de mesures. Notons que le temps total de
récupération du MINP, lors de nos expériences, était d'environ 1 minute 40 secondes,
temps dû aux calculs complexes nécessités par l'évaluation de la néguentropie de chacun
des sous-ensembles de l'ensemble de chemins du MINP partiel, et donc à la manipulation
d'un important volume de données compte tenu des performances très modestes de nos
machines. L'utilisation de machines plus récentes devrait faire largement diminuer le temps
de récupération du MINP partiel.
168
Validation
8.5
Synthèse
Grâce à l'outil développé dans le cadre de cette thèse, on a pu valider les techniques de
mesures décrites dans cette thèse ainsi que les algorithmes de reconstructions de MINP.
Les diérentes validations (par simulation de bas niveau, simulation de haut niveau, expérimentation sur un réseau conné et enn tests réels) ont permis d'identier les techniques
de mesures les plus ecaces et de valider les algorithmes développés.
169
Conclusion
Dans ce chapitre, nous donnons une rapide synthèse du travail conduit pendant cette
thèse, ainsi qu'un rapide portrait des diérents axes de travaux futurs qu'il semble intéressant de développer lors de travaux ultérieurs dans ce domaine.
9.1
Apport des travaux
Nous avons donc :
Déni deux nouveaux modèles pour la représentation des connaissances du réseau
obtenues par l'injection de tests eectués de bout en bout au travers de celui-ci.
Prouvé que ces modèles permettaient d'instancier un problème bien déni à partir
duquel nous donnons des exemples d'algorithmes de reconstruction
Conçu et développé des techniques de mesures qui ont donné des résultats satisfaisants dans le cadre pratique.
Implémenté un outil permettant la mise en oeuvre et l'utilisation de la chaîne complète modèle/algorithmique de reconstruction/mesure.
Validé nos techniques de mesures et algorithmes dans des cas réels à l'aide de cet
outil.
9.2
Axes de travaux futurs
4
axes principaux se déssinent naturellement pour de futurs travaux :
Le ranement de la modélisation des interactions entre chemins.
L'amélioration des algorithmes de reconstruction.
L'amélioration des techniques de mesure.
Le développement de techniques d'ordonnancement des ux circulant sur les chemins tirant pleinement parti des informations obtenues grâce à nos méthodes de
tomographie multiples sources/multiples destinations.
Ces 4 axes sont développés ci-après.
170
Conclusion
9.2.1 Modélisation
Plusieurs pistes peuvent être explorées lors de travaux futurs sur la modélisation des
interactions. Notons par exemple :
Mieux prendre en compte la variation de la néguentropie en faisant remonter cette
information à l'utilisateur. En eet, une néguentropie forte pour un ensemble de
chemins reètera une dépendance forte des performances des ces ux. A priori, cela
signie que les performances de ces ux ont des liens forts. A contrario, une néguentropie faible peut être dûe au fait que les ux partagent une ressource limitée sur un
segment court. Par exemple, nos expériences ont montré, conformément à la théorie,
que le partage d'un hub 100 Mb/s entre deux ux dont les sources et les destinations
sont proches peut entraîner une perte de capacité, soit, mais que la bande passante
cumulée de ces 2 ux dépasse la capacité nominale de cette ressource. Ceci est dû
au fait qu'un hub 100 Mb/s est déni comme un hub fournissant une capacité de
100Mb/s entre deux chemins de 100m. La présence d'un chemin plus court permet de
faire baisser la probabilité d'une transmission simultanée de deux paquets, et donc
celle d'une perte. Cela signie que la façon même de présenter la métrique comme
une bande passante nécessite une reexion plus poussée.
Donner une vision multi-métrique d'un réseau. Dans notre cas précis, par exemple,
le calcul d'un éventuel partage de bande passante entre ux dépendra non seulement
de la bande passante disponible mais aussi du RTT de chacun des ux. Si l'utilisation d'une simple liste de valeurs des RTT des diérents chemins est possible, il
conviendrait de pouvoir modéliser de manière unique ces deux paramètres en un seul
MINP.
9.2.2 Algorithmique de reconstruction
L'algorithmique de reconstruction est peut être l'axe prioritaire qui devrait guider de
futurs travaux, car la mise en place d'algorithmes hybrides permettrait une popularisation
de ces techniques, de par la réduction du coût qu'ils impliquent. Les diérents point devant
être abordés dans le futur sont donc :
Mettre en place les algorithmes basés sur une connaissance partielle ou totale du
réseau.
Développer des algorithmes plus ns dans le cadre de connnaissances partielles de
celui-ci.
Développer des techniques de mise à jour du MINP basées sur des techniques passives.
171
Conclusion
9.2.3 Techniques de mesures
Les techniques de mesures développés donnent déjà des résultats satisfaisants, et sont
peut être l'axe le moins prioritaire. Néanmoins, divers points restent à envisager :
Il serait intéressant de dénir exactement la sensibilité au choix des paramètres de
la principale technique de mesures développée.
Il serait intéressant d'observer la portabilité de la technique de mesures à d'autres
types de réseaux.
Développer des techniques passives de mesures.
L'outil comporte un système de stockage des MINP déjà déduits pour éviter de
procéder plusieurs fois aux mêmes mesures. Mais il serait utile qu'il soit capable
d'agréger ou au contraire de scinder un MINP en sous-parties pour répondre aux
requêtes d'un utilisateur. De plus, il devrait être en mesure de dénir la durée de vie
des MINP déduits (le temps pendant lequel ils sont valides), pour éventuellement,
à la manière d'un NWS, mener des tests réguliers sur les portions du réseau pour
lesquelles les connaissances stockées ne peuvent plus être considérées comme valides.
L'outil pourrait aussi inclure des fonctionnalités de prédiction des performances.
9.2.4 Optimisation
L'optimisation est l'étape nale permettant l'exploitation des résultats de tomographie.
Si les MINP résultants peuvent permettre de poser l'ordonnancement des ux suivant une
formalisation proche du problème de k-Bi-Partite Scheduling (k-bps, [117]) par exemple,
les informations contenues dans une modélisation MINP des interactions sont plus riches
que celles contenues dans cette modélisation. Il convient donc de formaliser le problème
d'optimisation du temps total de transfert des données de manière spécique au MINP.
On doit donc considérer les points suivants :
Concevoir et mettre en oeuvre des algorithmes permettant de tirer pleinement prot
des informations tirées des représentations du réseau obtenues.
Prendre en compte des facteurs de pondération externes à la problématique réseau.
172
Quatrième partie
ANNEXES
XSD
<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" jaxb:version="1.0">
<xsd:element name="deployment_description" type="deployment_description_Type"/>
<xsd:complexType name="deployment_description_Type">
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="unbounded" name="flow" type="flow_Type"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="flow_Type">
<xsd:attributeGroup ref="flow_Type_Attr"/>
</xsd:complexType>
<xsd:attributeGroup name="flow_Type_Attr">
<xsd:attribute name="source" type="xsd:string" use="required"/>
<xsd:attribute name="destination" type="xsd:string" use="required"/>
<xsd:attribute name="sourceport" type="xsd:decimal" use="optional"/>
<xsd:attribute name="destport" type="xsd:decimal" use="optional"/>
<xsd:attribute name="bandwidth" type="xsd:decimal" use="optional"/>
<xsd:attribute name="send_data_rate" type="xsd:decimal" use="optional"/>
</xsd:attributeGroup>
</xsd:schema>
Exemple
<deployment_description>
<flow source="localhost" destination="85.69.184.134"/>
<flow source="localhost" destination="134.158.16.130"/>
<flow source="139.124.51.2" destination="139.124.51.3"/>
174
</deployment_description>
175
DTD
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="Net_Lattices" type="Net_Lattices_Type"/>
<xsd:complexType name="Net_Lattices_Type">
<xsd:sequence>
<xsd:element minOccurs="1" maxOccurs="unbounded" name="Net_Lattice"
type="Net_Lattice_Type"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Net_Lattice_Type">
<xsd:sequence>
<xsd:element minOccurs="1" maxOccurs="1" name="PrimalFlows"
type="primalFlows_Type" />
<xsd:element minOccurs="0" maxOccurs="1" name="subpaths" type="subpaths_Type" />
</xsd:sequence>
<xsd:attributeGroup ref="net_lattice_Attr"/>
</xsd:complexType>
<xsd:complexType name="primalFlows_Type">
<xsd:sequence>
<xsd:element minOccurs="1" maxOccurs="unbounded" name="PrimalFlow"
type="PrimalFlow_Type" />
</xsd:sequence>
<xsd:attributeGroup ref="primalFlows_Attr"/>
</xsd:complexType>
<xsd:complexType name="PrimalFlow_Type">
<xsd:attributeGroup ref="PrimalFlow_Attr"/>
176
<xsd:attributeGroup ref="primalFlowSup_Attr"/>
</xsd:complexType>
<xsd:complexType name="subpaths_Type">
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="unbounded" name="subpath"
type="subpath_Type" />
</xsd:sequence>
<xsd:attributeGroup ref="subpaths_Attr"/>
</xsd:complexType>
<xsd:complexType name="subpath_Type">
<xsd:sequence>
<xsd:element minOccurs="1" maxOccurs="1" name="isASubpathOf"
type="path_Ref_List_Type" />
<xsd:element minOccurs="1" maxOccurs="1" name="containedSubpaths"
type="path_Ref_List_Type" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="path_Ref_List_Type">
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="unbounded" name="path_ref"
type="path_ref_Type" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="path_ref_Type">
</xsd:complexType>

<xsd:attributeGroup name="subpaths_Attr">

<xsd:attributeGroup name="PrimalFlow_Attr">
177
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="capacity" type="xsd:string" use="required"/>
<xsd:attributeGroup name="primalFlowSup_Attr">
<xsd:attribute name="source" type="xsd:string" use="required"/>
<xsd:attribute name="destination" type="xsd:string" use="required"/>
<xsd:attributeGroup name="primalFlows_Attr">

<xsd:attributeGroup name="net_lattice_Attr">
<xsd:attribute name="name"
type="xsd:string" use="required"/>
</xsd:schema>
Exemple
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Net_Lattices>
<Net_Lattice>
<PrimalFlows>
<PrimalFlow source="139.124.70.168" destination="139.124.51.2"
name="139.124.70.168-to-139.124.51.2" capacity="8.03184"/>
name="139.124.70.167-to-139.124.51.3" capacity="8.40523"/>
name="139.124.70.168-to-134.158.16.132" capacity="95.6247"/>
name="139.124.70.167-to-134.158.16.130" capacity="95.6322"/>
name="134.158.16.132-to-134.158.16.130" capacity="95.6377"/>
name="139.124.51.2-to-139.124.51.3" capacity="95.6419"/>
178
</PrimalFlows>
<subpaths>
<subpath name="|139.124.70.168-to-139.124.51.2|
139.124.70.167-to-139.124.51.3" capacity="8.03184">
<isASubpathOf>
<path_ref name="139.124.70.168-to-139.124.51.2"
capacity="8.0318400000000007565859050373546779155731201171875"/>
<path_ref name="139.124.70.167-to-139.124.51.3"
capacity="8.405229999999999535020833718590438365936279296875"/>
</isASubpathOf>
<containedSubpaths>
<path_ref name="|139.124.70.168-to-139.124.51.2|
134.158.16.132-to-134.158.16.130|139.124.70.167-to-134.158.16.130|
139.124.70.167-to-139.124.51.3|139.124.70.168-to-134.158.16.132"
capacity="95.6247"/>
</containedSubpaths>
</subpath>
<subpath name="|139.124.70.168-to-139.124.51.2|
134.158.16.132-to-134.158.16.130|139.124.70.167-to-134.158.16.130|
139.124.70.167-to-139.124.51.3|139.124.70.168-to-134.158.16.132"
capacity="95.6247">
<isASubpathOf>
<path_ref name="|139.124.70.168-to-139.124.51.2|
139.124.70.167-to-139.124.51.3" capacity="8.03184"/>
<path_ref name="134.158.16.132-to-134.158.16.130"
capacity="95.637699999999995270627550780773162841796875"/>
<path_ref name="139.124.70.167-to-134.158.16.130"
capacity="95.6321999999999974306774674914777278900146484375"/>
<path_ref name="139.124.70.168-to-134.158.16.132"
capacity="95.6247000000000042518877307884395122528076171875"/>
</isASubpathOf>
<containedSubpaths/>
</subpath>
</subpaths>
</Net_Lattice>
</Net_Lattices>
179
Liste des options d'udpmon modifié
Liste des options d'upmon_bw_mon
-A
-B
-G
-H
-M
-P
-Q
-S
-T
-V
-d
-e
-g
-i
-l
-n
-p
-t
-q
-v
-u
-w
-x
-m
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
<number of packets to receive for remote end to send ACK>
<bin width of remote histo in us>
<number of packets on which to return information>
get remote histograms
<min (low limit) of remote histo in us>
<precidence bits set - in hex - will be shifted left by 9>
<DSCP QoS bits set - in hex >
<size of send and receive socket buffers in bytes>
<tos bits set - in hex - will be shifted left by 1>
print version number
<the destination IP name or IP address a.b.c.d>
<end value of wait time in us>
<gap time to wait between bursts in us>
<increment for wait time in us>
<no. of frames to send>
<no. of bursts to send in Burst Mode>
<length in bytes of mock data packet>
<no. of seconds to run the test - calculates no. of frames to send >
quiet - only print results
turn on debug printout
<raw/udp port no - default 0x3799 ie 14233 decimal>
<wait time in us>
print more info (CPUStats)
Mint Car mode : Will send back arrival time for each packet and save
the result in the given file.
-b = Mint Car mode : maximum 'amplitude' of the signal
-s = Mint Car mode : period of the signal
-f = Mint Car mode : function type (0 : sinus, 1 : square wave, 2 :
saw tooth , 3 : triangle wave
-z = Mint Car mode : if setted, will send packets reflecting function as
a long burst.
180
Liste des options d'udpmon modié
-h = Mint Car mode : heart rate. Only look for the inner 1000's values and
consider the inter burst delay.
Liste des options d'udpmon_resp
-M = Mint Car mode.
181
Glossaire
arc inverse On appelle arc inverse d'un arc lij l'arc lji . 32
arcs propres On appelle arcs propres à un chemin p vis-à-vis d'un ensemble de souschemins P 0 de p les arcs appartenants à p qui n'appartiennent à aucun des éléments
de P 0 . 32
backbone Partie du réseau qui supporte le gros du trac, en utilisant les technologies les
plus rapides et une grande bande passante sur des distances importantes. 3, 41
borne induite par un lien unique Une métrique m possède une borne induite un lien
unique si la capacité de tout chemin est identique à celle d'un unique lien logique de
capacité la plus petite/la plus grande. 51, 52, 96100, 115
bornée Une métrique
m est bornée si la capacité de tout chemin est identique à celle
de son/ses sous-chemin(s) de capacité la plus petite/la plus grande selon la relation
associée à la métrique. 51, 52, 80, 85, 88, 92, 96, 105, 107109
bottleneck Lien limitant la capacité vis à vis d'une métrique des ux circulant sur un
chemin contenant ledit lien. 51, 52
bout en bout Des mesures de bout en bout sont des mesures ne faisant pas appel aux
équipements réseau le long du chemin reliant la source et la destination de la mesure.
5, 7, 19, 29, 32, 34, 41, 54, 57, 58, 69, 134, 144, 170
burst Voir train de paquets. 22, 129131, 133, 134, 140147, 158160, 166
capacité La capacité d'un chemin p suivant la métrique m est notée cpm . 4, 5, 8, 11, 12, 19,
26, 27, 29, 3234, 36, 39, 41, 45, 5054, 6468, 70, 79, 81, 8487, 89, 9199, 101105,
109, 110, 114, 115, 117, 119, 121, 122, 126129, 141143, 161
chemin On note pab le chemin reliant la source a ∈ S et la destination b ∈ R. Celui-ci est
la suite ordonnée pab = (lai , lij , ljk , ..., lqb ) d'arcs lij ∈ E . Chaque arc de cette suite
a pour origine la destination de l'arc le précédant immédiatement (si celui-ci existe).
. 5, 6, 28, 3043, 46, 5058, 6189, 92127, 129131, 133, 135, 140148, 150152,
155157, 159161, 164, 167, 168, 170, 171
chemin inverse On appelle chemin inverse d'un chemin pij = (l1 , ..., ln ) le chemin pji =
(l10 , ..., ln0 ) tel que tout lk0 est l'inverse de l'arc ln−k pour 0 ≤ k ≤ n − 1. 32, 56
consistance Voir consistant. 31, 32, 55, 56, 60, 63, 74, 82, 84, 85, 104
182
Glossaire
consistant Si le routage est consistant, il ne crée pas de chemins qui se rejoignent, se
séparent et se rejoignent encore. 31, 36, 61, 63, 81, 141
constance Une métrique m sera constante par rapport aux mesures si la capacité cpm dé-
duite des mesures est indépendante des chemins utilisés par les tests pour la détecter .
50, 85
constant Voir constance. 20, 33, 53, 64, 68, 69, 129, 132, 137, 138, 159
couvert Voir couverture. 32, 88, 93, 96, 99, 100, 102, 110
couverture Si les chemins de l'ensemble Ps admettent un sous-chemin commun maximum,
les chemins Ps sont couverts par leur sous-chemin commun maximum. On appellera
Ps
l'ensemble Ps la couverture de pmaximum
. 32, 39, 61, 63, 67, 82, 89, 93, 99102, 106,
108112, 128, 157
couverture unique Si un supremum existe pour un ensemble de chemins P 0 , il est unique.
85, 86, 88, 89, 102, 108, 109, 111, 115
cross-trac Trac interférant, dû à d'autres utilisateurs et applications utilisant un réseau partagé. 52
dos à dos Pour une paire de paquets, signie que le délai entre l'emission du dernier bit
du premier message et le premier bit du second message peut être considéré comme
nul. 4244, 117, 118, 120123, 129, 146, 159
détectable La capacité d'un chemin est détectable si il existe un ensemble de chemins
contenant ce chemin qui permet d'exhiber cette capacité par l'injection de tests . 33,
36, 5456, 60, 61, 6466, 6872, 76, 79, 83, 8587, 90, 92, 94100, 102, 104112, 115,
117, 125, 128130, 133, 138, 140, 141, 144, 146148
ux Un ux de données désigne les paquets circulant sur un élément de P suite à un test.
3, 5, 18, 2027, 3033, 37, 3942, 44, 45, 5055, 6668, 70, 72, 7679, 83, 85, 92, 95,
97, 99101, 103, 125128, 130, 132, 133, 140142, 144, 147, 151, 160, 161, 164, 168,
170172
graphe d'interférence Graphe de taille minimale présentant les mêmes interférences que
le graphe réseau réel. 73, 83
grid service Extension des Web Services permettant la gestion d'instances de services,
création et destruction dynamique. 2
high bandwidth-delay Désigne des liens réseau dont le produit de la bande passante et
du délai est important. 11, 21, 24
hybride Algorithme utilisant plusieurs sources d'informations diérentes sur le réseau. 39,
59, 112, 116, 171
183
Glossaire
indétectable Un chemin est indétectable si il n'est pas détectable. 33, 53, 56, 65, 67, 87,
109, 110, 115
inmum Borne inférieure d'un treillis, i.e. noeud couvert par tous les autres noeuds du
treillis. 66, 67, 69, 72, 109, 157, 161
INV-RTT-BOUNDED Modèle de partage de bande passante entre ux. Dans ce modèle, si P est un ensemble de chemins traversé par des ux en régime permanent, et
si pPmaximum est un sous-chemin commun étroit pour lesdits ux, alors la règle suivant
pP
T (pi )
doit être respectée ∀pi ∈ P,bw(fpPi ) = P|P1/RT
×cbwmaximum . 125, 127, 164
|
j=0
1/RT T (pj )
jitter La gigue (jitter) est la mesure de la variation du délai de transmission des paquets
d'une source à une destination donnée. 130, 132, 142
k-détectabilité Voir k-détectable. 54, 70, 76
k-détectable La capacité d'un chemin est k-détectable si il existe un ensemble de chemins
de cardinalité inférieure ou égale à k contenant ce chemin qui permet d'exhiber cette
capacité par l'injection de tests . 70, 76, 87
k-mesure Une k-mesure est une mesure qui s'eectue sur un ensemble de chemins de
cardinalité k, c'est-à-dire en injectant des ux sur ces k chemins. 76, 86, 87
k-test Un k-test permet d'établir une relation k-détectable. . 76, 110
lien étroit Lien limitant la capacité vis à vis d'une métrique des ux circulant sur des
chemins contenant ledit lien. Peut être considéré comme un goulot d'étranglement
possiblement commun à pusieurs ux. 67, 68
mesure Le terme de mesures désigne l'expérience consistant à injecter des ux dans le
réseau dans le but de déterminer certaines de ses propriétés. 5, 7, 15, 22, 2831, 33
46, 54, 55, 57, 58, 61, 63, 64, 68, 69, 7478, 80, 81, 83, 84, 86, 8992, 9496, 98105,
107, 108, 110133, 136, 138, 140142, 146148, 150152, 154, 156166, 168170, 172
middleware Intergiciel. 2
MINP inter-site MINP ne représentant que les interactions entre les chemins reliant des
sites distants sans prendre en compte les éléments de Pe2e susceptibles d'interagir à
l'interieur d'un site. 114
MINP intra-site MINP ne représentant que les interactions entre les chemins et souschemins contenus dans un site donné. 114
MINP partiel MINP ne représentant que les interactions entre un sous ensemble de
chemins de Pe2e généralement tiré de mesures actives. 72, 86, 87, 8992, 111113,
127, 128, 132, 133, 148, 154, 157, 162, 165, 168
184
Glossaire
monotonicité Une métrique est monotone si tout sous-chemin d'un chemin est de capacité
inférieure ou égale (selon la relation associée à la métrique) à la capacité du chemin
complet. 5, 63, 79, 81, 117
monotonicité étendue Considérons l'ensemble
Ps∗ d'ensembles de chemins Ps où chas
cun des Ps admet un sous-chemin commun maximum non nul pPmaximum
. Soit ≤ la
relation d'ordre associée à la métrique m. On peut dénir la motonicité comme m
0
est monotone étendue ⇐⇒ ∀Ps ∈ Ps∗ , ∀Ps tel que Ps ⊆ Ps , alors m(f PPs0
0
m(f PPss
pmaximum
0
). 50, 51, 84, 87
)≤
s
pmaximum
métrique Mesure d'une propriété du réseau souvent notée m. La métrique peut être la
bande passante atteignable en régime permanent par des ux TCP, le délai, etc . 5,
3234, 36, 38, 40, 41, 45, 46, 4954, 60, 61, 6367, 69, 70, 7274, 7680, 82, 84, 85,
8789, 92, 93, 96, 97, 99102, 104, 105, 107, 109, 115, 119, 122124, 171
métrique bornée Une métrique m est bornée si la capacité de tout chemin est identique
à celle de son/ses sous-chemin(s) de capacité la plus petite/la plus grande selon la
relation associée à la métrique. 51, 52, 92, 93, 100, 102
o-line Algorithme dont le déroulement ne dépend pas de l'acquisition du jeu de données.
90, 152, 156, 162
on-line Algorithme dont l'exécution dépend des données déjà acquises. 91, 95, 99, 101,
107
paramètre de sensibilité On appelle paramètre de sensibilité s la valeur minimale qui
peut être déduite des résultats de tests . 33, 36, 38, 60, 61, 64, 79, 86, 89, 105
point de conjonction Point où se rejoignent un ensemble de chemins. 32
point de disjonction Point où se séparent un ensemble de chemins. 32, 79, 81, 118, 120,
123
preuve Synonyme de mesure. 69, 118, 119, 127
propriété de regroupement Soit deux ensembles de chemins P
= Pnoyau ∪{pa }∪Ppivot ,
P = Pnoyau ∪ {pb } ∪ Ppivot , |Pnoyau | ≥ 0. Supposons que P et P 0 et Ppivot possèdent
tous trois un sous-chemin commun. Si {pa , pb } ∪ Ppivot possède un sous-chemin commun, alors P 00 = Pnoyau ∪{pa }∪{pb }∪Ppivot possède un sous-chemin commun unique.
0
85, 86
propriété de regroupement pour les métriques bornées Si la métrique considérée
est bornée, alors on peut pré-ordonner les diérentes intersections de chemin issues
de la propriété de regroupement si celles-ci sont au plus 3-détectables (i.e. 1 ou 2détectables). De plus, 2 sous-chemins communs sur les 3 peuvent être confondus car
ils ont la même capacité, celle du sous-chemin commun à l'ensemble des ux. 85
185
Glossaire
relation d'ordre associée Relation d'ordre associée à une métrique m. 33
sous-chemin Un sous-chemin de
pab est une sous-suite de la suite pab qui respecte luimême la dénition d'un chemin pour une source a0 ∈ S ∪ V et une destination
b0 ∈ V ∪ R. 4, 3234, 5053, 56, 6371, 7580, 83, 8590, 9295, 97, 98, 100112, 114,
117, 120, 121, 123, 124, 126, 128, 129, 134, 141, 143, 146148, 157, 160
sous-chemin commun On appelle sous-chemin commun à un ensemble de chemins Ps
un chemin contenu dans chacun des éléments de Ps . . 32, 33, 36, 38, 40, 51, 62, 66,
67, 71, 72, 76, 78, 79, 8387, 89, 90, 92104, 106108, 110, 111, 114, 115, 117119,
121123, 125, 127131, 135, 138, 140145, 147
sous-chemin commun maximum On appelera sous-chemin commun maximum d'un
ensemble de chemins Ps le sous-chemin commun le plus long de l'ensemble des souschemins communs de Ps . 32, 39, 50, 53, 64, 85, 87, 104, 120
stabilité Voir stable. 27, 55, 60, 63, 72, 74, 82, 84
stable Par stable, nous considérons que les chemins ne changent pas durant la totalité du
processus de mesures. 8, 11, 31, 55, 61, 69, 70, 72
supremum Borne supérieure d'un treillis, i.e. noeud couvrant tous les autres noeuds du
treillis. 66, 72, 84, 87, 88, 92, 108, 157, 161
symétrie La symétrie peut se rapporter soit au routage, soit à la métrique, voir dénition
correspondante. 60, 63, 73, 74, 82, 117
symétrie (métrique) Une métrique est symétrique si la capacité d'un chemin vis-à-vis
de la métrique considérée est constante suivant le sens de parcours de ce lien par les
ux injectés pour le détecter. 53
symétrie (routage) Le routage est symétrique si le chemin allant de n'importe quel hôte
a vers un hôte b est le chemin
inverse de celui allant de b vers a. 56
séparabilité Une métrique m est séparable si pour tout chemin p composé de l'union de
m m
deux sous-chemins disjoints pi et pj , cm
pj = g(cp , cpi ) pour une certaine fonction g on
m m
a : m est séparable ⇐⇒ ∀p = pi ∪ pj , cm
pj = g(cp , cpi ) pour une fonction g . 5, 53,
63, 79, 117
séparabilité étendue Considérons l'ensemble
Ps∗ d'ensembles de chemins Ps où chaPs
cun des Ps admet un sous-chemin commun maximum non nul pmaximum
. Soit les
0
00
0
00
couples d'ensembles Ps , Ps ⊂ Ps tels que Ps ∪ Ps = Ps , et leurs sous-chemins
0
00
s
s
et pPmaximum
. Une métrique m est séparable si il
communs maximums pPmaximum
existe une fonction g telle que m est séparable étendue ⇐⇒ m(fpPPss
) =
00
0
g(m(f
Ps
P
0
s
pmaximum
), m(f
Ps
P
00
s
pmaximum
maximum
))∀Ps , Ps ⊂ Ps tel que Ps ∪ Ps = Ps . 53, 84
0
00
0
00
186
Glossaire
technique de mesure Procédé permettant d'eectuer une mesure. 34, 61, 83, 108, 120,
122124, 129, 133, 146, 158, 164, 165, 172
test Action atomique d'une mesure consistant à établir un ux entre une source et une
destination. 3135, 39, 44, 52, 57, 64, 68, 72, 7577, 8084, 90, 92, 9597, 99, 100, 103,
104, 106, 108, 111, 118, 119, 121126, 130134, 136, 138, 140147, 150154, 160162,
166, 167, 169, 170, 172, 186
tier Centre de stockage de données situé physiquement dans les locaux d'une institution
ou d'un laboratoire membre du projet. 3, 4, 18, 151, 161
topologie Représentation de l'organisation et des caractéristiques du réseau. 26, 8, 11,
14, 19, 20, 2731, 3336, 3842, 45, 46, 49, 50, 5658, 6064, 67, 68, 72, 73, 7581,
83, 84, 86, 89, 94, 95, 98, 99, 102104, 108, 109, 111, 113115, 121, 127, 128, 153
topologie logique La topologie logique G00 (V 00 ∪S ∪R, E 00 ) correspondant à une topologie
physique est un graphe formé à partir de G0 (i.e. la topologie physique). Dans un
premier temps, chaque noeud i de V 0 est remplacé par une paire de noeuds (iin , iout )
reliée par un arc allant de iin à iout ; les arcs entrants de i sont reliés à iin et ses arcs
sortants à iout . Cette première phase permet de faire apparaître un arc pour chacun
des routeurs, switches, etc. déployés. Puis chacun des noeuds internes avec seulement
un parent et un enfant est confondu avec son père. 5, 57, 60, 64, 72, 73, 89
topologie physique La topologie physique interconnectant un ensemble de sources S à
un ensemble de destinations R est un sous-ensemble de G, G0 (V 0 ∪ S ∪ R, E 0 ) tel que
e ∈ E 0 ⇐⇒ ∃p ∈ P tel que e ∈ p et a ∈ V 0 ⇐⇒ ∃p ∈ P tel que lai ∈ p ou lia ∈ p, i
étant un sommet appartenant à V ∪ S ∪ R. 5, 18, 29, 57, 60, 63, 66, 108
traceroute Traceroute est un outil réseau qui permet de suivre le chemin qu'un paquet
de données (paquet IP) va prendre pour aller d'une machine A à une machine B. 5,
58, 77, 108, 109, 112, 126
trac interférant Voir cross-trac. 52, 131, 167
train de paquet Ensemble de paquets envoyé dos à dos, aussi appelés bursts. 44, 120,
121, 129, 159
web service Service éxecutable à distance dont les spécications reposent sur SOAP et
WSDL. 2, 14, 18, 150, 153157, 161
187
Acronymes
∞-MINP Système partiellement ordonné induit par une métrique contenant tous les souschemins communs maximum. Un ∞-MINP (∞ - Metric Induced Network Poset)
est un système partiellement ordonné M m = (N, ) formé à partir de l'ensemble
M axPe2e . N est déni par la relation ∀i ∈ M axPe2e ⇐⇒ i ∈ N , ≺ est déni par la
relation ∀i, j ∈ N, i ⊂ j ⇐⇒ j ≺ i, les éléments de p ∈ N ne sont pas étiquetés. L'∞-
MINP peut être considéré comme le MINP représentant les sous-chemins communs
de l'ensemble des sous-ensembles de Pe2e , que ces sous-chemins soient détectables ou
non. 7173
ACK ACKnoldegment. 21, 22, 24, 25
ADSL Asymetric Digital Subscriber Line. 54
AIMD Additive Increase Multiplicative Decrease. 21, 23, 24
AQM Active Queue Management. 26
ASP Application Service Provider. 10
BSS Blind Source Separation. 134
BTC Bulk Transfer Capacity. 42, 44
CPU CoProcessing Unit. 2, 1214, 16, 22, 24
DBT Deterministic Binary Tree. 79, 81, 82, 86
ECN Early Congestion Notication. 26
EGEE Enabling Grid for E-sciencE. 35, 7, 1316, 27
FTS File Transfer Service. 18, 20, 34
gLite Lightweight Middleware for Grid Computing. 16, 18
HTTP Hyper Text Transfer Protocol. 22
ICA Independent Component Analysis. 134
ICMP Internet Control Message Protocol. 35, 77
188
Acronymes
k-MINP Système partiellement ordonné induit par une métrique contenant des chemins
au plus k-détectables. Un k-MINP (k - Metric Induced Network Poset) est un système
partiellement ordonné M m = (N, ) formé à partir de l'ensemble M axPe2e . N est
déni par la relation ∀i ∈ M axPe2e , i k-détectable pour la métrique m ⇐⇒ i ∈ N ,
≺ est déni par la relation ∀i, j ∈ N, i ⊂ j ⇐⇒ j ≺ i, chaque élément de p ∈ N
est étiqueté par sa capacité cpm . Le MINP peut être considéré comme un k-MINP où
k = |Pe2e |. 7072, 89, 91, 92, 100
LHC Large Hadron Collider. 3, 13
MINP Système partiellement ordonné induit par une métrique. Un MINP (Metric Induced
Network Poset ) est un système partiellement ordonné M m = (N, ) formé à partir
de l'ensemble M axPe2e . N est déni par la relation ∀i ∈ M axPe2e , i détectable pour
la métrique m ⇐⇒ i ∈ N , ≺ est déni par la relation ∀i, j ∈ N, i ⊂ j ⇐⇒ j ≺ i,
chaque élément de p ∈ N est étiqueté par sa capacité cpm . 49, 64, 6674, 76, 78, 84,
8693, 96, 100, 102, 105, 107115, 150, 151, 153, 154, 156, 157, 161, 162, 168, 169,
171, 172
MINT Topologie induite par une métrique. 50, 53, 6064, 66, 7274
MINTCAR Metric Induced Network Topology - Construction Analysis and Retrieval.
150
MSMD Multiples sources, multiples destinations. 74
MSMDMINT Topologie induite par une métrique pour de multiples sources et de multiples destinations. 64, 66, 73, 74
MSS Maximum Size Segment. 22
MTU Maximum Transfer Unit. 21, 22, 143, 159
RED Random Early Detection. 26, 125
RTT Intervalle de temps entre l'émission d'un paquet depuis la source et la réception par
la source de l'accusé réception provenant de la destination. 20, 21, 23, 24, 39, 50, 53,
54, 77, 114, 171
SNMP Simple network management protocol. 35
SOAP Simple Object Access Protocol. 2
TCP Transmission Control Protocol. 5, 8, 1927, 33, 3942, 44, 50, 51, 53, 54, 6668, 77,
125, 126, 130, 132134, 156, 163, 164
UDP User Datagram Protocol. 20, 45, 129, 130, 133, 134, 140142, 144, 146, 147, 156,
163, 166
189
Acronymes
VO Virtual Organization. 15, 16
WSRF Web Service Resource Framework. 14, 28
XML eXtensible Markup Language. 2, 7, 153, 154, 157
190
Notations
A Matrice de routage.
B matrice orthogonale de vecteurs propres de E{xxT }.
C Facteur C de l'équation de Mathis.
Cji Coecient binomial des entiers naturels n et k.
D Matrice diagonale contenant les valeurs propres D = diag(d1 , ..., dn ) d'une matrice
donnée.
Do Ensemble des noeuds destinations de chemins ayant pour origine un noeud so .
E Ensemble des liens physiques reliant les noeuds du réseau (E ⊂ V ∪ S × V ∪ R).
E{x} Espérance pour une variable aléatoire x.
G Réseau vu comme un graphe orienté G = (V ∪ S ∪ R, E) où les sommets V sont les
équipements réseau déployés tels que les routeurs, les hub, etc, S l'ensemble des
hôtes sources, R l'ensemble des hôtes destinations, et E les liens physiques les reliant
(E ⊂ V ∪ S × V ∪ R). On notera lij un arc allant d'un noeud i à un noeud j . Un
hôte étant à la fois source et destination sera considéré comme deux hôtes diérents,
l'un source et l'autre destination.
G0 Graphe orienté représentant la topologie physique interconnectant un ensemble de
sources S à un ensemble de destinations R. Sous-ensemble de G, G0 (V 0 ∪ S ∪ R, E 0 )
tel que e ∈ E 0 ⇐⇒ ∃p ∈ P tel que e ∈ p et a ∈ V 0 ⇐⇒ ∃p ∈ P tel que lai ∈ p ou
lia ∈ p, i étant un sommet appartenant à V ∪ S ∪ R.
G00 Topologie logique G00 (V 00 ∪ S ∪ R, E 00 ) correspondant à une topologie physique. Graphe
formé à partir de G0 .
G1 (u) Fonction de contraste classique. Elle permet d'accentuer l'écart entre des variables
"totalement aléatoires" et d'autres. Dénie par G1 (u) = a11 log cosh(a1 u).
G2 (u) Fonction de contraste classique. Elle permet d'accentuer l'écart entre des variables
2
"totalement aléatoires" et d'autres. Dénie par G2 (u) = − exp(− u2 ).
P
H(Y ) Entropie d'une variable aléatoire Y dénie par H(Y ) = − i P (yi ) log P (yi ).
I(Pprobe ) Identication de sous-chemin communs dénie par I(Pprobe ) = (z = 0).
I(y1 , y2 , ..., ym ) Information mutuelle I entre plusieurs variables aléatoires yi ∈ y, i =
P
1 . . . m dénie par I(y1 , y2 , ..., ym ) = m
i=1 H(yi ) − H(y).
191
Notations
Interf (S, R)(pi , pj ) Matrice d'interférence.
J(y) Néguentropie J(y) = H(ygauss ) − H(y).
M m MINP pour la métrique m. Un MINP (Metric Induced Network Poset ) est un système
partiellement ordonné M m = (N, ) formé à partir de l'ensemble M axPe2e . N est
déni par la relation ∀i ∈ M axPe2e , i détectable pour la métrique m ⇐⇒ i ∈ N , ≺
est déni par la relation ∀i, j ∈ N, i ⊂ j ⇐⇒ j ≺ i, chaque élément de p ∈ N est
étiqueté par sa capacité cpm .
M axP Ensemble des sous-chemins communs maximum non nuls admis par au moins un
des sous-ensembles de cardinalité supérieure ou égale à 1 de l'ensemble de chemins
P.
N Elément du MINP pour une métrique m, i.e. M m = (N, ).
P Un ensemble de (sous-)chemins quelconque.
P 0 Dans une partition d'un ensemble P, représente une des parties.
P 00 Dans une partition d'un ensemble P, représente l'autre partie.
source Sous-ensemble de P
Pe2e
e2e dont chacun des éléments à la même racine (source).
Pall L'union de l'ensemble des chemins dénis par la fonction de routage et de l'ensemble
sans répétition de leurs sous-chemins.
Pe2e Ensemble des chemins de bout en bout dénis par la fonction de routage.
Pprobe Usuellement utilisé comme étant l'ensemble des chemins impliqué dans une mesure.
P owerSet(E) Power Set de l'ensemble E .
P rob(A) Probabilité d'un évènement A.
Q Taille d'un jeu de données pour le BTC.
R Ensemble des hôtes destinations.
RT T (pi ) RTT pour un chemin pi .
S Ensemble des hôtes sources.
Sd Site destination.
Ss Site source.
Sheader Taille du header TCP.
Supr(m) Supremum des éléments d'un MINP m.
T (Pi ) Ensemble contenant les résultats de tests injectés simultanément sur chacun des
chemins de Pi ..
Tpi Période pour un test périodique sur un chemin pi .
Ut Unité de temps.
192
Notations
V Ensemble des noeuds internes du réseau, i.e. les équipements réseau déployés tels que
les routeurs, les hub, etc.
W indT CP,t Taille de la fenêtre de congestion d'un ux TCP à un instant t (exprimée en
M SS ).
W indi,t Taille de la fenêtre de congestion (exprimée en M SS ) agrégée des n sockets d'une
transmission parallèle à un instant t.
W indi,t Taille de la fenêtre de congestion d'un ux TCP appartenant à une transmission
parallèle à un instant t (exprimée en M SS ).
X Matrice contenant un ensemble d'éléments Xj = gj (θj ) où gj est une fonction de densité
de probabilité de paramètre θj .
Xt Vecteur de paramètres dépendants du temps inuant sur les mesures, tels que les taux
de pertes, les délais induits par les liens, etc.
Xij Variable aléatoire dénie par les valeurs des mesures disjT ({ps0 i , ps0 j }), c'est-à-dire
{disjt0 ({ps0 i , ps0 j }), . . . , disjt |T |({ps0 i , ps0 j })}.
Y Matrice composée des diérentes mesures (i.e. des vecteur Yt de dimension J ) au cours
du temps.
Yt Vecteur de mesure de la fonction disj(Pprobe ) à un instant t.
Z Ensemble de sous-problèmes Z en prenant chaque paire de lignes de la matrice de
routage A : Z = {s = (i1 , i2 ) : 1 ≤ i1 < i2 ≤ I} où I est la dimension de Y .
∆ Intervalle de temps.
Ω Noeud de jointure supérieur (le supremum) élément de N que nous noterons Ω qui est un
chemin détectable de longueur 0 et qui est lié aux autres éléments de N par la relation
∀i ∈ N
Ω ≺ i. Si l'on considère la métrique de la bande passante atteignable en
régime permanent pour un ux TCP, l'étiquette de ce chemin pourrait être cΩ
m = ∞.
(Pprobe ) Relation n-aire (Pprobe ) dénie par (Pprobe ) = (conj(Pprobe ) ≥ s).
(Pprobe ) La relation n-aire (Pprobe ) (disjonction) dénie par (Pprobe ) = (disj(Pprobe ) ≥
s).
αx Ordre d'arrivée sur le noeud x utilisé lors de l'identication de sous-chemins communs.
αy Ordre d'arrivée sur le noeud y utilisé lors de l'identication de sous-chemins communs.
(Petit) intervalle de temps.
Vecteur de bruit.
mes (pi , pj ) Fonction d'interférence basée sur le partage de bande passante de ux de type
TCP en régime permanent traversant le réseau dénie par mes (pi , pj ) =
≤ Désigne généralement la relation associée à une métrique m.
P
m(fpiprobe )
{p }
m(fpi i )
.
193
Notations
G 0 (p, Psub ) Application qui fait correspondre à chaque chemin p ayant un ensemble de
sous-chemins Psub un nouveau chemin p0 . p0 est obtenu en supprimant tous les arcs
n'appartenant à aucun élément de Psub dans p. On supprime ces sous-chemins en
confondant leurs noeuds de départ et de destination respectifs en un seul et même
point. Cela revient à supprimer tous les liens propres à p vis-à-vis de ses sous-chemins
appartenant à Psub .
G(p, psub ) Application qui fait correspondre à chaque chemin p ayant un sous-chemin psub
un nouveau chemin p0 . p0 est obtenu en supprimant psub dans p. On supprime le
sous-chemin en confondant le noeud de départ de psub et son noeud destination en
un seul et même point.
H0 (Pi , Psub ) Application faisant correspondre à tout ensemble Pi de P un ensemble de
chemins constitué de toutes les images des p ∈ Pi par l'application G 0 (p, Psub ).
H(Pi , psub ) Application faisant correspondre à tout sous-ensemble Pi de P un ensemble de
chemins constitué de toutes les images des p ∈ Pi par l'application G(p, psub ).
I(pi ) Application qui fait correspondre à chaque pi ∈ M axPe2e l'ensemble Ps dont les
éléments sont les ensembles de chemins appartenant à Pe2e admettant pi comme
sous-chemin commun maximum.
F Ensemble des arbres possibles ayant pour source s0 et pour feuilles les éléments de R.
Mk Ensemble de k-MINP partiels issus de mesures.
T ∗ Arbre maximisant la pseudo-vraisemblance.
⊥ Interférence totale dénie par a, b ∈ V, a ⊥ b ⇐⇒ ∀(u, v) ∈ R, pau rl pbv .
Relation de couverture entre les noeuds appartenant à N d'un MINP correspondant à
la relation ⊆ entre les (sous-)chemins de Pe2e .
⊆ Désigne l'inclusion ensembliste.
τi Temps de transmission d'un message de taille q transmis sur une liaison physique élémentaire i.
×(Pprobe ) La relation n-aire × (identication de noeuds) dénie par ×(Pprobe ) = id(Pprobe ) >
0.
b Graphe minimal G
b = (Vb ∪ R ∪ S, E)
b ayant la même matrice d'interférence que le réseau
G
cible.
a, b, c Paramètres du fonctionnement AIMD d'une pile TCP dont dépend le facteur C .
cpm Capacité du chemin p pour une métrique m donnée.
P
conj(Pprobe ) Fonction conjonction conj(Pprobe ) = m(fL probe ), L ⊂ E t.q. l ∈ L ↔ l ∈
p
∀p ∈ Pprobe .
194
Notations
couv(x) Couverture du noeud x, fonction retournant l'ensemble des chemins couverts par
x.
d(pa ) Variable aléatoire représentant l'échantillon de n mesures correspondant à la mesure
de l'intervalle de temps entre le premier et le dernier paquet de chaque burst sur pa .
di Un hôte destination.
di Destination i.
do Désigne une destination unique (pour les méthodes de reconstruction par conjonction
de chemins).
P
disj(Pprobe ) Fonction disjonction dénie par disj(Pprobe ) = m(fL probe ), L ⊂ E t.q. l ∈
L ↔ l ∈ p,
∀p ∈ Pprobe .
fpPijs Flux transmis entre les hôtes i et j le long du chemin pij ∈ Ps lors de tests concomitants
sur l'ensemble des chemins appartenant à Ps .
g({x, ..., y}) Fonction permettant d'avoir la propriété de séparabilité étendue.
g(x, y) Fonction permettant d'avoir la propriété de séparabilité.
gj Fonction de densité de probabilité de paramètre θj .
R
h(y) Entropie diérentielle h(y) = − f (y) log f (y)dy .
id(Pprobe ) Fonction identication.
kurt(y) Kurtosis de y .
l Un lien quelconque.
li Un lien quelconque dans un ensemble, quand sa source et sa destination sont sans im-
portance particulière.
lij Un lien identié par sa source i et sa destination j .
loss Taux de perte.
lossi Taux de perte pour un (sous)-chemin i.
m(fpPij ) Mesure de l'eet de l'injection du ux fpPij vis à vis de la métrique m.
mi message i.
negens Néguentropie de l'ensemble T (Pi ), soit la néguentropie obtenue quand les tests sont
eectués simultanément.
negiso Néguentropie de l'ensemble {T ({p1 }), ..., T ({pi }), ..., T ({pn })}, pi ∈ P correspondant à l'injection de tests sur chacun des chemins de Pi séquentiellement (donc, par
dénition, les tests indépendants).
p Un (sous-)chemin quelconque.
p(y1 , y2 ) Fonction de densité de probabilité conjointe (joint
de y1 et y2 .
probability density function)
195
Notations
pPmaximum Sous-chemin commun maximum de l'ensemble P .
pi rl pj La relation d'interférence
réelle dénie par pi rl pj = ((pi )mes (pj ) ∨ (pj )mes (pi )).
pi Un (sous-)chemin quelconque dans un ensemble, quand sa source et sa destination sont
sans importance particulière.
p∞ Inmum p∞ ajouté à un MINP pour obtenir une structure de treillis complet. Cette
borne inférieure peut être dénie comme l'ensemble E contenant tous les liens ré-
seaux.
pij Un (sous-)chemin identié par sa source i et sa destination j .
q Taille d'un message.
s Paramètre de sensibilité, valeur minimale qui peut être déduite des résultats de tests.
s(pi , t) Taille d'un burst circulant à l'étape t sur le chemin pi lors de mesures basées sur
la néguentropie.
s1 Paramètre de sensibilité pour l'utilisation de l'approximation de la néguentropie.
s2 Paramètre de sensibilité pour l'utilisation de l'approximation de la néguentropie.
si Un hôte source i.
so Désigne un hôte origine.
smoy Taille moyenne des bursts injectés lors de mesures basées sur la néguentropie.
ti Instant i.
uli Taux d'utilisation du lien li .
y1 , y2 Variables aléatoires.
z Ordre d'arrivée statistique z = {αx 6= αy } utilisé lors de l'identication de sous-chemins
communs.
196
Bibliographie
[1] Global grid forum. http ://www.ggf.org.
[2] Datatag project, 2004. http ://datatag.web.cern.ch/datatag/.
[3] Apache tomcat, 2007. http ://tomcat.apache.org/.
[4] Arda project, 2007. http ://lcg.web.cern.ch/LCG/activities/arda/arda.html.
[5] Asian pacic grid, 2007. http ://www.apgrid.org/.
[6] bw-meter, 2007. http ://www.cc.gatech.edu/fac/Constantinos.Dovrolis/bw.html.
[7] Colt project, 2007. http ://dsd.lbl.gov/ hoschek/colt/.
[8] Das 3, 2007. http ://www.cs.vu.nl/das3/index.shtml.
[9] Datagrid project, 2007. http ://eu-datagrid.web.cern.ch/eu
[10] Dirac project, 2007. https ://twiki.cern.ch/twiki/bin/view/LHCb/DiracProject.
[11] Egee ii project, 2007. http ://www.eu-egee.org/.
[12] Egee project, 2007. http ://www.eu-egee.org/.
[13] Fts : File transfer service, 2007. https ://twiki.cern.ch/twiki/bin/view/EGEE/FTS.
[14] Garr consortium, 2007. http ://www.garr.it/garr-b-home-engl.shtml.
[15] Geant website, 2007. http ://www.geant.net/.
[16] glite project, 2007. http ://www.glite.org.
[17] Glue working group, 2007. http ://forge.ogf.org/sf/projects/glue-wg.
[18] Grid
resource
allocation
and
management,
http ://www.globus.org/grid_software/computation/gram.php.
2007.
[19] Infngrid, 2007. http ://grid.infn.it/.
[20] Kepler project, 2007. http ://kepler-project.org/.
[21] Large hadron collider, 2007. http ://public.web.cern.ch/public/Content/
Chapters/AboutCERN/CERNFuture/WhatLHC/WhatLHC-fr.html.
[22] Le batch scheduler bqs, 2007. http ://cc.in2p3.fr/rubrique351.html.
[23] Naregi project, 2007. http ://www.naregi.org/index_e.html.
[24] The network simulator - ns-2, 2007. http ://www.isi.edu/nsnam/ns/.
[25] Openpbs, 2007. http ://www.openpbs.org/.
197
Bibliographie
[26] Otcl language, 2007. http ://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl/.
[27] Pathload, 2007. http ://www.cc.gatech.edu/fac/Constantinos.Dovrolis/pathload.html.
[28] Pathrate, 2007. http ://www.cc.gatech.edu/fac/Constantinos.Dovrolis/pathrate.html.
[29] Projet grid 5000, 2007. http ://www.grid5000.fr.
[30] R-gma :relational grid monitoring architecture, 2007. http ://www.r-gma.org/.
[31] Renater, 2007. http ://www.renater.fr/.
[32] Simgrid project, 2007. http ://simgrid.gforge.inria.fr/.
[33] Starplane project, 2007. http ://www.starplane.org/.
[34] Sun grid engine, 2007. http ://gridengine.sunsource.net/.
[35] Supersinet, 2007. http ://www.sinet.ad.jp/.
[36] Surfnet, 2007. http ://www.surfnet.nl/info/en.
[37] Teragrid project, 2007. http ://www.teragrid.org/.
[38] Udpmon home page, 2007. http ://www.hep.man.ac.uk/u/rich/net/.
[39] Vthd, 2007. http ://www.francetelecom.com/sirius/rd/fr/ddm/fr/
technologies/ddm200404/techche1.php.
[40] Web service resource framework, 2007. http ://www.globus.org/wsrf/.
[41] Webmds, 2007. http ://www.globus.org/toolkit/docs/4.0/info/webmds/.
[42] K. Aida, Y. Futakata, and S. Hara. High-performance parallel and distributed computing for the bmi eigenvalue problem. In IPDPS '02 : Proceedings of the 16th International Parallel and Distributed Processing Symposium, page 177. IEEE Computer
Society, 2002.
[43] B. Allcock and al. The globus striped gridftp framework and server, 2005.
[44] M. Allman, S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann,
J. Touch, H. Kruse, S. Ostermann, K. Scott, and J. Semke. Ongoing TCP research
related to satellites. RFC 2760, Internet Request For Comments, February 2000.
[45] D. Arier. Network Tomography Based on Flow Level Measurements. PhD thesis,
University of Texas at Austin, USA, 2004.
[46] O. Aumage, L. Bougé, A. Denis, L. Eyraud, J.-F. Méhaut, G. Mercier, R. Namyst,
and L. Prylli. A portable and ecient communication library for high-performance
cluster computing (extended version). Cluster Computing, 5(1) :4354, Jan. 2002.
Special Issue : Selected Papers from the IEEE Cluster 2000 Conference.
[47] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, M. Stemm, and R. H. Katz. TCP
behavior of a busy internet server : Analysis and improvements. In INFOCOM (1),
pages 252262, 1998.
198
Bibliographie
[48] S. D. Ben. Ieee journal on selected areas in communications, vol. 22, no. 1, january
2004 1 tapestry : A resilient global-scale overlay for service deployment.
[49] A. Bestavros, J. Byers, and K. Harfoush. Inference and labeling of metric-induced
network topologies. Technical Report BUCS-TR-2001-010, Boston University, Computer Science Department, June 2001.
[50] A. Bestavros, J. W. Byers, and K. Harfoush. Inference and labeling of metric-induced
network topologies. IEEE Trans. Parallel Distrib. Syst., 16(11) :10531065, 2005.
[51] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. Rfc 2475- an
architecture for dierentiated services, 1998.
[52] T. Bu, N. Dueld, F. Presti, and D. Towsley. Network tomography on general
topologies. UMass CMPSCI Technique Report.
[53] H. Bullot, R. L. Cottrell, and R. Hughes-Jones. Evaluation of advanced tcp stacks
on fast long distance production networks. J. Grid Comput., 1 :345359, 2003.
[54] K. Butler, P. McDaniel, and W. Aiello. Optimizing bgp security by exploiting path
stability. In CCS '06 : Proceedings of the 13th ACM conference on Computer and
communications security, pages 298310, New York, NY, USA, 2006. ACM Press.
[55] A. R. Butt, R. Zhang, and Y. C. Hu. A self-organizing ock of Condors. 2003.
[56] J. W. Byers. Inference and labeling of metric-induced network topologies. IEEE
Trans. Parallel Distrib. Syst., 16(11) :10531065, 2005. Member-Azer Bestavros and
Member-Khaled A. Harfoush.
[57] H. Casanova and L. Marchal. A network model for simulation of grid application.
Research Report RR-2002-40, LIP, ENS Lyon, France, Oct. 2002. Also available as
INRIA Research Report RR-4596.
[58] R. Castro, M. Coates, G. Liang, R. Nowak, and B. Yu. Network tomography : Recent
developments. Statistical Science, 19, no. 3 :499517, 2004.
[59] R. Castro and R. Nowak. Likelihood based hierarchical clustering and network topology identication. 2683/2003 :113129, 2003.
[60] M. Coates, R. Castro, R. Nowak, M. Gadhiok, R. King, and Y. Tsang. Maximum
likelihood network topology identication from edge-based unicast measurements.
SIGMETRICS Perform. Eval. Rev., 30(1) :1120, 2002.
[61] R. Cohen, D. Dolev, S. Havlin, T. Kalisky, O. Mokryn, and Y. Shavitt. On the
tomography of networks and multicast trees. Physical Review, E 74, 2006.
[62] R. L. Cottrell and C. Logg. Overview of iepm-bw bandwidth testing of bulk data
transfer. Contributed to 15th Annual SC Conference on High Performance Networking and Computing : From Terabytes to Insights (SC 2002), Baltimore, Maryland,
16-22 Nov 2002.
199
Bibliographie
[63] B. Donnet, T. Friedman, and M. Crovella. Improved algorithms for network topology
discovery. In C. Dovrolis, editor, PAM, volume 3431 of Lecture Notes in Computer
Science, pages 149162. Springer, 2005.
[64] C. Dovrolis, P. Ramanathan, and D. Moore. What do packet dispersion techniques
measure ? In INFOCOM, pages 905914, 2001.
[65] C. Dovrolis, P. Ramanathan, and D. Moore. Packet-dispersion techniques and a
capacity-estimation methodology. IEEE/ACM Trans. Netw., 12(6) :963977, 2004.
[66] N. G. Dueld, F. L. Presti, V. Paxson, and D. F. Towsley. Inferring link loss using
striped unicast probes. In INFOCOM, pages 915923, 2001.
[67] L. Eyraud-Dubois, A. Legrand, M. Quinson, and F. Vivien. A rst step towards
automatically building network representations. In In 13th International European
Conference on Parallel and Distributed Computing - Euro-Par 2007, volume 4641 of
Lecture Notes in Computer Science, pages 848857, 2007.
[68] W.-c. Feng et al. Optimizing 10-gigabit ethernet for networks of workstations, clusters, and grids : A case study. Presented at Supercomputing 2003 (SC 2003) : Igniting
Innovation, Phoenix, Arizona, 15-21 Nov 2003.
[69] S. Floyd. Network working group request for comments : 3649 icsi category : Experimental december 2003 highspeed tcp for large congestion windows.
[70] M. Fomenkov, K. C. Clay, B. Huaker, and D. Moore. Macroscopic internet topology and performance measurements from the dns root name servers. In LISA, pages
231240. USENIX, 2001.
[71] I. Foster, C. Kesselman, J. Nick, and S. Tuecke. The physiology of the grid : An
open grid services architecture for distributed systems integration, june 2002. Open
Grid Service Infrastructure WG, Global Grid Forum.
[72] I. Foster, C. Kesselman, and S. Tuecke. The anatomy of the Grid : Enabling scalable
virtual organizations. Lecture Notes in Computer Science, 2150 :125, 2001.
[73] F. Georgatos and al. Providing active measurements as a regular service for isps.
In PAM, 2001. See also the RIPE NCC TTM service : http ://www.ripe.net/testtrac/.
[74] I. K. Guido Appenzeller and N. McKeown. Sizing router buers. In ACM SIGCOMM
2004, August 2004.
[75] T. Hacker, B. Noble, and B. Athey. Improving throughput and maintaining fairness
using parallel tcp, 2004.
[76] T. J. Hacker, B. D. Athey, and B. Noble. The end-to-end performance eects of
parallel tcp sockets on a lossy wide-area network. In IPDPS '02 : Proceedings of the
200
Bibliographie
16th International Parallel and Distributed Processing Symposium, page 314. IEEE
Computer Society, 2002.
[77] J. Hadamard. Lectures on cauchy's problem in linear partial dierential equations,
1923. Yale University Press.
[78] C. Hedrick. Rfc 1058 - routing information protocol, 1998.
[79] B. Huaker, D. Plummer, D. Moore, and K. Clay. Topology discovery by active
probing. In Symposium on Applications and the Internet, 2002. See also the skitter
project : http ://www.caida.org/tools/measurement/skitter/.
[80] A. Hyvärinen. New approximations of dierential entropy for independent component
analysis and projection pursuit. In Advances in Neural Information Processing Systems, volume 10, pages 273279. MIT Press, 1998.
[81] A. Hyvärinen, J. Karhunen, and E. Oja. Independent Component Analysis. John
Wiley and Sons, 2001.
[82] M. Jain and C. Dovrolis. Pathload : a measurement tool for end-to-end available
bandwidth. In PAM02 : Passive and Active Measurements (PAM) workshop, mars
2002.
[83] M. Jain and C. Dovrolis. End-to-end available bandwidth : measurement methodology, dynamics, and relation with tcp throughput. IEEE/ACM Trans. Netw.,
11(4) :537549, 2003.
[84] C. Jutten and J. Herault. Blind separation of sources, part 1 : an adaptive algorithm
based on neuromimetic architecture. Signal Process., 24(1) :110, 1991.
[85] A. Kamra, V. Misra, and D. Towsley. Achieving high throughput in low multiplexed,
high bandwidth, high delay environments. In First International Workshop on Protocols for Fast Long-Distance Networks, February 2003.
[86] N. T. Karonis, B. Toonen, and I. Foster. Mpich-g2 : A grid-enabled implementation
of the message passing interface. In Journal of Parallel and Distributed Computing
(JPDC), volume 63, pages 551563, may 2003.
[87] J. B. Keller. Inverse problems. Amer. Math. Monthly, 83 :107118, 1976.
[88] T. Kelly. Scalable tcp : Improving performance in highspeed wide area networks. In
Computer Communication Review, volume 32, April 2003.
[89] J. B. Khaled Harfoush, Azer Bestavros. Measuring bottleneck bandwidth of targeted
path. Research report, 2001.
[90] G. Kola. Proling grid data transfer protocols and servers. In Euro-Par, August
2004.
201
Bibliographie
[91] K. Krauter, R. Buyya, and M. Maheswaran. A taxonomy and survey of grid resource
management systems for distributed computing. Software, Practice and Experience,
32(2) :135164, 2002.
[92] S. Kullback. Information Theory and Statistics. dover reprint, 2001.
[93] A. Kuzmanovic, E. W. Knightly, and R. L. Cottrell. Hstcp-lp : A protocol for low
priority bulk data transfer in high speed high-rtt networks. Research Report SLACPUB-10456.
[94] S. Lacour, C. Perez, and T. Priol. Generic application description model : Toward
automatic deployment of applications on computational grids. In GRID '05 : Proceedings of the 6th IEEE/ACM International Workshop on Grid Computing, pages
284287, Washington, DC, USA, 2005. IEEE Computer Society.
[95] J. Lee, D. Gunter, B. Tierney, B. Allcock, J. Bester, J. Bresnahan, and S. Tuecke.
Applied techniques for high bandwidth data transfers across wide area networks,
2001.
[96] A. Legrand, F. Mazoit, and M. Quinson. An application-level network mapper.
Technical Report 2002-09, LIP, feb 2002.
[97] C. Logg, L. Cottrell, and J. Navratil. Experiences in traceroute and available bandwidth change analysis. Presented at SIGCOMM 2004 Workshops, Portland, Oregon,
30 Aug - 3 Sep 2004.
[98] D. M. Lopez-Pacheco and C. Pham. Performance of tcp (new reno, westwood), hstcp
and xcp in high-speed, highly variable-bandwidth environments. In Proceedings of
IEEE 3rd International Conference on Network Protocols (ICNP'04), Berlin, Germany, Oct. 2004. Student Poster Session.
[99] B. B. Lowekamp, N. Miller, R. Karrer, T. Gross, and P. Steenkiste. Design, implementation, and evaluation of the Remos network monitoring system. Journal of Grid
Computing, 1(1) :7593, 2003.
[100] S. Machiraju, D. Veitch, F. Baccelli, and J. Bolot. Adding denition to active probing.
SIGCOMM Comput. Commun. Rev., 37(2) :1728, 2007.
[101] M. Mathis, J. Semke, and J. Mahdavi. The macroscopic behavior of the TCP congestion avoidance algorithm. Computer Communications Review, 27(3), 1997.
[102] B.-H. B. J. McGregor, A. The nlanr network analysis infrastructure. IEEE Communications Magazine 38.
[103] J. Moy. Rfc 2328 - ospf version 2, 1998.
[104] V. Padmanabhan and L. Qiu. Network tomography using passive end-to-end measurements. DIMACS Workshop on Internet and WWW Measurement, Mapping and
Modeling, Piscataway, NJ, USA, February 2002.
202
Bibliographie
[105] A. J. Peters, P. Saiz, and P. Buncic. AliEnFS - a Linux File System for the AliEn
Grid Services. ArXiv Computer Science e-prints, pages 6071+, June 2003.
[106] M. Quinson. Découverte automatique des caractéristiques et capacités d'une plateforme de calcul distribué. PhD thesis, École normale supérieure de Lyon, Dec. 2003.
[107] M. Rabbat, R. D. Nowak, and M. Coates. Multiple source, multiple destination
network tomography. In INFOCOM, 2004.
[108] M. Ripeanu, I. Foster, and A. Iamnitchi. Mapping the gnutella network : Properties
of large-scale peer-to-peer systems and implications for system design. IEEE Internet
Computing Journal, 6(1), 2002.
[109] S. Seshan, M. Stemm, and R. H. Katz. SPAND : Shared passive network performance
discovery. In USENIX Symposium on Internet Technologies and Systems, 1997.
[110] S.Floyd. Rfc 3742 - limited slow-start for tcp with large congestion windows, 2004.
[111] SLAC. Network monitoring tools. http ://www.slac.stanford.edu/xorg/nmtf/nmtftools.html.
[112] E. S. Suviseshamuthu. Generating linear combination of spectral images with mutually exclusive specic information. PhD thesis, Université de la Méditerranée, 2007.
[113] Y. Tsang, M. C. Yildiz, P. Barford, and R. D. Nowak. Network radar : tomography
from round trip time measurements. In Internet Measurement Conference, pages
175180, 2004.
[114] P. Valtchev, D. Grosser, C. Roume, and M. R. Hacene. Galicia : An open platform for
lattices. In Using Conceptual Structures : Contributions to the 11th Intl. Conference
on Conceptual Structures (ICCS'03), pages 241254.
[115] S. Vazhkudai, J. Schopf, and I. Foster. Predicting the performance of wide area
data transfers. In Proceedings of the 16th Int'l Parallel and Distributed Processing
Symposium (IPDPS 2002)., 2002.
[116] P. Vicat-Blanc Primet, P. d'Anfray, C. Blanchet, L. Bobelin, O. Boudeville, F. Chanussot, V. Cung, Y. Denneulin, A. Djerrah, M. Drabik, Y. Jegou, P. Hyunh, N. Lacorne, D. Lacoste, B. Le Cun, L. Lefevre, D. Mateo, R. Metery, Y. Meurdesoif, J.-C.
Mignot, A. Pajot, C. Pham, R. Revire, G. Romier, and I. Touche. Réexions et
propositions pour une grille haute performance. Technical report, Scientic Report
of RNTL e-Toile Project, 2003. http ://www.urec.cnrs.fr/etoile/RS-etoile.pdf.
[117] F. Wagner. Redistribution de données à travers un réseau à haut débit. PhD thesis,
Université Henri Poincaré, Nancy, 2005.
[118] W. Wei, B. Wang, D. Towsley, and J. Kurose. Model-based identication of dominant
congested links. In IMC '03 : Proceedings of the 3rd ACM SIGCOMM conference on
Internet measurement, pages 115128, New York, NY, USA, 2003. ACM.
203
Bibliographie
[119] R. Wolski. Forecasting network performance to support dynamic scheduling using
the network weather service. In HPDC, pages 316325, 1997.
[120] R. Wolski, N. T. Spring, and J. Hayes. The network weather service : a distributed resource performance forecasting service for metacomputing. Future Generation
Computer Systems, 15(56) :757768, 1999.
[121] Y.Vardi. Network tomography : estimating source-destination trac intensities from
link data. Journal of the American Statistical Association, 91 :365377, 1996.
[122] M. Zangrilli and B. B. Lowekamp. Using passive traces of application trac in a
network monitoring system. In Proceedings of the Thirteenth IEEE International
Symposium on High Performance Distributed Computing (HPDC 13), pages 7786.
IEEE, June 2004.
204
Summary
Multiple sources, multiple destinations Metric Induced Network
Topology discovery for High Performances Grid
Nowadays grids connect up to thousands communicating resources that may interact in
a partially or totally coordinated way. Consequently, applications running upon this kind
of platform often involve massively concurrent bulk data transfers. In order to optimize
overall completion times, those transfers have to be scheduled based on knowledge about
network performances and topology.
Identifying and inferring performances of a network topology is a classic problem. Achieving this by using only end-to-end measurements at the application level is a method known
as network tomography. When topology reects capacities of sets of links with respect to a
metric, the model used to represent the topology obtained is called a Metric-Induced Network Topology (MINT). Such a type of representation, obtained using statistical methods,
has been widely used in order to represent performances of client/server communication
protocols.
However, it is no longer accurate when dealing with grids. In this thesis, we introduce
a novel representation of the infered knowledge from multiple source and multiple destination measurements, algorithms in order to reconstruct such representations, methods to
probe network in order to obtain an initial set of data from which we can reconstruct such
topology. We also describe the tool we have designed an implemented in order to achieve
these goals and experiences we have made in order to validate our methods and algorithms.
Key words : network tomography, grid, EGEE.
Academic discipline : Computer Sciences.
Laboratory : BT, 200 rue Pierre Duhem BP 389 13799 Aix-en-Provence Cedex 3 France
| CPPM - Centre de Physique des Particules de Marseille 163 avenue de Luminy - case 902
- 13288 Marseille Cedex 09 France | SPC - Systemes Parallèles Communicants Université
de la Mediterranée, Parc Scientique de Luminy, ESIL - F-13288 Marseille Cedex France.
Résumé
Tomographie depuis plusieurs sources vers de multiples destinations dans
les réseaux de grilles informatiques hautes performances
Identier et déduire les performances et la topologie d'un réseau est une problématique
classique. Résoudre ce problème en utilisant uniquement des tests de niveau applicatif,
une méthode appelée tomographie réseau, a été souvent proposé pour déterminer les performances du réseau d'un point de vue client/serveur. Quand la déduction de topologie
est basée sur les valeurs d'une métrique, on parle de Metric Induced Network Topology
(MINT).
Les grilles actuelles peuvent connecter des milliers de ressources communicantes qui
peuvent interagir de manière partiellement ou totalement coordonnée lors d'échanges de
données massifs. De fait, ces communications impliquent de façon concomitante plusieurs
sources et plusieurs destinations, rendant caduc le modèle client/serveur.
Dans cette thèse, j'introduis de nouvelles représentations de la connaissance du réseau
obtenues au cas d'un paradigme de communication comprenant de multiples sources et de
multiples destinations, des algorithmes pour reconstruire de telles représentations à partir
d'un jeu de données initial, ainsi que des méthodes pour obtenir à partir de mesures de
bout en bout ce jeu de données.
Je décris aussi l'outil M.I.N.T.C.A.R. que j'ai conçu et développé pendant cette thèse
pour implémenter l'ensemble de ces algorithmes et méthodes ainsi que les expériences menées pour valider ces méthodes et algorithmes.
Mots clefs : tomographie, réseau, grille, EGEE.
Discipline : Informatique.
Laboratoire : BT, 200 rue Pierre Duhem BP 389 13799 Aix-en-Provence Cedex 3 France
| CPPM - Centre de Physique des Particules de Marseille 163 avenue de Luminy - case 902
- 13288 Marseille Cedex 09 France | SPC - Systemes Parallèles Communicants Université
de la Mediterranée, Parc Scientique de Luminy, ESIL - F-13288 Marseille Cedex France.