bwauth code needs to be smarter about failed circuits

In the current bandwidth authority code, when a fetch attempt fails, it will still be counted as a circuit that went through all of the nodes -- even if those nodes weren't responsible for the failure.

This has the potential of resulting in a relay not being measured sufficiently, or at all: the code will consider failures from unstable nodes to be relevant for nodes that are perfectly stable.

In slices where exits and entries aren't well-distributed (like, all of them) this can result in some nodes not being measured at all, and losing their consensus weight. This seems to affect exits a lot more than it does other relay types: people on tor-relays@ have mentioned that removing their exit policies gets their consensus weight back, and I have been able to reproduce this.

changed milestone to %sbws: unspecified

added component::core tor/sbws milestone::sbws: unspecified owner::juga parent::29954 priority::medium sbws scanner severity::normal status::assigned tor-bwauth type::defect labels

Trac:
Cc: N/A to s7r@sky-ip.org

The problem does affect Exits more than middle relays, and a lot of operators reported that changing to middle relay instead of exit helped, but there also have been cases when even changing the ExitPolicy to reject : didn't bring the consensus weight back.

How does a bwauth exactly connect to an Exit and tries to measure it? What can happen in between this to make the bwauth think the Exit is misbehaving?

Trac:
Cc: s7r@sky-ip.org to s7r@sky-ip.org, starlight.2015q2@binnacle.cx

This is a feature that belongs in the new bwauth replacement project, see #13630 (moved).

Trac:
Reviewer: N/A to N/A
Severity: N/A to Blocker
Parent: N/A to #13630 (moved)
Sponsor: N/A to N/A

Priorities and Severities in torflow are meaningless, setting them all to Medium/Normal.

Trac:
Severity: Blocker to Normal
Priority: High to Medium

aagbsn was the default owner, unassigning

Trac:
Status: new to assigned
Owner: aagbsn to N/A

Mark all tickets that are assigned to nobody as "new".

Trac:
Status: assigned to new

Trac:
Cc: s7r@sky-ip.org, starlight.2015q2@binnacle.cx to s7r@sky-ip.org, starlight.2015q2@binnacle.cx, juga

Trac:
Parent: #13630 (moved) to 25925

Trac:
Parent: 25925 to #25925 (moved)

I'm not sure if this still need to be fixed on Torflow. Going to work on it on sbws

Trac:
Status: new to assigned
Owner: N/A to juga

Trac:
Keywords: N/A deleted, sbws, tor-dirauth added

We are reporting errors in sbws and i think it doesn't have the problem described here. Are there other ideas for this ticket?

Trac:
Cc: s7r@sky-ip.org, starlight.2015q2@binnacle.cx, juga to s7r@sky-ip.org, starlight.2015q2@binnacle.cx, juga, teor

Trac:
Keywords: tor-dirauth deleted, tor-bwauth added

Replying to juga:

We are reporting errors in sbws and i think it doesn't have the problem described here. Are there other ideas for this ticket?

The description says:

In slices where exits and entries aren't well-distributed…

sbws doesn't use slices, so its entry and exit selection is more robust. That might be why it doesn't have this problem.

Trac:
Milestone: N/A to sbws 1.1
Component: Core Tor/Torflow to Core Tor/sbws

Trac:
Parent: #25925 (moved) to N/A

Milestone renamed

Trac:
Milestone: sbws 1.1 to sbws 1.2

Milestone renamed

Trac:
Milestone: sbws 1.2 to sbws: 1.2.x

Milestone renamed

Trac:
Milestone: sbws: 1.2.x to sbws: 1.2.x-final

Milestone renamed

Trac:
Milestone: sbws: 1.2.x-final to sbws: unspecified

In sbws, when a relay is going to be measured, it selects randomly other relay that has double or equal bandwidth than the relay to measure, so it will likely not fail because of the other relay. The next time it will be measured, it will likely not be measured with the same other relay.

However, the fastest relay will be restricted to the be measured with slower relays and small set of possible relays. There's an scaling process after this, but maybe it's a good idea that gets restricted anyway.

In version 1.0.2, sbws was even prioritizing to measure relays with higher number of failures, but it was observed that then it'll continuosly try to measure unstable relays that will probably fail again. This has been removed in the last version and it only prioritizes relays to measure based on how long ago they were measured before.

Regarding the exit policies, it only affects to choose whether the relay to measure will be the first or the second hop and it only checks that policy allows to exit to port 443. A reason why an exit might always fail to be measured is when it retrieves the data from a CDN, the local resolver returns an IPv6 address, and the exit can exit to an IPv6 address. Maybe this is something to be monitered, but it'd not happen when #28463 (moved) is implemented.

I think this ticket can be closed, but it'd be great to get opinions on whether sbws design solves this.

I'd like to see the number of failures that sbws reports for large relays in the first and second position in the circuit.

Then I will have an opinion.

Trac:
Keywords: N/A deleted, scanner added
Parent: N/A to #29954 (moved)

mentioned in issue #26200 (moved)

mentioned in issue #28463 (moved)

mentioned in issue #29954 (moved)

mentioned in issue tpo/core/tor#26200 (closed)

moved to tpo/network-health/sbws#16559 (moved)