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 <mass...@us.ntt.net
<mailto:mass...@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
