mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-20 10:12:15 +01:00
Code Issues Projects Releases Wiki Activity

another iteration of the experiences section

Browse Source 
svn:r997
This commit is contained in:
Roger Dingledine 2004-01-15 07:37:25 +00:00
parent 90c3b8f0c1
commit 521cdd1ecb
1 changed files with 22 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
doc/tor-design.tex
View File

@ -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}