Vous êtes sur la page 1sur 43

Techniques et outils de mtrologie pour

lInternet et son trafic


Philippe Owezarski et Nicolas Larrieu
LAAS-CNRS

1. De la complexit de raliser des mesures en environnement Internet ............................... 3


1.1. Caractristiques gnrales du trafic IP ....................................................................... 3
1.2. Les mtriques ............................................................................................................. 4
1.2.1 Besoins en terme de fiabilit ..................................................................................... 5
1.2.2 Besoins temporels...................................................................................................... 6
1.2.3 Besoins en terme de dbit.......................................................................................... 6
1.3. Points durs techniques ................................................................................................ 7
1.3.1 Dimension gographique et administrative............................................................... 7
1.3.2 Problmes lis la mesure dans des systmes distribus.......................................... 7
1.3.3 Mesures, estimations et analyses............................................................................... 9
1.4. Points durs juridiques ................................................................................................. 9
2. Techniques et outils de mesure et mtrologie .................................................................. 11
2.1. Mesures actives ........................................................................................................ 11
2.1.1. Dfinition.......................................................................................................... 11
2.1.2. Problmatique associe aux mesures actives ................................................... 11
2.1.3. Exemples doutils ............................................................................................. 12
2.2. Mesures passives ...................................................................................................... 13
2.2.1. Dfinition.......................................................................................................... 13
2.2.2. Problmatique associe aux mesures passives ................................................. 13
2.2.3. Exemples doutils ............................................................................................. 14
3. Exemple de la plate-forme de mesure et mtrologie sur Renater..................................... 17
3.1. Plate-forme de mesure active ................................................................................... 17
3.2. Plate-forme de mesure passive ................................................................................. 18
3.2.1. La solution DAG .................................................................................................... 18
3.2.2. Carte de dploiement des sondes DAG.................................................................. 22
4. Analyse du trafic Internet ................................................................................................. 24
4.1. Trafic Internet et notions associes .......................................................................... 25
4.1.1. Fonction d'auto-corrlation..................................................................................... 25
4.1.2. Processus dpendance longue (LRD) .................................................................. 26
4.1.3. Distribution dcroissance lente............................................................................ 27
4.2. Analyse par dcomposition en ondelettes du trafic.................................................. 28
4.3. Analyse des phnomnes de dpendance longue dans le trafic ............................... 30
4.3.1. Tendance dvolution du trafic......................................................................... 30
4.3.2. Mise en vidence de la dpendance longue dans le trafic ................................ 33
4.3.3. Dmonstration du rle de TCP sur la LRD ...................................................... 35
5. Conclusion........................................................................................................................ 37
6. Remerciements ................................................................................................................. 39
7. Rfrences ........................................................................................................................ 39
8. Glossaire............................................................................................................................... 42

1
LInternet connat une mutation au niveau de ses usages. De rseau mono-service pour
transporter des fichiers binaires ou textuels il y a vingt ans, lInternet doit aujourdhui tre un
rseau multi-services pour le transport de donnes diverses et varies comme des donnes
audio et vido (films, vido la demande, tlphonie, etc.). De fait, il faut oprer une mutation
technologique du rseau de faon le rendre capable de transporter avec des QoS adquates et
multiples les diffrents types dinformations proposes par toutes les applications utilisant
lInternet. Toutefois, toutes les tentatives pour garantir la qualit de service de lInternet ont
chou, notamment cause dune complte mconnaissance du trafic de lInternet et des
raisons de cette complexit. Au final, tel quil existe aujourdhui, personne na la matrise, ni
mme une connaissance, complte du rseau, ce qui va lencontre de la mise en uvre de
multiples services de communication qualit garantie.
La mtrologie des rseaux de l'Internet au sens littral la science des mesures
applique lInternet et son trafic doit permettre d'apporter une rponse ces problmes. En
premier lieu, sil faut fournir des services ayant des qualits prdfinies, il faut tre capable de
mesurer ces qualits. Dautre part, la mtrologie doit permettre de rpondre aux questions
concernant le (ou les) modle(s) de trafic de l'Internet qui font aujourd'hui dfaut. Aujourdhui,
la mtrologie des rseaux science rcente sil en est (elle est apparue au dbut des annes
2000) change tout le processus de recherche et d'ingnierie des rseaux de l'Internet et en
devient la pierre angulaire.
La mtrologie de lInternet se dcompose en deux tches distinctes : la premire consiste
mesurer des paramtres physiques de la qualit de service offerte par le rseau ou sur le trafic.
Dans un rseau de la taille et de la complexit de lInternet cest dj nous le verrons une
tche complexe. Toutefois, cette activit de mesure et dobservation ne permet de ne mettre en
vidence que des phnomnes visibles. Or en rseau, ce qui est certainement encore plus
important cest den dduire les causes, i.e. dterminer les composants et/ou mcanismes
protocolaires qui les engendrent. On se retrouve en fait confront au mme problme que
Platon dans lallgorie de la caverne [PLA avJC] : Platon, dans sa caverne, o crpitait un feu
de bois, napercevait que lombre des hommes qui rodaient dans la grotte. Et les ombres
projetes sur les parois de la caverne taient immenses, pouvant laisser croire quelles taient
celles de gants. La mtrologie rseau mesure de la QoS ou analyse simple du trafic nous
confronte ce problme platonien : elle ne nous montre que les effets de toute la
mcanique des rseaux alors que ce qui nous intrigue, ce sont les causes de ces effets, les
phnomnes qui les engendrent. Cest cette tche sans aucun doute la plus dlicate et la plus
importante qui constitue le second volet de la mtrologie car en mettant en vidence les
causes des lacunes de lInternet, on trace les voies de recherche pour faire voluer les
mcanismes, architectures et protocoles de lInternet.
Cet article introduit donc les principes de base de lInternet et de son trafic, les besoins et
les mtriques physiques. Il montre les diffrentes techniques de mesure actives et passives,
leurs besoins, leurs qualits et dfauts, cite un ensemble doutils rel utilisables ainsi que leur
mise en place sur le rseau RENATER dans le cadre du projet de mtrologie franais
METROPOLIS. Puis, partir de ces mesures ou observations sur le trafic, larticle montre une
approche pour analyser le trafic qui met en vidence les causes des limitations actuelles,
dmontrant ainsi limportance de la mtrologie pour la recherche et lingnierie des rseaux.

2
1. De la complexit de raliser des mesures en
environnement Internet
1.1. Caractristiques gnrales du trafic IP
Un rseau de type Internet doit aujourdhui tre multi-services : il a vocation transporter un
grand nombre de types de service possdant des caractristiques de trafic diffrentes et des
contraintes de QoS diffrencies. Cependant, dans le souci dune modlisation simplifie
autant que pour les besoins oprationnels de gestion du rseau, on recherche plutt une
classification grossire des diffrents types de trafic [ROB 00]. La plupart des auteurs
saccordent gnralement pour distinguer deux grandes classes de trafic de
tlcommunications dans les rseaux haut dbit :

Le trafic de type streaming , dont la dure et le dbit ont une ralit intrinsque bien
que variable ventuellement. Souvent associ la notion de services orients
connexion , son intgrit temporelle doit tre prserve par le rseau. Le dlai de
transfert des donnes de mme que sa variation, la gigue, doivent tre contrlables, tandis
quun certain degr de perte de paquets peut tre tolrable. Les flux de trafic streaming
sont typiquement produits par les services tlphoniques et vido (vidoconfrence ou
tlchargement on-line de squences).
Le trafic dit lastique , ainsi nomm car son dbit peut sadapter des contraintes
extrieures (bande passante insuffisante par exemple) sans pour autant remettre en cause
la viabilit du service. Cette classe de trafic est essentiellement engendre par le transfert
dobjets numriques par nature (par opposition au transfert en mode numrique
dinformations analogiques la source) tels que des pages Web (application HTTP), des
messages lectroniques (e-mail, application SMTP) ou des fichiers de donnes
(application FTP). Le respect de leur intgrit smantique est indispensable mais les
contraintes de dlai de transfert sont moins fortes. Cette intgrit smantique est la plupart
du temps assure par le protocole de transport (TCP) et ne constitue donc pas un lment
de performance sur lequel loprateur de rseau puisse agir ; en revanche, le maintien dun
certain dbit effectif minimum de transfert des documents est un objectif de QoS.

Le trafic de type lastique est actuellement largement majoritaire sur les rseaux IP : on
constate couramment [THO 97] des proportions suprieures 95% en volume (octets) et
90% en nombre de paquets pour le trafic TCP, protocole avec lequel fonctionnent la plupart
des applications mentionnes ci-dessus.

Lanalyse des caractristiques du trafic Internet seffectue commodment en se plaant un


niveau de reprsentation selon trois entits de trafic, correspondant trois chelles de temps
diffrentes et, quoique de manire assez grossire, trois niveaux (couches) de la pile
protocolaire des rseaux de donnes :

Les paquets forment lentit de trafic la plus fine que lon considre dans les rseaux
de donnes, le paquet tant lunit lmentaire traite par la couche rseau . Les
paquets sont a priori de longueur variable dans un rseau IP et leur processus dapparition
est trs complexe, en raison notamment de la superposition de services de nature trs
diverse et de linteraction des couches protocolaires (dispositifs de contrle de flux et de
retransmission sur perte de paquets, tels TCP [BLA 92]). Comme nous le verrons dans la
partie 4, le trafic au niveau paquet possde la caractristique unanimement reconnue

3
dauto-similarit, laquelle rend trs ardue lvaluation de ses performances ce niveau.
Nous dtaillerons donc des outils capables partir de mesures du trafic dvaluer cette
caractristiques du trafic, de la qualifier et de la quantifier. Les chelles de temps dcrivant
le processus des paquets sont la microseconde et la milliseconde, en fonction des ordres de
grandeur du dbit de transmission des liens.
Les flots constituent une entit de trafic intermdiaire que lon pense tre la mieux
adapte pour effectuer les tudes dingnierie du trafic IP. Ils correspondent des
transferts plus ou moins continus de sries de paquets associs une mme instance dune
application donne. Les flots de type streaming sont associs des communications
audio/vido (tlphonie sur IP, vidoconfrence) ou encore des tlchargements en
temps rel de squences vidos. Les flots de trafic lastique sont crs par le transfert dun
fichier, dun message, dun objet (ou document) au sein dune page HTML, etc. Un flot
correspond donc plus ou moins la couche transport de la pile protocolaire Internet ; mais
pas compltement puisque cette notion nest pas ncessairement quivalente celle dune
connexion TCP, p. ex., comme on le verra par la suite. On peut estimer que les flots ont
une dure stendant de quelques secondes quelques minutes, voire quelques heures.
Au plus haut niveau, on peut tenter de dfinir la notion de sessions dans le but de se
rapprocher des priodes dactivit des utilisateurs (transposition de la notion dappels
considre en tlphonie commutation de circuits). Pour le trafic streaming, ce niveau ne
se distingue gure de celui des flots, du moins temporellement, puisque ce dernier
correspond dj des communications ou des appels. Sagissant du trafic lastique, les
sessions peuvent tre associes des connexions Telnet, FTP, ou des envois de
messages lectroniques. La notion de session est (encore) plus floue au sujet des
connexions de type WWW selon le protocole HTTP : on peut par exemple la dfinir
comme tant la dure de transfert dune page HTML dans son ensemble (comportant
plusieurs objets transfrer) ou dune suite de pages associes une mme consultation.
Les sessions sont gnres par la couche application des rseaux et lordre de grandeur de
leur dure se situe entre quelques minutes et quelques heures.

Il est donc important en mtrologie danalyser le trafic Internet ces 3 niveaux. Toutefois, en
termes de mesures, les informations des 3 niveaux sont contenues dans les informations du
niveau le plus bas, soit le niveau paquet. Ds lors, les mesures proprement parler sont
gnralement faites au niveau paquet, et ce sont ensuite des logiciels de traitement des traces
et mesures qui permettent den extraire les informations de niveaux flots et sessions.

1.2. Les mtriques


La QoS est aujourdhui dlicate dfinir, et il nexiste pas de consensus au niveau des
acteurs de la communaut rseaux. En effet, beaucoup limitent la dfinition de la QoS au
triptyque :
- Dlais de transmission des paquets ;
- Dbit ;
- Taux de perte au niveau des paquets.
Cette dfinition se limite considrer des paramtres physiques de la transmission de
paquets de donnes. Toutefois, de nombreux acteurs du domaine des rseaux considrent
galement que la QoS intgre des paramtres plus complexes (et moins physiques) comme :
- la disponibilit des services rseau, i.e. la possibilit pour un utilisateur denvoyer
une information avec une QoS donne, tout moment ;
- la scurit des transmissions, i.e. la capacit du rseau assurer que les messages
ne seront pas lus ou altrs par un pirate informatique ;

4
- la robustesse du rseau, i.e. sa capacit continuer fonctionner correctement et
avec le niveau de performance et de QoS requis mme en cas de panne de certains
de ses composants, ou en cas dattaque ;
- etc.

En ce qui concerne la mtrologie, et sa premire tape qui est la mesure ou la collecte


dinformations, il est vident que ce sont des paramtres physiques qui vont pouvoir tre
mesurs. Les paramtres plus complexes, dont la dfinition et les mtriques pourront tre
fixes par chacun, seront en fait dtermins partir de la mesure de ces paramtres de base.
Dans cette premire partie qui se focalise sur la mesure et lobservation des effets du rseau
sur le trafic et sa QoS, nous allons donc nous limiter la mesure et lobservation du triptyque
(dlai, dbit, perte).

Toutefois, le terme QoS peut avoir diffrentes connotations selon la personne qui
lemploie. Pour simplifier un peu la problmatique, on peut considrer quil existe deux points
de vue principaux :
- Le point de vue des applications (ou des utilisateurs) : chaque application a des
besoins en termes de dbit, dlai, gigue, fiabilit, etc. Ces besoins sont naturellement
diffrents dune application lautre, et chaque application souhaiterait pouvoir
bnficier dun service de communication spcifiquement adapt ses besoins.
- Le point de vue des oprateurs dont les objectifs sont doptimiser lutilisation des
ressources de linfrastructure de communication (et ainsi de maximiser leurs gains), de
limiter les pertes et les dlais, et de pouvoir facturer de faon juste et cohrente les
services rendus aux utilisateurs.

Enfin, il existe une dernire complexit la mesure de ces paramtres de QoS physiques
(aussi qualifis de simples) et qui est lie la dimension de lInternet, compos dune
multitude de rseaux interconnects, eux mmes composs de nombreux nuds et de points
de prsence dans les diffrentes villes du monde desservies. Ainsi, il est important de
dcomposer les mesures en deux nouvelles classes :
- les mesures de bout en bout qui concernent le triptyque {dlai, dbit, perte} entre deux
utilisateurs terminaux. Ce sont des mesures qui rejoignent le point de vue des
applications prcdemment cit ;
- les mesures de proche en proche qui concernent le triptyque {dlai, dbit, perte} entre
des nuds intermdiaires du rseau (routeurs, commutateurs, passerelles, etc.). Ce sont
des mesures qui rejoignent le point de vue des oprateurs.

La suite donne une dfinition des paramtres du triptyque physique {dlai, dbit, perte}
tout en en donnant les besoins lis aux diffrentes applications qui existent dans lInternet.
Cela permettra au lecteur dapprhender la grande diversit des besoins de ces applications, et
de toucher du doigt la complexit de lanalyse du trafic Internet compos de toute cette varit
de classes de trafic diffrentes.

1.2.1 Besoins en terme de fiabilit


Les multiples applications de lInternet, qui utilisent de nombreux mdias, ont donc des
besoins trs variables. Ainsi, les medias continus (audio et vido) ont comme caractristiques
d'tre plus ou moins redondants. Ainsi deux images successives d'une transmission vido
comportent gnralement peu de diffrences. De cette redondance rsulte la possibilit que
des pertes d'information (image) soient acceptables du point de vue de l'utilisateur final. Il

