[or-cvs] r18767: {projects} add a few intro paragraphs, and organize our ideas into six (projects/performance)

[arma@xxxxxxxx]

Author: arma
Date: 2009-03-05 01:39:55 -0500 (Thu, 05 Mar 2009)
New Revision: 18767

Modified:
   projects/performance/performance.tex
Log:
add a few intro paragraphs, and organize our ideas into six broad categories


Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-05 04:33:31 UTC (rev 18766)
+++ projects/performance/performance.tex	2009-03-05 06:39:55 UTC (rev 18767)
@@ -51,6 +51,77 @@
  
 \maketitle
 
+The Tor network's performance is a victim of its own success. As we've
+improved 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.
+%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, with the most
+severe listed first. For each reason, we explain our current intuition
+for how to fix it, how effective we think it would be, how much effort
+and risk is involved, and the recommended next steps.
+
+\pagebreak
+\tableofcontents
+\pagebreak
+
+1 Congestion control not good
+  TCP backoff slows down all streams since we multiplex
+  We chose Tor's congestion control starting window sizes wrong
+
+2 Some users add way too much load
+  Squeeze loud circuits
+  Snipe bittorrent
+  Throttle at the client side
+  Default exit policy of 80,443
+  Need more options here, since these all suck
+
+3 Simply not enough capacity
+  advocacy
+  incentives to relay
+  overlapped IO on windows
+  Node scanning to find overloaded nodes or broken exits
+  getting dynamic ip relays back into the client list quickly
+  reachable clients become relays automatically
+
+4 Choosing paths imperfectly
+  We don't balance the load over our bandwidth numbers correctly
+    a) steven's 50\% point, and b) mike's overloaded node point
+  The bandwidth numbers we get aren't very accurate either
+  Bandwidth might not even be the right metric to weight by
+  Considering exit policy in node selection
+  Guards are too rare?
+  Two hops vs three hops.
+
+5 Better handling of high/variable latency and failures
+  The switch to Polipo; prefetching, pipelining, etc
+  bad timeouts for giving up on circuits and trying a new one
+  If extending a circuit fails, try extending a few other places before
+    abandoning the circuit.
+
+6 Network overhead too high for modem users
+  our directory overhead progress already, plus proposal 158, should
+    make this way better.
+  we'll still need a plan for splintering the network when we get there
+  tls overhead also can be improved
+
+Last thoughts:
+
+- Metrics
+  Two approaches: "research conclusively first" vs "roll it out and see"
+  Need ways to measure improvements
+
+
+
+
+
 \section{Minimizing latency of paths}
 
 Currently Tor selects paths purely by the random selection of nodes, biased by node bandwidth.
@@ -283,8 +354,6 @@
 
 Other items to add in somewhere:
 
-%UDP transport
-
 Mike and Fallon's proposal
 
 Csaba's proposal to shrink the maximum circuit window.
@@ -304,3 +373,7 @@
 them the Running flag, they will no longer get into the consensus,
 thus saving directory overhead
 
+change the default exit policy to just 80 and 443, to squeeze the
+file-sharing off the network
+
+