[tor-relays] bwauths don't like one of my relays?

[teor]

Hi,

Thanks for reporting this issue, and sorry it's taken us a while to get
back to you. Many of us have been on leave over the holidays, and we're
still catching up.

> On 4 Jan 2020, at 10:18, trusting.mcnulty at protonmail.com wrote:
> 
> An update on my relay 'kima' ($54A35E582F9E178542ECCFA48DBE14F401729969) --
> 
> Eventually I did get assigned more weight; the relay is currently at 4600.
> 
> Along the way I think I discovered one potential problem with the bwauth bootstrapping process, at least for sbws.  (I'm not sure about torflow.)

Torflow's partitions have a similar issue, but it's actually worse:
a relay can get stuck in a low-bandwidth partition forever.

> When sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
> https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216
> 
> So this means that in this case, sbws would have picked any exit that was not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at least, well, 2.  That's not a lot.
> 
> As it turns out, something like 10% of exits have under a 600Kbyte/sec advertised bandwidth.  So it seems pretty easy from this weight=1 bootstrap scenario to get paired with an exit that will give poor test results.
> 
> Perhaps bwauth path selection should also choose a testing pair from exits/relays with a certain absolute minimum of weight or advertised bandwidth?

I've opened a ticket for this issue:
https://trac.torproject.org/projects/tor/ticket/33009

We'll try to resolve it before we deploy any more sbws instances.

T

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200121/b3a16eb7/attachment.sig>