[tor-dev] Next version of the algorithm

[George Kadianakis]

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