Loading doc/spec/proposals/000-index.txt +4 −0 Original line number Diff line number Diff line Loading @@ -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: Loading @@ -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 Loading doc/spec/proposals/145-newguard-flag.txt 0 → 100644 +37 −0 Original line number Diff line number Diff line 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 → 100644 +85 −0 Original line number Diff line number Diff line 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. Loading
doc/spec/proposals/000-index.txt +4 −0 Original line number Diff line number Diff line Loading @@ -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: Loading @@ -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 Loading
doc/spec/proposals/145-newguard-flag.txt 0 → 100644 +37 −0 Original line number Diff line number Diff line 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 → 100644 +85 −0 Original line number Diff line number Diff line 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.
