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.

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.