[tor-dev] Proposal 210: Faster Headless Consensus Bootstrapping

[Nick Mathewson]

On Thu, Oct 11, 2012 at 5:32 AM, Mike Perry <mikeperry at torproject.org> wrote:
> Also at:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/consensus-bootstrap:/proposals/xxx-faster-headless-consensus-bootstrap.txt
>
> -------------------------------------------------------------------------
>
> Title: Faster Headless Consensus Bootstrapping
> Author: Mike Perry
> Created: 01-10-2012
> Status: Open
> Target: 0.2.4.x+
>
>
> Overview and Motiviation
>
>  This proposal describes a way for clients to fetch the initial
>  consensus more quickly in situations where some or all of the directory
>  authorities are unreachable. This proposal is meant to describe a
>  solution for bug #4483.
>
> Design: Bootstrap Process Changes
>
>  The core idea is to attempt to establish bootstrap connections in
>  parallel during the bootstrap process, and download the consensus from
>  the first connection that completes.
>
>  Connection attempts will be done in batches of three. Only one
>  connection will be performed to one of the canonical directory
>  authorities. Two connections will be performed to randomly chosen hard
>  coded directory mirrors.

I misread this paragraph at first.  I thought you were suggesting 3
parallel directory downloads when in fact you were discussing 3
parallel TLS connections, with only the first one that finishes
actually getting a download.

[...]
> Design: Fallback Dir Mirror Selection

Out of scope for this proposal; relevant for proposal 206.

> Performance: Additional Load with Current Parameter Choices
>
>  This design and the connection count parameters were chosen such that
>  no additional bandwidth load would be placed on the directory
>  authorities. In fact, the directory authorities should experience less
>  load, because they will not need to serve the consensus document for a
>  connection in the event that one of the directory mirrors complete their
>  connection before the directory authority does.

To be clear, it's the part of this proposal that's shared with
proposal 206 (directory sources) that would lower load on the
authorities.

>  However, the scheme does place additional TLS connection load on the
>  fallback dir mirrors. Because bootstrapping is rare and all but one of
>  the TLS connections will be very short-lived and unused, this should not
>  be a substantial issue.

How do we know that bootstrapping is rare?

>  The dangerous case is in the event of a prolonged consensus failure
>  that induces all clients to enter into the bootstrap process. In this
>  case, the number of initial TLS connections to the fallback dir mirrors
>  would be 2*C/100, or 10,000 for C=500,000 users. If no connections
>  complete before the five retries, this could reach as high as 50,000
>  connection attempts, but this is extremely unlikely to happen in full
>  aggregate.
>
>  However, in the no-consensus scenario today, the directory authorities
>  would already experience C/9 or 55,555 connection attempts. The
>  5-retry scheme increases their total maximum load to about 275,000
>  connection attempts, but again this is unlikely to be reached
>  in aggregate. Additionally, with this scheme, even if the dirauths
>  are taken down by this load, the dir mirrors should be able to survive
>  it.

This looks like an argument of the form "The outcome would be
horrible, but the current outcome is also horrible, so we wouldn't
break stuff any worse."  Right?

I wonder if in this case the answer isn't to actually back off from
fetching after N minutes or M servers, like a sane system.  Or to
treat "hey, that's not a good consensus!" as different from "couldn't
connect to directory server" in terms of what it means for how we back
off.


-- 
Nick