[or-cvs] r19165: {projects} scribble in notes to finish off the skeletal todo list (projects/performance)

arma at seul.org arma at seul.org
Fri Mar 27 18:20:46 UTC 2009


Author: arma
Date: 2009-03-27 14:20:46 -0400 (Fri, 27 Mar 2009)
New Revision: 19165

Modified:
   projects/performance/perf-todo
Log:
scribble in notes to finish off the skeletal todo list


Modified: projects/performance/perf-todo
===================================================================
--- projects/performance/perf-todo	2009-03-27 18:02:34 UTC (rev 19164)
+++ projects/performance/perf-todo	2009-03-27 18:20:46 UTC (rev 19165)
@@ -132,4 +132,39 @@
     * 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.)
+Metrics: if we were more flexible in our Guard stability criteria, how
+many more relays would get the Guard flag? How would that influence the
+above numbers? I'd like to become very flexible so more than half of
+the relays get to be guards. Are there cutoffs that are reasonable and
+fit naturally into the data from the past few years?
+Metrics: if we're more flexible in our Guard speed criteria, how does
+that impact the speed that clients should expect? Originally we avoided
+20KB/s relays as guards, because "then clients can't ever get more than
+20KB/s". But they can't get that now anyway.
+    - Write a proposal for what new criteria we should use, and why
+      that'll safely increase the guard set.
 
+  - 5.1, better round-robin
+
+
+  - 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.
+Metrics: Right now we abandon the circuit after 10 seconds for the first
+try. What are the download stats if we don't abandon it? What "try a
+new one" timeouts will minimize the number of circuits we go through,
+while also minimizing the time-until-user-gets-website?
+    - Change Tor so it launches a new stream attempt on schedule, but
+      is willing to use the original attempt if it completes earlier.
+    D same with stream timeouts.
+
+  - 5.3, try extending a few other places
+
+  - 5.4, bundle the first data cell with the begin cell
+
+  - 6.1, directory overhead
+    * deploy proposal 158, the "microdescriptor" plan
+
+  - 6.2, TLS overhead
+    D can wait
+



More information about the tor-commits mailing list