Identifying submarine links via traceroute
Mark Tinka
mark at tinka.africa
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>
More information about the NANOG
mailing list