Monitoring du réseau ADSL en Algérie – Les Métriques

Monitoring du réseau ADSL en Algérie

1. Les Métriques

Tewfik Jazaïri – tewfik.j@gmail.com

(et contributeurs)
Juillet 2009

1/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

1. Introduction

Dans le précédent article, j'ai lancé un appel à contribution dans le but de proposer un
projet open source pour le monitoring des réseaux ADSL en Algérie. Comme cité dans ce
document, l'objectif est de pouvoir évaluer selon plusieurs critères la qualité des réseaux
ADSL, dans un premier temps. Dans un second temps, exploiter ces résultats afin de
produire une base de donnée en ligne consultable librement.

J'ai décidé de commencer par le choix des métriques. Le choix des paramètres à
« capturer » par le logiciel doit être fait soigneusement.

Comme d'habitude, votre participation est indispensable pour la réussite de ce projet.

Partagez ces documents dans votre entourage, apportez vos suggestions, corrections et
avis.

2. Résumé

Quoi : Choix des métriques, ou paramètres à mesurer afin d'avoir des échantillons
quantitatifs sur lesquels un jugement sera fait quand à la qualité de la connexion.

Pourquoi : Les mesures sont indispensables afin d'avoir une appréciation et pouvoir
archiver les résultats et les analyser par la suite.

Comment : Le choix des métriques doit être fait soigneusement. Aussi, une bonne
architecture du projet permettra d'évoluer facilement lorsque de nouveaux paramètres
sont amenés à être ajoutés. De plus, la façon de mesurer est très importante.

3. La problématique

Le choix des métriques, dans le but d'évaluer la qualité d'une connexion semble être trivial
à première vue. On serait tenté de ne tenir en compte que les débits en download et en
upload, ainsi que le ping. Même si ces paramètres sont très indicatifs de la qualité d'une
connexion internet, il ne sont pas pour autant suffisants. Le présent document essaie de
reprendre les différents concepts introduits dans le premier document, et tente de
proposer une première réponse à la problématique.

4. Que mesurer ?

La notion même de qualité est toute relative, et chacun lui associe sa propre définition,
selon ses estimations. Tous les paramètres que l'on peut mesurer au niveau de l'utilisateur

2/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

n'ont pas forcément d'influence sur la qualité de la connexion. Par exemple, la taille du
disque dur (dans une configuration normale), n'a pas d'influence sur la qualité de la
connexion internet. Aucune corrélation n'existe entre ces deux entités. On doit donc
sélectionner les paramètres les plus pertinents et les plus influents.

La qualité ressentie par l'utilisateur est liée à son mode d'utilisation de la connexion ADSL.
Pour un utilisateur lambda, une panne dans le service DNS par exemple signifierait pour
lui une coupure totale de la connexion. Alors qu'elle serait quasiment invisible pour un
autre utilisateur exploitant un service sans résolution DNS.

Dans une première approche, je suis tenté de choisir les métriques suivants :

– Le débit en download : ce métrique, exprimé en kilo octets par seconde, représente la

vitesse à laquelle voyagent les packets internet entre la machine client et le serveur.

– Le débit en upload : exprimé lui aussi en kilo octets par seconde, il représente quand à
lui la vitesse maximum que l'utilisateur peut faire transiter dans la voie montante.

– Le ping : ce métrique exprime le temps d'aller retour que met un paquet internet pour
voyager entre la machine client et une autre machine sur le réseau.

– La fiabilité du Serveur DNS : Le service DNS sert à traduire des adresses internet (ex:
google.com) en adresses ip (ex: 123.456.789.0). Lors d'une panne DNS, c'est à dire
lorsque le serveur DNS n'est plus capable de répondre aux questions du client, ce
dernier n'arrive plus à naviguer sur les pages web ou à accéder à sa messagerie
instantanée, car le système ne peut plus retrouver l'adresse ip du service concerné.
Dans un contexte algéro-algérien, et en raison de pannes répétées des services DNS des
fournisseurs ADSL, j'ai décidé de rajouter ce paramètre en premier lieu afin de pouvoir
séparer les pannes de connexion des pannes DNS.

– Le système d'exploitation : Il s'agira de récolter le type du système sur lequel les tests
prennent place. Ce paramètre peut être utile afin d'isoler les éventuels problèmes (s'il
sont issus du système client, ou du réseau d'une façon globale).

Ces métriques me semblent suffisants pour une première approche. Une architecture globale
intelligente incha'-allah permettrait l'addition de métriques dans les futurs versions du
logiciel, de façon quasi-transparente, tout en gardant une compatibilité avec les anciennes
versions.

3/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

5. Comment mesurer