5
apparait donc ici pour les medias les plus importants d'une application multimdia (audio et
vido) une contrainte de fiabilit du transfert des donnes non plus totale mais partielle, la
perte de certaines informations pouvant tre acceptable. Notons cependant que l'expression
d'une contrainte de fiabilit partielle est coupler avec la faon dont sont codes les donnes
audio et vido. En effet, certains codages (MPEG par exemple) introduisent une dpendance
entre les images qui peut rendre indcodables plusieurs images conscutives en cas de perte
de l'une d'entre elles, plus importante que les autres. A l'inverse, un codage de type M-JPEG
n'introduisant aucune dpendance entre les images, une contrainte de fiabilit exprime en
termes d'un pourcentage maximum de pertes admissibles et d'un nombre maximum de pertes
conscutives s'avre alors valide.

1.2.2 Besoins temporels


Les applications de diffusion diffre de mdias continus traitent leurs donnes de la mme
faon que s'il s'agissait de medias discrets. Deux types d'applications multimdias prsentent
des contraintes temporelles : les applications de diffusion en temps rel de mdias continus et
les applications multimdias interactives. Les contraintes temporelles s'expriment
gnralement par le biais de deux paramtres : le dlai de transit des donnes et la gigue.

- Dlai
Pour les applications interactives (telle que la visioconfrence), et un degr moindre
pour les applications de diffusion en temps rel (telles que le streaming audio ou vido),
afin que la communication se droule comme si elle avait lieu localement, il faut que les
donnes soient transmises en un temps infrieur au seuil de perception humain li au
media considr. Il apparat ainsi une contrainte sur le dlai de bout en bout du transfert
des donnes.
- Gigue
Les medias continus (tels que l'audio et la vido) prsentent des contraintes temporelles
dues leur caractre isochrone. Ces contraintes s'expriment en terme de rgularit dans
l'arrive des donnes (on suppose que la source des donnes met un dbit correspondant
au dbit idal de prsentation). Cette rgularit s'exprime par une contrainte sur le temps
inter-arrives des donnes, c'est-a-dire sur la diffrence entre les dates d'arrive de deux
donnes successives. Cette contrainte est appele la gigue . La date d'arrive d'une
donne tant calcule par :
trception = tmission + dtmin + dt
o :
o dtmin dsigne le temps de transmission optimal (sans attente dans le rseau) ;
o dt dsigne le temps d'attente dans le rseau.
On peut alors exprimer la gigue par :
tinter rception = tinter mission + dt2 - dt1
o :
o dt1 et dt2 reprsentent les temps d'attente dans le rseau pour deux donnes
successives.

1.2.3 Besoins en terme de dbit


Les besoins des applications en terme de dbit sont trs variables. Certaines, comme les
applications Web ou mail ne requirent que quelques kiloOctets de bande passante pour les
flux qu'elles changent. D'autres, au contraire, sont beaucoup plus exigeantes. Bien sr, c'est
cette dernire catgorie qui tend se gnraliser car de plus en plus d'applications rcentes
ncessitent une bande passante importante. On peut situer les applications de diffusion en
temps rel comme par exemple les chanes de tlvision sur Internet. Dans ce dernier cas, il

6
est d'ailleurs primordial de pouvoir fournir un service le plus stable et le plus rgulier possible
de faon ce que l'utilisateur l'extrmit du rseau reoive son flux multimdia avec un
niveau de qualit le plus rgulier possible.

1.3. Points durs techniques


Toutefois, la mesure de paramtres physiques simple sans parler de lestimation de
paramtres complexes partir de ces mesures qui sera prsente ultrieurement (partie 4)
reste un problme complexe dans lInternet. Cette partie dresse une liste la plus exhaustive
possible des problmes techniques qui se prsentent pour raliser des mesures sur le rseau
plantaire quest lInternet.

1.3.1 Dimension gographique et administrative


De faon vidente, les grandes difficults inhrentes la ralisation de mesures de trafic
ou de QoS sont lies la taille du rseau et son tendue gographique. Ainsi, il est
indispensable davoir de trs nombreux points de mesure dans le rseau. Regarder le trafic en
un seul point un moment donn est finalement assez peu significatif. Les communications
sur lInternet se font souvent sur de trs longues distances, et ne regarder ces communications
quen un seul point est trs rducteur. Toutefois, lInternet est une interconnexion de rseaux,
et ce titre de multiples oprateurs sont propritaires et en charge de la gestion et de
lopration dun de ces rseaux qui composent lInternet. Aussi, il est impossible aujourdhui
de positionner des outils de mesure en certains points du rseau contre la volont de
loprateur qui possde et gre ce point. Pour pouvoir faire de la mtrologie du rseau, il
faudrait pouvoir disposer de points de mesures au niveau de tous les nuds du rseau, mais la
construction de lInternet linterdit par dfaut. De plus, monitorer tous les nuds de lInternet
est une tche titanesque. Pour contourner cette difficult, de nombreux travaux sont en cours
depuis 3 4 ans sur les problmes dchantillonnage la fois spatial et temporel. Lide serait
de trouver des techniques qui partir de quelques points de mesure, qui ne fonctionneraient
que pendant des priodes de temps courtes, permettraient destimer de faon prcise le trafic
sur lensemble du rseau 24 heures sur 24. Mais aujourdhui, malgr les efforts consentis, les
rsultats en matire dchantillonnage sont au point mort, et dailleurs, nous nen parlerons
pas dans le reste de cet article par manque de rsultats positifs significatifs.
De plus, ltendue plantaire de lInternet entrane des variations journalires de lactivit.
Cela na donc que peu de sens de ne regarder quun seul point du rseau, car une connexion
inter-continentale peut tre confronte sur un des continents o la nuit est tombe un trafic
potentiellement plus rduit (et qui posera donc peu de problmes par rapport au respect de
contraintes de QoS), puis traverser quelques millisecondes plus tard un continent aux heures
pleines de la journe, et se heurter ainsi un trafic consquent et de possibles phnomnes
de congestion trs problmatiques pour la QoS de la communication. Dans un tel contexte, il
est donc indispensable de disposer de points de mesure sur ces diffrents continents, car le
trafic local peut avoir des consquences importantes sur la connexion inter-continentale que
nous considrions. De la mme faon, on retrouve le problme voqu dans la partie 1.2. au
sujet des mesures de bout en bout ou de proche en proche. On voit clairement sur cet exemple
de la connexion inter-continentale que la mesure de bout en bout ne donne quun rsultat
global de la QoS effective pour cette connexion, alors que les informations de proche en
proche permettent de localiser le problme entrainant les limitations de service.

1.3.2 Problmes lis la mesure dans des systmes distribus


Une autre classe de problmes laquelle on se retrouve confront lorsque lon souhaite
raliser des mesures sur lInternet est celle lie aux systmes distribus problmes dautant
plus dlicats rsoudre que lInternet est vaste, et surtout non matris dans son ensemble par

7
une entit unique. Ainsi, un des principaux problmes rgler concerne la possibilit davoir
recours une rfrence temporelle unique. En effet, si les horloges des machines sonde
impliques dans une mesure de dlai par exemple sont dsynchronises, le rsultat naura
aucune valeur et ne sera pas exploitable. Il existe bien des protocoles de synchronisation
dhorloges en rseau, dont le plus connu et utilis est NTP [MIL 96], mais les valuations de
performance de ce protocole ont montr que mme sil parvenait des rsultats assez
satisfaisants pour les rseaux locaux, il est totalement insuffisant sur les rseaux longues
distances tendus comme lInternet. En labsence de protocoles de synchronisation dhorloges
sur des rseaux longues distances plus performants que NTP, cest tout un pan de la recherche
sur les systmes distribus larges chelles et tendus gographiquement qui doit tre
invent. Ces recherches ne peuvent a priori explorer que deux axes :
- Soit trouver des mcanismes qui soient capables de dterminer le dcalage et la drive qui
existe entre les horloges impliques dans une mesure entre deux sondes distantes, de faon
pouvoir ensuite corriger les valeurs retournes par les sondes. Cest en fait la stratgie
qui est employe par NTP, mais avec un algorithme inadapt lInternet.
- Soit trouver un moyen de synchroniser physiquement et trs prcisment les horloges de
toutes les sondes de mesure et mtrologie sur une rfrence temporelle unique.
Nous verrons par la suite quelle solution nous proposons pour rsoudre ce problme de
synchronisation des horloges.

Un autre problme que lon rencontre dans les systmes distribus et encore accentu
dans lInternet cause de sa taille est li la localisation des mesures qui ne sont pas
ncessairement faites sur le point o elles vont tre exploites. Ces mesures devront donc tre
rapatries sur le lieu de leur exploitation. Ce rapatriement engendre au moins deux
problmes :
- Le premier est li la quantit de trafic que cela peut engendrer sur le rseau. En effet,
mme si parfois, par exemple sur la mesure dun dlai, seule une valeur scalaire est
transmise par les sondes de mesure et nengendre donc pas un surplus de trafic important,
il se peut que linformation rapatrier soit une trace de paquets complte qui peut elle
reprsenter plusieurs MgaOctets, voir plusieurs GigaOctets. Dans un tel cas, la
signalisation des informations de mesure est loin dtre transparente pour le rseau et son
trafic.
- Le second se prsente lorsque lon souhaite exploiter les mesures effectues en temps rel.
Naturellement, le rapatriement des donnes sur leur lieu dexploitation prend du temps
Plus ou moins selon les cas. Mais cependant assez pour se poser la question de la validit
temporelle de cette mesure. Dans un rseau haut dbit ce qui est le cas dans lInternet
aujourdhui et dont le trafic varie beaucoup et trs rapidement, il est lgitime de se
demander si la valeur de la mesure reue est encore valide. Cest en fait un problme que
lon rencontre dans les rseaux et les systmes distribus du fait que les messages de
contrle ou de signalisation dans le rseau utilisent le mme support de transmission que
les donnes de communications des utilisateurs Dans le cas de lInternet, messages de
signalisation et donnes utilisateurs sont transports dans les paquets qui empruntent les
mmes liens, passent par les mmes routeurs, etc. En faisant une analogie avec le trafic
routier, cela signifierait par exemple que pour dterminer le temps que lon va mettre un
samedi pour rallier Paris Marseille, on envoie un vhicule effectuer ce mme trajet dans
la nuit prcdent le jour du dpart. Naturellement, la valeur obtenue le vendredi soir peut
ne pas tre trs diffrente de ce quelle sera le samedi. Mais si le samedi en question est le
premier samedi du mois daot avec le tristement clbre chass-crois des vacances dt,
il est vident que la valeur obtenue le vendredi soir est sans rapport avec celle que mettra
le vhicule le samedi. La brusque augmentation du trafic automobile entre Paris et

8
Marseille le premier samedi du mois daot, avec la cration de bouchons (assimilables
aux congestions du rseau), fait que la mesure effectue la nuit auparavant est sans valeur.
Or en rseau, il nexiste pas de mdium parallle pour transporter les messages de contrle
ou de signalisation urgents, ce qui va rendre les performances des mcanismes de gestion
du rseau ou de signalisation des mesures sensibles au trafic de donnes existant sur le
rseau. Cest l aussi un problme majeur quil faudra rgler pour pouvoir mettre en
uvre et dployer des systmes de mesure dans lInternet, et en exploiter efficacement les
rsultats.

1.3.3 Mesures, estimations et analyses


Ce problme nous amne tout naturellement au problme suivant pour les mesures qui
concerne la dpendance des techniques de mesure ou leur calibration la nature du trafic.
Ainsi, il parat vident que lon ne pourra pas du tout utiliser les mmes solutions pour
mesurer du trafic ADSL 2 Mbps et le trafic dun oprateur de cur de rseau plusieurs
dizaines de Gbps. De la mme faon, la granularit dobservation ne pourra pas tre la mme
dans les deux cas. Egalement, cette granularit devra aussi tre adapte dautres
caractristiques du trafic : par exemple, si la taille moyenne des flux transmis sur diffrents
liens varie, il sera certainement judicieux dadapter la granularit dobservation la taille des
flux transports.

Finalement, et cest certainement l le problme principal de la mesure et de la mtrologie


dans les rseaux, il est quasiment impossible de faire des mesures sur la multitude de
mcanismes et protocoles que comporte larchitecture appele TCP/IP de lInternet. Ce
problme gnral voqu dans lintroduction de larticle fait que la mesure seule ne permet
pas dobtenir des informations sur le rseau et son comportement. Elle ne permet de ne voir
que les effets des mcanismes et protocoles, ce qui est loin dtre satisfaisant. La mesure doit
donc tre suivie dune phase au cours de laquelle des mthodes et des techniques de
mtrologie, par exemple bases sur la caractrisation et lanalyse du trafic et/ou des mesures
de QoS, vont permettre dexpliquer les causes des phnomnes observs. Et cest cette
impossibilit avec des mesures physiques simples qui justifie le plan de cet article qui
prsente dabord les techniques de mesures physiques simples (parties 2 et 3) mais surtout et
cest la contribution la plus importante de cet article les techniques de mtrologie
(caractrisation et analyse) qui vont permettre destimer les causes des phnomnes observs
sur le trafic ou la QoS du rseau (partie 4).

1.4. Points durs juridiques


Toutefois, les difficults avec les mesures et la mtrologie ne sarrtent pas aux problmes
techniques. De nombreux problmes juridiques se posent. Le premier a t impos par le
lgislateur franais avec la cration de la CNIL, laquelle interdit de crer des fichiers
contenant des donnes sur les individus et leurs usages. Typiquement, la collecte de traces de
trafic entre sous le coup de cette loi. Il faut donc, pour tre en toute lgalit, demander une
autorisation la CNIL pour constituer de tels fichiers de traces. En effet, une trace contient les
adresses IP des machines source et destination, et ce titre, les ordinateurs tant de plus en
plus individuels, cela identifie une personne physique, dont on pourra analyser les faits et
gestes sur le rseau. Cependant, le dbat est ouvert sur cette question car avec les systmes
multi-utilisateurs actuels, il faut clairement dfinir si juridiquement une adresse IP identifie
vraiment une personne physique ou non ? La question na pas encore t tranche, et comme
souvent avec les nouvelles technologies, le flou juridique le plus total est de rigueur. Dans les
faits, et notre connaissance, peu de chercheurs ou dingnieurs en rseau qui collectent des
traces de trafic nont demand dautorisation la CNIL. Dailleurs, ceux qui ont effectu une

9
demande attendent encore la rponse, la CNIL ne se pressant pas pour lgifrer sur cette
question. Lgalement, la collecte de trace est donc a priori interdite. Il convient donc toute
personne souhaitant collecter du trafic dtre trs prudente avec lutilisation quelle en fera. A
priori, dans notre cas qui consiste nanalyser les traces que par rapport aux aspects
techniques relatifs aux protocoles et mcanismes rseaux des fins damlioration, nous
nattentons pas au respect de la vie prive1. Il y a donc peu de chances quune plainte soit
dpose, ce qui semble laisser penser que notre activit en mtrologie est lgale. Cest du
moins linterprtation que nous avons faite de la loi avant de dmarrer nos travaux de
recherche en mtrologie. Cet article ne contient donc a priori que des informations dont la
divulgation ne porte atteinte personne. Par contre pour quelquun qui utiliserait des traces de
trafic pour connatre les usages dun individu ou dune famille comme les sites web consults
ou les fichiers tlchargs, il serait clairement en violation du droit dautrui la vie prive.
Toutefois, le flou existe ce niveau l, car il semble que lon se dirige vers le devoir pour les
FAI de dnoncer leurs utilisateurs qui tlchargeraient des films ou des musiques non libres
de droit2. Cela semble ouvrir une brche dans la surveillance des internautes si cette loi est
vote un jour. Mais le dbat fait rage lheure actuelle, et bien malin est celui qui pourrait en
deviner lissue.

