minor touchups on proposals

svn:r15263
This commit is contained in:
Roger Dingledine 2008-06-15 01:50:31 +00:00
parent 96bf9cd4c5
commit c96b15f9bc
4 changed files with 15 additions and 17 deletions

View File

@ -42,7 +42,7 @@ Proposals by number:
117 IPv6 exits [NEEDS-REVISION]
118 Advertising multiple ORPorts at once [DRAFT]
119 New PROTOCOLINFO command for controllers [CLOSED]
120 Suicide descriptors when Tor servers stop [OPEN]
120 Shutdown descriptors when Tor servers stop [OPEN]
121 Hidden Service Authentication [OPEN]
122 Network status entries need a new Unnamed flag [CLOSED]
123 Naming authorities automatically create bindings [CLOSED]
@ -73,7 +73,7 @@ Proposals by status:
133 Incorporate Unreachable ORs into the Tor Network
134 More robust consensus voting with diverse authority sets
OPEN:
120 Suicide descriptors when Tor servers stop
120 Shutdown descriptors when Tor servers stop
121 Hidden Service Authentication
135 Simplify Configuration of Private Tor Networks
137 Keep controllers informed as Tor bootstraps

View File

@ -1,5 +1,5 @@
Filename: 120-suicide-descriptors.txt
Title: Suicide descriptors when Tor servers stop
Filename: 120-shutdown-descriptors.txt
Title: Shutdown descriptors when Tor servers stop
Version: $Revision$
Last-Modified: $Date$
Author: Roger Dingledine
@ -56,11 +56,11 @@ Overhead issues:
We are creating more descriptors that want to be remembered. However,
since the router won't be marked as Running, ordinary clients won't
fetch the suicide descriptors. Caches will, though. I hope this is ok.
fetch the shutdown descriptors. Caches will, though. I hope this is ok.
Implementation:
To make things easy, we should publish the suicide descriptor only
To make things easy, we should publish the shutdown descriptor only
on controlled shutdown (SIGINT as opposed to SIGTERM). That would
leave enough time for publishing that we probably wouldn't need any
extra synchronization code.
@ -76,9 +76,6 @@ Acknowledgements:
Comments:
1) Don't name the official feature "suicide descriptors". Suicide is
irreversible, and the concept pushes many people's buttons. How about
"shutdown descriptors"?
2) Maybe add a rule "Don't do this for hibernation if we expect to wake
up before the next consensus is published"?
- NM 9 Oct 2007
- NM 9 Oct 2007

View File

@ -23,7 +23,7 @@ Status: Closed
At a typical bootstrap a client downloads a 140KB consensus, about
10KB of certificates to verify that consensus, and about 1.6MB of
server descriptors, about half of which it requires before it will
server descriptors, about 1/4 of which it requires before it will
start building circuits.
Another proposal deals with how to get that huge 1.6MB fraction to
@ -33,8 +33,8 @@ Status: Closed
to get in order to work.
About one third of the routers listed in a consensus are not running
and will therefor never be used by clients who use this consensus.
Not listing those routers will safe about 30% to 40% in size.
and will therefore never be used by clients who use this consensus.
Not listing those routers will save about 30% to 40% in size.
3. Proposed change
@ -47,3 +47,4 @@ Status: Closed
they support method 4 then this new method will be used: The
consensus document is formed like before but a new last step removes
all routers from the listing that are not marked as Running.

View File

@ -34,7 +34,7 @@ Goals
We need to make sure this information isn't exposed in a way that
helps an adversary.
Methods for curent clients:
Methods for current clients:
Every client downloads network status documents. There are
currently three methods (one hypothetical) for clients to get them.
@ -49,7 +49,7 @@ Methods for curent clients:
[In both of the above cases, clients choose a running
directory cache at random with odds roughly proportional to
its bandwidth. If they're just starting, they know a ]
its bandwidth. If they're just starting, they know a XXXX FIXME -NM]
- In some future version, clients will choose directory caches
to serve as their "directory guards" to avoid profiling
@ -82,12 +82,12 @@ Methods for curent clients:
Notes:
- [Over H hours, the N for V2 clients is 2*H, and the N for V3
clients is currently around N/2 or N/3.]
clients is currently around H/2 or H/3.]
- (We should only count requests that we actually intend to answer;
503 requests shouldn't count.)
- These measurements should also be be taken at a directory
- These measurements should also be taken at a directory
authority if possible: their picture of the network is skewed
by clients that fetch from them directly. These clients,
however, are all the clients that are just bootstrapping