[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