[or-cvs] [tor/master 09/10] give steven's everybody-a-bridge proposal a number

arma at torproject.org arma at torproject.org
Fri Oct 1 02:06:18 UTC 2010


Author: Roger Dingledine <arma at torproject.org>
Date: Thu, 30 Sep 2010 19:22:52 -0400
Subject: give steven's everybody-a-bridge proposal a number
Commit: 6de26d2bc862888ed67358c00c9f785ad8a55e09

---
 .../proposals/175-automatic-node-promotion.txt     |  239 ++++++++++++++++++++
 .../ideas/xxx-automatic-node-promotion.txt         |  239 --------------------
 2 files changed, 239 insertions(+), 239 deletions(-)
 create mode 100644 doc/spec/proposals/175-automatic-node-promotion.txt
 delete mode 100644 doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt

diff --git a/doc/spec/proposals/175-automatic-node-promotion.txt b/doc/spec/proposals/175-automatic-node-promotion.txt
new file mode 100644
index 0000000..bbe6b37
--- /dev/null
+++ b/doc/spec/proposals/175-automatic-node-promotion.txt
@@ -0,0 +1,239 @@
+Filename: xxx-automatic-node-promotion.txt
+Title: Automatically promoting Tor clients to nodes
+Author: Steven Murdoch
+Created: 12-Mar-2010
+Status: Draft
+Target:
+
+1. Overview
+
+   This proposal describes how Tor clients could determine when they
+   have sufficient bandwidth capacity and are sufficiently reliable to
+   become either bridges or Tor relays. When they meet this
+   criteria, they will automatically promote themselves, based on user
+   preferences. The proposal also defines the new controller messages
+   and options which will control this process.
+
+   Note that for the moment, only transitions between client and
+   bridge are being considered. Transitions to public relay will
+   be considered at a future date, but will use the same
+   infrastructure for measuring capacity and reliability.
+
+2. Motivation and history
+
+   Tor has a growing user-base and one of the major impediments to the
+   quality of service offered is the lack of network capacity. This is
+   particularly the case for bridges, because these are gradually
+   being blocked, and thus no longer of use to people within some
+   countries. By automatically promoting Tor clients to bridges, and
+   perhaps also to full public relays, this proposal aims to solve
+   these problems.
+ 
+   Only Tor clients which are sufficiently useful should be promoted,
+   and the process of determining usefulness should be performed
+   without reporting the existence of the client to the central
+   authorities. The criteria used for determining usefulness will be
+   in terms of bandwidth capacity and uptime, but parameters should be
+   specified in the directory consensus. State stored at the client
+   should be in no more detail than necessary, to prevent sensitive
+   information being recorded.
+
+3. Design
+
+3.x Opt-in state model
+
+   Tor can be in one of five node-promotion states:
+
+   - off (O): Currently a client, and will stay as such
+   - auto (A): Currently a client, but will consider promotion
+   - bridge (B): Currently a bridge, and will stay as such
+   - auto-bridge (AB): Currently a bridge, but will consider promotion
+   - relay (R): Currently a public relay, and will stay as such
+
+   The state can be fully controlled from the configuration file or
+   controller, but the normal state transitions are as follows:
+
+   Any state -> off: User has opted out of node promotion
+   Off -> any state: Only permitted with user consent
+
+   Auto -> auto-bridge: Tor has detected that it is sufficiently
+    reliable to be a *bridge*
+   Auto -> bridge: Tor has detected that it is sufficiently reliable
+    to be a *relay*, but the user has chosen to remain a *bridge*
+   Auto -> relay: Tor has detected that it is sufficiently reliable
+    to be *relay*, and will skip being a *bridge*
+   Auto-bridge -> relay: Tor has detected that it is sufficiently
+    reliable to be a *relay*
+
+   Note that this model does not support automatic demotion. If this
+   is desirable, there should be some memory as to whether the
+   previous state was relay, bridge, or auto-bridge. Otherwise the
+   user may be prompted to become a relay, although he has opted to
+   only be a bridge.
+
+3.x User interaction policy
+
+   There are a variety of options in how to involve the user into the
+   decision as to whether and when to perform node promotion. The
+   choice also may be different when Tor is running from Vidalia (and
+   thus can readily prompt the user for information), and standalone
+   (where Tor can only log messages, which may or may not be read).
+
+   The option requiring minimal user interaction is to automatically
+   promote nodes according to reliability, and allow the user to opt
+   out, by changing settings in the configuration file or Vidalia user
+   interface.
+
+   Alternatively, if a user interface is available, Tor could prompt
+   the user when it detects that a transition is available, and allow
+   the user to choose which of the available options to select. If
+   Vidalia is not available, it still may be possible to solicit an
+   email address on install, and contact the operator to ask whether
+   a transition to bridge or relay is permitted.
+
+   Finally, Tor could by default not make any transition, and the user
+   would need to opt in by stating the maximum level (bridge or
+   relay) to which the node may automatically promote itself.
+
+3.x Performance monitoring model
+
+   To prevent a large number of clients activating as relays, but
+   being too unreliable to be useful, clients should measure their
+   performance. If this performance meets a parameterized acceptance
+   criteria, a client should consider promotion. To measure
+   reliability, this proposal adopts a simple user model:
+
+    - A user decides to use Tor at times which follow a Poisson
+      distribution
+    - At each time, the user will be happy if the bridge chosen has
+      adequate bandwidth and is reachable
+    - If the chosen bridge is down or slow too many times, the user
+      will consider Tor to be bad
+
+   If we additionally assume that the recent history of relay
+   performance matches the current performance, we can measure
+   reliability by simulating this simple user.
+
+   The following parameters are distributed to clients in the
+   directory consensus:
+
+     - min_bandwidth: Minimum self-measured bandwidth for a node to be
+       considered useful, in bytes per second
+     - check_period: How long, in seconds, to wait between checking
+       reachability and bandwidth (on average)
+     - num_samples: Number of recent samples to keep
+     - num_useful: Minimum number of recent samples where the node was
+       reachable and had at least min_bandwidth capacity, for a client
+       to consider promoting to a bridge
+
+   A different set of parameters may be used for considering when to
+   promote a bridge to a full relay, but this will be the subject of a
+   future revision of the proposal.
+
+3.x Performance monitoring algorithm
+
+   The simulation described above can be implemented as follows:
+
+   Every 60 seconds:
+     1. Tor generates a random floating point number x in
+        the interval [0, 1).
+     2. If x > (1 / (check_period / 60)) GOTO end; otherwise:
+     3. Tor sets the value last_check to the current_time (in seconds)
+     4. Tor measures reachability
+     5. If the client is reachable, Tor measures its bandwidth
+     6. If the client is reachable and the bandwidth is >=
+        min_bandwidth, the test has succeeded, otherwise it has failed.
+     7. Tor adds the test result to the end of a ring-buffer containing
+        the last num_samples results: measurement_results
+     8. Tor saves last_check and measurements_results to disk
+     9. If the length of measurements_results == num_samples and
+        the number of successes >= num_useful, Tor should consider
+        promotion to a bridge
+   end.
+ 
+   When Tor starts, it must fill in the samples for which it was not
+   running. This can only happen once the consensus has downloaded,
+   because the value of check_period is needed.
+ 
+      1. Tor generates a random number y from the Poisson distribution [1]
+         with lambda = (current_time - last_check) * (1 / check_period)
+      2. Tor sets the value last_check to the current_time (in seconds)	
+      3. Add y test failures to the ring buffer measurements_results
+      4. Tor saves last_check and measurements_results to disk
+ 
+   In this way, a Tor client will measure its bandwidth and
+   reachability every check_period seconds, on average. Provided
+   check_period is sufficiently greater than a minute (say, at least an
+   hour), the times of check will follow a Poisson distribution. [2]
+ 
+   While this does require that Tor does record the state of a client
+   over time, this does not leak much information. Only a binary
+   reachable/non-reachable is stored, and the timing of samples becomes
+   increasingly fuzzy as the data becomes less recent.
+
+   On IP address changes, Tor should clear the ring-buffer, because
+   from the perspective of users with the old IP address, this node
+   might as well be a new one with no history. This policy may change
+   once we start allowing the bridge authority to hand out new IP
+   addresses given the fingerprint.
+
+3.x Bandwidth measurement
+
+   Tor needs to measure its bandwidth to test the usefulness as a
+   bridge. A non-intrusive way to do this would be to passively measure
+   the peak data transfer rate since the last reachability test. Once
+   this exceeds min_bandwidth, Tor can set a flag that this node
+   currently has sufficient bandwidth to pass the bandwidth component
+   of the upcoming performance measurement.
+
+   For the first version we may simply skip the bandwidth test,
+   because the existing reachability test sends 500 kB over several
+   circuits, and checks whether the node can transfer at least 50
+   kB/s.  This is probably good enough for a bridge, so this test
+   might be sufficient to record a success in the ring buffer.
+
+3.x New options
+
+3.x New controller message
+
+4. Migration plan
+
+   We should start by setting a high bandwidth and uptime requirement
+   in the consensus, so as to avoid overloading the bridge authority
+   with too many bridges. Once we are confident our systems can scale,
+   the criteria can be gradually shifted down to gain more bridges.
+
+5. Related proposals
+
+6. Open questions:
+
+   - What user interaction policy should we take?
+
+   - When (if ever) should we turn a relay into an exit relay?
+
+   - What should the rate limits be for auto-promoted bridges/relays?
+     Should we prompt the user for this?
+
+   - Perhaps the bridge authority should tell potential bridges
+     whether to enable themselves, by taking into account whether
+     their IP address is blocked
+
+   - How do we explain the possible risks of running a bridge/relay
+     * Use of bandwidth/congestion
+     * Publication of IP address
+     * Blocking from IRC (even for non-exit relays)
+
+   - What feedback should we give to bridge relays, to encourage then
+     e.g. number of recent users (what about reserve bridges)?
+
+   - Can clients back-off from doing these tests (yes, we should do
+     this)
+
+[1] For algorithms to generate random numbers from the Poisson
+    distribution, see: http://en.wikipedia.org/wiki/Poisson_distribution#Generating_Poisson-distributed_random_variables
+[2] "The sample size n should be equal to or larger than 20 and the
+     probability of a single success, p, should be smaller than or equal to
+     .05. If n >= 100, the approximation is excellent if np is also <= 10."
+    http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc331.htm (e-Handbook of Statistical Methods)
+
+% vim: spell ai et:
diff --git a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt
deleted file mode 100644
index bbe6b37..0000000
--- a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt
+++ /dev/null
@@ -1,239 +0,0 @@
-Filename: xxx-automatic-node-promotion.txt
-Title: Automatically promoting Tor clients to nodes
-Author: Steven Murdoch
-Created: 12-Mar-2010
-Status: Draft
-Target:
-
-1. Overview
-
-   This proposal describes how Tor clients could determine when they
-   have sufficient bandwidth capacity and are sufficiently reliable to
-   become either bridges or Tor relays. When they meet this
-   criteria, they will automatically promote themselves, based on user
-   preferences. The proposal also defines the new controller messages
-   and options which will control this process.
-
-   Note that for the moment, only transitions between client and
-   bridge are being considered. Transitions to public relay will
-   be considered at a future date, but will use the same
-   infrastructure for measuring capacity and reliability.
-
-2. Motivation and history
-
-   Tor has a growing user-base and one of the major impediments to the
-   quality of service offered is the lack of network capacity. This is
-   particularly the case for bridges, because these are gradually
-   being blocked, and thus no longer of use to people within some
-   countries. By automatically promoting Tor clients to bridges, and
-   perhaps also to full public relays, this proposal aims to solve
-   these problems.
- 
-   Only Tor clients which are sufficiently useful should be promoted,
-   and the process of determining usefulness should be performed
-   without reporting the existence of the client to the central
-   authorities. The criteria used for determining usefulness will be
-   in terms of bandwidth capacity and uptime, but parameters should be
-   specified in the directory consensus. State stored at the client
-   should be in no more detail than necessary, to prevent sensitive
-   information being recorded.
-
-3. Design
-
-3.x Opt-in state model
-
-   Tor can be in one of five node-promotion states:
-
-   - off (O): Currently a client, and will stay as such
-   - auto (A): Currently a client, but will consider promotion
-   - bridge (B): Currently a bridge, and will stay as such
-   - auto-bridge (AB): Currently a bridge, but will consider promotion
-   - relay (R): Currently a public relay, and will stay as such
-
-   The state can be fully controlled from the configuration file or
-   controller, but the normal state transitions are as follows:
-
-   Any state -> off: User has opted out of node promotion
-   Off -> any state: Only permitted with user consent
-
-   Auto -> auto-bridge: Tor has detected that it is sufficiently
-    reliable to be a *bridge*
-   Auto -> bridge: Tor has detected that it is sufficiently reliable
-    to be a *relay*, but the user has chosen to remain a *bridge*
-   Auto -> relay: Tor has detected that it is sufficiently reliable
-    to be *relay*, and will skip being a *bridge*
-   Auto-bridge -> relay: Tor has detected that it is sufficiently
-    reliable to be a *relay*
-
-   Note that this model does not support automatic demotion. If this
-   is desirable, there should be some memory as to whether the
-   previous state was relay, bridge, or auto-bridge. Otherwise the
-   user may be prompted to become a relay, although he has opted to
-   only be a bridge.
-
-3.x User interaction policy
-
-   There are a variety of options in how to involve the user into the
-   decision as to whether and when to perform node promotion. The
-   choice also may be different when Tor is running from Vidalia (and
-   thus can readily prompt the user for information), and standalone
-   (where Tor can only log messages, which may or may not be read).
-
-   The option requiring minimal user interaction is to automatically
-   promote nodes according to reliability, and allow the user to opt
-   out, by changing settings in the configuration file or Vidalia user
-   interface.
-
-   Alternatively, if a user interface is available, Tor could prompt
-   the user when it detects that a transition is available, and allow
-   the user to choose which of the available options to select. If
-   Vidalia is not available, it still may be possible to solicit an
-   email address on install, and contact the operator to ask whether
-   a transition to bridge or relay is permitted.
-
-   Finally, Tor could by default not make any transition, and the user
-   would need to opt in by stating the maximum level (bridge or
-   relay) to which the node may automatically promote itself.
-
-3.x Performance monitoring model
-
-   To prevent a large number of clients activating as relays, but
-   being too unreliable to be useful, clients should measure their
-   performance. If this performance meets a parameterized acceptance
-   criteria, a client should consider promotion. To measure
-   reliability, this proposal adopts a simple user model:
-
-    - A user decides to use Tor at times which follow a Poisson
-      distribution
-    - At each time, the user will be happy if the bridge chosen has
-      adequate bandwidth and is reachable
-    - If the chosen bridge is down or slow too many times, the user
-      will consider Tor to be bad
-
-   If we additionally assume that the recent history of relay
-   performance matches the current performance, we can measure
-   reliability by simulating this simple user.
-
-   The following parameters are distributed to clients in the
-   directory consensus:
-
-     - min_bandwidth: Minimum self-measured bandwidth for a node to be
-       considered useful, in bytes per second
-     - check_period: How long, in seconds, to wait between checking
-       reachability and bandwidth (on average)
-     - num_samples: Number of recent samples to keep
-     - num_useful: Minimum number of recent samples where the node was
-       reachable and had at least min_bandwidth capacity, for a client
-       to consider promoting to a bridge
-
-   A different set of parameters may be used for considering when to
-   promote a bridge to a full relay, but this will be the subject of a
-   future revision of the proposal.
-
-3.x Performance monitoring algorithm
-
-   The simulation described above can be implemented as follows:
-
-   Every 60 seconds:
-     1. Tor generates a random floating point number x in
-        the interval [0, 1).
-     2. If x > (1 / (check_period / 60)) GOTO end; otherwise:
-     3. Tor sets the value last_check to the current_time (in seconds)
-     4. Tor measures reachability
-     5. If the client is reachable, Tor measures its bandwidth
-     6. If the client is reachable and the bandwidth is >=
-        min_bandwidth, the test has succeeded, otherwise it has failed.
-     7. Tor adds the test result to the end of a ring-buffer containing
-        the last num_samples results: measurement_results
-     8. Tor saves last_check and measurements_results to disk
-     9. If the length of measurements_results == num_samples and
-        the number of successes >= num_useful, Tor should consider
-        promotion to a bridge
-   end.
- 
-   When Tor starts, it must fill in the samples for which it was not
-   running. This can only happen once the consensus has downloaded,
-   because the value of check_period is needed.
- 
-      1. Tor generates a random number y from the Poisson distribution [1]
-         with lambda = (current_time - last_check) * (1 / check_period)
-      2. Tor sets the value last_check to the current_time (in seconds)	
-      3. Add y test failures to the ring buffer measurements_results
-      4. Tor saves last_check and measurements_results to disk
- 
-   In this way, a Tor client will measure its bandwidth and
-   reachability every check_period seconds, on average. Provided
-   check_period is sufficiently greater than a minute (say, at least an
-   hour), the times of check will follow a Poisson distribution. [2]
- 
-   While this does require that Tor does record the state of a client
-   over time, this does not leak much information. Only a binary
-   reachable/non-reachable is stored, and the timing of samples becomes
-   increasingly fuzzy as the data becomes less recent.
-
-   On IP address changes, Tor should clear the ring-buffer, because
-   from the perspective of users with the old IP address, this node
-   might as well be a new one with no history. This policy may change
-   once we start allowing the bridge authority to hand out new IP
-   addresses given the fingerprint.
-
-3.x Bandwidth measurement
-
-   Tor needs to measure its bandwidth to test the usefulness as a
-   bridge. A non-intrusive way to do this would be to passively measure
-   the peak data transfer rate since the last reachability test. Once
-   this exceeds min_bandwidth, Tor can set a flag that this node
-   currently has sufficient bandwidth to pass the bandwidth component
-   of the upcoming performance measurement.
-
-   For the first version we may simply skip the bandwidth test,
-   because the existing reachability test sends 500 kB over several
-   circuits, and checks whether the node can transfer at least 50
-   kB/s.  This is probably good enough for a bridge, so this test
-   might be sufficient to record a success in the ring buffer.
-
-3.x New options
-
-3.x New controller message
-
-4. Migration plan
-
-   We should start by setting a high bandwidth and uptime requirement
-   in the consensus, so as to avoid overloading the bridge authority
-   with too many bridges. Once we are confident our systems can scale,
-   the criteria can be gradually shifted down to gain more bridges.
-
-5. Related proposals
-
-6. Open questions:
-
-   - What user interaction policy should we take?
-
-   - When (if ever) should we turn a relay into an exit relay?
-
-   - What should the rate limits be for auto-promoted bridges/relays?
-     Should we prompt the user for this?
-
-   - Perhaps the bridge authority should tell potential bridges
-     whether to enable themselves, by taking into account whether
-     their IP address is blocked
-
-   - How do we explain the possible risks of running a bridge/relay
-     * Use of bandwidth/congestion
-     * Publication of IP address
-     * Blocking from IRC (even for non-exit relays)
-
-   - What feedback should we give to bridge relays, to encourage then
-     e.g. number of recent users (what about reserve bridges)?
-
-   - Can clients back-off from doing these tests (yes, we should do
-     this)
-
-[1] For algorithms to generate random numbers from the Poisson
-    distribution, see: http://en.wikipedia.org/wiki/Poisson_distribution#Generating_Poisson-distributed_random_variables
-[2] "The sample size n should be equal to or larger than 20 and the
-     probability of a single success, p, should be smaller than or equal to
-     .05. If n >= 100, the approximation is excellent if np is also <= 10."
-    http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc331.htm (e-Handbook of Statistical Methods)
-
-% vim: spell ai et:
-- 
1.7.1




More information about the tor-commits mailing list