#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs