Hello,

we had a meeting about proposal 259 "New Guard Selection Behaviour". You can see the logs here: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-03-23-15.01.log.txt

Some notes:

- The latest version of the proposal can be found here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html There is also some discussion with Tim that has been happening in that thread since yesterday.

It's likely that the proposal will be slightly changed (read: improved) as implementation and testing proceeds.

The implementation of the proposal is currently happening here: https://github.com/twstrike/tor_for_patching/tree/prop259

- We discussed whether the guard algorithm should care about circuit restrictions like requiring that the guard of a circuit needs to be Stable (needs_uptime) or Fast (needs_capacity).

We decided that for now the algorithm should be able to handle these restrictions, by skipping to the next guard that satisfies the conditions in case the top guard does not. This is also how the current guard algorithm works.

In the future we should make it so that all Guards are both Stable and Fast, so that this stupid check does not need to happen [TODO: I should open a ticket for this if it doesn't already exist].

- We discussed how ReachableAddresses should work with regards to guardlists.

A suggestion by Tim came from here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010630.html who says: "I suggest that we compose the set of UTOPIC guards based on addresses that are reachable and preferred (or, if there are no guards with preferred addresses, those guards that are reachable). I suggest that we use the same mechanism with DYSTOPIC guards, but add a port restriction to 80 & 443 to all the other restrictions. (This may result in the empty set.)"

I think this suggstion makes sense for now.

- We also talked about directory guards and how they should work but we didn't come to a conclusion.

My current intuition is that if a directory circuit appears that requires a directory guard, we treat it as a constraint the same way we treat needs_capacity and needs_uptime. So if our top guard cannot be a directory guard (is not a V2Dir), we skip it and go down our list till we find a guard that does.

In the future (almost) all guards will be directory guards so this should become less of an issue (see #12538).

- Finally, a topic that came up after the meeting in: https://lists.torproject.org/pipermail/tor-dev/2016-March/010635.html had to do with how we treat bad guards in SAMPLED_UTOPIC_GUARDS and SAMPLED_DYSTOPIC_GUARDS.

So if suddenly 90% of the guards in SAMPLED_UTOPIC_GUARDS drop out of the consensus, what do we do? We mark them as bad, and then what? Do we remove them from the sampled list? Or do we keep them in there in case they come back? (This latter behavior is what tor currently does).

But then if we keep them, don't we also need to add some more guards in there to make up for the bad ones? How exactly should this work? Some thinking needs to be done here.

- We also discussed the need for good debug logging in the prop259 tor branch, so that we can test it ourselves. Ideally, the logging should be nice and intuitive, so that we can monitor the logs every now and then and check if the guard picking works properly.

For example, if the algorithm keeps on switching guards all the time, there is a problem. If the algo is using the 5th guard while the 1st guard is up, it's a problem. Good logging should be able to reveal all these problems without having to spend 20 minutes investigating every new log message.