Summary

  • Le maillage WLCG/OSG couvre plus de 170 sites et environ quatre millions de tests quotidiens ; l’outil relie chaque changement de trajet aux mesures du même corridor.
  • Lors d’une panne de câble, la route d’urgence a divisé le délai par deux tandis que le débit s’effondrait. Quatre classes séparent le changement de route de l’impact constaté.

Un traceroute, c’est une carte postale du trajet. Il raconte où les paquets sont passés au moment du test. Si l’itinéraire change, c’est une nouvelle. Ce n’est pas encore un diagnostic de performance. Un câble peut tomber, le trafic emprunter une autre route et l’application continuer à transférer à plein régime — ou le nouveau trajet peut sembler plus rapide pendant que le transfert cale. La carte et le service doivent se lire ensemble.

Le 26 octobre, à RIPE 93, Petya Vasileva a présenté une méthode pour combler ce fossé dans les réseaux de recherche et d’éducation. Le maillage perfSONAR WLCG/OSG relie plus de 170 sites et exécute environ quatre millions de tests par jour. L’outil observe chaque corridor entre une source et une destination par rapport à son propre trajet récent. Lorsqu’une route bouge, il rapproche ce changement des mesures de délai, de perte de paquets et de débit.

Ces mesures ne répondent pas à la même question. Le traceroute décrit le chemin observé. OWAMP peut suivre le délai aller simple et les pertes ; iperf3, lancé par pScheduler, mesure le débit. La documentation officielle de perfSONAR distingue ces types de tests pour une bonne raison : une route peut changer sans effet mesurable sur le service, et une mesure de performance peut bouger sans que l’instantané de route explique pourquoi.

L’outil attribue à chaque corridor l’une de quatre classes destinées aux opérateurs : impact confirmé, changement de route sans effet mesurable, tests interrompus ou vérification nécessaire. Le NOC reçoit ainsi une liste de départ. Il n’envoie pas chaque route modifiée en tête de file en exigeant qu’une personne explique pourquoi le graphe a cligné des yeux.

L’exemple de la panne de câble donne son titre à l’article. La route d’urgence a divisé la latence par deux ; le débit s’est effondré. Un tableau de bord qui ne surveille que le délai aurait pu annoncer une amélioration pendant qu’un gros transfert s’asphyxiait. La route allait plus vite. Le travail, lui, n’avançait plus. La méthode a repéré le désaccord en rapprochant le changement de chemin des mesures de performance.

Un second exemple suit des mois de pertes faibles et irrégulières. Les chemins partagés ont ramené le problème à l’élément d’entrée d’un seul site. Le gain est moins spectaculaire qu’une alerte de panne totale : il permet de transformer un « ça rame de temps en temps » en endroit que l’équipe peut inspecter. Le compte rendu de RIPE NCC signale des pertes sur des corridors britanniques, dont la liaison AMS–LON, et invite NOC et NREN à partager leurs journaux d’incidents. Ces journaux relient les motifs de mesure à ce que les équipes ont réellement vu.

La méthode s’appuie sur les mesures perfSONAR existantes. RIPE indique qu’elle ne demande ni flux BGP, ni sondes supplémentaires, ni données d’entraînement étiquetées. Le diagnostic reste près des instruments déjà installés sur le corridor. Le guide Science DMZ d’ESnet décrit la même séparation pratique : mesures continues de délai et de perte, tests de débit périodiques, puis ingénieurs réseau qui s’en servent pour chercher côté routage et commutation.

Quatre classes valent mieux qu’un point rouge parce qu’elles indiquent ce que les données autorisent à dire. « La route a changé » est une observation. « Impact confirmé » est une décision appuyée par des mesures alignées. « Tests interrompus » signale que le système de mesure a perdu sa vue. « Vérification nécessaire » garde le dossier ouvert sans jouer au juge.

Le verdict vient du réseau en fonctionnement. Une nouvelle route peut ne rien changer au service ; une latence plus basse peut cohabiter avec un transfert qui s’écroule ; une perte répétée peut se loger à une entrée plutôt que tout le long du corridor. Aligner route, délai, pertes et débit sur une même chronologie aide le NOC à traiter le problème ressenti par l’utilisateur, pas le graphe le plus tapageur. La publication ne donne pas le taux de fausses alertes par classe ; ce tableau montrerait combien de fois « impact confirmé » mérite son nom.

Sources: Session et résumé de RIPE 93 ; compte rendu RIPE NCC du 26 octobre ; guide de mesure Science DMZ d’ESnet ; documentation des tests perfSONAR.