Opened 3 years ago

Last modified 5 months ago

#22453 needs_information defect

We should rip out the bandwidth self-test — at Initial Version

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 034-triage-20180328, 034-removed-20180328, tor-bwauth, 035-backport, needs-proposal, reviewer-was-teor-20190422, 034-unreached-backport-maybe, 033-unreached-backport-maybe
Cc: 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.

Child Tickets

#19009defectassignedjugabandwidth testing circuits should be allowed to use our guards
#28509defectnewLimit relay bandwidth self-tests based on RelayBandwidthRate, not BandwidthRate
#28510defectnewWhen relays reset bandwidth tests, the test waits until the next directory document is received
#28511defectnewLimit the number of open testing circuits, and the total number of testing circuits
#28512defectnewIncrease NUM_PARALLEL_TESTING_CIRCS to avoid circuit windows
#28514defectnewOpen NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated

Change History (0)

Note: See TracTickets for help on using tickets.