Re: [tor-bugs] #20909 [Core Tor/Tor]: Tor 0.2.9.5-alpha still delivers outdated consensuses

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#20909: Tor 0.2.9.5-alpha still delivers outdated consensuses
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.2.9.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.2.9.5-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  regression, must-fix-                |  Actual Points:
  before-029-stable                              |
Parent ID:                                       |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Here are my questions on this issue:

 '''Are we delaying connections the way we expect?'''

 I did some calculations for the expected exponential delay growth in
 #20534.
 We should check we are actually getting an exponential distribution in
 practice.
 We need some debug logging around the exponential backoff functions.

 '''Is the exponential backoff maximum delay too high?'''

 If the network goes down for a period of time N seconds long, and then
 comes back up again, the backoff delay D will grow until D >= N. In fact,
 if the exponent is E, the backoff will be of the order of `N^E`. Until it
 hits the maximum.

 There's no network-driven reason for using INT_MAX as the maximum. I think
 we should define a maximum for each download schedule, which is a tradeoff
 between:

 '''If my network connection goes down, how long should I stay down after
 it comes up again?'''

 The answer for relay consensuses could be 3 hours, otherwise they expire.
 (Or perhaps 24, the reasonably live consensus period.)

 Clients can afford to wait longer, as long as they come up when a request
 is made.
 (But hidden services should come up automatically after a certain amount
 of time.)
 Is 24 hours ok for a hidden service to be down?

 '''If the Tor network is down or overloaded, how long do I need to wait to
 avoid making it worse?'''

 This really depends on how many clients there are. (And how many relays.
 And how many fallback directories they try.)

 I think 3 hours is too short. But maybe it's ok to have it just for
 consensuses?
 Perhaps 24 hours is safe as a general limit?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20909#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs