Check out the new USENIX Web site. next up previous
Next: Coverage of GeoTrack Up: Experimental methodology Previous: Dataset from 1995


GeoTrack

Once we have gathered traceroute data, we use the GeoTrack tool, which we developed previously as part of the IP2Geo project [13], to translate the network path between a pair of hosts to the corresponding geographic path. GeoTrack tries to infer the location of a router based on its DNS name. Network operators often assign geographically meaningful names to routers3, presumably for administrative convenience. For example, the name corerouter1.SanFrancisco.cw.net corresponds to a router located in San Francisco. However, not all router names are recognizable (i.e., some router names may not contain an indication of location). Here is a brief outline of how GeoTrack works; please refer to [13] for a more detailed description. The DNS name of the router is parsed to determine if it contains any location codes. GeoTrack uses a database of approximately 2000 location codes for cities in the U.S. and in Europe. Each ISP tends to use its own naming convention, so there may be multiple codes for each city (e.g., chcg, chcgil, cgcil, chi, chicago, ord for Chicago, IL). GeoTrack incorporates ISP-specific parsing rules that specify the subset of valid codes and the position(s) in which they may appear in the router names. We use the domain name of a router to decide which ISP it belongs to. While this heuristic works reasonably well, it is not perfect because multiple domain names may correspond to the same administrative domain (e.g., alter.net and uu.net), often due to the merger of what were once independent networks. For the same reason, even AS numbers would not enable us to determine the administrative domain boundaries with complete accuracy.

Subsections
next up previous
Next: Coverage of GeoTrack Up: Experimental methodology Previous: Dataset from 1995
Lakshminarayanan Subramanian 2002-04-14