[atlas] Probe location obfuscation

Hi Eric,

Thanks for sharing that, I didn't know about that probe. I amazed by the 
stability of its last mile RTT (see attached graph LM36492).

It looks like the probe is loosing connectivity to RIPE controllers once 
in a while, do you know if this is caused by starlink or is it other 
running experiments?

Cheers,
Romain

On 3/26/21 10:32 AM, Eric Kuhnke wrote:
> There are a number of instances where probes based on a satellite ISP 
> may be wildly different in geographical location vs. IP location.
> 
> For instance I have previously run systems in Afghanistan on 
> geostationary satellite capacity, where the other end of the link was in 
> Singapore. All of the IP adjacencies and transit, peer uplinks were in 
> Singapore.
> 
> This is fairly normal for anything geostationary. Systems based on o3b 
> (a MEO satellite network owned by SES) can also have wildly divergent 
> physical and logical locations.
> 
> I have a probe running right now on a SpaceX Starlink beta test terminal 
> ( https://atlas.ripe.net/probes/1001821/ 
> <https://atlas.ripe.net/probes/1001821/> ) which is logically in 
> downtown Seattle, but is physically in a rural eastern suburb of 
> Vancouver, BC.
> 
> With the growth of Starlink, OneWeb, Kuiper and such in the future this 
> issue will become more prevalent.
> 
> 
> 
> On Thu, Mar 25, 2021 at 6:03 AM Massimo Candela <massimo at us.ntt.net 
> <mailto:massimo at us.ntt.net>> wrote:
> 
>     [possibly OT]
> 
>     In 2018 we found 18 probes which were located so far from reality that
>     the collected RTT towards targets of known locations was faster than
>     the
>     speed of light (I remember we did something about those). I suspect
>     there are some cases more, just below speed of light. But not so
>     many, I
>     believe the vast majority of the probes are all set properly.
> 
>     With software probes there is also the problem of less users
>     reporting a
>     location at all (I don't have numbers, based on an observation in a
>     past
>     experiment. It may no longer be the case).
> 
>     I don't remember if there is something similar already in place, but I
>     would suggest a process like:
>     - if a probe doesn't have a location, set a location calculated by
>     latency measurements AND ask the user to review the result at is first
>     convenience;
>     - for all the probes currently having a location, use latency
>     measurements to mark the one possibly wrong and ask the user for update.
>     - overall, use latency measurements to periodically review the probe's
>     location. RTTs can be used to mark obviously wrong locations, without
>     being too restrictive.
> 
>     For RTTs above a certain amount (the usual 10ms?), deactivate the RTT
>     validation so users are still able to place probes in exotic locations.
> 
>     I don't think there is a use case for obfuscating probes more than at
>     the city level. And if there is, these probes should be tagged as such.
> 
>     Ciao,
>     Massimo
> 
>     On 25/03/2021 13:00, Ponikierski, Grzegorz via ripe-atlas wrote:
>      > I would add to it additional problem that some hosts obfuscate probe
>      > location even more. For example you can find probes which in
>     reality are
>      > located in US but are marked as CN or probes which are in reality in
>      > Wisconsin but are marked in California. Of course these are extreme
>      > cases. I guess most hosts just put a pin with probe location just
>      > somewhere around where it's locate as long it's in the same city. I
>      > don't remember, as a host of 3 probes, to get any precise
>      > recommendations how to mark probe location. Personally I just put
>     a pin
>      > in city district where probe is locate.
>      >
>      > Regards,
>      >
>      > Grzegorz
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: starlink_rtt.png
Type: image/png
Size: 94292 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20210326/84102258/attachment.png>