Hi George, We were having a similar discussion about what to include in the "receive new consensus" action.
We currently have three actions to remove dead/unused guards. They are: 1. Marking guards that are not listed in the latest consensus as "bad" 2. Remove guards that have been dead for 30 days 3. Remove guards that were added more than 30 days ago Specifically, our question was whether #2 and #3 should be part of the algorithm for new guard selection, as this seems to be more state file maintenance, or if these will always be a part of the "receive new consensus" action. If #2 and #3 can be separated, we were wondering where these would go- if there are other similar events for state file maintenance. We have an updated document here- https://github.com/twstrike/tor_guardsim/blob/develop/original_algorithm.md Looking forward to seeing what you think! Chelsea On Mon, Feb 15, 2016 at 10:15 AM, George Kadianakis <[email protected]> wrote: > Ola Bini <[email protected]> writes: > > > Hi again, > > > > Here is the newest version of the algorithm: > > https://gist.github.com/olabini/343da01de8e01491bf5c > > > > Thanks! Looks better! > > I think we are reaching the point that we need good simulations and > actually > running and stepping through the algorithm with actual data to find issues > and > suboptimalities. And maybe we also need to get a third person familiar with > guards to review it. > > BTW, I noticed you removed the "we received a new consensus" part. That's > fine > for now, but I think it should be added back at some point maybe as a > separate > event. I like the work done by rjunior and chelsea here: > https://gist.github.com/chelseakomlo/2acbe15314b5a809c6f4 > and I think the events described are quite close to the Tor networking > API. So > it might be worth having this algorithm mirror that event structure. > >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
