[tor-dev] Notes from the prop259 proposal reading group
desnacked at riseup.net
Fri Mar 25 11:51:53 UTC 2016
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
- The latest version of the proposal can be found here:
There is also some discussion with Tim that has been happening in that thread
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:
- 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
"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
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:
had to do with how we treat bad guards in SAMPLED_UTOPIC_GUARDS and
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.
More information about the tor-dev