Toutefois, mme en restant sur des aspects danalyse technique des rseaux, il est trs
difficile de convaincre les oprateurs de donner accs des traces de trafic provenant de leur
rseau. En effet, ces traces contiennent, pour un mtrologue averti de trs nombreuses
informations sur larchitecture du rseau, les mcanismes protocolaires utiliss et les
politiques de gestion mises en place. De la mme faon, cela donne des informations sur la
QoS que ce rseau peut offrir aux utilisateurs, sur sa robustesse face aux attaques, etc. Or la
fourniture daccs et de services Internet est un domaine conomique trs concurrentiel.
Rvler les secrets de conception et dadministration dun rseau revient donc rvler un
secret industriel et les concurrents pourraient ainsi en profiter en copiant cet oprateur.
Egalement, rvler la qualit de service que peut fournir un rseau surtout si elle est basse
ou les failles de scurit peut aussi porter prjudice un oprateur qui pourrait tre boud par
les utilisateurs potentiels qui lui prfreront un concurrent. Rvler les secrets de conception
dun rseau pourrait galement servir des pirates informatiques pour lattaquer de faon
imparable. Finalement, ces informations de mtrologie sont trs stratgiques pour les
oprateurs rseau et FAI. Ils les gardent donc jalousement, et contrlent trs fortement les
informations quils rendent publiques. Cest galement le cas pour les rseaux de la recherche,
qui sont pourtant des rseaux publics. Leurs administrateurs veillent ce que les informations
que nous publions ne soient pas de nature porter prjudice aux chercheurs, enseignants-
chercheurs et tudiants de nos universits et coles dingnieurs, par exemple en rvlant des
usages ne respectant pas la charte de ces rseaux pour lenseignement et la recherche.

1
De plus, pour encore plus se protger, il est possible pour les chercheurs ou ingnieurs qui collectent des traces
de trafic de les anonymiser, i.e. de transformer les adresses IP contenues dans les traces par un processus
irrversible, mais qui a la proprit de conserver la structure hirarchique de ladressage Internet. Ainsi, les
ingnieurs et chercheurs pourront continuer mener leurs recherches sur le routage ou les matrices de trafic par
exemple, tout en se prmunissant contre toute possibilit dtre accus de violer le droit la vie prive des
individus qui ont gnr le trafic captur (puisque le mcanisme danonymisation irrversible interdit de revenir
aux adresses initiales et de pouvoir donc identifier la personne physique derrire sa machine). Nous reviendrons
sur ces mcanismes danonymisation dans la partie 3.2.2.
2
Dj, un ingnieur ou un chercheur en rseau qui dans ses traces dcouvrirait un individu qui se livre des
activits pdophiles pourrait le dnoncer sans risque dtre accus davoir viol son droit la vie prive. Mais le
cas de la pdophilie est aujourdhui notre connaissance la seule exception pour laquelle la faute de lindividu
est de trs loin suprieure celle de lingnieur. Ce nest par exemple pas le cas pour la dnonciation dactivits
terroristes pour lesquelles seuls les services secrets et forces de lordre sont habilits.

10
Toutes ces limitations sont problmatiques dans notre travail quotidien. Toutefois, elles ne
le sont pas dans cet article qui ne traite que des techniques de mesure et des mthodes de
mtrologie et danalyse. Les exemples que nous donnons pour illustrer ces propos utilisent des
traces de plus de 12 mois qui ont de fait perdu de leur intrt stratgique vue la vitesse
dvolution des rseaux de lInternet. Toutefois, elles restent trs intressantes pour valider
nos mthodes danalyse et de mtrologie.

2. Techniques et outils de mesure et mtrologie


Aprs avoir pos les problmes techniques et juridiques, cette partie va maintenant
montrer comment on peut y apporter une solution. Nous nous focaliserons sur les seuls
problmes techniques, les problmes juridiques ntant pas de notre domaine de comptence.
Cette partie va donc montrer les diffrentes techniques qui ont t conues et dveloppes au
cours de ces dernires annes pour mesurer les paramtres physiques de base dans les rseaux,
ou collecter des traces de trafic. Le chapitre 3 illustrera la mise en place dquipements de
mesure sur Renater dans le cadre du projet METROPOLIS. Ensuite, le chapitre 4 et ses
suivants traiteront des mthodes danalyse et de mtrologie qui permettront daller plus loin
dans la comprhension des phnomnes qui sont observs dans le rseau.

2.1. Mesures actives


2.1.1. Dfinition
Le principe des mesures actives consiste gnrer du trafic dans le rseau tudier et
observer les effets des composants et protocoles rseaux et transport sur le trafic : taux de
perte, dlai, RTT, etc. Cette premire approche possde lavantage de prendre un
positionnement orient utilisateur. Les mesures actives restent le seul moyen pour un
utilisateur de mesurer les paramtres du service dont il pourra bnficier.

2.1.2. Problmatique associe aux mesures actives


Lun des inconvnients majeurs pour le rseau avec les mesures actives est la perturbation
introduite par le trafic de mesure qui peut faire voluer ltat du rseau et ainsi fausser la
mesure. En effet, le rsultat de la mesure donne une information sur ltat du rseau
transportant la fois les donnes normales des utilisateurs et de signalisation du plan de
contrle du rseau, mais galement lensemble des paquets sondes. Or on souhaiterait avoir
une information qui correspond au trafic normal uniquement, sans les paquets sondes lesquels
ont forcment un impact sur les performances du rseau. Il faut donc soit tre capable
destimer limpact des paquets sondes sur les performances du rseau, soit tre sr que ces
paquets sondes auront un impact minimal, si possible quasi nul. Cest cette dernire
proposition, a priori plus simple, qui suscite le plus defforts de recherche. On parle de trafic
de mesure non intrusif. Ainsi, de nombreux travaux mens actuellement abordent ce problme
en essayant de trouver les profils de trafic de mesure qui minimisent les effets du trafic
supplmentaire sur ltat du rseau. Cest par exemple le travail en cours au sein du groupe
IPPM de lIETF [PAX 98] [ALM 99a] [ALM 99b] [ALM 99c].
Un autre lment qui se pose dans ce genre de mesures est li la vitesse de
convergence des mesures vers un rsultat dont la fiabilit est bonne. En effet, pour mesurer
certains paramtres, il faut parfois mettre en uvre tout un processus complexe pour
approcher de la solution. Par exemple, pour mesurer le dbit disponible sur un chemin entre
une source et une destination, certains outils transmettent des dbits de paquets sondes qui
augmentent chaque tentative jusqu ce que des pertes apparaissent, ces pertes tant

11
assimiles des phnomnes de congestion. La valeur du dbit gnr est ainsi la valeur
retourne par loutil de mesure comme tant le dbit disponible sur le chemin. Toutefois, le
processus peut tre long, et dans le cas o le trafic transport sur le chemin est trs variable, le
rsultat est peu fiable. Parfois mme il est possible que loutil ne converge pas vers un rsultat.
Converger rapidement est donc essentiel pour pouvoir connatre prcisment les variations du
trafic sur un chemin.
Enfin, la prcision est un lment dterminant. Si les mesures ont des intervalles de
confiance importants, les rsultats sont sans intrt pour les chercheurs, ingnieurs ou
administrateurs rseaux. Par exemple, dans le cas de loutil de mesure du dbit disponible sur
un lien, la prcision est intimement lie la vitesse de convergence du processus de mesure, et
au pas daugmentation du trafic sonde lors de chaque changement ditration. Mais dans
dautres cas, comme par exemple la mesure de dlais, la prcision peut seulement tre lie la
qualit de la synchronisation temporelle entre la source et la destination des paquets sondes.

2.1.3. Exemples doutils


Les mesures actives simples restent tout de mme monnaie courante dans lInternet pour
lequel de nombreux outils de test, validation et / ou mesure sont disponibles. Parmi eux, on
peut citer les trs clbres ping et traceroute. Ping permet de vrifier quun chemin est valide
entre deux stations et de mesurer certains paramtres comme le RTT ou le taux de perte.
Traceroute permet de voir apparatre lensemble des routeurs traverss par les paquets mis
jusqu leur destination et donne une indication sur les temps de passage en chacun de ces
nuds. On peut galement citer MGEN qui prsente la particularit dmettre des paquets en
multicast, cest--dire destination de plusieurs rcepteurs la fois, et permet donc, grce
un mcanisme de duplication des paquets au dernier moment dans le rseau, de minimiser le
trafic des paquets sondes.
Il existe galement toute une batterie doutils pour lestimation de la capacit dun lien
ou dun chemin, comme clink [DOW 99], pchar [MAH 00], pathchar [JAC 97], etc. De la
mme faon des outils, souvent assez similaires dans leurs processus estiment le dbit
disponible sur un chemin du rseau. On peut citer Abing [NAV 03], Spruce [STR 03],
pipechar [GUO 05], pathchirp [RIB 03], IGI [HU 03], etc. Cet article, dont lobjectif est de
faire un tour dhorizon des diffrentes techniques de mesure, na pas pour objectif de rentrer
dans les dtails des algorithmes de chacun de ces outils. Le lecteur pourra se rfrer aux
publications originales qui dcrivent ces outils. A noter toutefois, et cest aussi une des raisons
pour laquelle nous ne nous attardons pas sur la description de ces outils, quils restent assez
peu efficaces : ils sont trs long converger et de fait inadapts pour un rseau dont le trafic
varie beaucoup. Ils sont galement imprcis ne serait-ce que pour estimer le dbit moyen
disponible [LAB 05].
Il existe galement des outils matriels pour les mesures actives, comme les sondes
RIPE TTM3 par exemple. Ces sondes sont en fait des PC utilisant le systme FreeBSD et
quipes de cartes GPS relies une antenne satellite. Avec le logiciel de gnration et
danalyse des paquets sondes dploys sur ces sondes, il est possible de connatre les dlais,
les taux de perte et la topologie du rseau entre les diffrentes sondes RIPE dployes dans
lInternet. Llment le plus intressant dans les quipements RIPE reste lexistence dun
service commercial (offert par RIPE) pour grer ces sondes et leurs mesures en continu. Il
existe aujourdhui plus de 250 sondes de ce type dans le monde, ce qui en fait une des plus
grandes plates-formes de mesures actives. Dautres plates-formes de ce type existent comme
NIMI [PAX 00], initie et maintenue par des universits, amricaines la base, de tous pays
aujourdhui. Toutefois, dans la partie 3.1, cet article dcrira en dtail une de ces plates-formes

3
http://www.ripe.net/projects/ttm/index.html

12
que nous connaissons bien car tant impliqus dans ce projet. Il sagit de la plate-forme
MetroMI du projet METROPOLIS dploye sur le rseau Renater.

2.2. Mesures passives


2.2.1. Dfinition
Les projets de mesures passives sont apparus beaucoup plus rcemment que les projets de
mesures actives car ils ncessitent des systmes de capture ou danalyse du trafic en transit
relativement avancs, et dvelopps trs rcemment mme si quelques logiciels simples,
mais aux capacits limites, existaient dj comme TSTAT, NTOP, LIBCAP, TCPdump,
TCPtrace, etc. sur lesquels nous reviendrons dans la partie 2.2.3. Ils ont nanmoins mis en
vidence que des outils de supervision, fonctionnant avec un approche passive taient de
nature rsoudre bon nombres de problmes qui se posent pour la conception, lingnierie,
lopration et la gestion des rseaux de lInternet, et cest l un des objectifs de cet article de
le dmontrer.
Des quipements matriels plus performants sont en fait la base de lessor actuel en
matire de mtrologie passive, et ont notamment ouvert la voie la mtrologie passive
microscopique (dfinie plus loin). Le principe des mesures passives est de regarder le trafic et
d'tudier ses proprits en un ou plusieurs points du rseau. L'avantage des mesures passives
est qu'elles ne sont absolument pas intrusives et ne changent rien l'tat du rseau lorsqu'on
utilise des solutions matrielles ddies (par exemple sur la base de cartes DAG [DAG 01]
prsentes dans la partie 3.2.1). Elles permettent des analyses trs avances. En revanche, il
est trs difficile de dterminer le service qui pourra tre offert un client en fonction des
informations obtenues en mtrologie passive. Il vaut mieux pour cela utiliser des techniques
actives.

Les systmes de mtrologie passive, peuvent galement se diffrencier en fonction du


mode d'analyse des traces. Ainsi, le systme peut faire une analyse en-ligne ou hors-ligne.
Dans le cadre d'une analyse en-ligne, toute l'analyse doit tre effectue dans le laps de temps
correspondant au passage du paquet dans la sonde de mesure. Une telle approche, temps-rel,
permet de faire des analyses sur de trs longues priodes et donc d'avoir des statistiques
significatives. Par contre, la complexit maximale pour ces analyses reste trs limite cause
du faible temps de calcul autoris (dautant plus faible que la capacit du rseau est
importante). A l'inverse, une analyse hors-ligne oblige la sonde sauvegarder une trace du
trafic pour analyse ultrieure. Une telle approche demande ainsi d'normes ressources ce qui
reprsente une limitation pour des traces de trs longue dure. Par contre, une analyse hors-
ligne permet des analyses extrmement compltes et difficiles, capables d'tudier des
proprits non triviales du trafic. De plus, comme les traces sont sauvegardes, il est possible
de faire plusieurs analyses diffrentes sur les traces, et de corrler les diffrents rsultats
obtenus sur la trace, ou obtenus sur des traces diffrentes, pour une meilleure comprhension
des mcanismes complexes du rseau.

2.2.2. Problmatique associe aux mesures passives


La principale contrainte qui se pose pour linstallation de sondes de mesure est due au
fait que le rseau dont nous souhaitons analyser le trafic est presque toujours un rseau
oprationnel ( lexception de quelques rseaux dexprimentation dans les laboratoires de
recherche), et que malgr la prsence de la sonde, ce rseau doit continuer fonctionner sans
aucune dgradation du service quil offre.
- Le premier besoin pour le systme de mesure mettre en place est donc une
transparence totale pour le rseau et son trafic. Cela signifie que pour tre non intrusif,

13
cet quipement ne devra pas provoquer de pannes, derreurs de transmission et ne pas
introduire de dlais pour ne pas modifier le profil du trafic et les performances du
rseau.
- Le second besoin lors du choix des sondes de mesure passive concerne sa prcision et
la validit des traces quelle produira. Ainsi, il est essentiel de ne pas manquer de
paquets transitant sur le rseau, et davoir des informations prcises sur le passage de
ces paquets, notamment au niveau temporel, qui reprsente aujourdhui une des
difficults majeures avec les systmes actuels. Le systme devra donc tre bien
dimensionn et offrir une horloge prcise qui ne drive pas.
- Le troisime besoin qui apparat concerne la possibilit de corrler des vnements de
plusieurs traces, par exemple de suivre un paquet en plusieurs points du rseau, ou
danalyser de faon croise le passage des paquets et de leurs acquittements, etc. Pour
pouvoir finement analyser de tels vnements se produisant en des points
gographiquement distants et des instants distincts mais faiblement loigns
temporellement, il est ncessaire de disposer dune base temporelle commune et
universelle pour toutes les sondes.

Enfin, il existe galement dautres besoins qui peuvent apparatre de seconde


importance lors de la conception dun outil de mesure mais quil ne faut pas ngliger. Le
premier concerne le problme de la mtrologie dun rseau complet et du rapatriement des
donnes collectes au niveau des diffrents points de mtrologie. Il est important de trouver
un moyen de ramener ces donnes vers les machines danalyse de faon efficace et sans
influer sur le rseau et sa charge. Le second concerne la nature des informations collecter, et
notamment la taille des enregistrements faits sur chaque paquet. En effet, collecter la totalit
des donnes du paquet, avec donc toutes les informations applicatives, est a priori contraire
aux rgles fixes par la CNIL sur le droit la vie prive. Il faut donc bien rflchir aux
donnes collecter sur chaque paquet par rapport lanalyse que lon souhaite faire.

2.2.3. Exemples doutils


