[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]

#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:
                                               |  0.3.0.6
 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
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3240
 >
 > Seems to me that the ways to deal with the edge case you describe above
 are:
 >
 > 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
 basically.

 Yes, we should implement this, if the other fixes don't resolve the md
 issue.
 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
 network.

--
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