[OpenIPMap] A long-overdue update on the status of openipmap

Emile Aben emile.aben at ripe.net
Fri Oct 24 12:55:22 CEST 2014 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/10/14 11:33, Sebastian Pesman wrote:
> Hi,
> 
> Having done a few traceroute reviews myself; I like the indicator
> arrow of the route direction. Still missing an option to make a
> comment as some PTR records are very clear but very wrong, thus I
> suspect that some routers are incorrectly corrected. For now I
> clear them if it's not possible due to latency / distance but in
> another route this might not be that obvious and someone could
> correct it just on ptr record name.

Yes, having some 'evidence' records to annotate these cases would be
good to have, and having logic to be careful to update these would be
good. What I've come to learn is that errors in PTR records are even
more common then I expected initially, and even happen in the largest
networks.

> If something is build that takes the distance between locations
> into consideration it should use the lowest ICMP replies from both
> hops to calculate if this would be possible.

Yes, that'd be still subject to probe geoloc errors and RTT
measurement errors, but I also want that (one of the features I had
hoped to have in by now). On the viz representation (hover over a hop
shows the area within which that hop must be located, based on the
minRTT), but also for the suggestions ('red' entries) and crowdsourced
info ('green' entries) it would be good to take RTT into account.

> Also if a hop is within a milisecond from the previous one, it
> should suggest the same city instead of something name based. What
> should I do now? Give a MSM id or add a screenshot? Ok MSM id
> (can't copy it that easy > suggestion.....)  msm:1769731 prb:13843 
> ts:2014-10-21T08:59:48.000Z

> Screenshot here / attached

Yes, better suggestions are possible based on RTT. Somebody else also
mentioned making all suggestions for RTTs < 1ms from the source
geolocate to the city the source is in.

There are cases where packets to hop X are not routed over hop X-1
(routing changes during taking trace, or weird ECMP setups that hash
over other things that our traceroutes try to keep constant), but for
suggestions what you propose above is definitely doable.

> Point is, within developing this it's often about the data and
> routes, less about the visual represenation. A way to link directly
> to the data of the traceroute would be helpfull to discuss
> situations where indentifying locations is very wrong or could be
> better. In case of this screenshot hop 9 should be suggested as
> Vienna Austria instead of Suzhou in China.

Yes, how about storing the triplet of (measurement ID, probe ID,
timestamp) together with userID, timestamp and a comment.
Automatic adding of evidence is also possible then: Say we have a user
that puts an IP in London, we can do a ping from a RIPE Atlas anchor
in London, and if that results in very low latency (1ms?) that could
also be added as strong evidence.

> Love the project!

Good!

I'm now wondering if I should prioritise getting RTT-based features in
first?

cheers,
Emile
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUSjAaAAoJEKxthF6wloMO5Q0QAMOgE+/DNGTOkY/wGIKccVEd
md1zBCIwH7PcYbRT1H/IaqcQyv6+RUSmT7+hGq67E3brJ2/5VxgMMUETEqJY7rXs
dpdaqjZUsrlePKIzhDoOsaakOb3TzTA+66UjH9POvcFaKA+ZYbyWapBCXAr4j/DI
JTfrSP0dFsayb2bstmtQr+zqq6dKhlLbCif1CFY33X2pCa04eA+0gOa7f/IybQeH
aA57hOXUWMd4hafvFcDdqjimyn/qw6GcjD6lOwBocC1C3Fjtc/DmydEzL3VcKgNm
HF7jvh17jE75o6xAXEsmNugYZbsI+FrDd01E35mkEpDxqr2VlCZwgYsXwttkhNSu
654SuuD+aTUItnD1v2e73mZcF746b9NHivcjer9uRe2mpUd0+j1iHpFtk9uWfVn+
8aFUdJwSdMYrsnxO5JpHpU8GiITHpmv1ZKgS2m9mY2Vr/eQrIG2Lticq4gt27CAq
ikEXEUo10nfcXNsJkyukw7zyIOXUmDGoJ/OnNkPYSJSRMyN8OvJOiTS5WBNL9w4n
IRRdlCCbSP3BKXN6RcMX7cqF4bkYYqtFXf4DCkOSrhfG72lYIYp/W+x3b6yitxhm
HAp4upZqoCcuz7CVtpgRLy8v123zyAt7k4n32YXwpPkB5NTxhJm9e4yj4hH5GQhT
wDN5YRFmPGTXyv4Ocq9A
=U8qm
-----END PGP SIGNATURE-----