another iteration of the experiences section

svn:r997

doc/tor-design.tex

@@ -1616,8 +1616,8 @@ with a session key shared by Alice and Bob.
 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
 matures.\footnote{For comparison, the current remailer network
-has about 30 reliable nodes.} Each node has at least a 768k/768k connection, 
-and
+has about 30 reliable nodes.} 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
 tell for sure), but we sometimes have several hundred users---admins at
 several companies have started putting their entire department's web
@@ -1625,23 +1625,28 @@ traffic through Tor, to block snooping admins in other divisions of
 their company from reading the traffic. Tor users have reported using
 the network for web browsing, ftp, IRC, AIM, Kazaa, and ssh.
 
-Each Tor currently node currently processes roughly 800,000 relay
+Each Tor node currently processes roughly 800,000 relay
 cells (a bit under half a gigabyte) per week. On average, about 80\%
 of each 500-byte payload is full for cells going back to the client,
 whereas about 40\% is full for cells coming from the client. (The difference
 arises because most of the network's traffic is web browsing.) Interactive
 traffic like ssh brings down the average a lot---once we have more
 experience, and assuming we can resolve the anonymity issues, we may
-consider partitioning traffic into two relay cell sizes: one to handle
+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}). 
+%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
-On the other hand, we have had no abuse issues since the network was
-deployed in October 2003. Our default exit policy rejects SMTP requests,
-to avoid spam issues.  Our slow growth rate gives us time to add features,
+%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,
 resolve bugs, and get a feel for what users actually want from an
 anonymity system.  Even though having more users would bolster our
 anonymity sets, we are not eager to attract the Kazaa or warez
@@ -1655,7 +1660,7 @@ 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}$ 
+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
@@ -1669,16 +1674,15 @@ right balance.
 %transport alternative?
 
 With the current network's topology and load, users can typically get 1-2
-megabits sustained transfer rate. Overall, this performance is sufficient
-for most of our users.  The Tor design aims foremost for security;
-performance is secondary.
+megabits sustained transfer rate, which is good enough for now. The Tor
+design aims foremost to provide a security research platform; performance
+just needs to be sufficient to not shed users \cite{econymics,back01}.
 
 Although Tor's clique topology and full-visibility directories present
-scaling problems, we still expect the network to a few hundred nodes and
-perhaps 10,000 users, before we're forced to change topologies to become
-more distributed.  With luck, the experience we gained running the
-current topology will help us choose among alternatives when the time
-comes.
+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
+more distributed. With luck, the experience we gain running the current
+topology will help us choose among alternatives when the time comes.
 
 \Section{Open Questions in Low-latency Anonymity}
 \label{sec:maintaining-anonymity}