[tor-dev] Next version of the algorithm

George Kadianakis 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.

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 at riseup.net>
> wrote:
>> 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
>> 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.

More information about the tor-dev mailing list