Add proposal 150 and proposal 151

svn:r15695

doc/spec/proposals/000-index.txt

@@ -72,6 +72,8 @@ Proposals by number:
 147  Eliminate the need for v2 directories in generating v3 directories [OPEN]
 148  Stream end reasons from the client side should be uniform [OPEN]
 149  Using data from NETINFO cells [OPEN]
+150  Exclude Exit Nodes from a circuit [DRAFT]
+151  Improving Tor Path Selection [DRAFT]
 
 
 Proposals by status:
@@ -85,6 +87,8 @@ Proposals by status:
    134  More robust consensus voting with diverse authority sets
    141  Download server descriptors on demand
    144  Increase the diversity of circuits by detecting nodes belonging the
+   150  Exclude Exit Nodes from a circuit
+   151  Improving Tor Path Selection
  OPEN:
    120  Shutdown descriptors when Tor servers stop
    121  Hidden Service Authentication

doc/spec/proposals/150-exclude-exit-nodes.txt

@@ -0,0 +1,36 @@
+Filename: 150-exclude-exit-nodes.txt
+Title: Exclude Exit Nodes from a circuit
+Version: $Revision$
+Author: Mfr
+Created: 2008-06-15
+Status: Draft
+
+Overview
+
+   Right now, Tor user can manually exclude a node of all the part of
+   circuits created using the directive ExcludeNodes.  
+   This proposal makes this exclusion, less restrictive, allowing to 
+   exclude a node only on the exit part of a circuit.
+
+Motivation
+
+   Helping the integration into vidalia (tor exit branch)or other tools,
+   of features to exclude a country for exit without reducing 
+   circuits possibilities, an privacy.
+   This feature could help people from a country were many sites 
+   are blocked to exclude this country for browsing, giving them a 
+   more stable navigation.
+   Add the possibility for the user to exclude the current used exit
+   node. 
+   
+   
+Implementation
+
+   ExcludeExitNodes is similar to ExcludeNodes except it's only
+   the exit node which is excluded for circuit build.
+   
+   Tor doesn't warn if node from this list is not an exit node.
+
+Security implications:
+
+   Open also possibilities for a future user bad exit reporting.

doc/spec/proposals/151-path-selection-improvements.txt

@@ -0,0 +1,59 @@
+Filename: 151-path-selection-improvements.txt
+Title: Improving Tor Path Selection
+Version:
+Last-Modified:
+Author: Fallon Chen, Mike Perry
+Created: 5-Jul-2008
+Status: Draft
+
+Overview
+
+  The performance of paths selected can be improved by adjusting the
+  CircuitBuildTimeout and the number of guards. This proposal describes
+  a method of tracking buildtime statistics, and using those statistics
+  to adjust the CircuitBuildTimeout and the number of guards.
+
+Motivation
+
+  Tor's performance can be improved by excluding those circuits that
+  have long buildtimes (and by extension, high latency). For those Tor
+  users who require better performance and have lower requirements for
+  anonymity, this would be a very useful option to have.
+
+Implementation
+
+  Learning the CircuitBuildTimeout
+
+    Based on studies of build times, we found that the distribution of
+    circuit buildtimes appears to be a Pareto distribution. The number
+    of circuits to observe (ncircuits_to_observe) before changing the
+    CircuitBuildTimeout will be tunable. From our preliminary
+    measurements, it is likely that ncircuits_to_observe will be
+    somewhere on the order of 1000. The values can be represented
+    compactly in Tor in milliseconds as a circular array of 16 bit
+    integers. More compact long-term storage representations can be
+    implemented by simply storing a histogram with 50 millisecond
+    buckets when writing out the statistics to disk.
+
+  Calculating the preferred CircuitBuildTimeout
+
+    Circuits that have longer buildtimes than some x% of the estimated
+    CDF of the Pareto distribution will be excluded. x will be tunable
+    as well.
+
+  Circuit timeouts
+
+    In the event of a timeout, backoff values should include the 100-x%
+    of expected CDF of timeouts.  Also, in the event of network failure,
+    the observation mechanism should stop collecting timeout data.
+
+  Other notes
+
+    Since this follows a Pareto distribution, large reductions on the
+    timeout can be achieved without cutting off a great number of the
+    total paths.  However, hard statistics on which cutoff percentage
+    gives optimal performance have not yet been gathered.
+
+Issues
+
+  Impact on anonymity