Home
Explore Cables Locations Map ISP status
Live Live Map Health Latency Pulse
Learn Research Guide Methodology

Methodology

Detecting and Attributing Submarine-Cable Latency Anomalies with Two-Signal Cross-Validation

Evgeny Korolev — GeoCables · Technical note, June 2026 · v1.1

GeoCables continuously measures RTT from a fixed probe fleet to the landing points of 703 submarine cables and flags latency anomalies. The contribution here is not the detector itself but a two-signal cross-validation layer that grades each alert against two independent physical signals — a change in the AS-path at the time of the event, and whether other probes whose route physically traverses the same cable corridor observe the same degradation. The two signals are largely independent, and their combination separates topology-level cable incidents from routing changes and from single-vantage noise. The numbers below are deliberately undramatic: the observation window contained no large-scale cable break, and the method correctly declines to manufacture one.

1. Data foundation

AssetScale
Submarine cables (with landing-point geometry)703
Landing points (geo-coded)1,932
Backbone / cable segments26,053
Own probes (Minsk, Almaty, Tbilisi, Jerusalem) + RIPE Atlas12 + RIPE
Completed health checks (since 2026-03-01)168,699
Cables under active measurement691

The method runs on a curated topology graph and a continuously accumulating measurement archive. Raw per-measurement RTT is preserved append-only, so any future detector can be re-run over the full history — a property that cannot be reconstructed retroactively from public cable maps alone.

2. Detection (baseline + haversine attribution)

Each check pings (and traceroutes) a target near a cable landing point. A measurement is a candidate anomaly when its RTT rises materially above that route's adaptive baseline. Candidates pass through a staged funnel before any alert is raised — the first layer of false-positive suppression:

StageMeaningCount
spikeraw measurement above baseline624
anomaly_confirmedspike that persists / is corroborated189
alertpromoted to a tracked incident114

Only ~18% of raw spikes (114 / 624) become alerts. Cable attribution is geometric: the latency jump is associated with the nearest cable segment by haversine distance between the suspected hop and the candidate cables' landing points.

3. Two-signal cross-validation

3.1 Signal A — AS-path reroute

When a submarine cable degrades, traffic frequently reroutes, changing the autonomous-system path. For each alert we compare the AS-path before the event (the modal path on that probe→target) with the path at the event.

VerdictMeaningCount
route_change_breakAS-path changed, with a large further latency rise on the new path4
route_changeAS-path changed5
same_pathRTT rose, path unchanged (congestion-class)57
no routing historyinsufficient routing history48

Of the 66 alerts with sufficient routing history, 9 (13.6%) were independently corroborated by a measured AS-path change. A naive fingerprint over the raw IP-path is far too noisy (ECMP load-balancing and intermittent timeouts produce ~18 distinct IP-paths per probe→target pair); the signal only becomes stable on the AS-set fingerprint (~1.5 distinct per pair), which is what we use.

3.2 Signal B — segment-aware multi-probe consensus

If only the detecting probe sees a degradation, the question is whether the other probes are silent witnesses or simply not on the affected cable. A probe routing around the cable is not a witness — its silence is no alibi. We therefore count a probe as an eligible witness only when its actual AS-path geo-traverses the same cable corridor the alerting probe's path used. This geo-corridor test demoted 30% of the naive same-cable "witnesses" as off-corridor.

VerdictMeaningCount
widespreadmajority of corridor witnesses also degraded — real cable event1
mixedsome corridor witnesses degraded4
routing_event_non_cablealerting probe rerouted, corridor witnesses healthy → BGP/peering, not a cut7
probe_specific_likely_fpcorridor witnesses healthy, no reroute → local artifact44
narrow_path_event_possiblesingle-probe cable — cannot rule out a narrow event1
insufficient_witness_contextno concurrent corridor witness — unknown57

3.3 Confidence ladder

The two signals are largely independent: an AS-path change reflects a topology event, while multi-probe consensus reflects the geographic breadth of degradation — distinct physical processes that need not co-occur. Very few alerts satisfy both. Combining them:

TierDefinitionCount (of 114)
Dual-confirmedAS-path change and multi-probe corroboration0
Single-signalcorroborated by exactly one signal14
Defensible false positivecorridor witnesses healthy and no reroute44
Unclassified (coverage)no witness present on the corridor — a probe-coverage limit, not method uncertainty56

The dual-confirmed count is zero, and that is the correct result: the 2026-03–06 window contained no large-scale submarine-cable break. A genuine major cut would light both signals simultaneously; the value of the method is that it discriminates — confidently labelling 44 alerts (38%) as defensible false positives and isolating 7 events as routing changes that are not cable faults — rather than producing a dramatic body count on a quiet month.

4. False-positive analysis (honest)

5. Limitations

6. Reproducibility & data

Detection uses an adaptive threshold calibrated to each route's baseline distribution rather than a fixed multiplier; the consensus tiers reflect the share of eligible corridor witnesses that corroborate the degradation. The exact parameterisation is intentionally omitted here and is available in a forthcoming complete publication or on request. Raw per-measurement RTT and AS-paths are retained, so the classifier can be re-run end-to-end over the full archive under any revised method. Source signals: RIPE Atlas (ping + traceroute), own probes, and the curated cable/landing-point graph.

© 2026 Evgeny Korolev / GeoCables. Method and figures may be cited with attribution. Live monitoring: Cable Health Monitor. Figures are from the production system as of 2026-06-17 and will evolve as the archive deepens.

🌐 Log In

Access your routes, favorites, and API key

Create account Forgot password?