[tor-bugs] #28519 [Core Tor/sbws]: Prioritize relays with no measured bandwidth in the consensus

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Nov 21 14:37:05 UTC 2018


#28519: Prioritize relays with no measured bandwidth in the consensus
---------------------------+--------------------------
 Reporter:  juga           |          Owner:  (none)
     Type:  defect         |         Status:  new
 Priority:  Medium         |      Milestone:  sbws 1.1
Component:  Core Tor/sbws  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:  #22453         |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+--------------------------

Comment (by pastly):

 Replying to [comment:3 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 [comment:1 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.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28519#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list