[tor-dev] Proposal 210: Faster Headless Consensus Bootstrapping
nickm at alum.mit.edu
Mon Oct 15 20:35:43 UTC 2012
On Thu, Oct 11, 2012 at 5:32 AM, Mike Perry <mikeperry at torproject.org> wrote:
> Also at:
> 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
> 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
> 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
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
More information about the tor-dev