Chelsea Komlo <cko...@thoughtworks.com> writes: > 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. >
Hello Chelsea, I agree that event actions #2 and #3 are not really connected to the "received new consensus" event. Currently in Tor these two actions are also performed by remove_obsolete_entry_guards() which is called by entry_guards_parse_state(). The entry_guards_parse_state() function is called when Tor starts up, to load any guard information from the state file. So in the new algorithm maybe this can fit under a new LOAD_STATE event? Looking at the new prop259, this could be part of the START of the algorithm, called when initializing USED_GUARDS. > 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 <desnac...@riseup.net> > wrote: > >> Ola Bini <ob...@thoughtworks.com> 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 tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev