Re: [tor-relays] (FWD) Network is suffering with only two torflows; can you help?

2020-04-08 Thread Roger Dingledine
On Mon, Apr 06, 2020 at 06:21:00AM -0400, Roger Dingledine wrote:
> FYI, below is a start at a short-term plan to address the current network
> weighting issues, now that, as of a few weeks ago, gabelmoo's torflow
> died and Sebastian hasn't been able to get it going properly again.

Things are looking much better:

(1) gabelmoo got its torflow going again and it's ramping up the set of
relays that it votes on.

(2) bastet switched from sbws (the newer one which is our hope for the
future but which also still has important bugs) to torflow.

(3) dizum is now voting using a copy of moria1's weights.

So we now have 3 torflows fully bootstrapped, and 2 torflows partially
bootstrapped, and we still have 2 sbws's running for comparison and
future debugging:
https://consensus-health.torproject.org/#bwauthstatus

If you want to see the visualization of these changes, check out
the "Bandwidth Auth Statistics, Past 7 Days" section on
https://consensus-health.torproject.org/graphs.html
where you can see the gabelmoo and bastet changes, and how those changes
are reflected in the graphs for the other bwauths too.

(In these graphs, the fraction of orange on the graph is how many relays
that bwauth is voting a low weight for. So a graph with a lot of orange
in it indicates that the bwauth is voting lower weights than expected but
that it's being overruled by the other bwauths. In a balanced equilibrium,
the amount of orange should equal the amount of purple.)

So for those relay operators who have had a weirdly low bandwidth weight
lately, it should be starting to recover now. Thanks for hanging in there.

And for those relay operators who have had a weirdly high bandwidth weight
lately, it should also be recovering, i.e. getting lower, as load gets
shifted to other relays. :)

That said: if your relay is still having a weirdly low weight, and that
remains the case over the next few days, please do let us know and we'll
check it out in more detail.

Thanks!
--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


[tor-relays] (FWD) Network is suffering with only two torflows; can you help?

2020-04-06 Thread Roger Dingledine
FYI, below is a start at a short-term plan to address the current network
weighting issues, now that, as of a few weeks ago, gabelmoo's torflow
died and Sebastian hasn't been able to get it going properly again.

See also nifty's new ticket:
https://bugs.torproject.org/33824

--Roger

- Forwarded message from Roger Dingledine  -

Date: Mon, 6 Apr 2020 06:06:26 -0400
From: Roger Dingledine 
To: dir-auth 
Subject: Network is suffering with only two torflows; can you help?

tl;dr there's a way at the bottom of this mail that you can help even
without running torflow yourself.

[...]

So, it looks like we're down to two remaining torflows, and because
that's less than three, we're suffering much more from the current errors
in sbws.

Specifically, (a) sbws doesn't vote for some relays, and (b) sbws votes
a super low weight for some relays.

There are somewhere between 500 and 1000 relays that are getting left
out of sbws's opinions:
https://consensus-health.torproject.org/#bwauthstatus
and then some thousands more that are getting drastically underweighted,
per the "Bandwidth Auth Statistics" graphs at the bottom of
https://consensus-health.torproject.org/graphs.html

Relay operators are sad that their relays are being useless, and thinking
about how maybe they should shut them off if nobody's going to use them.

I hear from GeKo that the sbws devs are aiming to fix the sbws issues
by end-of-April.

That's great, but I wonder if there are some short term hacks we can do
that will help until then.

Option 1: dizum, dannenberg, or tor26 start up a torflow. I'm guessing
they would have done this already if they were going to.

Option 2: maatuska, longclaw, or bastet switch from sbws to torflow. Is
this an workable option for any of you?

Option 3: Any of you besides Faravahar start hourly importing a copy of
moria1's weights:
https://freehaven.net/~arma/bwscan.V3BandwidthsFile
and you vote them as though you were running your own torflow, but you
don't need your own torflow.

Option 3 is pretty wild at first glance -- it violates some trust and
independence assumptions. But for those who aren't running a bwauth,
you're already not being listened to about bandwidth weights. So I think
this would be a fine hack in the short term to rescue the network, while
we wait for sbws.

Any takers? :)

Here's the simple two-step process for testing the idea:

(1) Set a "45 0-23 * * *" cron line to wget the above freehaven url.
(2) In your torrc, set "V3BandwidthsFile /path/to/that/bwfile"

If you like the idea, and it's just the wget that's too sketchy for you,
I can set up an ssh account that just dumps the file at you when you
present the right ssh key.

Or for super overkill, you'll notice that moria1's (signed) vote has
these two lines it:
bandwidth-file-headers timestamp=1586162183
bandwidth-file-digest sha256=24+52C1ItwnAyBTtBteyy6tjxk8JnUpQ/XZx3YStEXE
so with some stem or shell programming we should be able to verify the
file itself, rather than just verifying the place it came from. We could
be getting away from "short-term hack" there though. :)

--Roger

- End forwarded message -

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays