[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