[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}
 
 %% Please add your name in here if you contribute
-\author{Steven J. Murdoch}
+\author{Roger Dingledine \and Steven J. Murdoch}
 
 \pagestyle{fancy}
 \fancyhf{}
 
 \fancyhead[C]{\thetitle}
-\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
+under the radar of censors.
+
+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 @@
 length payload, however Tor does not currently send padding cells,
 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,
-thus saving directory overhead
-



More information about the tor-commits mailing list