[tor-bugs] #16696 [- Select a component]: BWauth no-consensus fallback logic may need revision

[Tor Bug Tracker & Wiki]

#16696: BWauth no-consensus fallback logic may need revision
--------------------------------------+-----------------
     Reporter:  starlight             |      Owner:
         Type:  defect                |     Status:  new
     Priority:  major                 |  Milestone:
    Component:  - Select a component  |    Version:
   Resolution:                        |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |
--------------------------------------+-----------------

Comment (by starlight):

 An additional important element is guard-node
 inertial.  Takes 90 days for a consensus
 weight change to fully propagate to guard
 assignments, and the last time this happened
 guards were not nearly so sticky.

 The rebalance mainly impacts exit and
 middle relays.  But very-fast exit relays
 are assigned zero guard-weights and behave
 like pure exits.  I suspect that even if
 the guard assignments all rotated it would
 still work fine at present.

 Two-to-three times more relays, all with
 lots more bandwidth, and relay code better
 able to handle abuse-by-bot.  Plus 500+
 wasted relays coming back online. Perfect
 balance is presently not as critical
 as it was previously.

 The PID controller algorithm certainly
 should be kept against future high-load
 scenarios (and perhaps with reduced
 emphasis on high-bandwidth relays?),
 but today bugs in TorFlow and the
 shortage of BWauths should to be
 corrected soon, especially to aid
 the morale of the operators of those
 500 unused relays.

 ======

 As for the no-BW-consensus fallback algorithm,
 my thought is it's not broken and doesn't need
 fixing.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16696#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online