diff options
| -rw-r--r-- | doc/tor-design.tex | 61 |
1 files changed, 34 insertions, 27 deletions
diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 4077a22a9..af9d96da7 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -87,7 +87,7 @@ the circuit. Traffic flows down the circuit in fixed-size \emph{cells}, which are unwrapped by a symmetric key at each node (like the layers of an onion) and relayed downstream. The Onion Routing project published several design and analysis -papers~\cite{or-ih96,or-jsac98,or-discex00,or-pet00}. While a wide area Onion +papers \cite{or-ih96,or-jsac98,or-discex00,or-pet00}. While a wide area Onion Routing network was deployed briefly, the only long-running public implementation was a fragile proof-of-concept that ran on a single machine. Even this simple deployment @@ -243,8 +243,9 @@ design~\cite{chaum-mix}. Chaum proposed hiding the correspondence between sender and recipient by wrapping messages in layers of public-key cryptography, and relaying them through a path composed of ``mixes.'' Each mix in turn -decrypts, delays, and re-orders messages, before relaying them toward -their destinations. +decrypts, delays, and re-orders messages, before relaying them +onward. +%toward their destinations. Subsequent relay-based anonymity designs have diverged in two main directions. Systems like {\bf Babel}~\cite{babel}, @@ -1495,15 +1496,15 @@ in~\cite{mix-acc}.\\ \Section{Early experiences: Tor in the Wild} \label{sec:in-the-wild} -As of mid-January 2004, the Tor network consists of 16 nodes -(14 in the US, 2 in Europe), and more are joining each week as the code +As of mid-January 2004, the Tor network consists of 17 nodes +(15 in the US, 2 in Europe), and more are joining each week as the code matures.\footnote{For comparison, the current remailer network has about 30 reliable nodes. We haven't asked PlanetLab to provide Tor nodes, since their AUP wouldn't allow exit nodes (see also~\cite{darkside}) and because we aim to build a long-term community of node operators and developers.} Each node has at least a 768Kb/768Kb connection, and -most have 10Mb. The number of users varies (and of course, it's hard to +many have 10Mb. The number of users varies (and of course, it's hard to tell for sure), but we sometimes have several hundred users---administrators at several companies have begun sending their entire departments' web traffic through Tor, to block other divisions of @@ -1520,15 +1521,7 @@ experience, and assuming we can resolve the anonymity issues, we may partition traffic into two relay cell sizes: one to handle bulk traffic and one for interactive traffic. -%We haven't asked to use PlanetLab~\cite{planetlab} to provide more nodes, -%because their AUP excludes projects like Tor (see also \cite{darkside}). -% I'm confused. Why are we mentioning PlanetLab at all? Could we perhaps -% be more generic? -NM -%We have had no abuse issues since the network was deployed in October -%2003. Our default exit policy rejects SMTP requests, to proactively -%avoid spam issues. Based in part on our restrictive default exit policy (we -% proactively chose to reject SMTP requests) and our low profile, we have had no abuse issues since the network was deployed in October 2003. Our slow growth rate gives us time to add features, @@ -1538,19 +1531,38 @@ anonymity sets, we are not eager to attract the Kazaa or warez communities---we feel that we must build a reputation for privacy, human rights, research, and other socially laudable activities. -As for performance, profiling shows that the Tor program itself spends almost +As for performance, profiling shows that Tor spends almost all its CPU time in AES, which is fast. Current latency is attributable to two factors. First, network latency is critical: we are intentionally bouncing traffic around the world several times. Second, our end-to-end congestion control algorithm focuses on protecting volunteer servers from accidental DoS rather than optimizing -performance. Right now the first $500 \times 500\mbox{B}=250\mbox{KB}$ -of the stream arrives -quickly, and after that throughput depends on the rate that \emph{relay -sendme} acknowledgments arrive. We can tweak the congestion control +performance. % Right now the first $500 \times 500\mbox{B}=250\mbox{KB}$ +%of the stream arrives +%quickly, and after that throughput depends on the rate that \emph{relay +%sendme} acknowledgments arrive. +For example, we did some informal tests using a test network of 4 nodes on +the same machine. We downloaded a 60 megabyte file from {\tt debian.org} +every 30 minutes for 2 days (100 sample points). It arrived in about +300 seconds on average, compared to 210s for a direct download. We ran +the same test on the main Tor network, pulling down the front page of +{\tt cnn.com}: while a direct download consistently took about 0.5s, +the performance through Tor was highly variable. Some downloads were +as fast as 0.6s, with others as slow as 25s (the average was 2.5s). It +seems that as the network expands, the chance of getting a slow circuit +(one that includes a slow or heavily loaded Tor node) is increasing. On +the other hand, we still have users, so this performance is good enough +for now. + +%With the current network's topology and load, users can typically get 1-2 +%megabits sustained transfer rate, which is good enough for now. +Indeed, the Tor +design aims foremost to provide a security research platform; performance +only needs to be sufficient to retain users~\cite{econymics,back01}. +We can tweak the congestion control parameters to provide faster throughput at the cost of larger buffers at each node; adding the heuristics mentioned in -Section~\ref{subsec:rate-limit} to give better speed to low-volume +Section~\ref{subsec:rate-limit} to favor low-volume streams may also help. More research remains to find the right balance. % We should say _HOW MUCH_ latency there is in these cases. -NM @@ -1558,14 +1570,9 @@ right balance. %performs badly on lossy networks. may need airhook or something else as %transport alternative? -With the current network's topology and load, users can typically get 1-2 -megabits sustained transfer rate, which is good enough for now. The Tor -design aims foremost to provide a security research platform; performance -only needs to be sufficient to retain users~\cite{econymics,back01}. - Although Tor's clique topology and full-visibility directories present scaling problems, we still expect the network to support a few hundred -nodes and perhaps 10,000 users before we're forced to make the network +nodes and maybe 10,000 users before we're forced to become more distributed. With luck, the experience we gain running the current topology will help us choose among alternatives when the time comes. @@ -1781,7 +1788,7 @@ our overall usability. \appendix -\Section{Rendezvous points and hidden services: Specifics} +\Section{Rendezvous points and hidden services} \label{sec:rendezvous-specifics} In this appendix we provide more specifics about the rendezvous points |