Parmi les outils de mtrologie passive notre disposition, il existe tout un ensemble doutils
logiciels, dont il serait illusoire de vouloir faire une liste exhaustive. Nous nous limiterons
donc aux plus connus et utiliss.

2.2.3.1. Solutions logicielles


La plus clbre de ces familles doutils logiciels est celle compose de TCPdump4,
TCPtrace 5 , Ethereal 6 , etc. qui sont tous des outils bass sur lutilisation de la librairie
LIBPCAP. Cette librairie permet daller lire sur une interface rseau les paquets qui transitent,
den rcuprer une copie, et de la stocker et/ou analyser. Naturellement, ces outils possdent
les avantages et les inconvnients de leur nature logicielle. Les avantages font quils sont
faciles utiliser, largement disponibles (les 3 outils cits sont dailleurs des logiciels libres), et
ne ncessitent pas dquipements matriels coteux pour fonctionner. A loppos, ces outils
souffrent de problmes dimprcisions, notamment temporelles, car le systme opratoire
effectue de nombreuses tches et peut mme tre interrompu entre la capture du paquet et
son estampillage par exemple. De mme, des problmes de performance limitent les capacits
de traitement et danalyse des ces outils logiciels, et parfois mme de capture. Ds lors que le
dbit du trafic sur le lien monitor augmente, ces outils ne donnent plus satisfaction ; ils ne
sont gure efficaces avec des ordinateurs de bureau classiques ds que le dbit excde une
4
http://www.tcpdump.org/
5
http://www.tcptrace.org/
6
http://www.ethereal.com/

14
dizaine de Mbps. Pour augmenter ces capacits, il faut utiliser des machines dont les capacits
de traitement et de communication externes et internes sont largement suprieures, mais sans
que les problmes de prcision, ni mme de possibilits danalyse ne soient largement
amliors. En fait, pour monitorer du trafic sur des liens trs hauts dbits, nous
recommandons de nutiliser ces outils logiciels que pour lanalyse du trafic en temps diffr ;
en aucun cas, ils ne donnent satisfaction pour des analyses en temps rel. Lapproche consiste
donc utiliser des outils matriels plus avancs et plus rcents de capture du trafic sur des
liens hauts dbits, de stocker la trace de ce trafic sur un disque dur, puis de faire lanalyse de
cette trace en temps diffr avec les outils logiciels cits. Naturellement, cela interdit un
certain nombre dapplications au rseau qui ncessitent des rsultats danalyse en temps rel.
Mais cela permet nanmoins de travailler la caractrisation et modlisation du trafic,
lanalyse de phnomnes particuliers sur les protocoles, lanalyse des attaques, etc. Il est
noter cependant que de part le faible investissement que ncessite la prise en main de ces
outils, coupl au fait quil nest pas ncessaire de faire des investissements matriels, ils sont
massivement utiliss dans la communaut rseau, et seuls les spcialistes en mtrologie
investissent dans des solutions matrielles plus performantes et plus coteuses. A noter
galement dans la mme famille, des outils comme TSTAT 7 ou NTOP 8 qui permettent
respectivement danalyser des connexions TCP et de monitorer le nombre de connexions sur
une machine. Ils prsentent videmment les mmes avantages et dfauts que TCPdump ou
Ethereal. TSTAT est utilis en gnral par les chercheurs et ingnieurs qui cherchent les
limitations de TCP sur une infrastructure de communication particulire. NTOP peut par
exemple tre utilis pour dtecter certaines attaques de dni de service.

2.2.3.2. Traffic Designer


Sinspirant de ces outils logiciels, la socit QoSMOS (une jeune pousse issue du LIP6
Paris) a conu, dvelopp et commercialise un outil de supervision et de mesure du trafic
Traffic Designer9 mais qui en plus exploite ces rsultats pour adapter sa gestion du trafic
aux besoins des utilisateurs en termes de QoS. Lobjectif est donc dexploiter au mieux les
ressources du rseau pour maximiser la satisfaction des utilisateurs. Loutil Traffic Designer
est compltement packag . Il arrive chez lutilisateur sous la forme dun PC
spcifiquement adapt cette tche, et avec tous les logiciels danalyse et de gestion du trafic.
Notre exprience avec cette solution a montr que les problmes de prcisions et de
performances sont rmanents. Avec les trafics actuels de lInternet, Traffic Designer nest
gure capable aujourdhui de traiter des dbits suprieurs une dizaine de Mbps. Toutefois cet
outil reste trs intressant par la quantit des logiciels danalyse fournis et par la qualit de son
interface graphique, et ce autant pour la facilit de dfinition des analyses particulires que
pour la prsentation des rsultats. En particulier, un des points forts de la solution QoSMOS
est son logiciel de classification applicative bas sur une reconnaissance des protocoles
applicatifs, et non pas sur lutilisation des numros de port IANA comme cela est fait dans
tous les autres outils danalyse. En effet, aujourdhui, de plus en plus dapplications utilisent
des numros de port dynamiques (comme le P2P par exemple) ou encapsulent leur connexions
dans des connexions dautres protocoles applicatifs (les applications de video streaming par
exemple encapsulent souvent leurs connexions dans des connexions web pour pouvoir passer
les pare-feux ou firewalls). Les numros de port fixs par lIANA pour les diffrentes
applications nont donc plus grande signification. Le mode de reconnaissance du protocole
applicatif par pattern matching sur les premiers paquets de la connexion applicative est
donc dune prcision remarquable qui limite lintroduction de biais dans lanalyse. De plus, la
7
http://tstat.tlc.polito.it/
8
http://www.ntop.org/
9
http://www.qosmos.net/Produits_et_services/Traffic_Designer/

15
socit QoSMOS, pour passer outre les problmes de performance propose pour les
spcialistes de la mtrologie rseau un logiciel dinjection de traces de trafic (captures par
ailleurs) dans loutil Traffic Designer : loutil TDplayer. Comme pour les outils
prcdemment cit, cela interdit des analyses en temps rel, mais cela permet dun autre ct
dutiliser les capacits des logiciels danalyse Traffic Designer, qui restent intressantes mme
en temps diffr.

2.2.3.3. IPANEMA
En allant encore plus loin dans les solutions de mtrologie ddies, on peut citer
IPANEMA 10 qui est une sonde qui combine mesures actives et passives. Ces sondes sont
constitues autour dun hardware ddi, et possdant un logiciel pour la gnration de paquets
sondes et un logiciel danalyse, lanalyse portant la fois sur les paquets sondes et sur le trafic
normal du lien monitor. Il faut donc pour que la solution fonctionne disposer de plusieurs
sondes dans le rseau pour pouvoir exploiter la fois les mesures actives et passives. Ainsi,
les sondes qui mettent le trafic et celles qui le voient passer peuvent schanger les mesures
quelles ont ralises pour une analyse complte et prcise. Toutefois, linconvnient majeur
de ces sondes IPANEMA est leur cot quasiment prohibitif. De plus, pour que la solution
puisse tre utile, il faut en dployer un assez grand nombre dans le rseau, ce qui amne des
tarifs indcents. Cest dailleurs certainement la raison pour laquelle les sondes IPANEMA
restent marginales aujourdhui, et que les spcialistes de la mtrologie leur ont prfr des
solutions tout aussi performantes mais moins onreuses comme les systmes DAG sur
lesquels nous reviendront au paragraphe 3.2.

2.2.3.4. Netflow
Toutefois, en pensant la mise en uvre oprationnelle des solutions de mtrologie
dans un rseau, il apparat que lendroit idal pour positionner des sondes de mesures passives
est indniablement dans les routeurs. CISCO a ainsi dvelopp le module Netflow [CIS 01]
dans ses routeurs, qui scrute le trafic en transit, et gnre rgulirement des informations
statistiques sur ce trafic. Netflow a ainsi t utilis dans de nombreux projets de recherche,
mais tend aussi remplacer les solutions de gestion de rseaux chez les ingnieurs rseaux
dexploitation. Netflow est la base un mcanisme pour amliorer les performances des
routeurs CISCO avec une gestion interne du routage par flux qui ne ncessitait de ne router
que le premier paquet de chaque flux, les paquets suivants tant ensuite commuts vers le
mme port que le premier paquet du flux. Ainsi, mme si la commutation / routage Netflow a
disparu des nouvelles gnrations de routeurs CISCO, le composant logiciels de mesures
statistiques est rest. Lexprience montre toutefois que les performances de Netflow restent
limites (code crit en Java et interprt), et que linfluence sur les performances du routeur
est non ngligeable. Mais il sagit certainement l dune voie explorer car ce sera
certainement la plus viable et la plus efficace ds lors que des solutions de mtrologie devront
tre mises en exploitation sur un rseau oprationnel. Elles prendront en fait la place et
tendront les solutions actuelles de gestion du rseau bases sur le protocole SNMP et ses
MIB (qui contiennent les informations mesures aux diffrents points monitors). A noter
dailleurs quil existe des travaux au niveau du groupe MRTG11 de lIETF qui essaient de
normaliser la reprsentation de ces rsultats de monitoring. Pour linstant ils portent sur
SNMP et ses MIB, mais il faudra quils puissent prendre en compte dautres solutions de
mtrologie et dautres formats qui vont apparatre prochainement.

10
http://www.ipanematech.com/New/FR/index.php
11
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

16
2.2.3.5. OCxMON
Enfin, des cartes ddies la capture du trafic sont apparues. Les premires dont
lintrt a t significatif sont les cartes OCxMON [APS 97] mais qui ne fonctionnent que
pour des rseaux ATM (OC3MON tant pour les liens 155 Mbps et OC12MON pour les
liens 622 Mbps). OCxMON est donc une carte de capture des enttes de chaque paquet qui
transitent sur un lien. Ces paquets sont ensuite stocks dans un fichier sur un disque dur. Il est
ainsi possible de passer tous les logiciels danalyse que lon souhaite sur cette trace. A noter
toutefois, quil est possible aussi de rcuprer en direct la sortie de la carte pour la rediriger
vers les logiciels danalyse, si ceux-ci sont assez rapides pour fonctionner la vitesse du lien.

2.2.3.6. DAG
Finalement, cest cette approche avec cartes de capture du trafic qui a aujourdhui le
plus de succs auprs des spcialistes de la mtrologie. La solution OCxMON ntant valide
que pour des liens ATM assez rares aujourdhui, cest vers la solution DAG que se sont le
plus souvent tourns les chercheurs et ingnieurs en mtrologie rseau, la carte DAG existant
pour de trs nombreuses technologies de rseaux et couvrant (presque ?) toutes les capacits
de liens. Cette solution sera dcrite prcisment dans la section 3.2.

3. Exemple de la plate-forme de mesure et mtrologie sur


Renater
Une fois effectu ce bref tour dhorizon de la problmatique associe aux mesures
dans les rseaux de communication et notamment dans lInternet et des diffrentes
techniques de mesures existantes, nous allons maintenant donner plus de dtails sur un
exemple que nous connaissons particulirement bien pour en tre des contributeurs :
lexemple de la plate-forme de mtrologie dploye autour du rseau Renater dans le cadre du
projet METROPOLIS. Nous allons donc donner tous les dtails de conception, mise en uvre
et dploiement des outils de mesures actives (partie 3.1) et de mesures passives (partie 3.2).

3.1. Plate-forme de mesure active


Comme nous lavons vu dans la partie 2.2.3, il existe aujourdhui deux plates-formes
de mtrologie active publiques, mondiales et de tailles significatives : les plates-formes RIPE-
TTP et NIMI. Naturellement, et cest dautant plus vrai pour les mesures actives, plus une
plate-forme de mesure comporte de sondes plus elle est mme de fournir des rsultats
intressants lchelle dun rseau ou dune interconnexion de rseaux. Aussi, notre choix en
termes dquipements de mesures actives pour notre plate-forme MetroMI (METROPOLIS
Measurement Infrastructure) a t conduit par la volont dtre compatible avec le petit millier
de machines existantes et composant ces deux plates-formes. Ainsi, les sondes de mesures
actives sont des sondes RIPE-TTM, i.e. des PC standards, avec le systme FreeBSD et une
carte GPS connecte des antennes GPS. Grce ce GPS, lensemble de la plate MetroMI
dispose dune rfrence temporelle universelle et toutes les sondes sont donc synchronises.
De plus, le GPS fonctionne par lmission toutes les secondes dun signal de synchronisation
sur lequel se calent les horloges des diffrentes machines. Cela assure aussi une grande
prcision des horloges dont la drive est annule toutes les secondes et la drive des
horloges actuelles sur une seconde est quasiment inexistante (dans tous les cas non mesurable
avec les outils classiques non atomiques dont nous disposons). Dautre part, nos sondes
RIPE-TTM hbergent une version du logiciel NIMI porte par les chercheurs du projet
METROPOLIS pour le systme FreeBSD. Nos sondes MetroMI deviennent donc compatibles
avec les sondes NIMI (par nature elles taient dj compatibles avec les machines de la plate-
forme RIPE-TTM).

17
En ce qui concerne la non intrusivit des mcanismes de mesure qui injectent des
paquets sondes et leur vitesse de convergence, cest naturellement le soucis des concepteurs et
dveloppeurs doutils de mesure active, et les solutions vont dpendre des paramtres quil
faut mesurer et de la manire employe pour les mesurer. Ce nest en tout cas pas un
problme de nature impacter la conception matrielle des machines de la plate-forme de
mesure active.
Enfin, il faut galement noter que la plate-forme MetroMI intgre ses propres logiciels
de mesure, dvelopps dans le cadre de METROPOLIS. Dautre part, les machines de la
plate-forme MetroMI peuvent tre isoles des plates-formes RIPE-TTM et NIMI dans le cas
o nous souhaiterions conduire des exprimentations pouvant tre incertaines pour lInternet
et la vivacit des machines des plates-formes RIPE-TTM et NIMI.
Le dploiement des sondes MetroMI est reprsent sur la figure 1.

ENST DAG

LIP6 QoSMOS
Jussieu

ENST-B INT RIPE TTM

Plate-forme
de mesure

ENS Lyon
Mont de
Marsan

Pau EURECOM

IUT GTR

LAAS

Figure 1. La plate-forme de mesure (active et passive) dploye dans le cadre de


METROPOLIS

3.2. Plate-forme de mesure passive


Par rapport la plate-forme passive, comme nous lavons vu dans la partie 2.2.3, il
nexiste pas de solution satisfaisante pour des analyses avances qui fonctionne en temps rel.
De mme, nous avons vu quelles taient pour la plupart inadaptes aux rseaux trs hauts
dbits car pas capables de capturer les paquets qui arrivent la vitesse du lien. De fait, nous
avons du nous orienter vers des solutions partir de cartes de capture ddies, et notamment
les cartes DAG. Ce choix prsente galement lavantage, tant donn ltat du march actuel
autour de ce genre dquipements, dtre presque un standard de fait. Tous les logiciels que
nous dveloppons pourront donc tre utiliss par la presque totalit de la communaut
mtrologie, et nous pourront de mme bnficier des dveloppements faits par dautres.

3.2.1. La solution DAG


Pour rpondre aux besoins (transparence, prcision temporelle, temps universel)
noncs dans la partie 2.2.2, la solution existante la mieux adapte est indniablement une

