diff options
| author | Steven Murdoch <Steven.Murdoch@cl.cam.ac.uk> | 2010-03-30 16:57:49 +0100 |
|---|---|---|
| committer | Roger Dingledine <arma@torproject.org> | 2010-09-30 22:04:52 -0400 |
| commit | 60842424ae9b1ed36a8d873f0fc6297c0176e362 (patch) | |
| tree | 136d5d19dda7578862c043493bb765b06794f98b /doc | |
| parent | 2ba53aca76c8567a962ce818be42710f3ca444fe (diff) | |
| download | tor-60842424ae9b1ed36a8d873f0fc6297c0176e362.tar.gz tor-60842424ae9b1ed36a8d873f0fc6297c0176e362.zip | |
Add comments from nickm and arma, from IRC
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt index 84b4ad477f..bbe6b37bf2 100644 --- a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt +++ b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt @@ -171,6 +171,27 @@ Target: 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 @@ -205,6 +226,9 @@ Target: - 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 |