put in the performance todo items that i marked as high-priority in

the projects/performance/perf-todo file.


svn:r19178

1 files changed, 38 insertions, 7 deletions

diff --git a/doc/TODO.external b/doc/TODO.external
index 988f6c67e7..205e8a5391 100644
--- a/doc/TODO.external
+++ b/doc/TODO.external
@@ -25,9 +25,6 @@ C       - coderman claims
 
 External constraints:
 
-Past due:
-N   - Refine proposal 158, and implement.
-
 For June/July:
 NR  - Work more on Paul's NRL research problem.
 
@@ -81,9 +78,43 @@ IC- get a buildbot up again. Have Linux and BSD build machines.
     (Windows would be nice but realistically will come later.)
 E - Get Tor to work properly on the iPhone.
 
-3.1.1, performance work.
-
-XXX
+3.1, performance work. [Section numbers in here are from performance.pdf]
+  - High-priority items from performance.pdf
+RS  - 1.2, new circuit window sizes. make the default package window lower.
+R+  - 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. Plan to put
+        a lot of the parameters in the consensus, so we can tune it with
+        short turnaround times.
+E+  - 2.5, Change Vidalia's default exit policy to not click "other
+      protocols". Or choose not to. Think this through first.
+R+  - 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
+    - 3.1.2, Tor weather
+I     - Implement time-to-notification (immediate, a day, a week)
+R     - Link to it from the Tor relay page
+R     - and the torrc.sample
+SM  - 4.1, balance traffic better
+      - 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
+        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,
+        then the 5 that aren't scanning will outvote any changes. Should
+        all 7 scan? Should only some vote? Extra points if it doesn't
+        change all the numbers every new consensus, so consensus diffing
+        is still practical.
+?   - 4.5, Older entry guards are overloaded
+      - Pick a conservative timeout like a month, and implement.
+M   - 5.2, better timeouts for giving up on circuits/streams
+      - clients gather data about circuit timeouts, and then abandon
+        circuits that take more than a std dev above that.
 
 4.1, IOCP / libevent / windows / tor
 N - get it working for nick
@@ -107,7 +138,7 @@ S - Have a clear plan for how users who become relays will be safe,
       involved in building them.
 
 4.5, clients download less directory info
-N - deploy proposal 158.
+N * deploy proposal 158.
 N - decide whether to do proposal 140. if so, construct an implementation
     plan for how we'll do it. if not, explain why not.