18
solution base sur les cartes DAG conues et dveloppes luniversit de Waikato en
Nouvelle-Zlande et, lheure actuelle, commercialises, maintenues et amliores par la
socit ENDACE. Le principe de fonctionnement des sondes DAG est dcrit sur la figure 2.
Le premier avantage de cette carte est de pouvoir travailler en drivation du lien analyser.
Ainsi, dans le cadre de rseaux sur fibres optiques, le principe de branchement de la sonde
consiste insrer un splitter optique qui laisse passer 80 % de la puissance optique sur la
fibre originelle (chemin normal), et rcupre 20 % de cette puissance destination de la sonde
DAG. Ainsi, le trafic nest absolument pas perturb, aucun dlai nest introduit au niveau du
splitter 12 et le trafic conserve donc les mmes caractristiques et profils. Le systme de
mesure est ainsi totalement transparent.
De son ct, la carte DAG est une carte ddie qui ralise, en temps-rel, lextraction
des enttes de tous les paquets qui passent sur le lien. La taille de lentte est prcise au
moment de la configuration de la carte pour la capture. Dans notre cas, nous souhaitons
pouvoir capturer les enttes IP et TCP (ce qui nous loigne a priori de certains problmes
juridiques qui peuvent se poser lorsque lon capture un chantillon plus grand de chaque
paquet). Enfin, pour chaque paquet captur, la carte ajoute une estampille code sur 64 bits
lentte capture. Le tout est ensuite stock sur disque. Il est noter que les traces ainsi
constitues deviennent rapidement trs volumineuses, surtout sur les rseaux hauts dbits, et
ncessitent donc dutiliser des disques de grandes capacits et en nombres suffisants. Toutes
les machines sont donc quipes de 3 disques durs de 73 Go.
Pour la mme raison, le trafic qui transite entre la carte DAG et le disque dur de la
station hte est trs lev, et pour les rseaux aux capacits les plus fortes, les bus PCI
classiques des ordinateurs habituels ne suffisent pas. Il est ncessaire dans ce cas dutiliser la
dernire gnration de bus PCI, savoir les bus 64 bits 66 MHz qui offrent des bandes
passantes bien suprieures aux bus PCI traditionnels de 32 bits cadencs 33 MHz. Tous ces
lments (carte ddie temps-rel, bus haute capacit, mmoire importante et disques durs de
grandes capacits) sont les lments indispensables pour garantir un systme bien
dimensionn capable de capturer une trace de tous les paquets ayant transit sur le lien mesur.
En ce qui concerne lestampille de passage de chaque paquet, stocke avec lentte du
paquet, une rfrence GPS est utilise. La carte est en effet directement relie une antenne
GPS. Ainsi, lhorloge de la station qui hberge la carte DAG est resynchronise chaque
seconde sur un signal GPS qui transporte le temps universel venant des horloges atomiques de
rfrence. Ainsi, la drive de lhorloge est quasiment inexistante, garantissant une grande
prcision des mesures temporelles, ainsi que le temps universel, car les sondes seront
effectivement synchronises sur le temps de rfrence universel.

12
Dailleurs, le splitter est un lment compltement passif bas sur des jeux de miroirs qui ne sont mme
pas aliments lectriquement, garantissant ainsi un fonctionnement normal mme en cas de panne dlectricit.

19
horloge
GPS

Carte DAG

Matrice
De disques
Ethernet

splitter
optique

Tampon mmoire principal

lien

Figure 2. Principe opratoire des cartes DAG

Respectant ces principes de conception, la sonde conue pour capturer le trafic sur un
lien Giga-Ethernet est dtaille sur la figure 3.

Poweredge 1650
Rack 1U avec
Bi-Pentium III 1.4 Ghz
RAM: 2 GB DAG 4.2e
HD: 3 x 73 GB Dual 1000baseSX 850 nm
Slot PCI : 64 bits / 66 MHz 64 bits / 66 Mhz bus interface
Archivage : DLT1

96042-GIG-20
Rpartition 80/20
SX multimode 850 nm

Figure 3. Conception de la sonde de mtrologie passive pour un lien Giga-Ethernet (le


modle de la station de travail qui accueille la carte DAG est naturellement la discrtion de
lutilisateur. Nous indiquons le modle exact que nous utilisons pour situer le niveau de
performance requis, mais nimporte quelle autre machine de puissance et de qualit de
communication interne quivalentes ou suprieures sera satisfaisante)

20
De la mme faon, la sonde pour capturer le trafic sur des rseaux Fast-Ethernet est
dtaille sur la figure 4. A noter que dans ce cas, le support physique est de la paire torsade.
Il ny a donc pas de splitter , inutile avec les proprits naturelles de propagation de
llectricit, et un systme de bypass le remplace pour garantir un bon fonctionnement du
rseau mme si la sonde sarrte.

Poweredge 1650
Rack 1U
Bi-Pentium III 1.4 Ghz
RAM: 2 GB
HD: 1 x 73 GB
+ 2 x 73 GB (RAID 0)
Archivage : DLT1

avec

DAG 3.5e
10/100Base-T
(avec splitter intgr)

Figure 4. Conception de la sonde de mtrologie passive pour un lien Fast-Ethernet (le modle
de la station de travail qui accueille la carte DAG est naturellement la discrtion de
lutilisateur. Nous indiquons le modle exact que nous utilisons pour situer le niveau de
performance requis, mais nimporte quelle autre machine de puissance et de qualit de
communication interne quivalentes ou suprieures sera satisfaisante)

Enfin, pour analyser les traces captures par les sondes, une plate-forme de stockage
des traces et danalyse a t conue et mise en place. Cette plate-forme est hberge au LAAS
Toulouse et ouverte aux partenaires de METROPOLIS. Les besoins de cette plate-forme
sont donc essentiellement une grande capacit de stockage, et une grande capacit de
traitement (processeurs et mmoire essentiellement). Cette plate-forme est donc compose de
2 PowerEdge 4600 dont les caractristiques sont :

Poweredge 4600
Rack 6U
Bi-Pentium Xeon 2.4 Ghz
RAM: 8 GB
HD: 8 x 73 GB
Archivage : DLT1
Dautre part, il a fallu penser un systme pour rapatrier les fichiers de traces des
sondes de mesures vers la plate-forme danalyse. La solution idale aurait t de pouvoir
utiliser les rseaux acadmiques, mais face la charge supplmentaire quauraient reprsente
ces transferts, certains rseaux acadmiques auraient eu du mal tenir. Il a donc t dcid
dquiper toutes ces machines avec des lecteurs de bandes au format DLT1, et nous faisons
ces transferts en envoyant les bandes par les services postaux ou les transporteurs rapides.

21
Cette solution a aussi lavantage de pouvoir utiliser les bandes comme systme darchivage
des traces que nous nutilisons plus pendant quelques temps, ce qui a permis de rduire la
capacit des disques de la plate-forme danalyse, et de rduire sensiblement son prix.

3.2.2. Carte de dploiement des sondes DAG


Nous avons demand plusieurs responsables des rseaux acadmiques franais
lautorisation de dployer nos quipements de mesure sur le rseau quils oprent. Notre
objectif tait de pouvoir dployer ces sondes sur des rseaux de natures diffrentes, soit sur le
rseau de cur, sur les rseaux rgionaux et la sortie des laboratoires. Toutes les
autorisations ne nous ont pas t accordes pour des raisons sur lesquelles nous reviendront
plus loin. Toutefois, aujourdhui, 5 sondes DAG ont t dployes. Ainsi, comme le montre la
figure 1, deux sondes en Fast-Ethernet ont t positionnes la sortie de deux grands
laboratoires que sont le LAAS (figure 5) et le LIP6 (figure 6). La troisime sonde en Giga-
Ethernet a, quant elle, t positionne la sortie du rseau de Jussieu sur RAP (figure 7),
nous permettant ainsi davoir accs aux traces du trafic dun rseau trs haut dbit. Une
autre sonde Giga-Ethernet a plus rcemment t installe la sortie du rseau de lENS Lyon,
et une autre en Fast-Ethernet la sortie du lien daccs de lIUT GTR de Mont-de-Marsan
Renater (via luniversit de Pau).

REMIP 2000 RENATER 2


Paris
Montpellier
Sciences Sociales ENSEEIHT
GigE GigE 155/75 Mbps
Black Black CISCO 7206 155 Mbps
Diamo Diamo
GigE nd nd GigE
NRD

GigE CICT GigE


Black Black GigE
Diamo GigE GigE Diamo
nd
CERFACS GigEnd GigE
RESEAU
RESEAU LAAS
MULTIMEDIA PRINCIPAL
GigE GigE Grand Campus
Ehternet commut
Summ Summ
it it
GigE CISCO
GigE 7204
CICT Eth Eth Switch Eth
Alpine Ethernet P550
Sonde QoSMOS
100Mb/s
IUFM
IPBS RESEAU DMZ
Sonde de mtrologie 100 Mbps
ENSCT UPS INSA DR/CNRS
LAAS

Figure 5. Schma de dploiement sur la plate-forme toulousaine

22
Mtrologie FastE

Figure 6. Schma de dploiement au LIP6

Mtrologie GigE

Figure 7. Schma de dploiement Jussieu

3 sondes QoSMOS Traffic Designer ont galement t installes au LAAS, LIP6 et


lENST. Le choix de positionnement des sondes de mtrologie passives microscopiques
(systme DAG) est aussi stratgique par rapport au positionnement des sondes de mtrologie
passive macroscopique et de sondes de mtrologie active. Ainsi, il sera possible, pour un
mme trafic de corrler les analyses micro- et macroscopiques, ainsi que les mesures actives

23
et passives, et ce en plusieurs points du rseau et ce sur leur chemin entre Toulouse et Paris.
Enfin, nous rappelons que la plate-forme danalyse est hberge par le LAAS Toulouse.

Au del de ces problmes techniques, une nouvelle contrainte venant des


administrateurs des rseaux qui hbergeaient nos sondes est apparue. Au del de la non
intrusivit de nos sondes qui a rapidement t avre et donc garantissant que les
performances des rseaux dont le trafic tait analys ne seraient pas perturbes, les
administrateurs ont demand ce que les traces soient anonymes. Dailleurs, les refus que
nous avons essuys parfois lors de nos demandes dinstallation de sondes sur certains rseaux
ont t motivs par laspect confidentiel des communications. Rendre les traces anonymes
signifie que les adresses des sources et destinations des paquets dont nous capturons les
enttes soient anonymises, de faon ne pas pouvoir savoir quels en taient les auteurs et
destinataires. De plus, lanonymisation ncessite la suppression des donnes utilisateurs
contenues dans la partie applicative de chaque paquet de donnes prlevs sur le rseau.
Naturellement, ces informations portent un certain nombre dinformations qui peuvent tre
utiles pour dcouvrir les topologies des rseaux, les usages que font certains du rseau, les
protocoles de routage, etc. De tels aspects ne pourront donc pas tre traits. Toutefois, pour
pouvoir tout de mme ne pas trop limiter les analyses et tudes que lon peut faire partir des
traces captures, il nous a fallu mettre en place un mcanisme danonymisation des adresses
dterministe (pour pouvoir continuer reconnatre les flux de lInternet par exemple) et
surtout qui ne casse pas la structure des adresses, dont les diffrents octets ne sont pas
attribus de faon alatoire. Un algorithme dcrit dans [XU 01] [XU 02] a ainsi t mis en
place non sans difficult, en particulier cause du nouveau format de stockage des traces
DAG, qui est dans cette nouvelle version des cartes DAG un format dynamique. Il faut
toutefois noter que lanonymisation ne satisfait pas tous les administrateurs de rseaux
acadmiques car malgr tout on connat la provenance des traces, et les rsultats obtenus
pourraient mettre en vidence les comportements dune communaut assez rduite et
identifiable.

4. Analyse du trafic Internet


Nous disposons maintenant dune plate-forme de mtrologie qui nous permet de raliser des
mesures de paramtres simples comme le dbit, les dlais, les taux de perte, etc. et de capturer
des traces de trafic dont chaque chantillon aura une taille plus ou moins importante selon le
type dinformation recherche. Toutefois, comme cela a t prsent dans lintroduction, tout
ceci ne donne quune vision superficielle du rseau, de son comportement et des services quil
offre. En aucun cas, cela ne donne des informations sur le fonctionnement des diffrents
composants du rseau comme les routeurs, les protocoles, etc. Or pour les ingnieurs,
administrateurs et chercheurs en rseau, cest bien la mcanique du rseau et de ses
composants qui est importante et quil est ncessaire de mettre en vidence. Les mesures et
captures de trafic effectues ne sont que le rsultat des effets des mcanismes et composants
du rseau. En fait, le problme le plus important et le plus complexe rsoudre en mtrologie
des rseaux de communication consiste dterminer partir de lobservation des effets
externes les causes internes (les mcanismes protocolaires) qui en sont responsables.
Cest donc au travers de la caractrisation et lanalyse des rsultats de mesure et des
traces de trafic quune telle tche pourra tre ralise. Nous insistons dailleurs sur le fait que
cest l aujourdhui le principal point dur de la mtrologie et de ltude du trafic. Certes, tous
les problmes au niveau de la mesure physique des paramtres simples nont pas encore t
rsolus, mais cest au travers de lanalyse que la mtrologie pourra vraiment atteindre les
objectifs que nous avons fixs pour elle. Cette partie de larticle va donc se focaliser sur ces
problmes de caractrisation et danalyse du trafic, mme si dans ce domaine les chercheurs

24
nen sont quau tout dbut de leurs travaux et ttonnent encore. Nous allons toutefois
prsenter les mthodes danalyse qui ont aujourdhui donn le plus de rsultats significatifs et
qui ont permis de progresser dans la connaissance et la comprhension de lInternet et de ses
mcanismes protocolaires et architecturaux.

En particulier, un des lments cls, et qui reste aujourdhui un des seuls lments de
conclusion quant lanalyse du trafic, cest laspect multi-chelles qui semble dterminant
mais aussi des plus complexes mettre en uvre pour lanalyse du trafic. Comme cela a t
prsent dans la partie 1.1, il existe diffrents niveaux dtudes du trafic, des bits ou octets
jusquaux sessions, en passant par les flux. Or chaque niveau correspond des granularits
diffrentes et le traitement de ces diffrents lments du rseau a donc des impacts sur des
chelles temporelles diffrentes. De plus, les flux (ou les sessions) ont des tailles variables, et
ont donc des consquences sur des chelles de temps variables. Cest l la principale difficult
pour lanalyse du trafic qui doit tre multi-chelles. Cest l aussi une des caractristiques qui
diffrencie la mtrologie des rseaux de communication des mesures physiques en gnral. En
physique, une granularit dtude et un point de vue, cohrents par rapport lchelle du
mcanisme que lon veut observer, est choisie une bonne fois pour toute, et lanalyse est faite
avec cette granularit. En mtrologie des rseaux, toutes les chelles de temps sont
indissociables, et toutes les granularits danalyse doivent tre considres en mme temps.
Cela rajoute naturellement une dimension la complexit des analyses, et ncessite de fait des
outils mathmatiques complexes que nous allons maintenant introduire.

4.1. Trafic Internet et notions associes


Les premires tudes mtrologiques sur le trafic Internet menes partout dans le monde ont
globalement montr que ce dernier est particulirement instable, cause des proprits d'auto-
similarit et de dpendance long terme appele aussi (LRD) [LEL 93]. Il est aussi montr
que la distribution queue lourde est trs implique dans ces proprits [WIL 98]. Avant de
dtailler dans la suite de ce chapitre toutes ces caractristiques du trafic Internet et den
analyser les causes, il est ncessaire d'introduire les notions mathmatiques associes aux
diffrents comportements observs dans le rseau.

4.1.1. Fonction d'auto-corrlation


Avant de prsenter cette fonction mathmatique, il faut dfinir les notions d'indpendance et
de corrlation :

- X, Y sont deux v.a. indpendantes ssi


P(X<x Y<y) = P(X<x).P(Y<y)

- X, Y sont deux v.a. dcorrles ssi


E(XY)=E(X).E(Y)

En pratique, on dispose de N mesures. La fonction d'auto-covariance se calcule comme la


fonction de covariance entre deux sries. La seconde srie est ici la mme que la premire
mais dcale d'un nombre K d'lments. La fonction d'auto-covariance CK s'crit alors :

