Date: Fri, 23 May 1997 17:12:36 -0700

From: John Hanley [jh@borogove.yahoo.com]

[section deleted]

I was observing that several detail records of a prefix (or of a /32) might be looked up by a fancy /usr/local/bin/traceroute and displayed, so as to help the user when he interprets the output.

Mapping prefix to AS number to ISP_name is useful, and has been done.

Mapping /32 to LatLong, or prefix to LatLong, or AS to LatLong, or domain name (in PTR) to LatLong, can be useful, and to some extent has been done. My personal favorite application of this is to nail down cases where "going round the long way" has a perceptible performance impact, due to speed_of_light on the "too long" path being some appreciable number of milliseconds. Alas, mapping strings like "dcb-7513-1-h11-0.cwi.net" to "Arlington VA" can be a full-time job. So the vendor (Cable&Wireless, here) should encode the info, as he know where he put the box, but few tools exploit LOC records, so few vendors are incented to publically document their network. Perhaps if a tool queried first 42.255.142.206.in-addr.arpa (miss), and then looked up an LOC from a shadow database, like 42.255.142.206.loc.nlanr.net, the chicken&egg bootstrapping problem could be overcome. (Look at how haphazard PTR maintenance is -- vendors only register them because traceroute is invaluable to them.)

Mapping prefix (or /32) to URL of geographically/topologically "nearby" traceroute.cgi would assist in doing bi-directional traceroutes. One-directional traceroutes lack info about asymetric routes and about loss of TTL_exceeded_ICMPs taking the return route. Two-direction traceroutes are a _little_ easier to interpret; they can at least allow one to verify/disprove a "symetric path" assumption which a human might be labouring under.

Mapping prefix (or /32) to a "nearby" NetNowD would assist in making one-way measurements.

Mapping a /32 (or /32<=>/32 link) to a database entry of recent performance measurements, or recent MIB stats, would be very very useful. If the database contained pathchar measurements, for example, we could start out with pathchar knowing the line rate of the physical link, and merely verifying (sanity checking) that results seen by a possibly distant client are consistent with the database's claim. The database entry could enjoy the benefits of being measured from a nearby workstation, and of being the filtered result of orders of magnitude more samples than a possibly distant client would inject into the network.

In each of these cases, network vendors, their users, and distant users could benefit from the mapping. Having the vendor maintain and publish the data is the most scalable approach, but it seems unlikely, given their reluctance thus far and given the slight benefits they would reap from current tools. Having 3rd party (3rd parties) create and maintain such mappings for diverse networks would at least offer a way to bootstrap out of chick&egg land, and might even be a sustainable effort in the long term.

Traceroute currently shows hops but doesn't show much context (doesn't describe the network neighborhood of a hop). Consider:

http://maps.yahoo.com/yt.hm?CMD=GEOPATH&oa1=Yahoo&oa2=3400+Central+Expy&IC=37.37766:-121.98876:555:3400+Central+Expy:::2:&oa3=Santa+Clara%2c+CA&FAM=yahoo&SEC=trip&stex=-y&dname=Apple&GMI=1&AD2=1+Infinite+Loop&AD3=cupertino

and then consider the context provided by the "Detailed Directions" link. I think the ever-complexifying commercial Internet could be better documented and understood if analagous context were kept up-to-date and displayed by widely-used tools.

Cheers,

BTW, I have LOC's for the following, but don't use tools which benefit from them:

yahoo.com {chicago-office,europe,telia.europe,lon,paris,sg}.yahoo.com