[tor-dev] [RFC] Proposal draft: The move to a single guard node
desnacked at riseup.net
Sat Apr 26 13:40:33 UTC 2014
Nicholas Hopper <hopper at cs.umn.edu> writes:
> On Tue, Apr 15, 2014 at 6:35 AM, George Kadianakis <desnacked at riseup.net> wrote:
>> A patch for the proposal would be useful. If you don't have time to do
>> it, just tell me and I will do it myself.
> Here's a patch:
Thanks for the patch! FWIW, the original proposal + your patch got
merged in torspec as proposal 236.
A nitpicking question:
> A guard N that has been visible for V out of NNN*30*24 consensuses
> has had the opportunity to be chosen as a guard by approximately
> F = V/NNN*30*24 of the clients in the network, and the remaining
> 1-F fraction of the clients have not noticed this change. So when
> being chosen for middle or exit positions on a circuit, clients
> should treat N as if F fraction of its bandwidth is a guard
> (respectively, dual) node and (1-F) is a middle (resp, exit) node.
> Let Wpf denote the weight from the 'bandwidth-weights' line a
> client would apply to N for position p if it had the guard
> flag, Wpn the weight if it did not have the guard flag, and B the
> measured bandwidth of N in the consensus. Then instead of choosing
> N for position p proportionally to Wpf*B or Wpn*B, clients should
Why do you mention Wpn*B here? That is, in the sentence "Wpf*B or Wpn*B".
Since we are talking about picking a *guard* N for middle or exit
positions a client would normally only use Wpf*B, right? Or am I
> choose N proportionally to F*Wpf*B + (1-F)*Wpn*B.
More information about the tor-dev