[atlas] Probe location obfuscation

That's very brief gaps between starlink satellites, the network is still
sparse. I have a smokeping instance at the same site on a 60s interval,
packet loss to the default gateway is averaging between 0.25 to 0.85% over
4 hour periods. Periodically there are antenna maintenance and firmware
updates at 0200-0400 local time which cause downtime of anywhere from a few
minutes to a few hours.



On Fri, Mar 26, 2021 at 12:47 AM Romain Fontugne <romain at iij.ad.jp> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20210326/2df28f86/attachment.html>