[tor-bugs] #23863 [Core Tor/Tor]: When our directory guards don't have each others' microdescs, we should mark some dead

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Nov 16 03:48:12 UTC 2017

#23863: When our directory guards don't have each others' microdescs, we should
mark some dead
 Reporter:  teor                               |          Owner:  (none)
     Type:  defect                             |         Status:  new
 Priority:  Medium                             |      Milestone:  Tor:
                                               |  0.3.2.x-final
Component:  Core Tor/Tor                       |        Version:  Tor:
 Severity:  Normal                             |     Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969                             |         Points:  1
 Reviewer:                                     |        Sponsor:

Comment (by teor):

 Replying to [comment:2 asn]:
 > Replying to [comment:1 teor]:
 > > Here's what we could do:
 > > 1. Try some directory mirrors
 > > 2. Try a fallback
 > > 3. Try an authority
 > > 4. If we still don't have mds for one or more primary guards, mark
 them dead until the next consensus
 > >
 > > This deals with the scenario where:
 > > 1. Authorities make new consensus with new mds (hh:00)
 > > 2. Client bootstraps and downloads consensus from authorities (either
 at random because they are part of the fallback list, or due to options)
 > > 3. Client chooses directory guards
 > > 4. Client tries directory guards for new mds
 > > 5. Directory guards are waiting for a random time between hh:00 and
 hh:30 to fetch new consensus and new mds. See
 > Seems to me that the ways to deal with the edge case you describe above
 > a) Eventually clients try authorities to fetch mds if all else fails
 (bad for the health of dirauths). I think that's what you suggested

 Yes, we should implement this, if the other fixes don't resolve the md
 It's only bad for the authorities if a lot of clients do it all the time.

 > b) We remove dirauths from the fallback list (less traffic on dirauths.
 any drawback?)

 You can't avoid this issue by stopping clients contacting authorities.
 Because there are other ways that a client can have a consensus with some
 microdescs that are not on its guards.

 And we already weight dirauths low on the fallback list, so not many
 clients contact them.

 Removing authorities from the fallback list would break clients that
 disable fallbacks, and clients on non-standard networks. Also, it would
 break clients if too many fallbacks go down on the public network.

 > c) We make dirservers fetch new consensuses/mds much faster than 30mins
 delay (bad for health of dirauths).

 You are right, this is bad because it requires every relay to do this,
 100% of the time. Which is impossible, as well as being bad for the

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

More information about the tor-bugs mailing list