[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
On Mon, Apr 7, 2014 at 11:34 AM, George Kadianakis > So, based on your
response, IIUC, the idea is that because young
> guards are underutilized, we want to increase the probability of them
> being chosen in non-guard positions, so that they become more utilized
> till more people pick them as guards?
Right.
> Some questions on the terminology you used:
>
> a) What do you mean by 'last rotation period'? When you say "for
> fraction k of the last rotation period", you mean that if the
> authorities read consensuses for the past 12 months, and the relay R
> was up as a guard for 6 months, then k would be 6/12 == 0.5?
The "rotation period" is the average length of time between choosing
guards. For example, with the current parameters (IIRC), clients
discard a guard and choose a new one at a time uniformly chosen
between 30 and 60 days. So the rotation period is 45 days = 45*24
hours = 1080 consensus votes, and essentially in each of those hours,
1/1080 of the clients choose a new guard. So the last rotation
period's worth of status documents should be the only ones that matter
for figuring out how heavily a node is used as a guard. For example,
if a relay has had the guard flag for 15 days (=360 consensus
documents) out of the last 45, then that relay has about k=360/1080 of
the number of clients using it as a guard as it would have, if it had
been a guard for the full 1080 hours.
(N.B. I'm making an assumption that guard rotations will be uniformly
distributed over the period. This should be safe in equilibrium, but
might get kind of shaky when the period first increases to 9 months or
whatever the final decision is)
> b) By (weight with the guard flag) you mean the result of:
> <consensus BW> * <consensus weight> ?
>
> Is that right, or did I misunderstand you?
Yes.
> Assuming the above terminology assumptions, I began trying to
> understand your formula. First of all, I was wondering how you ended
> up with it? Is this some standard form? I'm not very familiar with
> these things.
Well, the way the weights work is that they compute what fraction of
guard bandwidth should be used for middle and exit traffic, assuming
that the rest will be all used up by client-guard connections. That
is, the weights are telling us to use (1-(<consensus middle weight> +
<consensus exit weight>)) fraction of the guard's bandwidth for these
connections.
But if a relay has only fraction k of its "guard bandwidth" used up
this way, then (1-k) of this bandwidth should go back into the pool
for other positions. I think that's what the formula does, but I
could have it wrong. Does that make sense?
--
------------------------------------------------------------------------
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Research Director, The Tor Project
------------------------------------------------------------------------
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev