Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#28519 closed defect (wontfix)

Prioritize relays with no measured bandwidth in the consensus

Reported by: juga Owned by:
Priority: Medium Milestone: sbws: unspecified
Component: Core Tor/sbws Version:
Severity: Normal Keywords:
Cc: pastly, juga Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

sbws currently prioritizes relays for which it has not measurements.
It should also prioritize relays with no measure bandwidth in the consensus (https://trac.torproject.org/projects/tor/ticket/22453#comment:33).
Maybe it should also prioritize new relays (uptime).

Child Tickets

Change History (13)

comment:1 Changed 13 months ago by teor

sbws should also prioritise measuring relays that aren't in its own output file

comment:2 Changed 13 months ago by teor

Parent ID: #22453

comment:3 Changed 13 months ago by arma

It seems like the simple rule of "prioritize relays if we don't have enough recent measurements of them" should produce the behavior we want, right?

Like, if the consensus doesn't have a measured number, but it's the fault of *other* scanners (e.g. because we're the only ones voting a number), then re-measuring it over and over ourselves isn't going to help anything.

I'm trying to avoid the outcome where we need a full-page complex diagram to explain to people how sbws decides which relay to scan next. :) Some complexity is needed, but we should be trying to find ways to avoid adding complexity that we aren't sure we need.

comment:4 in reply to:  3 Changed 13 months ago by pastly

Replying to arma:

It seems like the simple rule of "prioritize relays if we don't have enough recent measurements of them" should produce the behavior we want, right?

[...]

I'm trying to avoid the outcome where we need a full-page complex diagram to explain to people how sbws decides which relay to scan next. :) Some complexity is needed, but we should be trying to find ways to avoid adding complexity that we aren't sure we need.

Exactly. SIMPLE bandwidth scanner.

If you understand a min-priority queue, you understand relay prioritization.

There's already an exception made for measurements that were errors.

Is it really smart to add exceptions for relays that don't have a measured bandwidth in the consensus?

<slippery slope>What about relays that have a high likelihood of being measured poorly? For example, ones in countries far away from the rest of the Tor network. What about fast relays, since maybe they're too fast and we might need to bring them down? What about slow relays, since they might need another chance to get a better weight?</slippery slope>

Replying to teor:

sbws should also prioritise measuring relays that aren't in its own output file

How does it not already do this? If it's in the v3bw file it just produced, it has some measurements for that relay. If it doesn't have enough* measurements to be in the v3bw file, then it will have a better priority of being measured already.

(* because apparently when acting like torflow we require more than 1 measurement before putting in the v3bw file. The specifics aren't important. I'm probably 50% wrong.)

comment:5 in reply to:  1 Changed 13 months ago by juga

Replying to teor:

sbws should also prioritise measuring relays that aren't in its own output file

That would mean having to read its own v3bw files, not only the raw results.
I've in my queue of tickets to review the ones about having the restrictions on the relays that end up in the file.

comment:6 Changed 13 months ago by juga

If we end up removing the relays' self-test when they start (#22453), should relays with less uptime be measured first?.

Edit: add ticket number

Last edited 13 months ago by juga (previous) (diff)

comment:7 Changed 13 months ago by teor

Parent ID: #22453#25925

comment:8 in reply to:  3 Changed 13 months ago by teor

Parent ID: #25925

Replying to arma:

It seems like the simple rule of "prioritize relays if we don't have enough recent measurements of them" should produce the behavior we want, right?

I think you're right: if we re-measure relays with few measurements, we'll eventually have enough measurements for those relays.

In some cases, we'll measure a relay, then exclude its measurement. But in order to find these cases, we need to do the analysis in #28547.

Once we know *why* relays aren't making it into the bandwidth file, we'll know if we need to fix the priority queue (or the exclusion code).

comment:9 Changed 13 months ago by teor

Resolution: wontfix
Status: newclosed

Let's open another ticket if we find an actual bug.

comment:10 Changed 13 months ago by teor

Milestone: sbws 1.1sbws 1.2

Milestone renamed

comment:11 Changed 13 months ago by teor

Milestone: sbws 1.2sbws: 1.2.x

Milestone renamed

comment:12 Changed 13 months ago by teor

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

Milestone renamed

comment:13 Changed 13 months ago by teor

Milestone: sbws: 1.2.x-finalsbws: unspecified

Milestone renamed

Note: See TracTickets for help on using tickets.