L'acte de mesurer, de prendre la mesure est un geste noble, qui demande à celui effectuant
la mesure une certaine précision. Sans quoi, la mesure n'aurait aucune signification.

Le choix des métriques est un point important, mais la façon d'effectuer la mesure est de
toute aussi grande importance. Pour vous donner un exemple, voici la situation suivante.

Imaginez que vous ayez à mesurer et représenter par exemple, la température d'un endroit
donné. Il vous paraitra évident et naturel de ne pas effectuer une mesure unique de
température. La raison est facilement compréhensible; cette mesure n'est pas forcément
représentative. Elle peut comporter une erreur, entre autres. Une réaction et solution directe
à cette problématique serait ensuite d'effectuer plusieurs mesures de températures
pendant une certaine durée. Puis, toujours pour des raisons de représentations -car
l'individu a besoin d'une information visible et non pas d'une série de données- on
prendrait la moyenne des ces mesures. La moyenne ainsi obtenue (sur une durée d'une
journée par exemple) représenterait globalement la température (moyenne, donc) de
l'endroit concerné. Première conclusion : la mesure des métriques ne peut et ne doit être
une mesure instantanée car cette mesure ne serait pas représentative de notre système.

Deuxième cas de figure : toujours dans le cadre de la mesure de la température, imaginez

que l'un des échantillons que vous avez mesuré est décalé d'un écart trop important par
rapport aux autres mesures (par exemple à cause d'un événement qui a provoqué la
variation brusque, comme l'ouverture d'une porte, le démarrage d'une machine, ...)

Dans ce cas, la valeur moyenne de l'ensemble des échantillons sera entachée du décalage
de cette valeur. Cette moyenne ne représente donc plus la tendance globale. Deuxième
conclusion : La valeur moyenne n'est pas un bon indicateur d'une série de données lorsque
certains échantillons sortent du modèle à priori de notre système.

Un troisième exemple pour renforcer cette idée : prenez un signal périodique sinusoïdal,
par exemple; calculez sa moyenne : elle est nulle sur une période. Et pourtant la richesse
'informationnelle' existe bel et bien. Si par contre on calcul la moyenne sur une durée
différente de la période, la moyenne ne serait plus nulle. Troisième conclusion : la fenêtre
d'échantillonnage est importante, car elle modifie la façon dont nous 'voyons' notre
système.

De ces exemples rapides on peut (aperce-)voir que les valeurs instantanées et les valeurs
moyennes ne sont pas forcément les meilleurs indicateurs.

Un mot sur ces opérations que l'on effectue : Lorsque nous choisissons de prendre une

4/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

valeur instantanée, ou une valeur moyenne, souvent c'est par soucis de compression, par
soucis de représentation. L'individu, pendant son processus de prise de décision, a besoin
de juger rapidement d'une situation, et il a besoin d'un indicateur directe. Il prend donc la
moyenne ou la valeur instantanée d'une série de données. Il filtre. Filtrer les autres
données qui pour lui représentent une sorte de bruit, l'empêchant de 'voir' une tendance,
écarter le doute. Ce besoin de filtrer est certes légitime, mais les solutions apportées sont
souvent en inadéquation avec le système en question et de sa dynamique.

Pour revenir à nos histoires de métriques, nous ne pouvons pas, d'après ce que nous
venons de voir, prendre des mesures instantanées, ni prendre des moyennes sur une
durée, ni même prendre une fenêtre d'échantillonnage arbitraire. Pendant la mesure, il est
donc prudent de choisir minutieusement ces paramètres. Il est évident que nous devons
filtrer les échantillons mesurés, d'une part pour éliminer le bruit (discussion à venir sur la
définition du bruit dans notre contexte), et d'autre part pour avoir une représentation
compacte.

La moyenne est une façon de filtrer, inefficace dans bien des cas, notamment lorsque la
dynamique du système est rapide. Afin de pallier à ce manque de 'visibilité', on peut
introduire d'autres paramètres, comme la déviation standard.

En quelques sortes, la déviation standard nous donne l'écart entre la moyenne et le reste
des mesures. On peut dire qu'elle nous donne une indication sur la 'position' des
échantillons, de leur répartition. La déviation standard est très utile et répond dans un
premier temps à une question intéressante : est-ce que la valeur moyenne des échantillons
est représentative de l'ensemble, ou pas ?

D'une façon résumée, voici la topologie globale sur la façon de mesurer les métriques :

1- Prendre des échantillons du métrique en question, sur une fenêtre bien déterminée
1a- S'assurer que les mesures effectuées ont été faites dans des conditions acceptables
(conformes)
2- Filtrer les valeurs ainsi obtenues, et s'assurer de leur crédibilité
3- Compacter les données et les préparer à être envoyées

5.1 Mesure du metric « Ping »

Comme vu rapidement un peu plus haut, le Ping est la mesure du temps d'aller-retour des
packets IP entre deux machines connectées sur un même réseau. Ce réseau peut être un
réseau local, ou réseau internet dans notre cas.

Dans une approche simpliste, on peut dire que le paramètre Ping ne dépendrait que du

5/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

média dans lequel voyagent les packets IP. C'est à dire, le temps de transit imposé par les
différents supports physiques entre vous; clients ADSL, et votre fournisseur de connexion
internet. Ces supports physiques sont tour à tour : la ligne téléphonique vers le
concentrateur de raccordement, puis la fibre optique entre le DSLAM et le fournisseur
d'accès ADSL, puis entre ce dernier et la Backbone internet. Les packets ont tendance à
voyager plus rapidement sur les supports à fibre optique, puis sur les supports à cuivre.

Même si cette définition est correcte, elle reste incomplète, car elle ne prend pas en compte
deux paramètres importants :

– D'abord; sur le chemin pris par les packets il y a des périphériques réseaux qui ne sont
pas passifs, et qui influent sur le transit des packets (c'est d'ailleurs leur fonction
principale), comme les DSLAM, les routeurs, les ponts réseaux, ...

– Ensuite; l'implémentation des mécanismes de gestion d'une connexion IP à savoir la

pile TCP/IP (tcp/ip stack) qui influe directement sur les mécanismes de régulations que
subissent les packets ip.

– Finalement l'influence des logiciels installés au niveau du client, comme les Firewall,
les anti-virus, anti-spyware (comme signalé par 'Assilabox' sur forumdz [1])

Pour vous donner un exemple palpable, voici les deux cas de figure suivants :

Premièrement, on effectue une mesure de ping pendant l'absence d'activité internet au

niveau de votre poste. Une telle mesure peut être accomplie manuellement d'une façon
aisée, en suivant les instructions suivantes :

– lancez une fenêtre de terminal au niveau de votre machine qui est connectée à internet
(si vous êtes sous windows 2000/xp, le moyen le plus rapide serait de faire : Démarrer >
Executer > tapez 'cmd' puis Entrée. Si vous êtes sous Linux, lancez un Xterm ou tout
autre façon de lancer un terminal)
– tapez l'instruction suivante : ping google.com
– vous voyez ensuite s'afficher au niveau de votre fenêtre terminal les temps d'aller-
retour des packets entre vous et le (un des) serveur(s) google.com. Ces temps est
exprimé en milli-secondes. Notez-le.

Deuxièmement, on effectue le même test de ping, mais dans une situation légèrement
différente, à savoir une utilisation de la bande passante en upload (attachement d'un
fichier par exemple).

Vous remarquerez que les résultats obtenus sont différents de plusieurs magnitudes. Cette
grande (grosse) différence est causée par l'un ou la combinaison des deux mécanismes

6/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

suivants :

– La Queue TCP de votre système d'exploitation : imaginez les packets sortants comme
placés dans une file, en attendant d'être envoyés vers leurs destinations. Comme cette
queue ne peut être infinie, il arrive parfois une saturation. Certains paquets alors sont
mis en attente, en quelque sorte. Hors, le test ping étant un test hautement temps réel,
les calculs sont alors faussés et la mesure n'est plus tout à fait valable (mais elle reste un
indicateur)

– Le même mécanisme peut être constaté coté Fournisseur d'accès, mais cette fois ci
d'une façon délibérée. Votre isp peut limiter le nombre de connexions TCP simultanées,
ainsi que le rythme d'ouverture des connexions TCP (TCP Rate Limit) de votre
connexion internet. Ceci à pour cause le même problème, et les mêmes conclusions.

5.2 Mesure du metric « Bande passante »

Comme signalé par 'Djoss' sur forumdz[1], il existe un projet similaire, appelé
Grenouille[2].
Ce projet repose sur la mesure de la bande passante ainsi que du ping au niveau des
fournisseurs d'accès en france.
J'ai survolé rapidement leurs codes, ainsi que la documentation et les pages wiki. La
critique principale étant leur méthode de mesure, qui est faite en téléchargeant un fichier
sur un serveur. Même si je peux comprendre leurs motivations, leurs façon de penser le
système n'est pas adaptée à notre quotidien algérien.

Je propose que la mesure de la bande passante en download soit faite de deux façon
différentes :

– en Bulk : en téléchargeant un bloc de données à partir d'un serveur (disussion à venir)

dont la disponibilité est prouvée à 100% et dont le potentiel en bande passante est
supérieur au nombre de demandes instantanées.

