Chelsea Komlo ckomlo@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:
- Marking guards that are not listed in the latest consensus as "bad"
- Remove guards that have been dead for 30 days
- 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 desnacked@riseup.net wrote:
Ola Bini obini@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.