K
1 N k
C = ( ( x)( xt + k x)
K
k =0 N k t = 0 xt

25
o x reprsente la moyenne de la srie de points.

- Interprtation des rsultats


Une caractristique des lois et des distributions que l'on peut calculer partir des traces
rseaux est d'avoir une fonction d'auto-corrlation spcifique. En effet, elle traduit une
corrlation persistante dans le temps13 ainsi que la prsence de dpendance long terme entre
les objets analyss (les paquets TCP la plupart du temps). Ainsi, il est ncessaire de pouvoir
calculer de faon systmatique la fonction d'auto-covariance d'une srie reprsentant ses
caractristiques d'auto-corrlation. Pour ce qui est de l'interprtation de l'auto-corrlation
d'une srie, on considre que la covariance est nulle lorsque la corrlation empirique (donn
Auto cov( K ) 2 2
par le graphique de ) est contenue entre et (n tant le nombre de
Auto cov(0) n n
points sur lesquels on calcule la fonction d'auto-corrlation). Il s'agit de l'application du
thorme de la limite centrale avec des hypothses gaussiennes. Cela correspond un
intervalle de confiance de 95 % (cf. [DAC 94]). La courbe reprsentant l'auto-corrlation
s'analyse en ayant au pralable calcul l'intervalle de confiance dans lequel la fonction doit se
situer. Si la courbe dpasse cet intervalle, il existe de la corrlation. C'est une premire
information pour mettre en vidence dans un deuxime temps la prsence de LRD dans la
srie analyse. En effet, on parle de LRD dans la srie quand la corrlation reste prsente pour
une valeur de K grande.

4.1.2. Processus dpendance longue (LRD)


Un processus dpendance longue ou mmoire longue signifie que la dpendance entre
deux variables du processus ne diminue pas trop rapidement avec l'loignement temporel. La
dfinition mathmatique introduite par [COX 84] est prsente ci-dessous :

Soit X=Xt un processus stochastique ( covariance) stationnaire temps discret, on dit que Xt
est mmoire longue s'il satisfait les proprits suivantes :



- t =0
(t ) = ( est la fonction d'auto-corrlation),
- La densit spectrale S est singulire14 l'origine,
- m.varXm quand m

Un processus dpendance longue possde la proprit suivante :

ct O<<1 ( est la fonction d'auto-correlation).


(t ) t

Ainsi la fonction d'auto-corrlation dcrot hyperboliquement.

La dpendance long terme a t dcouverte en premier par Hurst qui la dfinit comme un
processus ayant une fonction d'auto-corrlation non sommable (premire proprit) et

13
La fonction d'auto-corrlation ne se situe pas dans l'intervalle de confiance pour K grand (suprieur 5000 :
cette borne a t dfinie de manire empirique grce aux calculs qui sont dtaills dans [LAR 02]).
14
Une fonction f est dite singulire en un point a si elle n'est pas explicitement dfinie en ce point ( cause par
exemple d'une division par zro si x = a ou dans le cas d'une fonction dfinie sur un ensemble topologiquement
ouvert, d'un point a qui est la frontire de l'ensemble de dfinition de la fonction - C'est le cas de la fonction
ln(x) lorsque x=0).

26
15
caractrise par un paramtre H, dfini par la formule H = 1 , et appel paramtre de
2
Hurst. En 1993, Leland, Taqqu, Willinger et Wilson ont mis en vidence la LRD pour des
sries temporelles de paquets Ethernet. Depuis, une multitude de travaux et d'articles ont trait
de la dpendance long terme du trafic Internet (voir [WIL 98], [VER 00b], [PAR 96] et
[DOW 01]). Nous y reviendrons dans les sections suivantes.

4.1.3. Distribution dcroissance lente


Plusieurs travaux de recherches (voir [WIL 98], [VER 00b], [PAR 96] et [DOW 01]) ont
dmontr que la distribution queue lourde pour certaines caractristiques du trafic
(distribution des tailles de fichiers, des dures de transfert) est l'une des principales causes
de LRD du trafic Internet.
Une distribution est queue lourde si sa fonction de distribution a la proprit
suivante :

x , ]0,2[

P[ X > x] t

En d'autres termes, la forme asymptotique de la distribution queue lourde suit une loi
exponentielle avec infrieur 2.

On l'appelle queue lourde car, compare la distribution exponentielle et la distribution


normale, une variable alatoire qui suit une distribution queue lourde peut montrer pour des
trs grandes valeurs de X une probabilit P[X] suprieure celle obtenue pour une distribution
exponentielle quivalente. Cette variable a une variance infinie si ]0, 2[ et une moyenne
infinie si ]0, 1[.

4.1.4. Processus auto-similaire


L'auto-similarit est une notion trs importante dans la caractrisation du trafic Internet. En
effet, la nature du trafic de donnes en gnral, celui d'Internet plus particulirement, prsente
un aspect auto-similaire. Il s'agit de la manifestation du phnomne suivant : la structure des
variations d'amplitude du signal analys (par exemple le nombre d'octets transfrs par unit
de temps) se reproduit de manire similaire quelle que soit la finesse temporelle avec laquelle
il est reprsent. Ainsi, le comportement d'un trafic auto-similaire est l'oppos de celui d'un
trafic poissonnien, dont les variations d'amplitude sont filtres au fur et mesure que l'on
augmente la taille de la fentre d'observation [PAX 95]. Il existe diffrentes dfinitions
mathmatiques de l'auto-similarit. La suivante concerne les processus temps continu :
Un processus X(t) est dit auto-similaire de paramtre H R, si et seulement si pour tout
c > 0, cHX(t) et X(ct) possdent les mmes distributions jointes tous les ordres. Ainsi pour
tout entier n, t1, ... , tn, x1, ... , xn :

P(X(t1) x1, , X(tn) xn) = P(X(ct1) cHx1, , X(ctn) cHxn)

Cette dfinition signifie que si l'on modifie l'chelle sur laquelle on observe le processus par
un facteur positif c et que l'on zoome le mme processus par ce facteur lev la
puissance H, alors l'allure des deux processus obtenus est la mme. Par consquent, il n'y a
pas une stabilisation vers une moyenne comme dans le cas du processus de Poisson.

15
tant le coefficient de la fonction d'auto-corrlation [BER 94].

27
4.2. Analyse par dcomposition en ondelettes du trafic
Ainsi, ces premiers rsultats de caractrisation du trafic Internet confirment la nature de
nombreux phnomnes se produisant avec des granularits diffrentes (e.g. lauto-similarit),
et ncessitent donc de mettre en uvre une mthode danalyse multi-chelles. La technique
qui est aujourdhui la plus utilise pour une telle analyse multi-chelle nous vient du domaine
du traitement du signal. Il sagit danalyse base dondelettes que nous allons dcrire et
illustrer dans la suite.

Rappelons dabord le principe des ondelettes (voir [MAL 99] pour une introduction
complte). 0 reprsente londelette-mre. (t ) = 2 _ j / 2 (2 j t k ) reprsente sa forme
j ,k 0

dilate et translate et dX(j, k) = j,k, X0 les coefficients dondelette correspondants.


Londelette-mre 0 est aussi caractrise par un entier N 1, le nombre de moments
vanescents qui joue un rle cl dans lanalyse pratique et thorique de la longue mmoire.
Pour tous les processus X stationnaires au second ordre, son spectre fX() peut tre exprim
laide de ses coefficients dondelette par lquation :
2
E (d X ( j , k ) 2 ) = f ( )2 j 0 2 d
j
X

o 0 est la transforme de Fourier de 0 et E lesprance mathmatique. Si X est un


processus dpendant long terme de paramtre d, cela implique que :
E (d X ( j , k ) 2 ) C 2 j ( 2 d +1) , si 2j+

De plus, il a t prouv que {dX(j, k), k Z} forment une squence dpendante court terme si
N > d + 1/2. Cela signifie quils ne souffrent pas des difficults statistiques dues aux
proprits de longue mmoire. En particulier, les moyennes temporelles
2

S = 1/
j n d
j
nj ( j , k ) peuvent tre utilises comme des estimateurs efficaces et robustes
k =1 X
2
pour E (d ( j , k ) ) .
X
Ceci conduit la procdure destimation suivante : une rgression
linaire pondre de log2Sj par rapport log22j = j, ralise la limite de la granularit dtude
la plus grande, fournit une estimation de 2d+1, et par consquent de d. Les reprsentations
graphiques de log2Sj en fonction de log22j = j sont communment qualifies de diagrammes
logarithmiques (LD : logscale diagrams) destimation de la LRD, comme par exemple le
diagramme de la figure 9. La possibilit de faire varier N apporte de la robustesse ces
procdures danalyse et destimation. La dfinition complte ainsi que les performances de
cette procdure destimation sont dtailles dans [ABR 00] [ABR 98] [VEI 99].

Pour ceux que les quations rebutent, et pour visualiser le principe de lanalyse du
trafic par dcomposition en ondelettes, nous lillustrons sur la figure 8. Ainsi, la proprit
dauto-similarit du trafic signifie que le schma oscillant du trafic Internet se produit toutes
les chelles de temps. Il est donc important pour analyser le trafic de disposer dun outil
capable danalyser le comportement du trafic, et notamment ses variations, toutes les
chelles de temps, i.e. pour toutes les granularits. Pour cela, nous avons utilis une analyse
en ondelettes [ABR 98]. La fonction en ondelettes a t slectionne car elle reprsente bien
les variations du trafic, et ce quelles que soient leurs dure dans le temps (la preuve est
visuelle sur la figure 8). Le principe de cette analyse consiste extraire du trafic toutes les
ondelettes possibles. Pour cela, nous utilisons plusieurs fonctions en ondelettes chacune de
frquence diffrente afin d'obtenir les diffrentes granularits temporelles dobservation. Les
fonctions avec les priodes les plus larges reprsentent les plus longues vagues, c'est dire
celles gnres par les flux lphants.

28
chelle (s)

temps (s)

Figure 8 : Analyse en ondelettes de la LRD du trafic Internet

La courbe de la figure 9 a t obtenue en utilisant l'outil LDEstimate [ABR 98] qui


estime la LRD qui se manifeste dans le trafic toutes les chelles temporelles. Le rsultat
produit par cet outil est une reprsentation graphique en chelle logarithmique des lois qui
rgissent le niveau de dpendance du trafic diffrentes chelles temporelles. Il est obtenu
grce lanalyse en ondelettes du trafic Internet que nous venons de prsenter et reprsente le
niveau de variabilit des oscillations en fonction de la granularit d'observation. Le facteur de
Hurst (caractristique des processus auto-similaires qui se retrouvent dans le trafic Internet, cf.
[PAR 00]) est obtenu directement sur la courbe de LRD en mesurant sa pente. La figure 9
montre un comportement diffrent pour deux chelles temporelles (appel phnomne de bi-
scaling ). La frontire entre ces deux niveaux de LRD se trouve autour de l'octave 8 (ce qui
correspond 28 units de temps, soit ici environ 250 ms) et met en vidence des niveaux de
LRD diffrents pour les chelles de temps courtes et longues, ceci se traduisant par diffrentes
lois de puissance. Pour les chelles petites (octave < 8), c'est dire les paquets proches les uns
des autres, la dpendance est peu marque. Par contre, pour les chelles plus grandes octave >
8), c'est dire des paquets plus loigns, la dpendance est beaucoup plus importante. Il est
important de noter ici que toutes les analyses de traces de trafic qui ont t faites de par le
monde, et ce que les traces proviennent de nimporte quel type de rseau, indpendamment de
la priode de la journe, ont montr le mme phnomne de bi-scaling. Il semble donc que
lon ait affaire une signature significative et robuste du trafic quil faudra analyser plus en
dtail. Nous approfondissons maintenant ce phnomne et essayons den dcouvrir les causes
avec des analyses complmentaires, et notamment une analyse fine de la rpartition du trafic
par application (rpartition faite par loutil QoSMOS Traffic Designer) et une tude de la
taille des flux contenus dans le trafic (puisquon a vu quelle pouvait influer sur lauto-
similarit et la dpendance longue du trafic).

29
Figure 9 : Evaluation de la LRD dans le trafic Internet

4.3. Analyse des phnomnes de dpendance longue dans le trafic


4.3.1. Tendance dvolution du trafic
Commenons cette partie par dcrire l'volution de la distribution du trafic par application
mesure dans l'Internet ces dernires annes. La figure 10 illustre cette distribution mesure
en mai 2000 sur le rseau SPRINT. La grande proportion reprsente par le trafic HTTP (plus
de 75 % du trafic Internet) est remarquable. On note aussi que les principales applications
standards sont reprsentes : web, web scuris, courriel, ftp ou news. Cependant, de
nouvelles applications mergentes ( cette poque) sont prsentes : flux de streaming
multimdia (comme MediaPlayer ou RealAudio) ou jeux distribus en rseau (comme Quake).
Nanmoins, la caractristique la plus importante de ce trafic reste son lasticit et ses
contraintes temporelles de QdS qui ne sont pas importantes (pour la grande majorit de ses
applications).

Main TCP applications throughputs (SPRINT)


30000

25000
Other
Telnet
Throughput (kbits/s)

20000
RealAudio
MediaPlayer
15000
Quake
NNTP
10000 SMTP
FTP
5000 HTTPS
HTTP
0
10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
Time

30
Figure 10. Rpartition du trafic sur le rseau SPRINT (mai 2000) les applications sont
classes dans le mme ordre sur la lgende et dans le graphique}

Trois mois plus tard, la distribution tait peu prs la mme l'exception d'une nouvelle
application, la deuxime en partant du haut sur le graphique de la figure 11, qui est devenue,
en quelques semaines, l'une des applications majeures de l'Internet. Il s'agissait de Napster,
affuble du terme application tueuse car, en l'espace de trois mois, elle reprsenta entre 20
et 30 % du trafic. Ce type d'application P2P connut, au fil du temps, un succs de plus en plus
important auprs des utilisateurs, reprsentant ainsi une part de plus en plus importante du
trafic au sein de l'Internet. Bien que Napster et quelques dboires avec la justice amricaine,
elle a ouvert la voie tout un ensemble d'applications P2P comme Gnutella, E-donkey,
Morpheus et d'autres.

Main TCP applications throughputs (SPRINT)


40000
35000
Other
T h ro u g h p u t (k b its /s )

30000 Telnet
25000 RealAudio
MediaPlayer
20000
Quake
15000 Napster
10000 NNTP
SMTP
5000 FTP
0 HTTPS
HTTP
1: 0
00
3: 0
00
5: 0
00
7: 0
00
9: 0
00
1 1: 0 0
1 2: 0 0
1 3: 0 0
1 4: 0 0
1 5: 0 0
1 6: 0 0
1 7: 0 0
1 8: 0 0
1 9: 0 0
2 0: 0 0
2 1: 0 0
2 2: 0 0
2 3: 0 0
0: 0
0

0
:0

2:

4:

6:

8:
10

Time

Figure 11. Rpartition du trafic sur le rseau SPRINT (aot 2000) les applications sont
classes dans le mme ordre sur la lgende et dans le graphique}

En effet, trois ans plus tard, le trafic P2P n'a cess d'augmenter et l'heure actuelle, sur
certains liens du rseau Renater, il peut reprsenter la mme proportion que le trafic HTTP (cf.
figure 12). Bien sr, Napster a t remplac par Kazaa ou E-donkey. Une telle augmentation
du trafic P2P a irrmdiablement eu un impact sur les caractristiques du trafic global,en
particulier, cause de la nature des fichiers changs (la plupart du temps de la musique ou
des films) qui sont comparativement beaucoup plus longs que les flux du trafic web, le trafic
majoritaire quelques annes auparavant.

31
Dbits des principales applications Internet
(rseau ReNatER)

Figure 12. Rpartition du trafic sur le rseau RENATER (mai 2003) - les applications sont
classes dans l'ordre inverse sur la lgende et dans le graphique}

