iPlane: Datasets

CSE Home

About Us

Search

Contact Info

Below are the datasets generated as part of the measurements gathered by iPlane. Each dataset is accompanied by the methodology used to generate it and a description of its format.

• Archives of traceroutes performed (today - 2689 MB) (yesterday - 2694 MB) (day before yesterday - 2683 MB) - Refreshed daily
  
  iPlane Nano (atlas) and (daily update) - Refreshed daily
  
  List of per-vantage traceroute files from today.
  
  Logs of per-vantage traceroute files over the whole period of iPlane's lifetime.
  
  Measurement method: iPlane performs traceroutes from several vantage points daily to map the Internet's topology.  Above are pointers to the traceroute logs gathered over the past three days.  The archive for each day has a trace.out.vantage_point file, one for each vantage point, that contains all the traceroutes gathered on that day from vantage_point. 
  
  Format: Every trace.out log file contains a sequence of records. Each record begins with a header, and is followed by a sequence of traceroutes. The record header comprises a 4-byte client ID, a 4-byte unique ID, a 4-byte count of number of traceroutes in the record, and a 4-byte count of the length of the record in terms of bytes.  Each traceroute entry begins with a header of its own, and is followed by an entry for each hop along the path measured.  The traceroute header comprises a 4-byte destination IP address and a 4-byte count of the number of hops on the path.  The entry for each hop is a 4-byte IP address of that hop, a 4-byte floating point value of RTT to that hop, and a 4-byte TTL value in the response received from that hop.  The TTL value has been incremented by 256 for cases when the hop was discovered to be part of an MPLS tunnel.
  The tool readoutfile can be used to read out each trace.out file. The source code for this tool is here.


• Lists of alias clusters - Refreshed every two months
  
  Measurement method: iPlane discovers all sets of aliases among the interfaces observed in traceroutes.  Alias candidates are identified using two known techniques---interfaces that return the same source address when probed with UDP packets are on the same router, interfaces on either end of a link in the core are usually in the same /30 prefix.  True aliases are then identified as ones that return similar IP-IDs and identical return TTLs when probed at the same time.
  
  Format: We provide all sets of alias sets that we have discovered. Each line in this file contains a space-separated list of interfaces that correspond to a single router.


• IP to PoP mapping - Refreshed every two months
  
  Measurement method: All the interfaces observed in traceroutes are further clustered into Points of Presence (PoPs) within each AS, i.e., all interfaces that are in the same AS and are in the same location are clustered together.  Apart from the identification of aliases, clustering uses two other techniques. Locations of interfaces are inferred based on their DNS names, using rules from the undns and sarangworld projects. Here are archives of the undns and sarangworld rulesets that include our updates to these name-to-location mappings. The mapping of interfaces we have discovered to their locations based on their DNS names is here.
  
  Format: Each line in this IP-to-PoP mapping file contains a space-separated (IP address, PoP-number, latitude, longitude) tuple. The PoP-number has no significance other than that all addresses mapped to the same PoP-number are in the same PoP. Tuples with invalid values for the latitude or longitude coordinate correspond to PoPs for which we do not know the exact location.


• Origin AS mapping - Refreshed every two months
  
  Measurement method: BGP feeds from several sources---RouteViews, RIPE, Abilene, and Dante---are merged to assemble a large set of AS paths.  In each AS path to a particular prefix, the prefix is deemed to be in the last AS on that path.
  
  Format: Each line in this file is a space-separated pair of a prefix and its origin AS.


• IP to AS mapping - Refreshed every two months
  
  Measurement method: To further refine the AS mapping for each interface in the measured topology, iPlane maps each router to its AS.  In each set of aliases, every interface is mapped to its origin AS, and then the AS mapping for each interface is revised to be the AS that accounts for a majority.
  
  Format: We provide a file where each line contains an interface's address followed by the AS to which it is mapped.


• Access link bandwidths - Refreshed periodically
  
  Measurement method: iPlane measures bandwidth capacities of access links in the Internet by participating in several popular BitTorrent swarms. The bandwidth of an end-host's access link is measured by passively monitoring the TCP connection on which the end-host uploads data to one of iPlane's vantage points. We find that our measured bandwidths are similar across end-hosts within the same /24 prefix.
  
  Format: Each line in the file contains a space-separated pair of the address of a /24 prefix and the median of access link bandwidths (in Kbps) measured by iPlane for end-hosts in this prefix.


• Internet Atlas with IP to PoP mapping and Inter-PoP links - Refreshed daily
  
  Measurement method: Our daily traceroutes are processed using the AS mapping and IP-to-PoP clustering datasets to identify all the inter-PoP links we observe. These links constitute the topology of the Internet as observed by iPlane.
  
  Format: Each line in the file contains one distinct inter-PoP link. The format of each line is "cluster1 as1 cluster2 as2 latency", representing a link between PoPs numbered cluster1 and cluster2 (cluster numbers correspond to those in the IP-to-PoP mapping dataset), where these PoPs are in ASes as1 and as2, respectively (AS number is 0 if unknown). latency is our estimated latency for this link; a negative value is assigned if we do not have any estimate.


• Loss rates of inter-PoP segments - Refreshed daily
  
  Measurement method: The set of inter-PoP links in the atlas is partitioned across all PlanetLab nodes. Each PlanetLab node measures the loss rates along the links assigned to it by sending out 100 1KB ICMP-ECHO probes along each link with an inter-probe spacing of 2 seconds.
  
  Format: Each line in the file corresponds to one distinct inter-PoP segment (inter-cluster links chained together by clusters of degree two are merged to a single segment). The format of each line is "cluster1 cluster2 loss-rate", representing a segment between PoPs numbered cluster1 and cluster2 (cluster numbers correspond to those in the IP-to-PoP mapping dataset), with the loss rate on this segment measured to be loss-rate.

	Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to iplane-support]