[tor-dev] Next version of the algorithm
desnacked at riseup.net
Mon Feb 15 21:04:04 UTC 2016
Chelsea Komlo <ckomlo at 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.
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-
> Looking forward to seeing what you think!
> On Mon, Feb 15, 2016 at 10:15 AM, George Kadianakis <desnacked at riseup.net>
>> Ola Bini <obini at 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
>> running and stepping through the algorithm with actual data to find issues
>> 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
>> for now, but I think it should be added back at some point maybe as a
>> event. I like the work done by rjunior and chelsea here:
>> 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.
More information about the tor-dev