[tor-bugs] #4483 [Tor]: If k of n authorities are down, k/n bootstrapping clients are delayed for minutes

[Tor Bug Tracker & Wiki]

#4483: If k of n authorities are down, k/n bootstrapping clients are delayed for
minutes
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  teor
     Type:  defect                               |         Status:
 Priority:  High                                 |  needs_review
Component:  Tor                                  |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.8.x-final
 Keywords:  performance, bootstrap, dirauth-     |        Version:
  dos-resistance, tor-client, large-feature,     |     Resolution:
  prop210, 028-triage, TorCoreTeam201512,        |  Actual Points:
  MikePerry201512R                               |         Points:
Parent ID:  #2664                                |  medium/large
  Sponsor:  SponsorU                             |
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:41 nickm]:
 > bc8f21f7bd4ed3ea52da94f44c58f34919841307 (Add attempt-based connection
 schedules)

 All fixups for this commit are in 8e50ae7.

 >   * download_status_schedule_helper dereferences dls before it does
 tor_assert(dls); coverity won't like that, I think.

 Oops, but by the power of C99, I can swap those lines.

 >   * download_status_schedule_helper seems like a bad name.  It doesn't
 have a verb.  Maybe it should be ..._get_interval?

 It's actually getting a delay, so I have modified the name of the function
 and the variables in the function to reflect this.

 >   * Somewhere, we need to explain how a dls actually works -- what it
 means, how to interpret it.  I don't think the documentation in or.h
 really explains.  Honestly, I'm not sure how this commit '''works'''.  I
 think that an expanded comment on download_schedule_t type might be in
 order.

 I have updated the comments on:
 * download_schedule_t
 * download_want_authority_t
 * download_schedule_increment_t
 * download_status_t
 * download_status_increment_failure

 I hope this explains how the code works better, let me know if there's
 anything that could be clearer.

 I also made sure n_download_attempts is incremented for all schedules. It
 doesn't make sense to only track it for attempt-based schedules.

 > 3244f51e18832cd507957a589e89452bd98164b3 (Multiple simultaneous
 connections for clients)

 See fixup cc6b228 for the change for this commit.

 >    * N_CONSENSUS_BOOTSTRAP_SOURCES concerns me.  What if we think
 (someday) that we should try three fallbacks and an authority? Or that we
 should try an authority only after three fallbacks have failed?  How much
 code would we need to discard?

 TL;DR: We currently try 3 fallbacks and 2 authorities, if we need to.

 Sorry for naming N_CONSENSUS_BOOTSTRAP_SOURCES badly, it's actually the
 number of different schedules used to download a document, not the number
 of sources.
 (Modified the name to N_CONSENSUS_BOOTSTRAP_SCHEDULES.)

 I think that this commit is unclear because the previous commit was poorly
 documented.

 The schedules determine how many authorities and fallbacks are attempted,
 and in which order.

 For example, the current default schedules are:
 {{{
 TestingClientBootstrapConsensusAuthorityDownloadSchedule 10, 11, ...
 TestingClientBootstrapConsensusFallbackDownloadSchedule  0, 1, 4, 11, ...
 }}}

 This means that:
 A fallback is tried immediately.
 If a connection hasn't been successful after 1 second, another fallback is
 tried.
 If a connection hasn't been successful after 5 seconds (1+4), another
 fallback is tried.
 If a connection hasn't been successful after 10 seconds, an authority is
 tried.
 If a connection hasn't been successful after 16 seconds (1+4+11), another
 fallback is tried.
 If a connection hasn't been successful after 21 seconds (10+11), another
 authority is tried.

 (We can tune the schedules to manage the tradeoff between fallback load,
 authority load, and bootstrap success rate.)

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