Académique Documents
Professionnel Documents
Culture Documents
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.
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Plate-forme
de mesure
ENS Lyon
Mont de
Marsan
Pau EURECOM
IUT GTR
LAAS
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
lien
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
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.
22
Mtrologie FastE
Mtrologie GigE
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.
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.
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.
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
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.
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.
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
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)
29
Figure 9 : Evaluation de la LRD dans le trafic Internet
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.
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
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].
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 :
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.
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].
36
TCP New Reno (NR) : cas rel 82,335 157,959 0,521
TCP NR & TFRC : cas simul 77,707 102,176 0,761
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
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