[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] [RFC] Proposal draft: The move to a single guard node
Nicholas Hopper <hopper@xxxxxxxxxx> writes:
> On Tue, Apr 15, 2014 at 6:35 AM, George Kadianakis <desnacked@xxxxxxxxxx> 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:
> https://www-users.cs.umn.edu/~hopper/single-guard-node.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
confused?
> choose N proportionally to F*Wpf*B + (1-F)*Wpn*B.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev