[tor-bugs] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
-----------------------------------+------------------------------------
 Reporter:  teor                   |          Owner:  (none)
     Type:  defect                 |         Status:  new
 Priority:  High                   |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor           |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID:                         |         Points:  1
 Reviewer:                         |        Sponsor:  SponsorQ
-----------------------------------+------------------------------------

Comment (by teor):

 arma and nickm and I had an irc conversation about this today:

 Replying to [comment:12 teor]:
 > The relevant constants in tor are:
 >
 > NUM_SECS_BW_SUM_INTERVAL and maybe we will need to increase
 NUM_SECS_BW_SUM_IS_VALID to remember 2-4 days of daily bandwidth, rather
 than just one day:
 > https://gitweb.torproject.org/tor.git/tree/src/or/rephist.c#n1242

 NUM_SECS_BW_SUM_INTERVAL 24 hours
 /* similar to the 6 periods * 4 hours we had before */
 NUM_SECS_BW_SUM_IS_VALID 5 days

 > And maybe we should also change MAX_BANDWIDTH_CHANGE_FREQ, otherwise
 relays will report bandwidth spikes every 20 minutes in their descriptors.
 But we should be careful here, because this affects the bandwidth
 authority system. But it seems that at least an hour would be reasonable:
 > https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2516

 /* descriptor bandwidth changes propagate to clients between:
  * 10 minutes (upload right before vote, then client bootstrap from
 authority)
  * 3 hours (upload just after vote, then client fetch from mirror as late
 as possible)
  * after they are uploaded by relays. There's no point in reporting them
 much more often
  * than this, because the feedback loop only runs at this speed. */
 MAX_BANDWIDTH_CHANGE_FREQ 3 hours

 arma believes relays that already have enough measured bandwidth are able
 to share their bandwidths less often (that is, when they are Fast or Guard
 or Measured or something), or share them after a larger change. (That is,
 arma said that small relays should share it more often, and I inverted his
 logic and set a minimum instead.)

 I agree, but I'm not sure how much more delay or how much more bandwidth
 we can allow. So let's take this change in 0.3.2, and do some analysis for
 0.3.3. I split this part off into #24104.

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