nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-09-20 21:16:22 +02:00
Code Issues Packages Projects Releases Wiki Activity

edit experiences section

Browse Source 
svn:r996
This commit is contained in:
Nick Mathewson 2004-01-15 06:28:58 +00:00
parent 1d760b34ad
commit 90c3b8f0c1
1 changed files with 40 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
doc/tor-design.tex
View File

@ -1613,10 +1613,11 @@ with a session key shared by Alice and Bob.
\Section{Early experiences: Tor in the Wild} \Section{Early experiences: Tor in the Wild}
\label{sec:in-the-wild} \label{sec:in-the-wild}
The current Tor network, as of mid January 2004, consists of 16 nodes As of mid-January 2004, the Tor network consists of 16 nodes
(14 in the US, 2 in Europe), and we're adding more each week as the code (14 in the US, 2 in Europe), and more are joining each week as the code
gets more robust.\footnote{For comparison, the current remailer network matures.\footnote{For comparison, the current remailer network
has about 30 nodes.} Each node has at least a 768k/768k connection, and has about 30 reliable nodes.} Each node has at least a 768k/768k 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
@ -1624,53 +1625,60 @@ 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.
As of mid January, each Tor node was processing roughly 800,000 relay Each Tor currently 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. (They are whereas about 40\% is full for cells coming from the client. (The difference
difference because most of our 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 will experience, and assuming we can resolve the anonymity issues, we may
consider partitioning traffic into two relay cell sizes: one to handle consider partitioning 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}. On because their AUP excludes projects like Tor (see also \cite{darkside}).
the other hand, we have had no abuse issues since the network was deployed % I'm confused. Why are we mentioning PlanetLab at all? Could we perhaps
in October 2003. Our default exit policy rejects smtp requests, to block % be more generic? -NM
spamming even before it becomes an issue. For now we're happy with our On the other hand, we have had no abuse issues since the network was
slow growth rate, while we add features, resolve bugs, and get a feel for deployed in October 2003. Our default exit policy rejects SMTP requests,
what users actually want from an anonymity system. We are not eager to to avoid spam issues. Our slow growth rate gives us time to add features,
attract the Kazaa or warez communities, even though they would greatly resolve bugs, and get a feel for what users actually want from an
bolster the anonymity sets---we must build a reputation of being for anonymity system. Even though having more users would bolster our
privacy, human rights, research, and other entirely legitimate activities. anonymity sets, we are not eager to attract the Kazaa or warez
communities---we feel that we must build a reputation for privacy, human
rights, research, and other socially approved activities.
As for performance, profiling shows that almost all the CPU time for the As for performance, profiling shows that almost all the CPU time for the
Tor program itself is spent in AES (which is fast). Thus latency comes Tor program itself is spent in AES, which is fast. Current latency is
from two factors. First, network latency is a critical factor: we are attributable
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 our end-to-end congestion control algorithm focuses on protecting
volunteer servers from accidental DoS rather than providing maximum volunteer servers from accidental DoS rather than optimizing
performance. Right now the first $500*500B=250KB$ of the stream arrives 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 quickly, and after that throughput depends on the rate that \emph{relay
sendme} acknowledgements arrive. We can tweak the congestion control sendme} acknowledgments arrive. We can tweak the congestion control
parameters to provide faster throughput at the expense of requiring parameters to provide faster throughput at the cost of
larger buffers at each node; adding the heuristics mentioned in larger buffers at each node; adding the heuristics mentioned in
Section~\ref{subsec:rate-limit} to give better speed to low-volume Section~\ref{subsec:rate-limit} to give better speed to low-volume
streams will change the equation too. More research remains to find the streams may also help. More research remains to find the
right balance. right balance.
%performs badly on lossy networks. may need airhook or something else as %performs badly on lossy networks. may need airhook or something else as
%transport alternative? %transport alternative?
With the current network's topology and load, users can typically With the current network's topology and load, users can typically get 1-2
get 1-2 megabits sustained transfer rate. Overall, this performance is megabits sustained transfer rate. Overall, this performance is sufficient
sufficient. The Tor design focuses on security; usability and performance for most of our users. The Tor design aims foremost for security;
just have to not suck too much. performance is secondary.
we expect it to scale to a few hundred nodes and perhaps 10,000 users, Although Tor's clique topology and full-visibility directories present
before we're forced to change topologies to become more distributed. scaling problems, we still expect the network to a few hundred nodes and
but really, give us a chance to run it for a while more, first. 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.
\Section{Open Questions in Low-latency Anonymity} \Section{Open Questions in Low-latency Anonymity}
\label{sec:maintaining-anonymity} \label{sec:maintaining-anonymity}