Changes between Initial Version and Version 36 of Ticket #22453

Nov 21, 2018, 3:43:20 AM (8 months ago)


  • Ticket #22453

    • Property Status changed from new to needs_information
    • Property Parent ID changed from to #25925
    • Property Summary changed from We should rip out the bandwidth self-test to Relays should regularly do a larger bandwidth self-test
    • Property Owner set to juga
    • Property Milestone changed from Tor: 0.3.2.x-final to Tor: 0.4.0.x-final
    • Property Keywords 034-triage-20180328 034-removed-20180328 tor-bwauth 035-backport 034-backport-maybe 033-backport-maybe 029-backport-maybe-not added
    • Property Reviewer changed from to teor
    • Property Type changed from enhancement to defect
  • Ticket #22453 – Description

    initial v36  
    99In 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.)
     11Note: if we do keep it in, here's a better design:
    1114But 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.