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

[s7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

That is correct Mike Perry - (at least in my case) Tor is much slower
(any page takes more time to load) than when bandwidth authorities
were assigning weights. This happens on 2 different client computers
and one live Tails (obviously each uses a different Guard). I wouldn't
say it is now slow enough that someone wouldn't be using it, but it is
indeed slower than it was before (pre-self advertised weights).

I don't think it's a good idea to get back to self advertised weights.

On 8/5/2015 1:17 AM, Mike Perry wrote:
> 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.
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVwUG0AAoJEIN/pSyBJlsRyUcH/jOkx+8YxBQMCAJyyHWtl6WJ
Ix8ItcJOkMry8Mt0pGrmlgwYQjmoP/jv9RzFMVNc60rKpSjFHxUk0YAyZfXB4Zhj
sX/ZfBdhcQv6hZZ431Iqp/D/GOdAVOGlk8XnKczddPXQc5kO+OY4pQKYV6Eotn2v
fOTuwy0pst5pcDvH/6ZTa52mN+DBrOTqlL7JY4Hx8BdWds2FpMvYWdP/Jk+GbE5m
/1QkfgRjox8sMnn+y+nbaswGjQ4y2EWjVSXU/TbJyam3XJHR1WDwrlYQma86JUGZ
Yu/u6VAyG6+JCk72bMD+ofO5yQmeo3ii2WhYTcF5H60N91p/6mKkPxOcm4Xr418=
=t/IX
-----END PGP SIGNATURE-----