mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-11 05:33:47 +01:00
5166e5ff55
on the specifics of recording, storing, and learning circuitbuildtimeout parameters. svn:r16511
113 lines
4.3 KiB
Plaintext
113 lines
4.3 KiB
Plaintext
Filename: 151-path-selection-improvements.txt
|
|
Title: Improving Tor Path Selection
|
|
Version:
|
|
Last-Modified:
|
|
Author: Fallon Chen, Mike Perry
|
|
Created: 5-Jul-2008
|
|
Status: Draft
|
|
|
|
Overview
|
|
|
|
The performance of paths selected can be improved by adjusting the
|
|
CircuitBuildTimeout and avoiding failing guard nodes. This proposal
|
|
describes a method of tracking buildtime statistics at the client, and
|
|
using those statistics to adjust the CircuitBuildTimeout.
|
|
|
|
Motivation
|
|
|
|
Tor's performance can be improved by excluding those circuits that
|
|
have long buildtimes (and by extension, high latency). For those Tor
|
|
users who require better performance and have lower requirements for
|
|
anonymity, this would be a very useful option to have.
|
|
|
|
Implementation
|
|
|
|
Storing Build Times
|
|
|
|
Circuit build times will be stored in the circular array
|
|
'circuit_build_times' consisting of uint16_t elements as milliseconds.
|
|
The total size of this array will be based on the number of circuits
|
|
it takes to converge on a good fit of the long term distribution of
|
|
the circuit builds for a fixed link. We do not want this value to be
|
|
too large, because it will make it difficult for clients to adapt to
|
|
moving between different links.
|
|
|
|
From our initial observations, this value appears to be on the order
|
|
of 1000, but will be configurable in a #define NCIRCUITS_TO_OBSERVE.
|
|
|
|
Long Term Storage
|
|
|
|
The long-term storage representation will be implemented by storing a
|
|
histogram with BUILDTIME_BIN_WIDTH millisecond buckets (default 50) when
|
|
writing out the statistics to disk. The format of this histogram on disk
|
|
is yet to be finalized, but it will likely be of the format
|
|
'CircuitBuildTime <bin> <count>'.
|
|
Example:
|
|
|
|
CircuitBuildTimeBin 1 100
|
|
CircuitBuildTimeBin 2 50
|
|
...
|
|
|
|
Reading the histogram in will entail multiplying each bin by the
|
|
BUILDTIME_BIN_WIDTH and then inserting <count> values into the
|
|
circuit_build_times array each with the value of
|
|
<bin>*BUILDTIME_BIN_WIDTH.
|
|
|
|
Learning the CircuitBuildTimeout
|
|
|
|
Based on studies of build times, we found that the distribution of
|
|
circuit buildtimes appears to be a Pareto distribution.
|
|
|
|
We will calculate the parameters for a Pareto distribution
|
|
fitting the data using the estimators at
|
|
http://en.wikipedia.org/wiki/Pareto_distribution#Parameter_estimation.
|
|
|
|
The timeout itself will be calculated by solving the CDF for the
|
|
a percentile cutoff BUILDTIME_PERCENT_CUTOFF. This value
|
|
represents the percentage of paths the Tor client will accept out of
|
|
the total number of paths. We have not yet determined a good
|
|
cutoff for this mathematically, but 85% seems a good choice for now.
|
|
|
|
From http://en.wikipedia.org/wiki/Pareto_distribution#Definition,
|
|
the calculation we need is pow(BUILDTIME_PERCENT_CUTOFF/100.0, k)/Xm.
|
|
|
|
When to Begin Calculation
|
|
|
|
The number of circuits to observe (NCIRCUITS_TO_CUTOFF) before
|
|
changing the CircuitBuildTimeout will be tunable via a #define. From
|
|
our measurements, a good value for NCIRCUITS_TO_CUTOFF appears to be
|
|
on the order of 100.
|
|
|
|
Dealing with Timeouts
|
|
|
|
Timeouts should be counted as the expectation of the region of
|
|
of the Pareto distribution beyond the cutoff. The proposal will
|
|
be updated with this value soon.
|
|
|
|
Also, in the event of network failure, the observation mechanism
|
|
should stop collecting timeout data.
|
|
|
|
Circuits that timeout will be destroyed, as this indicates one
|
|
or more of their respective nodes are currently overloaded.
|
|
|
|
Client Hints
|
|
|
|
Some research still needs to be done to provide initial values
|
|
for CircuitBuildTimeout based on values learned from modem
|
|
users, DSL users, Cable Modem users, and dedicated links. A
|
|
radiobutton in Vidalia should eventually be provided that
|
|
sets CircuitBuildTimeout to one of these values and also
|
|
provide the option of purging all learned data, should any exist.
|
|
|
|
These values can either be published in the directory, or
|
|
shipped hardcoded for a particular Tor version.
|
|
|
|
Issues
|
|
|
|
Impact on anonymity
|
|
|
|
Since this follows a Pareto distribution, large reductions on the
|
|
timeout can be achieved without cutting off a great number of the
|
|
total paths. This will eliminate a great deal of the performance
|
|
variation of Tor usage.
|