[tor-dev] [RFC] Proposal draft: The move to a single guard node

[George Kadianakis]

> 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!