[atlas] Probe location obfuscation
- Previous message (by thread): [atlas] Probe location obfuscation
- Next message (by thread): [atlas] Unused Probes (was: What to do with broken v1 probe?)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Eric Kuhnke
eric.kuhnke at gmail.com
Fri Mar 26 09:10:49 CET 2021
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: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20210326/2df28f86/attachment.html>
- Previous message (by thread): [atlas] Probe location obfuscation
- Next message (by thread): [atlas] Unused Probes (was: What to do with broken v1 probe?)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]