[tor-bugs] #2550 [Torflow]: bwauth should reschedule quicker bandwidth test when bandwidthrate changes?

[Tor Bug Tracker & Wiki]

#2550: bwauth should reschedule quicker bandwidth test when bandwidthrate changes?
-------------------------+--------------------------------------------------
 Reporter:  arma         |          Owner:  mikeperry
     Type:  enhancement  |         Status:  new      
 Priority:  normal       |      Milestone:           
Component:  Torflow      |        Version:           
 Keywords:               |         Parent:           
   Points:  ?            |   Actualpoints:           
-------------------------+--------------------------------------------------

Comment(by mikeperry):

 Ok, I am going to attempt to clearly and accurately combine option 1, 2
 (which is done already), and 3a into "The Plan, v1".

 First (option 3a), we use ensure we have a rolling window of at least 24
 hours worth of advertised bandwidths for a relay. (This info is maintained
 in the BwHistory table, but we need a way to get it into aggregate.py).

 Whenever we compute a measured value, we use the minimum value of this 24
 hour window as the advertised bandwidth. Again, this advertised value is
 what is multiplied by the ratio of the relay's average stream bw to the
 network-wide average stream bw (in aggregate.py).

 Now (option 1), we alter bwauthority.py to discard its results every time
 it notices a new minimum. This improves the turnaround time to measure a
 ratio for the node as it behaves while clients they are being crushed due
 to the throttle change. Thus, we should have a double-minimum for these
 relays. They would be super fun to use for all times other than when they
 are being crushed, and like normal relays during the "crush" period.

 Again, Option 1 would need some additional smarts to ensure that it
 doesn't discard results too often: otherwise the bw auth would make no
 progress. Perhaps these smarts are based on how many measurements it
 managed to get since the last discard, and this is used to estimate a
 measurement frequency, to determine if the measurement frequency is high
 enough to make progress. Or perhaps these smarts are simpler (ie "do not
 discard more often than 1x per 24 hours").

 In summary, option 3a allows us to report one minimum, while option 1
 allows us to actually measure the severity of this minimum due to clients
 *also* not responding fast enough to the change.

 I suppose these two still could be done independently. Perhaps they should
 in fact be separate child tickets.

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