[tor-dev] [RFC] Proposal draft: The move to a single guard node
George Kadianakis
desnacked at riseup.net
Fri Apr 11 12:45:37 UTC 2014
> 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.
>
Ah, I see. I originally misinterpreted what you meant by 'last
rotation period'.
> (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)
>
Yep.
We also don't consider new releases of TBB/Tails (many users pick new
entry guards), or sudden bulk arrival of users (botnets, real life
events, etc.).
> > 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?
>
I see. That makes sense, I think.
I will ponder on this a bit more, and then edit the proposal.
(I would like to think a bit more about how accurate the assumption
"relay has been a guard for 0.25 of the rotation period =>
relay has 0.25 of its bandwidth occupied for guard purposes")
Thanks!
More information about the tor-dev
mailing list