– en rafale : en téléchargeant des pages web tel que le ferait un navigateur accédant à un
site web (mode navigation). Les métriques seraient alors les temps de chargement des
objets embarqués au niveau de la page html (quelque chose qui ressemblerait à
FireBug::Réseau)

Naturellement, les tests ne se limitent pas à ces deux modes, je vous invites aussi à
proposer vos idées et soumettre vos critiques.

7/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

5.3 Mesure du metric «Qualité du DNS»

Vu notre contexte, la qualité du DNS influe énormément sur la qualité ressentie par
l'utilisateur final, aussi il est toujours intéressant de tester la qualité des serveurs DNS du
fournisseur d'accès. Il suffit d'interroger (query, question) le(s) serveur(s) DNS et
déterminer les délais de la réponse, ainsi que la justesse (et donc la disponibilité). Ce
paramètre est peut être le plus facile à mesurer parmi les metrics proposés.

5.4 Autres metrics importants (contributeur: Assilabox)

Le membre Assilabox sur le forum forumdz a proposé d'intégrer les paramètres liés à la
qualité de la ligne téléphonique du client ADSL. Je trouve l'idée fort intéressante. Je
reprend ici son post :

1. module pour la récupération des valeurs suivantes (a partit du SAGEM 3302):

• ADSL Up Speed
• ADSL Down Speed (très intéressant pour l'autodetection de la bande passante
max, NDR)
• ADSL Attenuation UP
• ADSL Attenuation Down (très intéressants pour connaître la qualité de la ligne,
NDR)
• ADSL SNR Up
• ADSL SNR Down
• ADSL CRC
• ADSL HEC

Ceci peut se faire, par un simple parsing html ou text (telnet? a vérifier). Bien sure,
il faut penser a avoir l'accord au préalable de l'utilisateur notamment s'il a changer
le mot de passe par défaut du routeur.

Je pourrais aussi essayer de récupérer de ces valeurs depuis le modem sagem A800
(qui est également en ma possession). Ceux qui ont d'autres modem/routeur
peuvent se proposer pour faire la même chose. (et ce module aura alors un fichier de
configuration par type de modem, d'une part pour reconnaître le pattern à extraire ainsi que
la façon de 'discuter', il suffira de renseigner ce fichier de configuration pour que le module
apprenne à s'interfacer avec un nouveau modem, NDR)

2. liste des processus en cours, toujours avec l'accord de l'utilisateur ? Pour lui
demander d'arrenter les processus qui consomme de la BP lors du test (clients P2P,
download managers)? Les récupérer sur la BD pour analyse ? (Je proposerais plutôt
pour ma part le classement par type de trafic, peu importe qui l'a généré, à mon sens: http,
ftp, smtp, edonkey, torrent, ..., NDR )

8/9
 Monitoring du réseau ADSL en Algérie – Les Métriques

3. Un module like MTR ou MTR (traceroute + ping) qui sera, a mon avis, l'un des
outils les plus pertinents pour localiser les failles chez les FAI ;_) (un mtr a partir
des serveurs serait peut être plus intéressant, afin d'éviter les pb d'interopérabilité?)

4. Etat de service du réseau du FAI: Il est facile de retourouver les adresse IP de

tous les DSLAM, Serveur DNS etc.. chez un FAI et de mettre en place un service
smokeping pour surveiller l'etat du reseau en permanence. Cette fois, la recolte de
donnees se fera en permanence et independement des utilisateurs.

5.5 Règles générales lors de la mesure

– Je dois adapter l'acte de la mesure à la grandeur et à sa dynamique.

– Je ne dois pas gêner, ou au plus minimiser la gène au client lors de la mesure
– Si le trafic est fréquent, exploiter cette activité pour déduire certains métriques (temps
de réponses du DNS, RTT, Max Bandwidth)
– Dans une vision globale, il faut faire l'équilibre entre ; Les metrics (ping, debit), Les
options (cibles, sources), Les transformations(min, max, moyenne, std dev) (discussion
à venir)

6. Conclusions

– Nous devons avoir notre propre 'Grenouille', entre autre car le contexte et les réalités
sont différents
– Les mesures doivent être faites soigneusement en tenant compte des spécificités
– On peut effectuer des relevés de façon non obstrusive
– La mesure du upload est « tricky », une discussion est indispensable
– Tirer profit du protocole SNMP embarqué sur les modems ADSL pour la récolte des
paramètres

Annotations

[1] Appel à contribution sur forumdz: http://www.forumdz.com/showthread.php?

t=14895&page=2

[2] Projet Grenouille, la météo du net: http://www.grenouille.com/

9/9