Identifying submarine links via traceroute

Wed Sep 29 12:49:08 UTC 2021

On 9/29/21 04:23, PAUL R BARFORD wrote:
> Hello,
>
> I am a researcher at the University of Wisconsin.  My colleagues at 
> Northwestern University and I are studying submarine cable infrastructure.
>
> Our interest is in identifying submarine links in traceroute 
> measurements.  Specifically, for a given end-to-end traceroute 
> measurement, we would like to be able to identify when two hops are 
> separated by a submarine cable.  Our initial focus has been on 
> inter-hop latency, which can expose long links.  The challenge is that 
> terrestrial long-haul links may have the same or longer link latencies 
> as short submarine links. So, we're interested in whether there may be 
> other features (e.g., persistent congestion, naming conventions in 
> router interfaces, peering details, etc.) or techniques that would 
> indicate submarine links.
>
> Any thoughts or insights you might have would be greatly appreciated - 
> off-list responses are welcome.

Back in the day, when submarine cables were not as rife, it was not 
uncommon to see things like "FLAG" or "APCN-2" or "SMW-3" in 
traceroutes. I haven't seen such in a very long time, but likely some 
operators may still do this.

For traceroutes that cross oceans visibly, e.g., lhr-jfk, mrs-mba, 
hnd-lax, mru - cdg, e.t.c., you could glean from there. But many 
operators do not follow any "common norm" to annotate things like this, 
so YMMV.

You also find some countries that will use a submarine festoon either as 
a primary or backup route for a terrestrial link. In such cases, the 
distances may be the same, or even shorter across the festoon, e.g., 
consider a festoon cable between Cape Town - Durban, vs. a land-based 
run for the same two points.

Considering how wide-spread submarine links are for both short and long 
spans, I think folk are simply treating them as any other link, from an 
operational perspective. You may be able to come up with a 
semi-automatic mechanism to measure this, but I fear without deliberate 
and consistent human intervention, the data could get stale very quickly.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210929/8f99c28f/attachment.html>