nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 22:03:31 +01:00
Code Issues Packages 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 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 (14 in the US, 2 in Europe), and more are joining each week as the code
matures.\footnote{For comparison, the current remailer network matures.\footnote{For comparison, the current remailer network
has about 30 reliable nodes.} Each node has at least a 768k/768k connection, has about 30 reliable nodes.} Each node has at least a 768Kb/768Kb
and connection, and
most have 10Mb. The number of users varies (and of course, it's hard to 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 tell for sure), but we sometimes have several hundred users---admins at
several companies have started putting their entire department's web 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 their company from reading the traffic. Tor users have reported using
the network for web browsing, ftp, IRC, AIM, Kazaa, and ssh. 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\% 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, 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 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 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 traffic like ssh brings down the average a lot---once we have more
experience, and assuming we can resolve the anonymity issues, we may 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. bulk traffic and one for interactive traffic.
We haven't asked to use PlanetLab \cite{planetlab} to provide more nodes, %We haven't asked to use PlanetLab \cite{planetlab} to provide more nodes,
because their AUP excludes projects like Tor (see also \cite{darkside}). %because their AUP excludes projects like Tor (see also \cite{darkside}).
% I'm confused. Why are we mentioning PlanetLab at all? Could we perhaps % I'm confused. Why are we mentioning PlanetLab at all? Could we perhaps
% be more generic? -NM % be more generic? -NM
On the other hand, we have had no abuse issues since the network was %We have had no abuse issues since the network was deployed in October
deployed in October 2003. Our default exit policy rejects SMTP requests, %2003. Our default exit policy rejects SMTP requests, to proactively
to avoid spam issues. Our slow growth rate gives us time to add features, %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 resolve bugs, and get a feel for what users actually want from an
anonymity system. Even though having more users would bolster our anonymity system. Even though having more users would bolster our
anonymity sets, we are not eager to attract the Kazaa or warez 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, intentionally bouncing traffic around the world several times. Second,
our end-to-end congestion control algorithm focuses on protecting our end-to-end congestion control algorithm focuses on protecting
volunteer servers from accidental DoS rather than optimizing 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 of the stream arrives
quickly, and after that throughput depends on the rate that \emph{relay quickly, and after that throughput depends on the rate that \emph{relay
sendme} acknowledgments arrive. We can tweak the congestion control sendme} acknowledgments arrive. We can tweak the congestion control
@ -1669,16 +1674,15 @@ right balance.
%transport alternative? %transport alternative?
With the current network's topology and load, users can typically get 1-2 With the current network's topology and load, users can typically get 1-2
megabits sustained transfer rate. Overall, this performance is sufficient megabits sustained transfer rate, which is good enough for now. The Tor
for most of our users. The Tor design aims foremost for security; design aims foremost to provide a security research platform; performance
performance is secondary. just needs to be sufficient to not shed users \cite{econymics,back01}.
Although Tor's clique topology and full-visibility directories present Although Tor's clique topology and full-visibility directories present
scaling problems, we still expect the network to a few hundred nodes and scaling problems, we still expect the network to support a few hundred
perhaps 10,000 users, before we're forced to change topologies to become nodes and perhaps 10,000 users, before we're forced to make the network
more distributed. With luck, the experience we gained running the more distributed. With luck, the experience we gain running the current
current topology will help us choose among alternatives when the time topology will help us choose among alternatives when the time comes.
comes.
\Section{Open Questions in Low-latency Anonymity} \Section{Open Questions in Low-latency Anonymity}
\label{sec:maintaining-anonymity} \label{sec:maintaining-anonymity}