[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):

 I think we should implement an authority md fetch for clients that run out
 of microdesc attempts. And I think they can easily handle the load of a
 few mds, because they are handling a similar consensus load from clients
 and relays already.

 I also don't think removing fallbacks from the list will help much,
 because bootstrapping clients try authorities anyway.

 See below for details.

 Replying to [comment:7 asn]:
 > Replying to [comment:3 teor]:
 > > Replying to [comment:2 asn]:
 > > > 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.
 > >
 >
 > True. But we have lots of clients, so I think before doing this we might
 want to calculate the probability of this happening, to try to understand
 how many clients will end up doing this behavior.

 Yes, I think we should estimate how often it will happen. We can afford to
 have a few thousand clients download a few mds per hour (0.1% of 2 million
 clients per hour). Because we have a few thousand relays download two
 consensus flavours and all the new mds from the authorities, and they are
 handling this load fine.

 > > > 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.
 > >
 >
 > True. But it's less likely if dirauths are not in the picture, since
 basically your edge-case is guaranteed to happen everytime a client
 randomly picks a dirauth early in the hour (e.g. between hh:00 and hh:05).

 Yes. Directory mirrors download at random between hh:00 and hh:30, so
 missing microdescriptors are guaranteed to happen for 50% of clients that
 bootstrap off authorities (9/(150*10 + 9) ~= 0.6% of clients bootstrap off
 authorities) at hh:15. Assuming that clients bootstrap at random
 throughout the hour, this is 0.6% * 0.25 = 0.15% of bootstrapping clients
 per hour. So we can afford to have all these clients try an authority for
 their mds, because the number of bootstrapping clients is much lower than
 the number of running clients. (We could afford to have 0.15% of all
 clients do this, not just 0.15% of the bootstrapping ones.)

 The actual figure is slightly higher than this, because after trying 3
 fallbacks/authorities, 0.3.2 and later clients try an authority directly.
 When 10% of fallbacks are down, 0.1% of clients try an authority for this
 reason. But the authorities are already handling this consensus fetch
 traffic fine, so an extra few mds won't be an issue.

 (For 0.3.1 and earlier clients, 100% try an authority and a fallback
 straight away when bootstrapping, and they pick whichever wins. So we
 might want to think a bit harder about backporting #17750 and #23347, if
 we also want to backport an authority md fetch to earlier versions.)

 We could easily reduce the 0.3.2 client authority fetch to 0.115% (0.015%
 + 0.1%) by weighting the fallbacks at 100 rather than 10. But that doesn't
 remove the 0.1% that try an authority after 3 fallbacks. So I'm not sure
 re-weighting (or removing) would have the impact you want.

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

 These clients would have nothing in the fallback list to bootstrap off,
 because they don't use the hard-coded public fallbacks. We can avoid this
 by only removing the authorities when using public fallbacks, but that
 makes the code hard to test in chutney.

 > > Also, it would break clients if too many fallbacks go down on the
 public network.
 > >
 >
 > Hmm, I don't understand these points exactly. Can you expand? Why would
 clients break worse than currently if we remove dirauths from fallbacks?
 We can add a few more relays in the fallbacks to compensate.

 The idea of having authorities in the fallback list is that clients will
 use them if a large number of the fallbacks break for some reason (for
 example, a bad bug on mirrors). I am not sure if this actually works, but
 let's not break it until we are sure:
 * removing them will help this issue, and
 * removing them won't create any other issues.

 I don't think removing authorities from the fallback list would help this
 issue, because 0.1% of bootstrapping clients will still try an authority
 when they fail 3 fallbacks.

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