Roger Dingledine:
On Thu, Jul 30, 2015 at 08:53:33PM +0200, nusenu wrote:
Has this fallback happened before (=some experience on the potential impact available) or is this outage happening for the first time since the bwauths are in place?
Indeed, it happened a few times back in 2010-2011 when we were first rolling out the bwauths: https://metrics.torproject.org/torperf.html?graph=torperf&start=2009-05-... but it's been mighty stable since then.
Interestingly, you'd expect a big bump in torperf response times when we switched to self-advertised weights. But there isn't one: https://metrics.torproject.org/torperf.html?graph=torperf&start=2015-07-...
Some years ago, Karsten made a nice overlay of bw auth failures to torperf data, which allowed us to see a 4-5X reduction in torperf fetch times while the bw auths were active vs not.
I just added a comment to https://trac.torproject.org/projects/tor/ticket/16696#comment:3 asking Karsten to repeat this visualization. That might be a bad place to do it, though. Might need a new ticket (or tickets)?
I'm guessing this is because we have enough relays, with enough capacity, to handle the current load adequately.
I'm wondering if the downtime in this case hasn't happened for a long enough stretch of consecutive consensus periods for it to impact the network. That might be one explanation. Spare capacity might be another.
But that doesn't mean the current relays are useless. Historically speaking, it means pretty soon more users will show up, once word gets out that Tor isn't as slow as it used to be. :)
I worry that the "capacity economics" involved here might not have the same properties as they used to, and that we might not see increased adoption as a result.
In particular, the switch to one guard makes it much more likely that a new user will pick a slow guard and this will cause them to have a horrible Tor experience. With three guards, you had a much better chance to get at least one fast guard in that case, and then CBT could sort out which was which.
In my case, I usually pick my guards manually for ease of use with my firewall, and as a result performance is always very fast with the three fast guards I have chosen (I often get throughput 750k-1MB/sec for large transfers). In some instances where I have not selected my guards manually, Tor Browser is unbearably slow. Like really, really painfully slow. The whole time. Until I reinstall it.
This makes me think that the performance of people who pick guards from the tail is much much worse than the performance of the top guards, and this property likely is acting as a deterrent to adoption. If even a small fraction of users perceive Tor as totally unusable, the word of mouth is still going to be "OMG Tor is like SOOOOO UNUSABLY SLOW!!"
So long as this keeps happening, I suspect it is unlikely for people to rush to Tor because it is now faster.
I think once we expect most of the clients to have switched to 1 guard, we should get some torperf graphs going for guards of various capacities, and see what the actual effects of this are.