r16664@tombo: nickm | 2008-07-02 14:03:44 -0400

 Add two new proposals.


svn:r15606

doc/spec/proposals/000-index.txt

@@ -67,6 +67,8 @@ Proposals by number:
 142  Combine Introduction and Rendezvous Points [OPEN]
 143  Improvements of Distributed Storage for Tor Hidden Service Descriptors [OPEN]
 144  Increase the diversity of circuits by detecting nodes belonging the [DRAFT]
+145  Separate "suitable as a guard" from "suitable as a new guard" [DRAFT]
+146  Add new flag to reflect long-term stability [DRAFT]
 
 
 Proposals by status:
@@ -80,6 +82,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
+   145  Separate "suitable as a guard" from "suitable as a new guard"
+   146  Add new flag to reflect long-term stability
  OPEN:
    120  Shutdown descriptors when Tor servers stop
    121  Hidden Service Authentication

doc/spec/proposals/145-newguard-flag.txt

@@ -0,0 +1,37 @@
+Filename: 145-newguard-flag.txt
+Title: Separate "suitable as a guard" from "suitable as a new guard"
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Mathewson
+Created: 1-Jul-2008
+Status: Draft
+
+Overview
+
+   Right now, Tor has one flag that clients use both to tell which
+   nodes should be kept as guards, and which nodes should be picked
+   when choosing new guards.  This proposal separates this flag into
+   two.
+
+Motivation
+
+   Balancing clients amoung guards is not done well by our current
+   algorithm.  When a new guard appears, it is chosen by clients
+   looking for a new guard with the same probability as all existing
+   guards... but new guards are likelier to be under capacity, whereas
+   old guards are likelier to be under more use.
+
+Implementation
+
+   We add a new flag, NewGuard.  Clients will change so that when they
+   are choosing new guards, they only consider nodes with the NewGuard
+   flag set.
+
+   For now, authorities will always set NewGuard if they are setting
+   the Guard flag.  Later, it will be easy to migrate authorities to
+   set NewGuard for underused guards.
+
+Alternatives
+
+   We might instead have authorities list weights with which nodes
+   should be picked as guards.

doc/spec/proposals/146-long-term-stability.txt

@@ -0,0 +1,85 @@
+Filename: 146-long-term-stability.txt
+Title: Add new flag to reflect long-term stability
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Mathewson
+Created: 19-Jun-2008
+Status: Draft
+
+Overview
+
+  This document proposes a new flag to indicate that a router has
+  existed at the same address for a long time, describes how to
+  implement it, and explains what it's good for.
+
+Motivation
+
+  Tor has had three notions of "stability" for servers.  Older
+  directory protocols based a server's stability on its
+  (self-reported) uptime: a server that had been running for a day was
+  more stable than a server that had been running for five minutes,
+  regardless of their past history.  Current directory protocols track
+  weighted mean time between failure (WMTBF) and weighted fractional
+  uptime (WFU).  WFU is computed as the fraction of time for which the
+  server is running, with measurements weighted to exponentially
+  decay such that old days count less.  WMTBF is computed as the the
+  average length of intervals for which the server runs between
+  downtime, with old intervals weighted to count less.
+
+  WMTBF is useful in answering the question: "If a server is running
+  now, how long is it likely to stay running?"  This makes it a good
+  choice for picking servers for streams that need to be long-lived.
+  WFU is useful in answering the question: "If I try connecting to
+  this server at an arbitrary time, is it likely to be running?"  This
+  makes it an important factor for picking guard nodes, since we want
+  guard nodes to be usually-up.
+
+  There are other questions that clients want to answer, however, for
+  which the current flags aren't very useful.   The one that this
+  proposal addresses is,
+
+       "If I found this server in an old consensus, is it likely to
+       still be running at the same address?"
+
+  This one is useful when we're trying to find directory mirrors in a
+  fallback-consensus file.  This property is equivalent to,
+
+       "If I find this server in a current consensus, how long is it
+       likely to exist on the network?"
+
+  This one is usefule if we're trying to pick introduction points or
+  something and care more about churn rate than about whether every IP
+  will be up all the time.
+
+Implementation:
+
+  I propose we add a new flag, called "Longterm."  Authorities should
+  set this flag for routers if their Longevity is in the upper
+  quartile of all routers.  A router's Longevity is computed as the
+  total amount of days in the last year or so[*] for which the router has
+  been Running at least once at its current IP:orport pair.
+
+  Clients should use directory servers from a fallback-consensus only
+  if they have the Longterm flag set.
+
+  Authority ops should be able to mark particular routers as not
+  Longterm, regardless of history.  (For instance, it makes sense to
+  remove the Longterm flag from a router whose op says that it will
+  need to shutdown in a month.)
+
+  [*] This is deliberately vague, to permit efficient implementations.
+
+Compatibility and migration issues:
+
+  The voting protocol already acts gracefully when new flags are
+  added, so no change to the voting protocol is needed.
+
+  Tor won't have collected this data, however.  It might be desirable
+  to bootstrap it from historical consensuses.  Alternatively, we can
+  just let the algorithm run for a month or two.
+
+Issues and future possibilities:
+
+  Longterm is a really awkward name.
+
+