[or-cvs] another iteration of the experiences section

[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:
another iteration of the experiences section


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -d -r1.130 -r1.131
--- tor-design.tex	15 Jan 2004 06:28:58 -0000	1.130
+++ tor-design.tex	15 Jan 2004 07:37:25 -0000	1.131
@@ -1616,8 +1616,8 @@
 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 @@
 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 @@
 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 @@
 %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}