Re: [atlas] Probe location obfuscation
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 From: "Mccherry, Paul (Student)" <p.mccherry@lancaster.ac.uk> Date: Thursday 2021-03-25 at 11:20 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: [atlas] Probe location obfuscation Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://atlas.ripe.net/about/faq/#are-the-locations-of-probes-made-public<https://urldefense.com/v3/__https:/atlas.ripe.net/about/faq/*are-the-locations-of-probes-made-public__;Iw!!GjvTz_vk!EWq0OCOmS-1Af9zWmGzygQZxC02O19msR11hqwe7X3bHqvxoqX8Tt17N3fDKNB4$> I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.
One thing I noticed for probes at homes is sometimes linked to the source DC where the fibre/copper routers are located Col
On 25 Mar 2021, at 12:00, Ponikierski, Grzegorz via ripe-atlas <ripe-atlas@ripe.net> 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
From: "Mccherry, Paul (Student)" <p.mccherry@lancaster.ac.uk <mailto:p.mccherry@lancaster.ac.uk>> Date: Thursday 2021-03-25 at 11:20 To: "ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>" <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> Subject: [atlas] Probe location obfuscation
Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://atlas.ripe.net/about/faq/#are-the-locations-of-probes-made-public <https://urldefense.com/v3/__https:/atlas.ripe.net/about/faq/*are-the-locations-of-probes-made-public__;Iw!!GjvTz_vk!EWq0OCOmS-1Af9zWmGzygQZxC02O19msR11hqwe7X3bHqvxoqX8Tt17N3fDKNB4$>
I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.
Hi, On 2021-03-25 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.
We don't have strict rules about precisely how the hosts should geolocate their probes -- and could not enforce those even if we had them. Instead we recommend doing this "roughly correct", which for some hosts means city / neighbourhood is good enough, for some others it's the exact spot of the utility box at home :-)
Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://atlas.ripe.net/about/faq/#are-the-locations-of-probes-made-public <https://urldefense.com/v3/__https:/atlas.ripe.net/about/faq/*are-the-locations-of-probes-made-public__;Iw!!GjvTz_vk!EWq0OCOmS-1Af9zWmGzygQZxC02O19msR11hqwe7X3bHqvxoqX8Tt17N3fDKNB4$>
I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.
We have a very simple algorithm that does the obfuscation consistently with a certain maximum distance added, which may not be precisely 1km. We can talk offline about the details if you're really interested in the precise method. Cheers, Robert
Thanks Robert I am using the probe estimated geolocations to validate a new active geolocation method I am formulating. The probe I that I thought had an anomaly was in fact found to be within 1k distance of my estimated geo location using the new method. The original discrepancy was due to a number of factors that I had failed to accurately apply. However, I have other probes that have similar but different issues and whilst I am working my way through these issues any additional information you can provide would be greatly appreciated. Regards Paul McCherry Phd Student Lancaster University. ________________________________ From: Robert Kisteleki <robert@ripe.net> Sent: 25 March 2021 12:47 To: Mccherry, Paul (Student) <p.mccherry@lancaster.ac.uk>; ripe-atlas@ripe.net <ripe-atlas@ripe.net> Subject: [External] Re: [atlas] Probe location obfuscation This email originated outside the University. Check before clicking links or attachments. Hi, On 2021-03-25 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.
We don't have strict rules about precisely how the hosts should geolocate their probes -- and could not enforce those even if we had them. Instead we recommend doing this "roughly correct", which for some hosts means city / neighbourhood is good enough, for some others it's the exact spot of the utility box at home :-)
Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fatlas.ripe... <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fatlas.ripe.net%2Fabout%2Ffaq%2F*are-the-locations-of-probes-made-public__%3BIw!!GjvTz_vk!EWq0OCOmS-1Af9zWmGzygQZxC02O19msR11hqwe7X3bHqvxoqX8Tt17N3fDKNB4%24&data=04%7C01%7Cp.mccherry%40lancaster.ac.uk%7C0d707df0f3534cd8707008d8ef8c2bb3%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637522732594157947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VdT77jYEFo5pWuPHqRjnowZPIq9neOLHKc%2B47slBNI8%3D&reserved=0>
I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.
We have a very simple algorithm that does the obfuscation consistently with a certain maximum distance added, which may not be precisely 1km. We can talk offline about the details if you're really interested in the precise method. Cheers, Robert
2317 is actually 10 miles down the east lancs rd but configuration says manchester Col
On 26 Mar 2021, at 06:25, Mccherry, Paul (Student) <p.mccherry@lancaster.ac.uk> wrote:
Thanks Robert
I am using the probe estimated geolocations to validate a new active geolocation method I am formulating.
The probe I that I thought had an anomaly was in fact found to be within 1k distance of my estimated geo location using the new method. The original discrepancy was due to a number of factors that I had failed to accurately apply.
However, I have other probes that have similar but different issues and whilst I am working my way through these issues any additional information you can provide would be greatly appreciated.
Regards
Paul McCherry Phd Student Lancaster University.
From: Robert Kisteleki <robert@ripe.net <mailto:robert@ripe.net>> Sent: 25 March 2021 12:47 To: Mccherry, Paul (Student) <p.mccherry@lancaster.ac.uk <mailto:p.mccherry@lancaster.ac.uk>>; ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> Subject: [External] Re: [atlas] Probe location obfuscation
This email originated outside the University. Check before clicking links or attachments.
Hi,
On 2021-03-25 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.
We don't have strict rules about precisely how the hosts should geolocate their probes -- and could not enforce those even if we had them. Instead we recommend doing this "roughly correct", which for some hosts means city / neighbourhood is good enough, for some others it's the exact spot of the utility box at home :-)
Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fatlas.ripe... <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fatlas.ripe.net%2Fabout%2Ffaq%2F%23are-the-locations-of-probes-made-public&data=04%7C01%7Cp.mccherry%40lancaster.ac.uk%7C0d707df0f3534cd8707008d8ef8c2bb3%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637522732594157947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZRNBZBO61oUXTYZGVYNyfyNRG2J4sv4AIrchzrCitOg%3D&reserved=0><https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fatlas.ripe.net%2Fabout%2Ffaq%2F*are-the-locations-of-probes-made-public__%3BIw!!GjvTz_vk!EWq0OCOmS-1Af9zWmGzygQZxC02O19msR11hqwe7X3bHqvxoqX8Tt17N3fDKNB4%24&data=04%7C01%7Cp.mccherry%40lancaster.ac.uk%7C0d707df0f3534cd8707008d8ef8c2bb3%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637522732594157947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VdT77jYEFo5pWuPHqRjnowZPIq9neOLHKc%2B47slBNI8%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fatlas.ripe.net%2Fabout%2Ffaq%2F*are-the-locations-of-probes-made-public__%3BIw!!GjvTz_vk!EWq0OCOmS-1Af9zWmGzygQZxC02O19msR11hqwe7X3bHqvxoqX8Tt17N3fDKNB4%24&data=04%7C01%7Cp.mccherry%40lancaster.ac.uk%7C0d707df0f3534cd8707008d8ef8c2bb3%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637522732594157947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VdT77jYEFo5pWuPHqRjnowZPIq9neOLHKc%2B47slBNI8%3D&reserved=0>>
I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.
We have a very simple algorithm that does the obfuscation consistently with a certain maximum distance added, which may not be precisely 1km. We can talk offline about the details if you're really interested in the precise method.
Cheers, Robert
Thanks Colin Its useful to know that there are discrepancies such as this as it will save me time in relooking at my data and calculations and wondering why its isnt making sense. regards Paul ________________________________ From: Colin Johnston <colinj@mx5.org.uk> Sent: 26 March 2021 08:16 To: Mccherry, Paul (Student) <p.mccherry@lancaster.ac.uk> Cc: Robert Kisteleki <robert@ripe.net>; ripe-atlas@ripe.net <ripe-atlas@ripe.net> Subject: Re: [atlas] [External] Re: Probe location obfuscation 2317 is actually 10 miles down the east lancs rd but configuration says manchester Col On 26 Mar 2021, at 06:25, Mccherry, Paul (Student) <p.mccherry@lancaster.ac.uk<mailto:p.mccherry@lancaster.ac.uk>> wrote: Thanks Robert I am using the probe estimated geolocations to validate a new active geolocation method I am formulating. The probe I that I thought had an anomaly was in fact found to be within 1k distance of my estimated geo location using the new method. The original discrepancy was due to a number of factors that I had failed to accurately apply. However, I have other probes that have similar but different issues and whilst I am working my way through these issues any additional information you can provide would be greatly appreciated. Regards Paul McCherry Phd Student Lancaster University. ________________________________ From: Robert Kisteleki <robert@ripe.net<mailto:robert@ripe.net>> Sent: 25 March 2021 12:47 To: Mccherry, Paul (Student) <p.mccherry@lancaster.ac.uk<mailto:p.mccherry@lancaster.ac.uk>>; ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net> <ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net>> Subject: [External] Re: [atlas] Probe location obfuscation This email originated outside the University. Check before clicking links or attachments. Hi, On 2021-03-25 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.
We don't have strict rules about precisely how the hosts should geolocate their probes -- and could not enforce those even if we had them. Instead we recommend doing this "roughly correct", which for some hosts means city / neighbourhood is good enough, for some others it's the exact spot of the utility box at home :-)
I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.
We have a very simple algorithm that does the obfuscation consistently with a certain maximum distance added, which may not be precisely 1km. We can talk offline about the details if you're really interested in the precise method. Cheers, Robert
[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
More than a year ago I have started some statistical work to flag probes with likely incorrect geolocation. Unfortunately higher priority work has taken precedence since. I would make time to share and explain what I have done so far if someone were to convince me that they had serious intentions to progress the work. Daniel On 25 Mar 2021, at 14:02, Massimo Candela 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
I think it's very related topic. In my practice I regularly find mislocated probes and report them to RIPE because I don't have a way to contact directly with host. RIPE on the other hand can only politely ask host to update location. It's volunteer project after all. Of course majority of probes are marked correctly, otherwise whole project would be just a waste of time. Still, Another related topic of probe locations is Hong Kong. Some probes which has pins in Hong Kong have country set to China and some to Hong Kong. Apart from political problems, it's important to reliably distinguish Mainland China and Hong Kong SAR because from routing/Internet point of view these are on two different worlds on opposite sides of Great Firewall of China. It means that I have to manually select probes when I want to measure Mainland China or Hong Kong. Regards, Grzegorz From: Massimo Candela <massimo@us.ntt.net> Date: Thursday 2021-03-25 at 14:03 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: Re: [atlas] Probe location obfuscation [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
I have a file that I generate a few times a day with the MaxMind locations of all the probe addresses. It would be pretty trivial to run that against the official probe locations and generate a list of suspicious locations, but I don’t generally bother as I’m not sure what I would do with the data. When I’ve spot checked differences, Maxmind has seemed more frequently correct than the Atlas data (at least for eyeball networks), but both are far from perfect. I suspect you’d find the latency method below to be pretty inaccurate as well. If latency from a known-location probe were low, that would tell you something definitive, but if it were high it might just be telling you that the local ISPs in a region don’t talk to each other locally. Maxmind et al. have hopefully already done a bunch of that work. -Steve Global Traceroute
On Mar 25, 2021, at 6:02 AM, Massimo Candela <massimo@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
At least where I’m located, MaxMind (and other IP-to-location databases, if there are other ones in the game) don’t get any closer than the country. Regarding the Atlas-set location, I just checked and it turns out that the location pin is right down the street, but I know for a while in the past I had it about a 15 minute drive away for political reasons - the wrong flag was appearing on the info page. On Fri, Mar 26, 2021 at 1:52 AM Steve Gibbard <scg@gibbard.org> wrote:
I have a file that I generate a few times a day with the MaxMind locations of all the probe addresses.
It would be pretty trivial to run that against the official probe locations and generate a list of suspicious locations, but I don’t generally bother as I’m not sure what I would do with the data.
When I’ve spot checked differences, Maxmind has seemed more frequently correct than the Atlas data (at least for eyeball networks), but both are far from perfect.
I suspect you’d find the latency method below to be pretty inaccurate as well. If latency from a known-location probe were low, that would tell you something definitive, but if it were high it might just be telling you that the local ISPs in a region don’t talk to each other locally. Maxmind et al. have hopefully already done a bunch of that work.
-Steve Global Traceroute
On Mar 25, 2021, at 6:02 AM, Massimo Candela <massimo@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
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/ ) 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@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
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@us.ntt.net <mailto:massimo@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
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@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
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@us.ntt.net <mailto:massimo@us.ntt.net>> wrote:
[possibly OT]
In 2018 we found 18 probes which were located so far from reality
On 3/26/21 10:32 AM, Eric Kuhnke wrote: 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
participants (10)
-
Colin Johnston -
Daniel Karrenberg -
Eric Kuhnke -
Massimo Candela -
Mccherry, Paul (Student) -
Micha Bailey -
Ponikierski, Grzegorz -
Robert Kisteleki -
Romain Fontugne -
Steve Gibbard