[tor-bugs] #22453 [Core Tor/Tor]: Relays should regularly do a larger bandwidth self-test

[Tor Bug Tracker & Wiki]

#22453: Relays should regularly do a larger bandwidth self-test
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  juga
     Type:  defect                               |         Status:
                                                 |  needs_information
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.0.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  034-triage-20180328,                 |  Actual Points:
  034-removed-20180328, tor-bwauth,              |
  035-backport, 034-backport-maybe, 033          |
  -backport-maybe, 029-backport-maybe-not        |
Parent ID:  #25925                               |         Points:
 Reviewer:  teor                                 |        Sponsor:
-------------------------------------------------+-------------------------
Description changed by teor:

Old description:

> 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.

New description:

 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.)

 Note: if we do keep it in, here's a better design:
 https://trac.torproject.org/projects/tor/ticket/22453#comment:35

 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#comment:36>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online