Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:26:24Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26301dir-spec: update descriptor on bandwidth changes only when uptime is less tha...2020-06-13T15:26:24Zjugadir-spec: update descriptor on bandwidth changes only when uptime is less than a dayAs commented in https://trac.torproject.org/projects/tor/ticket/24104#comment:19, after changes to the code, the spec should be updatedAs commented in https://trac.torproject.org/projects/tor/ticket/24104#comment:19, after changes to the code, the spec should be updatedTor: 0.3.5.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/24104Delay descriptor bandwidth reporting on established relays2020-06-13T15:27:48ZteorDelay descriptor bandwidth reporting on established relaysIn #23856, we:
* reduced the bandwidth stats interval from 4 hours to 24 hours, and
* reduced urgent (2x change) descriptor bandwidth reports from every 20 minutes to every 3 hours.
But we think we can make descriptor bandwidth reports ...In #23856, we:
* reduced the bandwidth stats interval from 4 hours to 24 hours, and
* reduced urgent (2x change) descriptor bandwidth reports from every 20 minutes to every 3 hours.
But we think we can make descriptor bandwidth reports even slower on large relays, because they have less need to ramp up their bandwidth.
Here are our options:
* don't report until the change is larger, for example, 4x
* don't report for longer, for example, every 6 hours or 24 hours
* delay the reporting of the *first* large change, as well as subsequent large changes
Here are the open questions:
* tor traffic has a daily cycle, so do we need to report large bandwidth changes multiple times a day to cope with this? (I think the answer is "no", because small changes are already reported every 18 hours on the standard descriptor schedule, and that seems to work fine. And large changes are already reported once, then the delay is imposed.)Tor: 0.2.9.x-finaljugajuga