# [or-cvs] r18873: {projects} start rearrange stuff on page 1. in-progress. (projects/performance)

arma at seul.org arma at seul.org
Wed Mar 11 04:34:56 UTC 2009

Author: arma
Date: 2009-03-11 00:34:55 -0400 (Wed, 11 Mar 2009)
New Revision: 18873

Modified:
projects/performance/performance.tex
Log:
start rearrange stuff on page 1. in-progress.

Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-11 04:06:17 UTC (rev 18872)
+++ projects/performance/performance.tex	2009-03-11 04:34:55 UTC (rev 18873)
@@ -38,37 +38,61 @@
\makeatother

\newcommand{\thetitle}{Performance Improvements on Tor}
-\title{\thetitle}
+\title{\thetitle\\or,\\Why Tor is slow and what we're going to do about it}

-\author{Steven J. Murdoch}
+\author{Roger Dingledine \and Steven J. Murdoch}

\pagestyle{fancy}
\fancyhf{}

-\fancyfoot[C]{\thepage}
+\fancyfoot[C]{\thepage}

\begin{document}

\thispagestyle{plain}
-
+
\maketitle

As the Tor project has grown, the performance of the Tor network has
-suffered. We've focused on
-improving Tor's installers and its usability in general, and as people
-increasingly realize that having some privacy online is a good move, more
-people are using Tor. Further, Tor's flexibility in terms of handling
-many protocols has bitten us because a small number of people are loading
-down the network with file sharing traffic.
+suffered. This document describes our current understanding of why Tor
+is slow, and lays out our options for fixing it.
+
+Over the past few years, our funding (and thus our development effort)
+has focused primarily on usability features and blocking-resistance. In
+this time we've come up with a portable self-contained Windows bundle;
+deployed tools to handle the upcoming censorship arms race; further
+developed supporting applications like Vidalia, Torbutton, and Thandy;
+made it easier for users to be relays by adding better rate limiting and
+an easy graphical interface with uPnP support; developed an effective
+translation and localization team and infrastructure; and spread
+understanding of Tor in a safe word-of-mouth way that stayed mostly
+
+As we've been adding these features, people around the world have been
+increasingly realizing that having privacy online is a good move, and
+Tor's user base has grown larger than the current network can handle. At
+the same time, Tor's flexibility in terms of handling many protocols has
+bitten us because a small number of people are loading down the network
+with file sharing traffic.
+
%Tor remains slow because we're lagging behind in deploying some of
%the new research ideas to handle load better, and because we haven't
%increased the capacity of the network to handle the new load.
-This document describes our current understanding of why Tor is slow,
-and lays out our options for fixing it.

-The Tor network is slow right now for six main reasons. We discuss each
+%better understanding of anonymity (research)
+Two approaches: "research conclusively first" vs "roll it out and see"
+
+
+
+We've identified six main reasons why the Tor network is slow.
+
+While all six reasons need to be resolved in order to make the Tor
+network fast enough,    dependencies
+
+
+We discuss each
reason in its own section, starting with the most severe in terms of
long-term effect. For each reason,
we explain our current intuition for how to fix it, how effective we
@@ -568,7 +592,9 @@
The main problem with this approach is that the efficiency is low: at
even cheap hosting rates, the cost of a significant number of new relays
grows quickly. For example, if we can find 100 non-exit relays providing
-1MB/s for as low as \$100/mo, that's \$120k per year. Figure some more
+1MB/s for as low as \$100/mo (and at that price it'd be renting space +on a shared server, with all the resource sharing hassles that comes +with), that's \$120k per year. Figure some more
for maintenance and coordination, the overhead to find 100 locations
that are on sufficiently different networks and administrative zones, etc.

@@ -1283,7 +1309,7 @@
Tor clients must download information on the network, before they can start building connections.
The current directory format (version 3) is already gives a substantial reduction in size.
However, more improvements are possible and Proposal 158, which further reduces the directory overhead, is scheduled to be deployed in the Tor 0.2.2.x series.
-Further background on the directory overhead was given in a blog post~\footnote{\url{http://blog.torproject.org/blog/overhead-directory-info%3A-past%2C-present%2C-future}}
+Further background on the directory overhead was given in a blog post~\footnote{\url{https://blog.torproject.org/blog/overhead-directory-info\%3A-past\%2C-present\%2C-future}}

\subsection{TLS overhead also can be improved}

@@ -1337,6 +1363,13 @@
other than as a periodic keep-alive.

+%\subsection{Hibernating relays shouldn't be listed as Running}
+
+%we are giving Running flags to hibernating relays. if we stop giving
+%them the Running flag, they will no longer get into the consensus,
+%thus saving directory overhead. but this is simply a bug that we
+%should fix.
+
\section{Last thoughts}

\subsection{Lessons from economics}
@@ -1410,15 +1443,10 @@
\prettyref{sec:congestion} could be used to implement the latter strategy.
If web-browsing users are more sensitive to latency than bandwidth, then we could optimize the network for latency rather than throughput.

-\subsection{Metrics}
-
-  Two approaches: "research conclusively first" vs "roll it out and see"
-  Need ways to measure improvements
-
\subsection{The plan moving forward}

+Need ways to measure improvements

-
%\subsection*{Acknowledgements}

% Mike Perry provided many of the ideas discussed here
@@ -1428,27 +1456,3 @@

\end{document}

-
-
-
-
-
-
-
-
-Other items to add in somewhere:
-
-Mike and Fallon's proposal
-
-If extending a circuit fails, try extending a few other places before
-abandoning the circuit.
-
-capacity-building:
-
-%get dynamic ip address relays known to clients quicker, so they can be
-%more useful for the network
-
-we are giving Running flags to hibernating relays. if we stop giving
-them the Running flag, they will no longer get into the consensus,