Hank, Shane, thanks for your interest! Happy to answer any questions about reverse traceroute!
Inline:
Hank,
On 16/04/2024 19.44, Hank Nussbacher wrote:
> https://pulse.internetsociety.org/blog/reverse-traceroutes-help-troubleshoot-improve-visibility-of-internets-health
>
> "Measure at least one reverse path from 39,544 Autonomous System (AS)
> destinations, which host 92.6% of Internet users. As a comparison, RIPE
> Atlas vantage points can measure from 4,344 AS destinations,
> representing 67.1% of the Internet user base."
This particular metric feels highly-contrived... as if to highlight one
specific property that their system excels at. Number of ASN doesn't
mean that much really... a single vantage point at Comcast would account
for 30 million customers and probably twice that many users, but not
actually tell you much about the network for the vast majority of those
users.
We looked at these metrics because:
- a goal is to cover as much of the Internet as possible (which, yes, is not clearly defined and could mean any number of things)
- we need to capture coverage in some ways, and there are many possible ways, each with cons and many with pros. We picked some that seemed useful but couldn't look at everything given constraints on time and paper length.
- we wanted to assess how many ASes completely blocked our measurements (because of configured policy, say)
We are open to suggestions on other things to look at!
To be clear, reverse traceroute doesn't need a probe in a network to measure routes from the network. It uses measurements from MLab and RIPE Atlas to measure the path back from a host that isn't part of the system/isn't running our software.
It seems like the effort is targeted at operators and not end users,
with the selling point is to provide a win-win situation, where
operators gain useful metrics and the researchers learn about the
network. This would encourage operators to run their code, and the
researchers could more easily coax them to run their tool, getting these
impressive numbers. (I haven't read the paper of course, because
apparently the ACM is not open access and honestly I don't feel like
spending $15 for access.)
ACM DL access is annoying for sure. We try to make sure our papers are readily available.
If not, it should work from here:
If you can't find a version but want one, please write me off list. I happen not to have put this one on my (out of date) homepage, but I'm happy to.
Happy to answer any questions!
Ethan
My understanding is that RIPE Atlas is mostly targeted at end users, not
operators, so probably a bit harder to get probes placed, as it has no
direct benefit for operators... and in fact could reveal details about
their network and the quality of their service that they would not care
to share. This is not *completely* true, as there are the RIPE Atlas
Anchors, which I think are intended to run as infrastructure nodes, but
mostly.
> Has anyone tried this and indeed found better visibility via their system?
I have not. It looks less flexible than Atlas, but also nice and simple!
Thanks for pointing it out.
Cheers,
--
Shane
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas