[atlas] Satellite based "last mile" and Atlas probes

On 23/04/2021 10:12, Malte Appel wrote:

> You can find these measurements either in the Built-ins tab of the 
> probe (Ping First Hop / Ping Second Hop).
> 
> https://atlas.ripe.net/probes/1001821/#tab-builtins
> 
> Or over the API by accessing measurements with ids 1 (first hop, see
>  below) and 2 (second hop).
> 
> https://atlas.ripe.net/api/v2/measurements/1/results/?probe_ids=1001821&start=1619136000&stop=1619222399

Ah, perfect, thanks.   There was a disconnect between the link
previously sent, and the references to #1 and #2, mostly because those
measurements don't appear to be listed on that RIPE page!

Here are some probes that I spotted on my own Atlas visualiser as having
slow access to the DNS root system (~300ms+) followed up by queries to
measurements to #1 or #2 to look for very slow last "mile" connectivity:

11268 (DSL, very variable 100 - 900ms)
12803 (4G, /me waves at Eberhard!)
16494 (LTE, variable 30 - 250ms)
20306 (Satellite, 1st and 2nd sub 3ms, root servers 700ms+)
26228 (data not accessible)
27843 (data not accessible)
33110 (untagged, 2nd hop 270 - 420ms)
50592 ("Swisscom SAT Probe", 1st and 2nd hop sub 4ms, root 600ms+)
51871 (FTTH, 1st and 2nd hops sub 2ms, large root latency jump today)
52560 ("FastestVPN", consistent 285ms second hop)
1000244 (untagged, 2nd hop 600ms, occasional drops to 60ms)
1000795 (untagged, very variable, 35 - 1000ms!)

For background, the RSSAC Local Perspective WG is looking at
measurements of the root system, perhaps using Atlas, but we'd like to
be able to establish a baseline figure that we can subtract to account
for probes that are on the end of a slow internet access technology.  We
don't want the figures skewed by these outliers.

I'll probably need to do some explicit traceroutes on those where the
high latency was not introduced by the 1st or 2nd hop to find out where
the latency does happen.

I also spotted an odd probe geolocated in the north SF Bay area but with
170ms second hop latency and only hitting root anycast instances located
in Europe.  It smells like a long distance BGP tunnel to me, but I know
the individual that runs that network so I'll check with him.

Ray