[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r15606: Add two new proposals. (in tor/trunk: . doc/spec/proposals)
Author: nickm
Date: 2008-07-02 14:04:01 -0400 (Wed, 02 Jul 2008)
New Revision: 15606
Added:
tor/trunk/doc/spec/proposals/145-newguard-flag.txt
tor/trunk/doc/spec/proposals/146-long-term-stability.txt
Modified:
tor/trunk/
tor/trunk/doc/spec/proposals/000-index.txt
Log:
r16664@tombo: nickm | 2008-07-02 14:03:44 -0400
Add two new proposals.
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r16664] on 49666b30-7950-49c5-bedf-9dc8f3168102
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2008-07-02 17:55:08 UTC (rev 15605)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2008-07-02 18:04:01 UTC (rev 15606)
@@ -67,6 +67,8 @@
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 @@
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
Added: tor/trunk/doc/spec/proposals/145-newguard-flag.txt
===================================================================
--- tor/trunk/doc/spec/proposals/145-newguard-flag.txt (rev 0)
+++ tor/trunk/doc/spec/proposals/145-newguard-flag.txt 2008-07-02 18:04:01 UTC (rev 15606)
@@ -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.
Property changes on: tor/trunk/doc/spec/proposals/145-newguard-flag.txt
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Added: tor/trunk/doc/spec/proposals/146-long-term-stability.txt
===================================================================
--- tor/trunk/doc/spec/proposals/146-long-term-stability.txt (rev 0)
+++ tor/trunk/doc/spec/proposals/146-long-term-stability.txt 2008-07-02 18:04:01 UTC (rev 15606)
@@ -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.
+
+
Property changes on: tor/trunk/doc/spec/proposals/146-long-term-stability.txt
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native