[tor-bugs] #22453 [Core Tor/Tor]: We should rip out the bandwidth self-test
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue May 30 17:52:08 UTC 2017
#22453: We should rip out the bandwidth self-test
------------------------------+--------------------------------
Reporter: arma | Owner:
Type: enhancement | Status: new
Priority: Medium | Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords:
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------+--------------------------------
Inspired by #8247 ("In sum. a vestigial tiny bw self-test seems silly to
keep around"), I wonder if we're at the point where we can just take out
all the bandwidth self-test infrastructure.
In favor of ripping it out: there's some complexity at relay startup where
we try to delay publishing our descriptor until we've done the self-test,
since we know we'll have a newer bandwidth number to include soon. We've
had bugs in this delay step.
In favor of ripping it out: in the current design we try to build 4
separate circuits, without using our guards in order to have actually
independent paths, for pushing our 500KB. Relays that aren't reachable end
up with hundreds or thousands of connections open, because they keep
making new circuits and each one probably is to a new relay. Not a big
deal but kind of unfortunate.
In favor of ripping it out: 50KB, which is the most that the current
bandwidth test can tell you, is super tiny compared to current descriptor
bandwidths and current consensus weights. In fact, as prophesied in #8247,
the threshold for the Fast flag is now above 50KB, so publishing 0 vs 50
is essentially just moving you around within the "don't use, they're too
slow" bucket.
In favor of keeping it: maybe the bandwidth authorities have some sort of
psychotic behavior in the face of relays that have a 0 in their
descriptor? Like, they multiply the 0 by a factor for how much better than
the other 0's they are? I have no idea. In case they do, I propose that we
proceed with ripping out the self-test, and simply replace it with the
number "20KB" to guard against psychotic bwauth behavior. (I picked that
number because the directory authorities already use the number 20 when
assigning a weight to a relay that (A) is unmeasured and (B) self-declares
at least 20KB in its descriptor.)
But what about bridges, you might ask? Public relays might have the
bwauths to measure them remotely, but bridges don't have that. I think
nothing uses the bandwidths in bridge descriptors. Are there any plans for
that to change in the future? Even if there are, I think raising the floor
from 0 to 20, and retaining the behavior where we publish a bigger number
if we actually see a bigger number due to client load, should make us
compatible with whatever these plans might be.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22453>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list