<div dir="ltr"><div>Some quick thoughts</div><div><br></div><div><br></div><div><br></div>I think the RTT features are at this point the most helpfull because they improve the output accuracy. Other features such as visual representation are things others could change for their purpose. The RTT features can also be gradually build-in in terms of complexity.<div><br></div><div>If you do not take the first and last hop into account, then you are basically left with 'public' router locations. These cities are saved into the system, doing a count on them gives them a value that could be taken into account with the suggestions: "well known router locations / internet exchanges". If the lookup for a hop is not for the first/last one of the traceroute then the min-latency and the lat/long of the previous hop should give a radius where the current hop should be in. </div><div><br></div><div>Then check the known routerlocations and "popularity" for suggestions. If none are found, do the PTR name based suggestion.</div><div><br></div><div>This could be improved, if the certainty of the next hop is high, that radius could be used to limit the currents hop possible locations, but that is for later I think.<br></div><div><br></div><div>Also taking into account that traces of RIPE atlas have a known starting point and traces to a RIPE probe have a known end-point aswell. Not usefull for 3rd parties that use OpenIPmap but for the RIPE sources it will help improving the data.</div><div><br></div><div>When this is a public service, this could be abused or mis-used and polute the data. This is more a security issue, anonymous lookups might not be allowed to change router locations and registered users are logged to the system making it traceable. Maybe some sort of reputation system could also prevent a low reputation from overiding a location set by a (very) high reputation, option left is then to send a suggestion.</div><div><br></div><div>Sebastian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 24, 2014 at 12:55 PM, Emile Aben <span dir="ltr"><<a href="mailto:emile.aben@ripe.net" target="_blank">emile.aben@ripe.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br> Hash: SHA1<br> <br> </span><span class="">On 24/10/14 11:33, Sebastian Pesman wrote:<br> > Hi,<br> ><br> > Having done a few traceroute reviews myself; I like the indicator<br> > arrow of the route direction. Still missing an option to make a<br> > comment as some PTR records are very clear but very wrong, thus I<br> > suspect that some routers are incorrectly corrected. For now I<br> > clear them if it's not possible due to latency / distance but in<br> > another route this might not be that obvious and someone could<br> > correct it just on ptr record name.<br> <br> </span>Yes, having some 'evidence' records to annotate these cases would be<br> good to have, and having logic to be careful to update these would be<br> good. What I've come to learn is that errors in PTR records are even<br> more common then I expected initially, and even happen in the largest<br> networks.<br> <span class=""><br> > If something is build that takes the distance between locations<br> > into consideration it should use the lowest ICMP replies from both<br> > hops to calculate if this would be possible.<br> <br> </span>Yes, that'd be still subject to probe geoloc errors and RTT<br> measurement errors, but I also want that (one of the features I had<br> hoped to have in by now). On the viz representation (hover over a hop<br> shows the area within which that hop must be located, based on the<br> minRTT), but also for the suggestions ('red' entries) and crowdsourced<br> info ('green' entries) it would be good to take RTT into account.<br> <span class=""><br> > Also if a hop is within a milisecond from the previous one, it<br> > should suggest the same city instead of something name based. What<br> > should I do now? Give a MSM id or add a screenshot? Ok MSM id<br> > (can't copy it that easy > suggestion.....) msm:1769731 prb:13843<br> > ts:2014-10-21T08:59:48.000Z<br> <br> > Screenshot here / attached<br> <br> </span>Yes, better suggestions are possible based on RTT. Somebody else also<br> mentioned making all suggestions for RTTs < 1ms from the source<br> geolocate to the city the source is in.<br> <br> There are cases where packets to hop X are not routed over hop X-1<br> (routing changes during taking trace, or weird ECMP setups that hash<br> over other things that our traceroutes try to keep constant), but for<br> suggestions what you propose above is definitely doable.<br> <span class=""><br> > Point is, within developing this it's often about the data and<br> > routes, less about the visual represenation. A way to link directly<br> > to the data of the traceroute would be helpfull to discuss<br> > situations where indentifying locations is very wrong or could be<br> > better. In case of this screenshot hop 9 should be suggested as<br> > Vienna Austria instead of Suzhou in China.<br> <br> </span>Yes, how about storing the triplet of (measurement ID, probe ID,<br> timestamp) together with userID, timestamp and a comment.<br> Automatic adding of evidence is also possible then: Say we have a user<br> that puts an IP in London, we can do a ping from a RIPE Atlas anchor<br> in London, and if that results in very low latency (1ms?) that could<br> also be added as strong evidence.<br> <br> > Love the project!<br> <br> Good!<br> <br> I'm now wondering if I should prioritise getting RTT-based features in<br> first?<br> <span class=""><br> cheers,<br> Emile<br> -----BEGIN PGP SIGNATURE-----<br> Version: GnuPG v1<br> <br> </span>iQIcBAEBAgAGBQJUSjAaAAoJEKxthF6wloMO5Q0QAMOgE+/DNGTOkY/wGIKccVEd<br> md1zBCIwH7PcYbRT1H/IaqcQyv6+RUSmT7+hGq67E3brJ2/5VxgMMUETEqJY7rXs<br> dpdaqjZUsrlePKIzhDoOsaakOb3TzTA+66UjH9POvcFaKA+ZYbyWapBCXAr4j/DI<br> JTfrSP0dFsayb2bstmtQr+zqq6dKhlLbCif1CFY33X2pCa04eA+0gOa7f/IybQeH<br> aA57hOXUWMd4hafvFcDdqjimyn/qw6GcjD6lOwBocC1C3Fjtc/DmydEzL3VcKgNm<br> HF7jvh17jE75o6xAXEsmNugYZbsI+FrDd01E35mkEpDxqr2VlCZwgYsXwttkhNSu<br> 654SuuD+aTUItnD1v2e73mZcF746b9NHivcjer9uRe2mpUd0+j1iHpFtk9uWfVn+<br> 8aFUdJwSdMYrsnxO5JpHpU8GiITHpmv1ZKgS2m9mY2Vr/eQrIG2Lticq4gt27CAq<br> ikEXEUo10nfcXNsJkyukw7zyIOXUmDGoJ/OnNkPYSJSRMyN8OvJOiTS5WBNL9w4n<br> IRRdlCCbSP3BKXN6RcMX7cqF4bkYYqtFXf4DCkOSrhfG72lYIYp/W+x3b6yitxhm<br> HAp4upZqoCcuz7CVtpgRLy8v123zyAt7k4n32YXwpPkB5NTxhJm9e4yj4hH5GQhT<br> wDN5YRFmPGTXyv4Ocq9A<br> =U8qm<br> -----END PGP SIGNATURE-----<br> </blockquote></div><br></div>