En fait, cette augmentation du trafic P2P couple la prsence du trafic classique induit les
caractristiques suivantes :
- Le trafic Internet est toujours compos de milliers de petits flux appels souris (imputables
principalement au trafic web ainsi qu'au trafic de contrle P2P),
- Un nombre de flux lphants qui ne cesse d'augmenter.

A tel point que la distribution de la taille des flux dans l'Internet change de faon importante.
Ce phnomne a t analys depuis le dbut des annes 2000 et les rsultats sont prsents
dans la figure 13. La distribution exponentielle (celle possdant la queue la moins lourde), sert
de rfrence car elle est proche du modle de Poisson16. Nous pouvons voir sur cette figure
que la proportion de trs longs flux a augment de faon trs importante depuis l'an 2000. Si
en 2000, cette distribution n'tait pas trs loigne d'une exponentielle, ce n'est plus du tout le
cas l'heure actuelle. Au contraire, elle dispose d'une queue trs lourde et est trs loigne de
la distribution exponentielle.

16
Ce modle est utilis comme rfrence dans la majorit des cas lorsqu'il s'agit de raliser des simulations ou
des valuations de performance en rseau.

32
%

Exponentielle
100 aot 2000
90 dcembre 2003
80
70
60
50
40
30
20
10

20 40 60 80 100
Nb de paquets / flux

Figure 13. Evolution de la distribution des tailles de flux dans l'Internet entre 2000 et 2003

4.3.2. Mise en vidence de la dpendance longue dans le trafic


En revenant lvolution majeure du trafic Internet qui consiste en un nombre de plus en plus
grand de flux longs, la figure 14 illustre les modifications que nous pouvons observer. Pour
cela, elle compare le trafic Internet actuel avec un trafic qui suit un modle de Poisson. Ces
deux trafics sont observs diffrentes granularits (0,01 s, 0,1 s et 1 s) et il est facile de
remarquer que le trafic Internet ne se lisse pas aussi vite que le trafic Poissonnien.
L'analyse a montr que ce rsultat est totalement d aux lphants prsents dans le
trafic Internet. En effet, la transmission d'lphants cre dans le trafic l'arrive d'une grande
vague de donnes qui a la particularit de durer un temps relativement long (plus d'une
seconde17). C'est pour cela que l'on observe cette diffrence entre les deux types de trafic : la
transmission des lphants induit des oscillations persistantes dans le trafic actuel.

17
Les flux web sont traditionnellement transmis en moins d'une seconde dans l'Internet actuel.

33
Figure 14 : Comparaison entre les oscillations observables dans un trafic Internet et un trafic
Poissonnien. Cette tude ralise dans le cadre de METROPOLIS se base sur du trafic dune
plaque ADSL de France Tlcom.

De plus, les connexions TCP utilises pour transmettre les flux lphants plus
volumineux durent plus longtemps et la dpendance qui existe entre les paquets d'une mme
connexion se propage ainsi sur des chelles de temps plus longues. C'est ce phnomne que
l'on nomme traditionnellement LRD. On lui attribue plusieurs causes dont la principale est
imputable aux mcanismes de contrle de congestion de TCP (le protocole dominant de
l'Internet). Parmi tous les mcanismes de TCP, il est vident que celui bas sur un contrle en
boucle ferme introduit de la dpendance court terme, tant donn que les acquittements
dpendent de l'arrive d'un paquet, et que l'mission de tous les paquets suivants de la
connexion est conditionne par cet acquittement. De la mme faon, les deux mcanismes de
TCP ( slow-start et congestion avoidance ) introduisent de la dpendance plus long
terme entre les paquets de diffrentes fentres de congestion. Ainsi, en gnralisant ces
observations, il est vident que tous les paquets TCP d'une connexion sont dpendants les uns
des autres. En plus, l'augmentation des capacits des liens de l'Internet en permettant la
transmission de flux de plus en plus longs, augmente le phnomne de LRD. C'est pourquoi
on observe sur la figure 14, la persistance d'un comportement oscillatoire dans le trafic
Internet qui reste trs marqu mme avec une granularit d'observation importante (1 s).
Etant donn que le phnomne de dpendance de TCP se propage dans le trafic par
l'intermdiaire des flux (i.e. les connexions TCP) [VER 00], l'augmentation de la taille des
flux induit une augmentation de la porte de la dpendance qui peut atteindre des chelles trs
importantes. Ainsi, une oscillation au temps t induit alors d'autres oscillations d'autres
instants qui peuvent tre potentiellement trs loigns de t. D'autre part, il est vident que les
lphants, en raison de leur dure de vie trs importante dans le rseau et des grandes
capacits de ce dernier (la plupart du temps les liens tant sur-dimensionns), ont le temps
d'atteindre de grandes valeurs pour leur fentre de contrle de congestion. Ainsi, une perte
induit pour le flux qui la subit une importante diminution, suivie par une importante
augmentation de son dbit. L'augmentation de la taille des flux favorise donc les oscillations
avec une forte amplitude et un phnomne de dpendance long terme.
Bien sr, les oscillations sont trs nfastes pour une utilisation optimale des ressources
globales du rseau tant donn que la capacit libre par un flux subissant une perte ne peut
pas tre immdiatement utilise par un autre (en raison de la phase de slow-start notamment).

34
Ceci se traduit par un gaspillage de ressources et induit, une diminution de la QoS globale du
rseau. En fait, plus le trafic oscille, moins les performances sont importantes [PAR 97].

En revenant la courbe de la figure 9, obtenue en utilisant l'outil LDEstimate, et qui


estime la LRD qui se manifeste dans le trafic toutes les chelles temporelles, il est
maintenant possible dinterprter le rsultat de bi-scaling observ. Ainsi, pour les chelles
petites (octave < 8), c'est dire les paquets proches les uns des autres, la dpendance est peu
marque. Par contre, pour les chelles plus grandes octave > 8), c'est dire des paquets
appartenant des fentres de congestion conscutives, la dpendance est beaucoup plus
importante. Evidement, ce phnomne existe pour l'ensemble des fentres de congestion d'un
mme flux. Ainsi, la prsence dans le trafic de trs long flux introduit un phnomne de
dpendance trs long terme qui est visible sur la figure 12 pour les octaves trs grands (>
12). Ce niveau de LRD dans le trafic devient un problme majeur tant donn que chaque
oscillation se produisant un temps t peut se reproduire n'importe quel temps t' qui est
dpendant de t (en raison de la LRD qui existe entre les paquets changs par le biais des
protocoles traditionnels : ici TCP sur les longs flux). Il est intressant de noter que nos
expriences ont montr que le coude prsent sur la courbe de LRD correspondait la taille
moyenne des flux, la partie droite de la courbe correspondant donc l'impact des flux
lphants.

4.3.3. Dmonstration du rle de TCP sur la LRD


Lanalyse du trafic qui vient dtre dcrite, laquelle vient sajouter notre connaissance des
architectures et protocoles de lInternet sans oublier une part non ngligeable dintuition de
la part de chercheurs nous a permis de montrer leffet ngatif de TCP sur le trafic, lequel
TCP apparat comme inadapt pour transmettre des gros flux sur des liens trs hauts dbits.
Toutefois, en ltat actuel, ce rsultat, mme sil apparat cohrent, nest pas prouv. Mais
maintenant que lanalyse mtrologique nous a fait toucher du doigt les problmes que TCP
engendre avec le trafic actuel, il est facile de monter une exprimentation pour dmontrer ce
rsultat. Cest ce qui va tre fait dans la suite.

Evaluation de l'impact de TFRC sur la QoS


Ainsi, lanalyse prcdente nous amne penser que la LRD est un bon moyen de caractriser
la variabilit du trafic, en particulier dans sa persistance. Aussi, l'exprience qui va tre dcrite
dans la suite a pour objectif, sur un exemple, de montrer l'existence de ce lien entre les deux
aspects variabilit et LRD. Pour ce faire, l'exprience mene s'est propose de comparer au
travers de simulations NS le trafic rel avec le mme trafic re-simul (le principe de la
technique de rejeu est prsente dans [OWE 04a]), mais pour lequel le mcanisme de contrle
de congestion du protocole de transmission TCP a t remplac par TFRC [OWE 04b] [FLO
01]. L'objectif de TFRC par rapport TCP est de fournir des sources de trafic beaucoup plus
lisses et rgulires, c'est--dire des sources qui ne prsentent pas ou peu d'oscillations. Ce
mcanisme a t aussi dfini pour permettre un meilleur transfert du trafic gnr par les
applications de streaming dans l'Internet qui ncessitent naturellement un maximum de
rgularit pour leurs dbits d'mission et de rception. On montre ainsi que lorsque l'on
emploie TFRC, et donc quand on gnre un trafic rgulier et lisse, la LRD qui apparat dans le
rseau est trs rduite par rapport au cas o TCP est utilis.

Cette exprience dcrite plus prcisment dans [OWE 04b] a pour objectif de fournir
une tude comparative des caractristiques globales du trafic suivant que les lphants sont
transmis en utilisant TCP ou TFRC. Cette exprience vise aussi fournir des rsultats dans un

35
environnement raliste. L'tude comparative porte sur la trace originale d'une part et sur la
trace simule d'autre part dans laquelle les flux lphants sont transmis en utilisant TFRC.
Par rapport au thme de cette tude comparative qui vise tudier les effets de TFRC
sur le caractre oscillant du trafic, les paramtres qui vont tre valus sont les paramtres
traditionnels de dbit, mais aussi des paramtres statistiques du trafic comme la LRD, et
quelques paramtres mesurant le niveau de variabilit du trafic. Pour cela, nous utilisons un
coefficient de stabilit (SC) qui est dfini par le quotient :

trafic _ moyen _ chang


Coefficient _ de _ stabilit ( SC ) =
cart _ type _ du _ trafic _ chang ( )

La figure 15 prsente le trafic dans les deux cas d'tude soit le cas rel et le cas simul (avec
TFRC). Visuellement, il apparat clairement qu'en utilisant TFRC pour transmettre les
lphants la place de TCP, le trafic global est bien plus lisse et rgulier, et que tous les
grands pics de trafic que l'on peut voir sur le trafic rel ont disparu du trafic simul avec
TFRC.

Figure 15 : Evolution du dbit au cours du temps

Les rsultats quantitatifs sont prsents dans le tableau 1. Ils confirment que la variabilit du
trafic dans le cas du trafic rel (utilisant TCP pour transmettre les lphants) est bien plus
importante par rapport au cas simul dans lequel les lphants sont gnrs avec le protocole
TFRC (voir les diffrences sur les carts types et les coefficients de stabilit).
En ce qui concerne le dbit global, nous avons mesur des dbits assez proches dans
les deux cas. Ce rsultat est excellent pour TFRC qui est par dfinition born par le dbit
thorique de TCP. Il nest de plus pas conu pour consommer rapidement une grande quantit
de ressources [OWE 03a], et mme si TFRC est donc moins agressif que TCP, il est capable
d'atteindre quasiment le mme niveau de performance que TCP. Ceci confirme l'importance
de la stabilit du trafic pour obtenir des performances de haut niveau et optimises pour les
rseaux de communication [PAR 97].

Protocole Dbit moyen (ko) (ko) CS

36
TCP New Reno (NR) : cas rel 82,335 157,959 0,521
TCP NR & TFRC : cas simul 77,707 102,176 0,761

Tableau 1 : Caractrisation du dbit pour les protocoles TCP et TFRC

