[tor-bugs] #4483 [Tor]: If k of n authorities are down, k/n bootstrapping clients are delayed for minutes

[Tor Bug Tracker & Wiki]

#4483: If k of n authorities are down, k/n bootstrapping clients are delayed for
minutes
-------------------------+-------------------------------------------------
     Reporter:  arma     |      Owner:
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:  Tor: 0.2.8.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  performance bootstrap dirauth-dos-
Actual Points:           |  resistance  tor-client large-feature prop210
       Points:           |  Parent ID:  #2664
-------------------------+-------------------------------------------------

Comment (by nickm):

 Replying to [comment:21 arma]:
 > I remain excited for somebody to work on this one.
 >
 > I think it seems clear that we're going to have to launch multiple
 connections -- that is, that we'll need to launch a second connection even
 while the first one hasn't finished yet. That's just a fact because of
 long tcp timeouts. (In particular, consider networks where the active "it
 didn't work" tcp packets don't make it back to the user.)
 >
 > Given that, I think Mike's suggested approach in proposal 210 is a fine
 one.

 Agreed.  I can imagine small tweaks to the proposal, where instead of
 launching 3 connections at once, we launch one connection immediately,
 then another connection if the first hasn't gotten an answer in a second
 or two, then a third connection a second or two after that.

 > I especially like that we're retaining a connection attempt to the
 directory authorities -- since they're the only ones that cause a warn-
 level log when your clock appears wrong. I believe, but somebody should
 check, that clients get this warn-level log simply when they finish the
 TLS connection to the authority, because of the netinfo cell, right?
 (Notifying users about wrong clocks is one of the sticking points on
 deploying the current implementation of FallbackDirs (until #2628 is
 done).

 I believe that's all correct.

 > One ambiguity in the proposal: say we've launched our three connections,
 one to an authority and two to fallbackdirs, and it's time to launch three
 more. Do we do the same patterns, one to a new authority and two to new
 fallbackdirs? Or do we say we've got one that's to an authority, and
 that's good enough, and pick three new from the fallbackdirs? My guess is
 that the proposal suggests the former, but I think it's up for grabs which
 is wiser. Probably still the former.

 Hmm. I kinda like the latter, but I don't have strong feelings there.  It
 would be nice to make an argument either way.

 > As for implementation, I think we could trigger channel attempts for the
 three chosen relays, and then have a function that gets called whenever a
 channel finishes being established, and in that function see if we're in a
 situation where we want to launch a directory fetch. Should be pretty
 clean.

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