mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 04:13:28 +01:00
minor touchups on proposals
svn:r15263
This commit is contained in:
parent
96bf9cd4c5
commit
c96b15f9bc
@ -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
|
||||
|
@ -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
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user