En ce qui concerne la LRD, la figure 16 montre que dans le cas simul la proprit de bi-
scaling est sensiblement rduite et la courbe, mme pour les grandes octaves a une pente peu
marque. Cela signifie que toutes les formes de dpendance, et en particulier celles long
terme ont t rduites de faon drastique. Les valeurs pour la LRD qui s'exprime l'aide du
facteur de Hurst sont: H(trafic rel) = 0.641 et H(trafic simul) = 0.194 (ce qui dans ce dernier
cas est non significatif, mais marque bien l'absence de LRD).

Figure 16 : Evaluation de la LRD pour le trafic simul incluant des lphants TFRC

La LRD : une mtrique caractristique de la QoS


Cette exprience a permis de mettre en vidence le lien troit qui existe entre la caractristique
oscillante du trafic et la LRD. En effet, partir du moment o on utilise pour transmettre les
flux lphants un protocole qui ne cre pas d'oscillations (TFRC) et qui brise le modle de
dpendance lors de la rcupration des pertes, la LRD disparat quasiment du trafic.
Ce rsultat d'analyse est important car il donne un outil pour caractriser
qualitativement et quantitativement un des phnomnes caractristiques du trafic Internet, qui
est de plus un lment dgradant de la performance du rseau. Surtout, il permet de donner
des directions de recherche pour trouver des parades ce phnomne, en particulier
concernant les protocoles de transport et leurs mcanismes de contrle de congestion.
Ce travail de caractrisation et danalyse par rapport ce qui se fait dans le domaine et
qui a juste pour vocation de trouver un modle mathmatique dcrivant le trafic Internet a
donc bien permis danalyser tous les phnomnes de variabilit du trafic de lInternet et de les
expliquer, mettant en cause notamment le comportement de TCP lorsquil est utilis pour
transmettre des flux lphants sur des rseaux hauts dbits. En connaissant maintenant les
mcanismes de TCP qui engendrent cette dynamicit dans son dbit dmission (conduisant
une inefficacit et une instabilit dommageable), nous avons maintenant les cartes en main
pour proposer des solutions pour viter la variabilit du trafic.

5. Conclusion
Cet article vient donc de dresser un panorama des activits de mtrologie dans les rseaux de
communication en gnral, et lInternet en particulier. En premier lieu, nous y avons dfini ce

37
qutait la mtrologie et avons situ son besoin au niveau de lingnierie et de la recherche en
rseau. Un des lments de la contribution de cet article et qui est un lment cl de la
mtrologie de lInternet a t de dcomposer les activits de mtrologie en deux parties :
une premire partie concerne la mesure et lobservation proprement parler des phnomnes
se produisant sur le rseau, que ce soit en termes de mesures de la QoS ou dobservation du
trafic transitant sur les liens ou dans le nuds du rseau. La seconde partie concerne la mise
en vidence au travers danalyses pousses de phnomnes invisibles que lon doit dduire
des phnomnes observs. Ces phnomnes sont naturellement assez peu explicites puisquils
rsultent de la superposition de trs nombreux mcanismes et protocoles, de multiples
applications, de comportements dutilisateurs divers et varis et de topologies de rseaux trs
diffrentes dun domaine (ou AS) lautre. En isoler les diffrentes composantes est donc
particulirement ardu et est aujourdhui lobstacle le plus important rencontr en mtrologie.
Larticle a donc prsent des outils de mtrologie actifs et passifs qui permettent de
rpondre aux besoins de mesure ou dobservation du trafic et de la QoS du rseau. Aprs avoir
dtaill ces besoins, et naturellement les points durs qui se prsentent, larticle a mis en
vidence les points de vue diffrents de chaque technique, et pour chacune delles, leurs
avantages et inconvnients. Ces outils de mesure, dont le descriptif pouvait paratre vague
dans leur prsentation gnrale, ont t illustrs sur ltude de cas que fut la mise en place
dune plate-forme de mtrologie en bordure du rseau Renater dans le cadre du projet
METROPOLIS. Il a ainsi t montr comment concevoir cette plate-forme pour rpondre
point par point aux besoins et rsoudre les points durs.
Ensuite, larticle sest focalis sur les problmes danalyse du trafic permettant disoler,
partir de lobservation deffets, les phnomnes et comportements invisibles du rseau.
Comme nous lavons dj dit plusieurs reprises, il sagit l du problme majeur quil reste
rsoudre, et ltat de lart est encore loin des objectifs. Larticle prsente toutefois une
mthode danalyse qui emprunte ses outils nos collgues du traitement du signal. Larticle a
ainsi montr que lon pouvait mettre en vidence la responsabilit de certains protocoles (ici
TCP) dans la limitation des performances et de la qualit des rseaux actuels. De plus, en
mettant ce problme en vidence, et grce lanalyse prcise qui a t faite des effets ngatifs
du protocole, la route suivre pour corriger ce mcanisme protocolaire est trace.

Cest donc bien le processus de recherche et dingnierie des rseaux qui est boulevers
par larrive rcente des activits de mtrologie. Comme nous venons de le voir, une analyse
hors ligne du trafic va permettre de modifier un des principaux protocoles de transport de
lInternet le protocole TCP afin de ladapter aux besoins actuels (qui ntaient pas ceux
quon lui demandait de remplir il y a plus de 20 ans, au tout dbut de lInternet). Ce travail est
en cours, notamment lIETF avec la conception du protocole DCCP [HAN 03]. Dailleurs,
dans ce processus de recherche et dingnierie des rseaux, la connaissance accrue que lon
gagne sur le trafic ou la topologie des rseaux permet de modifier notre faon de faire des
simulations ou des mulations. Ces simulations qui servent tester des ides de mcanismes,
de protocoles ou darchitectures que lon peut avoir vont donc pouvoir bnficier de cette
connaissance, car nous pourrons simuler des topologies et des trafics ralistes. Nos
mcanismes, protocoles ou architectures seront donc confronts des conditions
exprimentales ralistes, et nous ne connatrons a priori plus les carts incroyables entres les
performances obtenues par nos propositions en simulation et dans le cas rel.
Enfin, le grand dessein de la mtrologie est bien videmment de passer du stade hors ligne
au stade en-ligne (ou temps rel). En effet, lobjectif quil faut atteindre est de pouvoir
bnficier de tous les rsultats de caractrisation et danalyse de la QoS et/ou du trafic en
temps rel, et ce en tous les points du rseau. Ainsi, on pourrait concevoir des mcanismes
capables de ragir instantanment lapparition dun phnomne dans le rseau. Toutefois,

38
avant quune telle approche ne puisse tre dploye, il faut rsoudre un certain nombre de
problmes : dabord, avoir des outils de mesure active qui convergent trs rapidement, ce qui
nest pas le cas aujourdhui pour tous les paramtres de QoS. Il faut aussi que les sondes de
capture puissent passer la vole les donnes aux outils danalyse, en vitant ainsi le dlai du
lutilisation dun fichier intermdiaire. Naturellement, ceci ne peut tre possible que si les
outils danalyse peuvent travailler la vitesse du lien, ce qui est aujourdhui loin dtre le cas.
Cela situe lampleur de la tche car nos analyses restent encore aujourdhui trs basiques par
rapport tous les phnomnes quil pourrait tre ncessaire danalyser pour concevoir un
rseau dont les mcanismes se baseraient sur ces rsultats danalyse. Enfin, il faudra aussi
concevoir un protocole de diffusion des rsultats danalyse dans tous le rseau qui soit la
fois performant face un facteur dchelle important et trs rapide. Les premiers travaux de
recherche autour dune architecture rseau oriente mesures ont dbut, notamment au LAAS.
Une de nos premire contribution significative dans ce domaine sappelle MBN (Masurement
Based Networking), et repose sur deux lments essentiels : une architecture de mesure MBA
(Measurement Based Architecture), et un protocole de Reporting des rsultats de mesure et
danalyse MRP (Measurement reporting Proctocol). Les premiers rsultats dapplication de
cette architecture un exemple de contrle de congestion corrigeant les dfauts de TCP sont
prsents dans [LAR 02].

6. Remerciements
Les rsultats prsents dans cet article sont le fruit dun travail collectif qui a t men
pendant un petit peu plus de 3 ans dans le cadre du projet RNRT (Rseau National de la
recherche en Tlcommunications) METROPOLIS. Aussi, nous souhaitons remercier tous
nos partenaires du projet METROPOLIS qui ont contribu la mise en place des quipements
de mtrologie active et passive, et aux travaux danalyse des mesures et traces collectes.
Enfin, nous tenons remercier Patrice Abry de lENS de Lyon et directeur de recherche au
CNRS pour avoir contribu lanalyse des traces de trafic en nous formant lutilisation des
analyses partir dondelettes et loutil LDestimate.

7. Rfrences
[ABR 98] P. Abry and D. Veitch, Wavelet analysis of long-range dependent traffic, IEEE
Trans. Information Theory, Vol. 44, 1998
[ABR 00] P. Abry., P. Flandrin., M. Taqqu, D. Veitch, Wavelets for the analysis,
estimation and synthesis of scaling data, In Self-Similar Network Traffic and
Performance Evaluation, K. Park and W. Willinger, Eds., Wiley, 2000
[ALM 99a] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way Delay Metric for IPPM",
RFC 2679, September 1999
[ALM 99b] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way Packet Loss Metric for
IPPM", RFC 2680, September 1999
[ALM 99c] G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip Delay Metric for IPPM",
RFC 2681, September 1999
[APS 97] J. Apsidorf, "OC3MON: Flexible, affordable, high performance statistics
collection", Proceedings of INET, June 1997
[BER 94] J. Beran, Statistics for Long-Memory Processes, Monographs on Statistics and
Applied Probability, Chapman and Hall, New York, NY, 1994
[BLA 92] U. Black, TCP/IP and related protocols, McGraw-Hill, 1992

39
[CIS 01] "NetFlow Services Solutions Guide", http://www.cisco.com/univercd/cc/td/doc/-
cisintwk/intsolns/netflsol/
[COX 84] D. R. Cox, Long-Range Dependance: A Review, The Iowa State University
Press, 1984
[DAC 94] D. Dacunha-Castelle and M. Duflo, Probabilits et statistiques Tome 1
Problmes temps fixe , Editions Masson, Collection mathmatiques
appliques pour la matrise, 2me dition, pages 47-48, 1994
[DAG 01] Dag 4 SONET network interface, http://dag.cs.waikato.ac.nz/dag/dag4-
arch.html
[DOW 99] A. B. Downey, Using Pathchar to Estimate Internet Link Characteristics,
ACM SIGCOMM, 1999, pp. 222-23
[DOW 01] A. B. Downey, Evidence for long tailed distributions in the Internet, ACM
SIGCOMM Internet Measurement Workshop, November 2001
[FLO 01] S. Floyd and V. Paxson, Difficulties in simulating the Internet, IEEE/ACM
Trans. on Networking, Vol. 9, n 4, Aug. 2001.
[GUO 05] J. Guojon. Pipechar, http://www-didc.lbl.gov/Pipechar
[HAN 03] M. Handley, S. Floyd, J. Pahdye and J. Widmer, TCP Friendly Rate Control
(TFRC): Protocol Specification, RFC 3448, Proposed Standard, January 2003
[HU 03] N. Hu, P. Steenkiste, Evaluation and Characterization of Available Bandwidth
Probing Techniques, IEEE Journal on Selected Areas in Communication, No
21, 2003
[JAC 97] V. Jacobson. Pathchar -- a tool to infer characteristics of internet paths. April
1997
[LAB 05] Y. Labit, P. Owezarski, N. Larrieu, "Evaluation of active measurement tools for
bandwidth estimation in real environment", 3rd IEEE/IFIP Workshop on End-
to-End Monitoring Techniques and Services (E2EMON'05), Nice (France), 15
Mai 2005
[LAR 02] N. Larrieu, Mtrologie des rseaux IP : dveloppement de nouveaux outils
pour caractriser, analyser et rejouer le trafic rseau , rapport de diplme
ingnieur INSA, juin 2002.
[LAR 05] N. Larrieu, P. Owezarski, "Measurement based networking approach applied to
congestion control in the multi-domain Internet", 9th IFIP/IEEE International
Symposium on Integrated Network Management (IM'2005), Nice, France, 15-19
May 2005
[LEL 93] W. Leland, M. Taqqu, W. Willinger and D. Wilson, On the self-similar nature
of Ethernet traffic, ACM SIGCOM, September 1993
[MAH 00] B. A. Mah. Pchar. http://www.ca.sandia.gov/ bmah/Software/ Pchar/, 2000
[MAL 99] S. MALLAT, A Wavelet tour of signal processing, Academic Press, 1999
[MIL 96] D. Mills, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
OSI, Request for Comments 2030, October 1996
[NAV 03] J. Navratil. ABwE: A Practical Approach to Available Bandwidth Estimation,
PAM 2003, La Jolla, April 2003

40
[OWE 03a] P. Owezarski, N. Larrieu, Coherent charging of differentiated services in the
Internet depending on congestion control aggressiveness, Computer
Communications Journal, Issue 13, Vol.26, August 2003
[OWE 04a] P. Owezarski, N. Larrieu, A trace based method for realistic simulations,
IEEE International Conference on Communications (ICC'2004), Paris, France,
June 20th-24th, 2004
[OWE 04b] P. Owezarski, N. Larrieu, Internet traffic characterization - An analysis of
traffic oscillations, 7th IEEE International Conference on High Speed
Networks and Multimedia Communications (HSNMC'04), Toulouse (France),
June 30 - July 2, 2004
[PAR 96] K. Park, G. Kim and M. Crovella, On the relationship between file sizes,
transport protocols, and self-similar network traffic, IEEE ICNP, 1996
[PAR 97] K. Park, G. Kim, M. Crovella, On the Effect of Traffic Self-similarity on
Network Performance, SPIE International Conference on Performance and
Control of Network Systems, November, 1997
[PAR 00] K. Park and W. Willinger, Self-similar network traffic : an overview, In Self-
similar network traffic and performance evaluation, edited by K. Park and W.
Willinger, J. Wiley & Sons, 2000
[PAX 95] V. Paxson and S. Floyd, Wide area traffic: The failure of Poisson modeling,
IEEE/ACM Trans. on Networking, Vol. 3, pp. 226-244, 1995
[PAX 98] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for IP Performance
Metrics", RFC 2330, May 1998
[PAX 00] V. Paxson, A. Adams, M. Mathis, "Experiences with NIMI", PAM (Passive and
Active Measurements) Workshop, 2000
[PLA avJC] Platon, lallgorie de la caverne , La Rpublique, Livre VII, IVme sicle av
JC
[RIB 03] V.J. Ribeiro, R.H. Riedi, R.G. Baraniuk, J. Navratil, L. Cottrell, PathChirp:
Efficient Available Bandwidth Estimation for Network Paths, Passive and
Active Measurement Workshop, 2003
[ROB 00] J. Roberts, Engineering for Quality of Service, In Self-similar network traffic
and performance evaluation, edited by K. Park and W. Willinger, J. Wiley &
Sons, 2000
[STR 03] J. Strauss, D. Katabi, F. Kaashoek, A Measurement Study of Available
Bandwidth Estimation Tools, ACM SIGCOMM Internet Measurement
Workshop, 2003
[THO 97] K. Thompson, G. Miller and M. Wilder, Wide-area internet traffic patterns and
characteristics, IEEE Network, Vol. 11, n 6, Nov./Dec. 1997
[VEI 99] D. Veitch, P. Abry, A wavelet based joint estimator of the parameters of long-
range dependence, IEEE Trans. on Info. Theory special issue on Multiscale
Statistical Signal Analysis and its Applications 45, 3, Apr. 1999
[VER 00] A. Veres, Z. Kenesi, S. Molnar, G. Vattay, On the propagation of long-range
dependence in the Internet, SIGCOMM'2000, Stockholm, Sweden, September
2000

41
[VER 00b] A. Veres and M. Boda, On the Impact of Short Files and Random Losses on
Chaotic TCP Systems, in Proc.IFIP ATM & IP 2000 Workshop, Ilkley, UK,
July 2000
[WIL 98] W. Willinger, V. Paxson and M. Taqqu, Self-Similarity and Heavy Tails:
Structural Modeling of Network traffic, In A Practical Guide To Heavy Tails:
Statistical Techniques and Applications, ISBN 0-8176-3951-9, 1998
[XU 01] J. Xu, J. Fan, M. Ammar, S.B. Moon, "On the Design and Performance of
Prefix-Preserving IP Traffic Trace Anonymization", ACM SIGCOMM Internet
Measurement Workshop, San Francisco, CA, November, 2001
[XU 02] J. Xu, J. Fan, M. Ammar, S.B. Moon, "Prefix-Preserving IP Address
Anonymization: Measurement-based Security Evaluation and a New
Cryptography-based Scheme", IEEE International Conference on Network
Protocols, Paris, 2002

8. Glossaire
ADSL Asymetric digital Subscriber Line. ADSL est une technique de multiplexage
de donnes numriques sur une ligne tlphonique analogique utilise pour
interconnecter des utilisateurs finaux au rseaux Internet.
AS Autonomous System. Il sagit dun rseau opr par une seule et mme
autorit.
ATM Asynchronous Transfer Mode. Cest une technique de commutation de
cellules qui a t pendant longtemps t utilise comme une alternative la
commutation de paquets pour les rseaux numriques longues distances.
CNIL Commission Nationale Informatique et Liberts.
DCCP Datagram Congestion Control Protocol. Il sagit dun nouveau protocole de
transport en cours de discussion lIETF qui pourrait remplacer TCP dans le
futur.
ENS Ecole Normale Suprieure.
ENST Ecole Normale Suprieure des Tlcommunications.
FAI Fournisseur dAccs Internet.
FTP File Transfer Protocol. Cest le protocole applicatif de tlchargement des
fichiers depuis un serveur.
GPS Global Positionning System.
GTR Gnie Telecom et Rseaux.
HD Hard Drive ou disque dur.
HTML Hyper Text Markup Language. Langage de description de pages web.
HTTP Hyper Text Transfer Protocol. Cest le protocole utilis par le web pour le
tlchargement et la navigation sur le web.
IANA Internet Assigned Numbers Authority. Cest lautorit qui attribute les
numros de ports aux applications references dans lInternet.
IETF Internet Engineering Task Force. Il sagit dun organisme qui dveloppe et
normalise les nouveaux protocoles et architectures pour lInternet.
IP Internet Protocol. Cest le protocole de base des communications Internet.

42
IPPM IP Performance Metrics. Groupe de travail de lIETF qui rflchit aux
problmes de la mesure dans lInternet.
IUT Institut Universitaire de Technologie.
LAAS Laboratoire Danalyse et dArchitecture des Systmes.
LIP6 Laboratoire dInformatique de Paris 6.
LRD Long Range Dependence.
MetroMI Metropolis Measurement Infrastructure.
METROPOLIS Metrologie pour lInternet et ses Services.
MGEN Multicast Generator. Outil de gnration de trafic multicast largement utilis.
MIB Management Information Base. Cest une base de donnes normalise pour
la gestion des rseaux laide du protocole SNMP.
M-JPEG Moving-Joint Picture Expert Group. Cest une norme de compression de
squences dimages vidos pour laquelle chaque image est compresse et
code individuellement.
MPEG Moving Picture Expert Group. Cest une norme de compression de
sequences videos base sur un codage diffrentiel.
MRTG Multi Router Traffic Grapher. Cest un outil de supervision de la charge des
liens dun rseau.
NIMI National Internet Measurement Infrastructure.
NS Network Simulator.
NTP Network Time Protocol. Cest un protocole de synchronisation des horloges
de machines interconnectes par un rseau de communication.
P2P Peer-to-Peer ou Pair--Pair. Protocole dchange de fichier o tous les
participants sont la fois clients et serveurs.
PC Personal Computer ou Ordinateur personnel.
PCI Peripheral Component Interconnect. Standard pour les bus de
communication des ordinateurs, notamment les PC.
QoS Qualit de Service
RAM Random Access Memory. Mmoire vive dun ordinateur.
RAP Rseau Acadmique Parisien.
RENATER REseau NATional pour lEnseignement et la Recherche
RIPE Rseau IP Europens.
RTT Round Trip Time ou temps daller-retour.
SMTP Simple Mail Transfer Protocol. Protocole denvoi de-mails.
SNMP Simple Network Management Protocol.
TCP Transfer Control Protocol. Cest le protocole de transport le plus utilis dans
lInternet.
TFRC TCP Friendly rate Control. Cest un nouveau mcanisme de contrle de
congestion propos pour les applications orientes flux dans lInternet.
TTM Test Traffic Measurement. Cest le nom des sondes de mesure active de la
socit RIPE.
WWW World Wide Web ou la toile.

43

Vous aimerez peut-être aussi