aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorRoger Dingledine <arma@torproject.org>2004-01-15 07:37:25 +0000
committerRoger Dingledine <arma@torproject.org>2004-01-15 07:37:25 +0000
commit521cdd1ecb2ec750678af3e04d864b0d1b1e450e (patch)
treeb5b3cd97e93c29a53bceffb63da2f24bb42b44de /doc
parent90c3b8f0c1aad5fa65ee188d589b5a3a6858113e (diff)
downloadtor-521cdd1ecb2ec750678af3e04d864b0d1b1e450e.tar
tor-521cdd1ecb2ec750678af3e04d864b0d1b1e450e.tar.gz
another iteration of the experiences section
svn:r997
Diffstat (limited to 'doc')
-rw-r--r--doc/tor-design.tex40
1 files changed, 22 insertions, 18 deletions
diff --git a/doc/tor-design.tex b/doc/tor-design.tex
index 1e16c0806..724ed126f 100644
--- a/doc/tor-design.tex
+++ b/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}