[or-cvs] r18856: {projects} expand the everybody-a-relay section (projects/performance)

[arma@xxxxxxxx]

Author: arma
Date: 2009-03-10 08:17:19 -0400 (Tue, 10 Mar 2009)
New Revision: 18856

Modified:
   projects/performance/performance.tex
Log:
expand the everybody-a-relay section


Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-10 12:03:44 UTC (rev 18855)
+++ projects/performance/performance.tex	2009-03-10 12:17:19 UTC (rev 18856)
@@ -723,20 +723,39 @@
 reachability testing, bandwidth estimation, UPnP support built in to
 Vidalia, and so on.
 
+There are a few risks here though. First, relaying traffic could
+introduce anonymity vulnerabilities, and we need to learn more about
+that first. (That's on the roadmap for 2009.) Second, making clients
+into relays by default could make some users upset. Third, this
+approach could change how sysadmins view Tor. By putting ourselves
+into the same category as Skype, we would scale up the ``blocking
+Tor connections'' arms race by a level that's hard to predict.
+Also, we need to finish deployment of \prettyref{sec:overlapped-io}
+before we can roll this out, or we'll just make a bunch of Windows
+machines crash.
+
+We had originally been avoiding the ``everybody a relay'' design until
+we had a better plan for scaling the directory to be able to distribute
+tens of thousands of relay addresses. I think these two plans are not as
+related as we first thought, though. For example, a very simple answer
+for what to do if we get more relays than our current directory scheme
+can handle is to publish only the best relays, for some metric of best
+that considers capacity, expected uptime, etc. That should be a perfectly
+adequate stopgap measure. Besides, if we get into the position of having
+too many relays, we'll want to look at the distribution and properties
+of the relays we have when deciding what algorithms would best make use
+of them.
+
 {\bf Impact}: High.
 
 {\bf Effort}: Medium, now that we've done a lot of hard work already.
 
-{\bf Risk}: Medium. Relaying traffic could introduce anonymity risks,
-and we need to learn more about that first. Also, making users into
-relays by default could make some users upset.
+{\bf Risk}: Medium.
 
 {\bf Plan}: Wrap up our investigations into the anonymity implications
 of being a relay, at the same time as working on a plan for exactly how
 the Tor client should decide if it's suitable for elevation to relay
-status. We need to finish deployment of \prettyref{sec:overlapped-io}
-before we can roll this out, or we'll just make a bunch of Windows
-machines crash.
+status. This is going to happen, it's just a matter of how soon.
 
 \section{Tor clients choose paths imperfectly}