Hi folks,
As part of the hackweek projects ( https://gitlab.torproject.org/tpo/community/hackweek/ ), some of us are thinking about simple tweaks we can do to tune the network to better handle this month's traffic overload.
The long term answer is to try out proposal 327: https://gitweb.torproject.org/torspec.git/tree/proposals/327-pow-over-intro.... because we think a lot of the overload has to do with people sending way too many intro cells to some onion services, and giving the onion services ways to defend themselves is the only real answer.
But while we're thinking about implementing that proposal, one of our earlier steps is to set the guard-n-primary-guards-to-use consensus parameter from 1 to 2.
Now that it's taken effect (you can watch the votes at https://consensus-health.torproject.org/#consensusparams ), this change means that clients will now choose between two guard relays by default (rather than just one) when building circuits.
This is potentially a big deal, since it puts us into a different point in the performance vs safety tradeoff space.
Here is some reading for why we originally moved down to 1 guard by default: https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramete... https://www-users.cse.umn.edu/~hoppernj/single_guard.pdf
But on the theory that some guards are way overloaded right now and some aren't, giving clients two bites at the apple might make a dramatic improvement in terms of reliable and consistent performance.
There is also some argument in favor of using two guards anyway. One reason (explained more in proposal 291) is that there are already some edge cases where clients use their second guard. And also, in the glorious future, we will want to be using multiple guards because we have switched to the multi-path Conflux design (proposal 329) -- though we're not there yet.
So: I am giving you all here some early warning, in case you see anything odd on the network when we make this change. Let us know if you do. :)
--Roger