> 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! _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev