[tor-relays] BWauth no-consensus state in effect

[Mike Perry]

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-06&end=2015-08-04&source=all&filesize=50kb
> 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-06&end=2015-08-04&source=all&filesize=50kb

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.



-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150804/134bb336/attachment-0001.sig>