Hank, Shane, thanks for your interest! Happy to answer any questions about reverse traceroute! Inline: On Tue, Apr 16, 2024, 4:19 PM Shane Kerr <shane@time-travellers.org> wrote:
Hank,
On 16/04/2024 19.44, Hank Nussbacher wrote:
https://pulse.internetsociety.org/blog/reverse-traceroutes-help-troubleshoot...
"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. - these metrics are posted on the RIPE Atlas site ( https://sg-pub.ripe.net/petros/population_coverage/ , https://atlas.ripe.net/coverage/), so made sense to compare metrics Atlas already uses - 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. The paper should be open access when accessed via the conference website. This link works for me for open access: https://dl.acm.org/doi/10.1145/3517745.3561422 If not, it should work from here: https://conferences.sigcomm.org/imc/2022/program/ We also hosted it openly in the HAL repository, but it isn't loading for me at the moment: https://hal.laas.fr/hal-03788618/ 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