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!