nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 22:03:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Section on peer-to-peer bandwidth estimation

Browse Source 
svn:r18242
This commit is contained in:
Steven Murdoch 2009-01-22 21:07:30 +00:00
parent afc5b61777
commit 494dbd3ccb
1 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
doc/design-paper/performance.tex
View File

@ -76,6 +76,17 @@ For example, an attacker who wishes to monitor traffic could create several node
A Tor client trying to minimize latency would be more likely to select these nodes for both entry than exit than it would otherwise.
This particular problem could be mitigated by selecting entry and exit node as normal, and only using latency measurements to select the middle node.
\section{Peer-to-peer bandwidth estimation}
Snader and Borisov proposed that each Tor node opportunistically monitor the data rates that it achieves when communicating with other Tor nodes.
Since currently Tor uses a clique topology, given enough time, all nodes will communicate with all other Tor nodes.
If each Tor node reported their measurements back to a central authority, it would be possible to estimate the capacity of each Tor node.
This estimate would be difficult to game, when compared to the current self-advertisement of bandwidth capacity.
Experiments show that opportunistic bandwidth measurement has a better systematic error than Tor's current self-advertised measure, although has a poorer log-log correlation (0.48 vs. 0.57).
The most accurate scheme is active probing of capacity, with a log-log correlation of 0.63, but this introduces network overhead.
All three schemes do suffer from fairly poor accuracy, presumably due to some nodes with high variance in bandwidth capacity.
\section{Considering exit policy in node selection}
When selecting an exit node for a circuit, a Tor client will build a list of all exit nodes which can carry the desired stream, then select from them with a probability weighted by each node's capacity\footnote{The actual algorithm is slightly more complex, in particular exit nodes which are also guard nodes will be weighted less, and there is also preemptive circuit creation}.