Les outils pour la capture, le rejeu et l’analyse des flux

Dans le cadre de certaines évaluations, la même expérience doit être réalisée un certain

nombre de fois en changeant certains paramètres du système satellite (bande passante totale

allouée, quantité de CRA, de RBDC, etc…). Pour être bien sûr que les différences que nous

observons sont bien dues aux variations du système et non aux variations de certains

paramètres des flux, il est donc nécessaire de rejouer exactement les mêmes flux pour chaque

114

expérience. En effet, dans le cas d’une vidéoconférence par exemple, le débit correspondant

au flux vidéo peut beaucoup varier d’une session à l’autre en fonction des images à

transmettre. Pour cela, nous avons du utiliser différents outils de capture, de rejeu et d’analyse

de trafic que nous allons maintenant présenter.

IV.2.2.1.FLOC : un outil de capture de trafic

L’outil FLOC (FLOw Capturer) a été développé au LAAS et fait partie d’un ensemble

de 3 logiciels appelés (FL3 (FLOC : FLOw Capturer, FLORE : FLOw REplayer, FLAN :

FLow ANalyzer) [155] permettant la capture, le rejeu et l’analyse de flux. Ce logiciel a été

conçu pour permettre de capturer à la volée, pendant une durée donnée, l’ensemble des

données IPv4 ou IPv6 véhiculées par toutes les connexions provenant d’une application. Cet

outil utilise les mêmes fonctionnalités que le traceur de connexion implémenté pour le QoS

Agent et permet d’obtenir le nombre de connexions ouvertes, le protocole de transport associé

à chaque connexion (UDP ou TCP), la date d’émission de chaque paquet capturé et la taille

du paquet (charge utile du niveau transport). Ces deux dernières informations permettent

d’obtenir deux fichiers contenant les informations nécessaires au rejeu de ces flux : le délai

inter-paquet et la taille des paquets.

IV.2.2.2.JTG : un outil de génération, de rejeu et d’analyse de trafic

Pour la génération, le rejeu et l’analyse de trafic, nous avons choisi d’utiliser l’outil JTG

(Jugi’s Traffic Generator) [156] développé par l’université d’Helsinki. Ce générateur de trafic

simple et précis permet d’échanger entre un émetteur et un récepteur des flux UDP et TCP

totalement configurables et notamment permet de rejouer des flux capturés à partir de deux

informations obtenues grâce à l’outil FLOC : le délai inter-paquet et la taille des paquets.

JTG présente aussi l’avantage de pouvoir analyser les flux à partir des fichiers log, au

format MGEN (Multi-GENerator) [157], obtenus au niveau du récepteur et de tracer les

courbes correspondantes à différentes caractéristiques du flux : la gigue, le délai, la variation

du délai inter-paquet ainsi que les pertes. Ces courbes sont réalisées en utilisant l’outil

jtg_calc de jtg puis gnuplot. C’est principalement pour ces raisons que nous avons choisi cet

outil plutôt que les parties FLORE et FLAN de Fl3.

Dans le cadre de nos expériences, nous avons dû effectuer certaines modifications sur cet

outil :

• Pour permettre la gestion de flux IPv6, il existe une version JTG6 mais cette dernière

ne fonctionne que sous certains systèmes d’exploitation n’incluant pas Fedora Core. Il

a donc fallu modifier le code source pour ajouter cette fonctionnalité.

• Nous avons aussi ajouté la possibilité d’analyser et de tracer la courbe du débit

correspondant à un flux. Plusieurs méthodes de calcul de débit ont ainsi été ajoutées.

• Enfin, dans le cadre de nos expériences sur Mobile IPv6, nous avons modifié le code

source pour que le flux généré par un terminal mobile puisse continuer pendant et

après un changement de réseau sans s’interrompre.

Il est important de noter que pour obtenir des résultats concluants, il est indispensable de

synchroniser temporellement l’émetteur et le récepteur concerné. Pour cela, nous avons utilisé

115

la synchronisation NTP en utilisant un modèle hiérarchique. Sur la Figure 41, l’émulateur

satellite sert de référence temporelle surlaquelle se synchronisent les STs et GW. De même,

les clients se synchronisent sur leur ST/GW respectif, ce qui nous permet d’obtenir une

précision inférieure à la milliseconde sur un réseau LAN et de l’ordre de quelques

millisecondes sur un réseau WLAN.

IV.2.2.3.ORENETA

Dans le cadre des expériences correspondant aux évaluations de QoS ou de Mobile IPv6

et de ses extensions, il est possible de réaliser les tests en rejouant les différents flux mais

dans le cas de la mobilité SIP, pour tester les performances de notre architecture, il nous faut

utiliser les logiciels SIP puisque ce sont eux qui initient les mécanismes de mobilité et de QoS

et qui permettent donc aux flux de reprendre depuis le nouveau réseau.

Cependant, pour pouvoir comparer la mobilité SIP à Mobile IPv6, il est nécessaire de

pouvoir obtenir des fichiers log permettant d’analyser les flux et de tracer les mêmes courbes

que celles obtenues avec JTG. C’est pour cette raison que nous avons choisi d’utiliser l’outil

ORENETA (One way delay REal-time NETwork Analyser) [158] qui permet de capturer à la

volée différents flux identifiés par leur quadruplet {port source, adresse source, port

destination, adresse destination} au niveau de deux entités appelées meters et localisées au

niveau de l’émetteur et du récepteur des flux que l’on cherche à étudier. Ces deux entités

transmettent également à la volée les informations concernant les paquets capturés vers un

serveur central appelé analyzer qui permet d’une part de visualiser en direct certaines

caractéristiques concernant les flux (débit, délai, pertes, variation du délai) mais aussi de créer

des fichiers log au format MGEN à la fin de la communication. Ces fichiers peuvent ensuite

être analysés par JTG de la même manière que précédemment si bien sûr les différents meters

sont synchronisés temporellement (pour cela, nous avons utilisé la synchronisation NTP).

Le désavantage d’un tel outil est qu’il génère lui-même du trafic pour transmettre les

données concernant les paquets capturés. Pour ne pas fausser nos évaluations, il a donc fallu

mettre en œuvre un réseau spécialement dédié à ce trafic. La Figure 42 résume les interactions

existant entre nos différents outils de mesures.

116

Figure 42 – Interactions entre les différents outils de mesure utilisés