[tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
--------------------------+------------------------------------
 Reporter:  teor          |          Owner:
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  regression    |  Actual Points:
Parent ID:  #20499        |         Points:  0.5
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Here are the schedules we used to use before exponential backoff was
 implemented:
 {{{
 TestingServerDownloadSchedule "0, 0, 0, 60, 60, 120, 300, 900, 2147483647"
 TestingClientDownloadSchedule "0, 0, 60, 300, 600, 2147483647"
 TestingServerConsensusDownloadSchedule "0, 0, 60, 300, 600, 1800, 1800,
 1800, 1800, 1800, 3600, 7200"
 TestingClientConsensusDownloadSchedule "0, 0, 60, 300, 600, 1800, 3600,
 3600, 3600, 10800, 21600, 43200"
 ClientBootstrapConsensusFallbackDownloadSchedule "0, 1, 4, 11, 3600,
 10800, 25200, 54000, 111600, 262800"
 ClientBootstrapConsensusAuthorityOnlyDownloadSchedule "0, 3, 7, 3600,
 10800, 25200, 54000, 111600, 262800"
 ClientBootstrapConsensusAuthorityDownloadSchedule "10, 11, 3600, 10800,
 25200, 54000, 111600, 262800"
 TestingBridgeDownloadSchedule "3600, 900, 900, 3600"
 }}}

 And here are the average exponential backoff attempt times for each unique
 starting point above:
 {{{
 0, 1, 2, 3.5, 5.5, 8.5, 13, 19.5, 29, 43.5, 65.5, ...
 10, 15, 22.5, 34, 51, 76.5, ...
 3600, 5400, 8100, ...
 }}}

 This means:
 * In 0.2.9, almost every tor instance will try to download almost every
 document 11 times in the first minute. In 0.2.8, this was 3-4 times in the
 first minute.
 * In 0.2.9, clients will try authorities 5 times in the first minute. In
 0.2.8, this was 2 times in the first minute.
 * In 0.2.9, bridge clients will try to download bridge descriptors 2 times
 in the first 3 hours. In 0.2.8, this was 4 times in the first 3 hours.

 We can't fix this by modifying the minimum times. But we might be able to
 fix it by modifying the exponent. Or providing a failure count at which we
 increase the delay to hourly, rather than slowly increasing it in an
 exponential fashion.

 Here's what it would look like if the exponent were 3 (max = 5*delay)
 rather than 1.5 (max = 2*delay), and we adjusted the client to authority
 and bridge descriptor start times:
 {{{
 0, 1, 3, 9, 27, 81, ...
 6, 18, 54, ...
 1200, 3600, 10800, ...
 }}}

 This would mean:
 * In 0.2.9, almost every tor instance would try to download almost every
 document 5 times in the first minute. In 0.2.8, this was 3-4 times in the
 first minute.
 * In 0.2.9, clients would try authorities 3 times in the first minute (and
 twice in the first 24 seconds). In 0.2.8, this was 2 times in the first
 minute (and twice in the first 21 seconds).
 * In 0.2.9, bridge clients will try to download bridge descriptors 3 times
 in the first 3 hours (the first time after 20 minutes). In 0.2.8, this was
 4 times in the first 3 hours (the first time after 1 hour).

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