[atlas] Reverse traceroute

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 at time-travellers.org> wrote:

> 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.
- 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 at ripe.net
> https://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20240416/19944fd6/attachment-0001.html>