mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-13 06:33:44 +01:00
Add weight consensus line, as described on or-dev,
list elements of RELAY_REQUEST_SD cells svn:r15844
This commit is contained in:
parent
f66b810616
commit
221eccd9fe
@ -107,7 +107,7 @@ Status: Draft
|
|||||||
from that key is valid.
|
from that key is valid.
|
||||||
|
|
||||||
|
|
||||||
3. Doing away with the need for all SDs
|
3. No longer require clients to have copies of all SDs
|
||||||
|
|
||||||
3.1 Load balancing info in consensus documents
|
3.1 Load balancing info in consensus documents
|
||||||
|
|
||||||
@ -116,11 +116,32 @@ Status: Draft
|
|||||||
clients to not require all server descriptors this information will
|
clients to not require all server descriptors this information will
|
||||||
have to move into the network status document.
|
have to move into the network status document.
|
||||||
|
|
||||||
[XXX Two open questions here:
|
Consensus documents will have a new line per router similar
|
||||||
a) how do we arrive at a consensus weight?
|
to the "r", "s", and "v" lines that already exist. This line
|
||||||
b) how to represent weights in the consensus?
|
will convey weight information to clients.
|
||||||
Maybe "s Guard=0.13 Exit=0.02 Middle=0.00 Stable.."
|
|
||||||
]
|
"w Exit=41 Guard=94 Middle=543 ..."
|
||||||
|
|
||||||
|
It starts with the letter w and then contains any number of Key=Value
|
||||||
|
pairs. Values will be non-negative integers. Clients will pick
|
||||||
|
routers with a propability proportional to the number for the intended
|
||||||
|
purpose.
|
||||||
|
|
||||||
|
Clients MUST accept sums of all weights for a given purpose over all
|
||||||
|
routers in a consensus up to UINT64_max.
|
||||||
|
|
||||||
|
[XXX how do we arrive at a consensus weight?
|
||||||
|
option a) Perhaps the vote could contain the node's bandwidth, and
|
||||||
|
this could be used to calculate the weights? It's
|
||||||
|
necessary that the consensus remain a deterministic
|
||||||
|
function of the votes.
|
||||||
|
option b) Every voter assigns weights for each of the purposes
|
||||||
|
(Exit, Guard, ..) so that their total sum is some constant
|
||||||
|
X. When building a consensus we take the median for each
|
||||||
|
purpose for each router.
|
||||||
|
|
||||||
|
Option a has the disadvantage that if we want to tweak the weighting
|
||||||
|
we have to make a new consensus-method]
|
||||||
|
|
||||||
3.2 Fetching descriptors on demand
|
3.2 Fetching descriptors on demand
|
||||||
|
|
||||||
@ -143,11 +164,7 @@ Status: Draft
|
|||||||
has a hash for the descriptor of this server. We want exactly
|
has a hash for the descriptor of this server. We want exactly
|
||||||
that descriptor, not a different one.)
|
that descriptor, not a different one.)
|
||||||
|
|
||||||
[XXX: How? We could either come up with a new cell type,
|
It does that by sending a RELAY_REQUEST_SD cell.
|
||||||
RELAY_REQUEST_SD that takes only a hash (of the SD), or use
|
|
||||||
RELAY_BEGIN_DIR. The former is probably smarter since we will
|
|
||||||
want to use it later on as well, and there we will require
|
|
||||||
padding.]
|
|
||||||
|
|
||||||
A client MAY cache the descriptor of the guard node so that it does
|
A client MAY cache the descriptor of the guard node so that it does
|
||||||
not need to request it every single time it contacts the guard.
|
not need to request it every single time it contacts the guard.
|
||||||
@ -168,7 +185,16 @@ Status: Draft
|
|||||||
constant upper limit in order to conceal a client's destination
|
constant upper limit in order to conceal a client's destination
|
||||||
from anybody who might be counting cells/bytes.
|
from anybody who might be counting cells/bytes.
|
||||||
|
|
||||||
[XXX: detailed spec of RELAY_REQUEST_SD cell and its reply]
|
RELAY_REQUEST_SD cells contain the following information:
|
||||||
|
- hash of the server descriptor requested
|
||||||
|
- hash of the identity digest of the server for which we want the SD
|
||||||
|
- IP address and OR-port or the server for which we want the SD
|
||||||
|
- padding factor - the number of cells we want the answer
|
||||||
|
padded to.
|
||||||
|
[XXX this just occured to me and it might be smart. or it might
|
||||||
|
be stupid. clients would learn the padding factor they want
|
||||||
|
to use from the consensus document. This allows us to grow
|
||||||
|
the replies later on should SDs become larger.]
|
||||||
[XXX: figure out a decent padding size]
|
[XXX: figure out a decent padding size]
|
||||||
|
|
||||||
3.3 Protocol versions
|
3.3 Protocol versions
|
||||||
@ -210,10 +236,7 @@ Status: Draft
|
|||||||
RELAY_REQUEST_SD cell that asks for C's server descriptor (by SD digest).
|
RELAY_REQUEST_SD cell that asks for C's server descriptor (by SD digest).
|
||||||
|
|
||||||
In order to answer that request B obviously needs a copy of C's server
|
In order to answer that request B obviously needs a copy of C's server
|
||||||
descriptor. In the future we might amend RELAY_REQUEST_SD cells to
|
descriptor. The RELAY_REQUEST_SD cell already has all the info that
|
||||||
contain also the expected IP address and OR-port of the server C (the
|
B needs to contact C so it can ask about the descriptor before passing it
|
||||||
client learns them from the network status document), so that B no
|
|
||||||
longer needs to know all the descriptors of the entire network but
|
|
||||||
instead can simply go and ask C for its descriptor before passing it
|
|
||||||
back to the client.
|
back to the client.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user