[tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Nov 3 05:37:04 UTC 2017


#23817: Tor re-tries directory mirrors that it knows are missing microdescriptors
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-guard, tor-hs, prop224,          |  Actual Points:
  032-backport? 031-backport?                    |
Parent ID:  #21969                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:11 asn]:
 > And I agree with you, we should wipe the `outdated_dirservers_list` list
 everytime we fetch a new consensus. Should we also clear it at any other
 point? Maybe we should not let it grow to a huge size (cap it?).

 If we are clearing it on every consensus, and doing exponential backoffs
 (average 2.5x) on every failure, then the list can't grow much beyond
 log_2(3*60*60) = 14 entries. (After 3 hours, we should either stop trying
 because our consensus is not live, or we should get another consensus and
 clear the list. Or, if we keep trying with reasonably live consensuses,
 the limit will be log_2(24*60*60) = 17 entries.) So let's log a BUG()
 warning when the list has > 30 entries, because something is wrong with
 our logic if that happens.

 I'm not sure if we should clear the list when it gets too big: it seems
 like that could trigger slow zombie behaviour, if clients keep on retrying
 a microdescriptor that doesn't exist. So we have to do something different
 at that point. And we have to set the point early enough that clients get
 all the microdescs they need within a minute or so.

 So, when is the list too big?
 (Or when have we waited too long?)
 Should we mark guards down if they depend on a microdesc we can't get?
 Should we give up until the next consensus?
 Should we try a fallback or an authority?
 Should we do something different if we're waiting for an important
 (primary guard) microdesc?

 Maybe we need another ticket to answer these questions.
 Because I think some of them can wait until we see how this change
 performs.

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


More information about the tor-bugs mailing list