[or-cvs] add some informal performance statements

[arma@seul.org (Roger Dingledine)]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-design.tex 
Log Message:
add some informal performance statements
tighten the tex


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.141
retrieving revision 1.142
diff -u -d -r1.141 -r1.142
--- tor-design.tex	30 Jan 2004 13:38:25 -0000	1.141
+++ tor-design.tex	30 Jan 2004 15:06:59 -0000	1.142
@@ -87,7 +87,7 @@
 \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 @@
 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 @@
 \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 @@
 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 @@
 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 @@
 %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 @@
 
 \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