[or-cvs] r19163: {projects} put priorities on some items. flesh out section 4. add more (projects/performance)

[arma at seul.org]

Author: arma
Date: 2009-03-27 13:25:42 -0400 (Fri, 27 Mar 2009)
New Revision: 19163

Modified:
   projects/performance/perf-todo
Log:
put priorities on some items. flesh out section 4. add more metrics
questions for karsten.


Modified: projects/performance/perf-todo
===================================================================
--- projects/performance/perf-todo	2009-03-27 17:03:48 UTC (rev 19162)
+++ projects/performance/perf-todo	2009-03-27 17:25:42 UTC (rev 19163)
@@ -11,22 +11,24 @@
   - 1.2, new circuit window sizes
     - Conclude whether the transition period will hurt as much as it
       seems like it will.
-    - Pick a lower number, and switch to it.
+    * Pick a lower number, and switch to it.
 Metrics: gather queue sizes from relays so we have a better sense of
 what's actually going on.
 
 Roger, others:
-  - 2.1, squeeze loud circuits
+  * 2.1, squeeze loud circuits
     - Evaluate the code to see what stats we can keep about circuit use.
     - Write proposals for various meddling. Look at the research papers
-      that Juliusz pointed us to. Ask our systems friends.
+      that Juliusz pointed us to. Ask our systems friends. Plan to put
+      a lot of the parameters in the consensus, so we can tune it with
+      short turnaround times.
 
   - 2.4, rate-limit at clients
     - Consider ways to choose what rate limits to use.
     - Reconsider in the context of 2.1 proposals above
 
   - 2.5, Default exit policies
-    - Change Vidalia's default exit policy to not click "other protocols".
+    * Change Vidalia's default exit policy to not click "other protocols".
     D let exit relays specify some destination networks/ports that get
       rate limited further.
 Metrics: At what fraction of exit relays allowing a given port out
@@ -39,18 +41,18 @@
 How to phrase it so it's more useful?)
 
   - 2.6, tell users not to file-share
-    - Put statement on the Tor front page
-    - Put statement on the download pages too
-    - And the FAQ
+    * Put statement on the Tor front page
+    * Put statement on the download pages too
+    * And the FAQ
     D Should we put some sort of popup in Vidalia? How to detect?
     - Contact Azureus people and get them to fix their docs, and/or
       remove the feature, and/or pop up a warning.
 
   - 3.1.2, Tor weather
-    - Link to it from the Tor relay page
-    - and the torrc.sample
+    * Link to it from the Tor relay page
+    * and the torrc.sample
 M   - Put a link in Vidalia's relay interface
-I   - Implement time-to-notification (immediate, a day, a week)
+I   * Implement time-to-notification (immediate, a day, a week)
 N   - Build a plan for how Tor weather can learn about hibernating
       relays if we take them out of the v3 consensus and we obsolete v2.
 
@@ -78,11 +80,11 @@
      looking at anonymity risks)
 
   - 4.1, balance traffic better
-    - Steven and Mike should decide if we should do Steven's plan
+    * Steven and Mike should decide if we should do Steven's plan
       (rejigger the bandwidth numbers at the authorities based on
       Steven's algorithm), or Mike's plan (relay scanning to identify
       the unbalanced relays and fix them on the fly), or both.
-    - Figure out how to actually modify bandwidths in the consensus. We
+    * Figure out how to actually modify bandwidths in the consensus. We
       may need to change the consensus voting algorithm to decide what
       bandwidth to advertise based on something other than median:
       if 7 authorities provide bandwidths, and 2 are doing scanning,
@@ -116,4 +118,18 @@
       coordinates, so we can do more direct measurements of whether it
       should work.
 
+  - 4.4, Looking at exit policy when picking relays
+    D pending results from section 4.1
 
+  - 4.5, Older entry guards are overloaded
+Metrics: compare "how fast each relay should be based on its advertised
+capacity" with "how long the relay has had the guard flag", to see how
+big an issue this is really.
+Metrics: How many relays does a client touch over time x, given that they
+drop old guards y seconds after choosing them? Even if y is infinite,
+we have some number based on guards going away. How does x grow as we
+reduce y?
+    * Pick a conservative y like six months, and implement.
+    D Reduce y based on the results of the metrics. (don't partition
+      clients too far by tor version though.)
+