[tor-bugs] #22355 [Core Tor/Tor]: Update dir-spec with client fallback directory mirror attempt and timeout behaviour

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun May 28 10:13:30 UTC 2017


#22355: Update dir-spec with client fallback directory mirror attempt and timeout
behaviour
--------------------------+------------------------------------
 Reporter:  teor          |          Owner:
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  torspec       |  Actual Points:
Parent ID:                |         Points:  0.5
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 It's also worth noting that the relevant comment in the source code is out
 of date due to exponential backoff, and the behaviour will also be
 modified by #17750:

 https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n559

 For a summary, see #22421, the most relevant lines are:

 {{{
    * Clients with only authorities will try:
    *  - at least 3 authorities over 10 seconds, then exponentially
 backoff,
    *    with the next attempt 3-21 seconds later,
    * Clients with authorities and fallbacks will try:
    *  - at least 2 authorities and 4 fallbacks over 21 seconds, then
    *    exponentially backoff, with the next attempts 4-33 seconds later,
 }}}

 Other background info:

 The schedules are a list of maximum delays, and the multiplier is 3 (in
 test networks, 2).

 Each attempt occurs after a random delay between (last_delay + 1) and
 (min(last_delay*3, scledule_max_delay) + 1).

 Calculating for authorities and fallbacks separately:

 If 90% of fallbacks are up (and not censored), we expect at least 99.99%
 of clients to try a fallback that is up within the first 16 seconds
 (trying at most 4 fallbacks). (We try to rebuild the list when 10% of
 fallbacks go down.)

 If 7/8 authorities are up (and not censored), we expect 100% of clients to
 try an authority that is up within the first 17 seconds (trying at most 2
 authorities). (I'm not sure what the stats are on how many authorities are
 ever down at the same time.)

 So, to answer your original question, a reasonable timeout is 17 seconds +
 (SSL establishment time) + (the time it takes to download a consensus,
 certificates, and relay descriptors). We aimed for 30 seconds, because
 that's when Linda's study found that most users give up.

 Or if you can get an event when the client connects to a directory server,
 you can be smarter about keeping on trying, or giving up at around 20-25
 seconds.

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


More information about the tor-bugs mailing list