[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):

 Reviewed the initial effects of the fallback-to-self-measure
 state which lasted from about 16:00 to 21:00 GMT on 7/30.

 Does not look dire, and it even appears possible that
 the middle-fast relays have sufficient excess
 capacity to absorb the load redirected from
 super-fast relays.  Medium-fast relays tend
 to be loaded to only 20-30% in the present
 environment.

 Attached several Blutemagie graphs for a sample
 of super-fast relays (.PNG files).  The relays
 exhibiting the largest drop-off were saturated
 and might even be gaming the BWauths for weightings
 in excess of their true capacity.

 Two attached .SVGs show middle-speed relay weightings,
 Interestingly the weight-increase from the event was
 less than an earlier eccentric values assigned by
 a prior iteration of TorFlow.  I operate Binnacle
 and it easily handled the earlier elevated weight.

 Three possibilities come to mind

 1) change nothing as the current behavior, while not perfect, might be
 best

 2) permit two or even one BWauth to fulfill a consensus quorum

 3) increase the self-measure bandwidth cap, perhaps to somewhere from 15k
 to 30k

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