[or-cvs] r18876: {projects} give it a real summary, so you can read just page 1 and have (projects/performance)

arma at seul.org arma at seul.org
Wed Mar 11 05:41:12 UTC 2009


Author: arma
Date: 2009-03-11 01:41:12 -0400 (Wed, 11 Mar 2009)
New Revision: 18876

Modified:
   projects/performance/performance.tex
Log:
give it a real summary, so you can read just page 1 and have some
inkling about our plans.


Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-11 05:16:45 UTC (rev 18875)
+++ projects/performance/performance.tex	2009-03-11 05:41:12 UTC (rev 18876)
@@ -60,8 +60,8 @@
 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;
+has focused on usability and blocking-resistance.
+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
@@ -70,35 +70,65 @@
 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.
+%s we've been adding these features, people around the world have
+%ontinued to realize that they want privacy online, 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.
 
+In parallel to adding these features, we've also been laying the
+groundwork for performance improvements. We've been working with academics
+to write research papers on improving Tor's speed, funding
+some academic groups directly to come up with prototypes, and
+thinking hard about how to safely collect metrics about network
+performance. But it's becoming increasingly clear that we're not going
+to produce the perfect answers just by thinking hard. We need to roll
+out some attempts at solutions, and use the experience to get a better
+intuition about how to really solve the problems.
+
 %better understanding of anonymity (research)
-Two approaches: "research conclusively first" vs "roll it out and see"
+%Two approaches: "research conclusively first" vs "roll it out and see"
 
-
-
 We've identified six main reasons why the Tor network is slow.
+Problem \#1 is that Tor's congestion control does not work well. We need
+to come up with ways to let the ``quiet'' streams (like web browsing)
+co-exist better with the ``loud'' streams (like bulk transfer).
+Problem \#2 is that some Tor users simply put too much traffic onto the
+network relative to the amount they contribute, so we need to work on
+ways to limit the effects of those users and/or provide priority to the
+other users.
+Problem \#3 is that the Tor network simply doesn't have enough capacity
+to handle all the users that want privacy on the Internet. We need to
+develop strategies for increasing the overall community of relays, and
+consider introducing incentives to make the network more self-sustaining.
+Problem \#4 is that Tor's current path selection algorithms don't actually
+distribute load correctly over the network, introducing hotspots. We need
+to develop ways to more accurately estimate the properties of each relay,
+and also ways for clients to select paths more fairly.
+Problem \#5 is that Tor clients aren't as good as they should be at
+handling high or variable latency and connection failures. We must come
+up with heuristics for clients to automatically shift away from bad
+circuits, and other tricks for them to dynamically adapt their behavior.
+Problem \#6 is that low-bandwidth users spend too much of their bandwidth
+overhead downloading directory information. We've made a serious dent
+in this problem already, but more work remains here too.
 
-While all six reasons need to be resolved in order to make the Tor
-network fast enough,    dependencies
+We discuss each reason more in its own section below. For each section,
+we explain our current intuition for how to address the problem,
+how effective we think each fix would be, how much effort and risk is
+involved, and the recommended next steps.
 
+While all six categories need to be resolved in order to make the Tor
+network fast enough to handle everyone who wants to use it, we've ordered
+the sections by precedence. That is, solving the earlier sections will
+be necessary before we can see benefits from solving the later sections.
 
-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
-think each fix would be, how much effort and risk is involved, and the
-recommended next steps.
-
 \pagebreak
 \tableofcontents
 \pagebreak



More information about the tor-commits mailing list