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
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
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
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
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
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'allerretour 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
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
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
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