DOI: 10.5281/zenodo.4911583
title: Large-scale Latency Measurements in the Tor Network

description: <em>This dataset supplements our following research paper:</em> [1] Schatz, David; Rossberg, Michael; Schaefer, Guenter: Optimizing Packet Scheduling and Path Selection for Anonymous Voice Calls. Accepted at ARES 2021. <strong>Measurement Method</strong> The basic idea to estimate the latency (one-way delay) between any two Tor relays <em>u, v </em>is as follows [2]: Use a measurement agent <em>a</em> (a custom Tor client [3]). Pick an arbitrary entry relay <em>e</em> and build a three hop circuit <em>(e, u, v)</em>, i.e. network packets would normally traverse the path <em>(a, e, u, v)</em> and back. Agent <em>a</em> asks the relay <em>v</em> to open a connection to <em>localhost</em>, which will be refused with a special error message. The agent <em>a</em> can measure the RTT (round-trip time) of this failed attempt and divide it by 2 to get an estimate of the one-way latency d<sub>l</sub> of the path <em>(a, e, u, v)</em>. Due to the "leaky pipe" design of Tor, the agent <em>a</em> can do the same with relay <em>u</em> to estimate the one-way latency <em>d<sub>s</sub></em> of the path <em>(a, e, u)</em>. The estimation for the one-way delay between relays <em>u</em> and <em>v </em>is <em>d<sub>u,v</sub> = d<sub>l</sub> - d<sub>s</sub></em>. <strong>Measurement Series</strong> As agent, we used a PC at the TU Ilmenau in Germany, connected to the DFN network. As entry relays, we always used Tor relays from Germany as well. To later reduce the influence of random jitter in our estimations, we measured both <em>d<sub>l</sub></em> and <em>d<sub>s</sub></em> for a pair <em>u, v</em> 100 times (once overy 0.5 seconds). The measurements took place from 2019-12-19 to 2021-01-06. <strong>Dataset Content</strong> The dataset consists of three files: <em>paths</em>: This file contains the measurement results for <em>d<sub>l</sub></em> and <em>d<sub>s</sub></em> for each pair <em>u, v</em> we measured. Each line consists of 4 entries (separated by a space): Our internal ids for u and v, an indication if it is <em>d<sub>l</sub></em> (value = 3) or <em>d<sub>s</sub></em> (value = 2), and a comma separated list of the 100 (or less due to potential packet loss) measurements. Each measurement is the one-way latency in <strong>microseconds</strong>. <em>probedRelays</em>: This file contains the mapping from our internal ids of relays to their Tor fingerprints, one in each line, separated by a space. <em>relayInfo</em>: This file contains a subset of the relay descriptors for all active relays during our measurement period, one per line. Each line contains 4 entries: The fingerprint, the IP address, the consensus weight and a comma seperated list of flags. Note that we only measured relays which include the flags <em>stable, running, </em>and<em> valid</em>. The file was last updated on 2021-01-06 (relays that were not online at this date show their last known infos before that date). <strong>Our Pre-Processing</strong> For our research [1], we used the minium values for <em>d<sub>l</sub></em> and <em>d<sub>s</sub></em> (of the 100 each) to get <em>one latency estimate</em> <em>d<sub>u,v </sub></em>for each pair <em>u, v. </em>We further filtered 90 duplicates, i.e. 90 internal ids that actually mapped to the same fingerprint as some other id, leaving a total of 4102 probed relays. Further filtering was done as described in [1]. <strong>Limitations</strong> Unfortunately, we did not record the timestamp of measurements. Nevertheless, the <em>paths</em> file lists our measurements in chronological order and the measurement "speed" was constant during the ~2 years of measurements. Furthermore, we did not record the fingerprint of the selected entry relays. Further note that the long measurement period of ~2 years implies that estimated latencies do not capture a "snapshot" of the Tor network. For example, if a relay <em>v</em> got an "upgraded" access links during the two years, early estimates containing <em>v</em> will be higher than later estimates. <strong>References</strong> [2] Panchenko, Andriy; Renner, Johannes. Path Selection Metrics for Performance-Improved Onion Routing. SAINT 2009. Pages 114–120. [3] To build custom Tor circuits, we used the Python library <em>stem</em>, which uses the control port of a local Tor client.
description: {"references": ["Andriy Panchenko and Johannes Renner. 2009. Path Selection Metrics for Performance-Improved Onion Routing. In SAINT. 114\u2013120"]}