From d280b64b5fcca4286d85adfab59c24832785cbfa Mon Sep 17 00:00:00 2001 From: Peter Palfrader Date: Fri, 11 Jul 2008 19:01:48 +0000 Subject: Add weight consensus line, as described on or-dev, list elements of RELAY_REQUEST_SD cells svn:r15844 --- proposals/141-jit-sd-downloads.txt | 57 ++++++++++++++++++++++++++------------ 1 file changed, 40 insertions(+), 17 deletions(-) (limited to 'proposals/141-jit-sd-downloads.txt') diff --git a/proposals/141-jit-sd-downloads.txt b/proposals/141-jit-sd-downloads.txt index 2384405..870115d 100644 --- a/proposals/141-jit-sd-downloads.txt +++ b/proposals/141-jit-sd-downloads.txt @@ -107,7 +107,7 @@ Status: Draft 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 @@ -116,11 +116,32 @@ Status: Draft clients to not require all server descriptors this information will have to move into the network status document. - [XXX Two open questions here: - a) how do we arrive at a consensus weight? - b) how to represent weights in the consensus? - Maybe "s Guard=0.13 Exit=0.02 Middle=0.00 Stable.." - ] + Consensus documents will have a new line per router similar + to the "r", "s", and "v" lines that already exist. This line + will convey weight information to clients. + + "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 @@ -143,11 +164,7 @@ Status: Draft has a hash for the descriptor of this server. We want exactly that descriptor, not a different one.) - [XXX: How? We could either come up with a new cell type, - 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.] + It does that by sending a RELAY_REQUEST_SD cell. 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. @@ -168,7 +185,16 @@ Status: Draft constant upper limit in order to conceal a client's destination 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] 3.3 Protocol versions @@ -210,10 +236,7 @@ Status: Draft 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 - descriptor. In the future we might amend RELAY_REQUEST_SD cells to - contain also the expected IP address and OR-port of the server C (the - 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 + descriptor. The RELAY_REQUEST_SD cell already has all the info that + B needs to contact C so it can ask about the descriptor before passing it back to the client. -- cgit v1.2.3-54-g00ecf