Summary

  • A WLCG/OSG mesh with 170+ sites and about four million daily tests links each corridor’s path changes to delay, loss and throughput.
  • The cable-fault case halved latency on an emergency path while throughput collapsed; four result classes keep route changes separate from measured service impact.

A traceroute is a route postcard. It tells an operator where packets went when the test ran. If the postcard changes, that is news. It is not yet a performance diagnosis. A cable can fail, traffic can take a different path, and an application can still be moving data at full speed—or the new route can look quicker while the transfer falls over. The map and the service need to be read together.

Petya Vasileva’s 26 October RIPE 93 presentation tackled that gap in research and education networks. The WLCG/OSG perfSONAR mesh spans more than 170 sites and runs roughly four million tests a day. The method watches each source–destination corridor against its own recent path baseline. When the route shifts, it lines that change up with delay, packet loss and throughput from the same measurement system.

That combination matters because the measurements answer different questions. A traceroute describes the observed path. OWAMP can track one-way delay and loss; iperf3, scheduled through pScheduler, measures throughput. The official perfSONAR documentation treats these as separate test types for a reason: a path may change without a measurable service effect, and a performance reading may move for reasons a route snapshot cannot explain.

Vasileva’s tool gives each corridor one of four operator-facing labels: confirmed impact, routing change with no measurable effect, tests interrupted, or needs review. The list gives a NOC a place to start. It does not send every changed route to the top of the incident queue and make someone explain why the graph blinked.

The cable-fault example is the title’s punchline. The emergency path cut latency in half; throughput collapsed. A dashboard watching only delay could announce improvement while a large transfer was struggling. The route got quicker. The work did not. The method caught that disagreement by lining up the path shift with the performance record.

A second example followed months of bursty, low-level loss across a mesh. Shared-path evidence narrowed the problem to one site’s ingress element. That is a different kind of win: not a dramatic outage alert, but a way to turn a vague “sometimes slow” complaint into a place an operator can inspect. RIPE NCC’s meeting report notes packet loss on UK corridors, including the AMS–LON cable fault, and asks NOCs and NRENs to share incident records. Those records can connect a measurement pattern to the event the operators actually saw.

The method is built from existing perfSONAR measurements. RIPE says it needs no BGP feed, no additional probes and no labelled training data. That keeps the diagnosis close to the instruments already watching the corridor. ESnet’s Science DMZ guidance describes the same practical split: continuous latency and loss checks, periodic throughput tests, then network engineers using the results to troubleshoot routing and switching.

A four-way label is more useful than a red dot because it shows what the evidence can support. “Route changed” is an observation. “Confirmed impact” is a decision supported by aligned measurements. “Tests interrupted” says the measuring system lost its own view. “Needs review” leaves the case visible without pretending the evidence has settled it. Every class gives an operator a next question instead of a theatrical alarm.

The running network supplies the verdict. A new path may be operationally harmless; a shorter measured delay may sit beside a collapsing transfer; recurring loss may live at one edge rather than across the whole corridor. Put path, delay, loss and throughput on one time axis and the NOC can act on the failure the user feels, not the graph that happens to look dramatic. The published method provides no class-level false-alert rate; that table would show how often “confirmed impact” earns its name.

Sources: RIPE 93 session and abstract; RIPE NCC Communications’ 26 October meeting report; ESnet’s Science DMZ monitoring guide; perfSONAR test documentation.