[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:  major    |  Milestone:  Tor: 0.2.8.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  performance, bootstrap, dirauth-
Actual Points:           |  dos-resistance, tor-client, large-feature,
       Points:           |  prop210, 028-triage
  medium/large           |  Parent ID:  #2664
                         |    Sponsor:
-------------------------+-------------------------------------------------

Comment (by teor):

 Replying to [comment:22 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've revised proposal #210 to implement this exponential backoff scheme,
 will still maintaining the same number of connections within the first
 second.
 Please see my branch `bootstrap-exponential-backoff` in
 https://github.com/teor2345/torspec.git

 See my email to tor-dev for the full proposal text.
 https://lists.torproject.org/pipermail/tor-dev/2015-October/009622.html


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

 I've specified a retry schedule that we make 1 authority connection and 2
 directory mirror connections in the first second. This will:
 * place a similar connection load (TLS) on the authorities
 * reduce download load (data) on the authorities if the mirror (or first
 few mirrors) are faster
 * continue to warn the user if their clock is wrong by making sure we try
 to complete at least one authority TLS connection every time we launch
 (then close it if we are already downloading the directory)
 * other connections are closed as soon as a consensus download starts

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

 In the updated scheme, we connect to mirrors at a faster rate than
 authorities, approximately 5 mirror connections for every authority
 connection. (And even fewer if the connections succeed.)

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

 Sounds good, I'll try to make it work along with #15775.

 I've also added a section on trying both IPv4 and IPv6 addresses. I think
 this will allow us to implement IPv6 bootstrap along with #8374.

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