Opened 3 years ago

Last modified 3 weeks ago

#16559 assigned defect

bwauth code needs to be smarter about failed circuits

Reported by: TvdW Owned by: juga
Priority: Medium Milestone: sbws: unspecified
Component: Core Tor/sbws Version:
Severity: Normal Keywords: tor-bwauth, sbws
Cc: s7r@…, starlight.2015q2@…, juga, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (21)

comment:1 Changed 3 years ago by s7r

Cc: s7r@… added

comment:2 Changed 3 years ago by s7r

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?

comment:3 Changed 3 years ago by starlight

Cc: starlight.2015q2@… added

comment:4 Changed 13 months ago by teor

Parent ID: #13630
Severity: Blocker

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

comment:5 Changed 13 months ago by teor

Priority: HighMedium
Severity: BlockerNormal

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

comment:6 Changed 13 months ago by teor

Owner: aagbsn deleted
Status: newassigned

aagbsn was the default owner, unassigning

comment:7 Changed 12 months ago by teor

Status: assignednew

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

comment:8 Changed 8 months ago by juga

Cc: juga added

comment:9 Changed 8 months ago by juga

Parent ID: #1363025925

comment:10 Changed 8 months ago by juga

Parent ID: 25925#25925

comment:11 Changed 7 months ago by juga

Owner: set to juga
Status: newassigned

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

comment:12 Changed 7 months ago by juga

Keywords: tor-dirauth sbws added

comment:13 Changed 5 months ago by juga

Cc: teor 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?

comment:14 Changed 5 months ago by juga

Keywords: tor-bwauth added; tor-dirauth removed

comment:15 in reply to:  13 Changed 5 months ago by teor

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.

comment:16 Changed 4 weeks ago by teor

Component: Core Tor/TorflowCore Tor/sbws
Milestone: sbws 1.1

comment:17 Changed 4 weeks ago by teor

Parent ID: #25925

comment:18 Changed 3 weeks ago by teor

Milestone: sbws 1.1sbws 1.2

Milestone renamed

comment:19 Changed 3 weeks ago by teor

Milestone: sbws 1.2sbws: 1.2.x

Milestone renamed

comment:20 Changed 3 weeks ago by teor

Milestone: sbws: 1.2.xsbws: 1.2.x-final

Milestone renamed

comment:21 Changed 3 weeks ago by teor

Milestone: sbws: 1.2.x-finalsbws: unspecified

Milestone renamed

Note: See TracTickets for help on using tickets.