mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
another iteration of the experiences section
svn:r997
This commit is contained in:
parent
90c3b8f0c1
commit
521cdd1ecb
@ -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}
|
||||
|
Loading…
Reference in New Issue
Block a user