[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [torspec/master] Add a load analysis section.



commit 42cbe7ea09b87c0cec70413ea40a4436b3eac3db
Author: Mike Perry <mikeperry-git@xxxxxxxxxx>
Date:   Wed Oct 3 19:46:01 2012 -0700

    Add a load analysis section.
    
    Also tweak some parameters based on the analysis.
---
 .../xxx-faster-headless-consensus-bootstrap.txt    |   51 ++++++++++++++++----
 1 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/proposals/xxx-faster-headless-consensus-bootstrap.txt b/proposals/xxx-faster-headless-consensus-bootstrap.txt
index 2fd34c1..9aef215 100644
--- a/proposals/xxx-faster-headless-consensus-bootstrap.txt
+++ b/proposals/xxx-faster-headless-consensus-bootstrap.txt
@@ -17,30 +17,61 @@ Description
  parallel during the bootstrap process, and download the consensus from the
  first connection that completes.
 
- Connection attempts will be done in batches of five. Only one connection
- will be performed to one of the canonical directory authorities. Four
+ 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.
 
- If no connections complete within 5 seconds, another batch of five
+ If no connections complete within 5 seconds, another batch of three
  connections will be launched. Otherwise, the first connection to complete
- will be used to download the consensus document, after which
- bootstrapping will proceed as normal.
+ will be used to download the consensus document and the others will be
+ closed, after which bootstrapping will proceed as normal.
 
- If at any time, the total open bootstrap connection attempts exceeds
- 25, no new connection attempts are to be launched until existing
+ If at any time, the total outstanding bootstrap connection attempts
+ exceeds 15, no new connection attempts are to be launched until existing
  connection attempts experience full timeout.
 
 Fallback Dir Mirror Selection
 
  The set of hard coded directory mirrors from #572 shall be chosen using
- the 50 Guard nodes with the longest uptime.
+ the 100 Guard nodes with the longest uptime.
 
  The fallback weights will be set using each mirror's fraction of
- consensus bandwidth out of the total of all 50 mirrors.
+ consensus bandwidth out of the total of all 100 mirrors.
 
  This list of fallback dir mirrors should be updated with every
- major Tor release.
+ major Tor release. In future releases, the number of dir mirrors
+ should be set at 20% of the current Guard nodes, rather than fixed at
+ 100.
+
+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.
+
+ 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.
+
+ 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 TLS connections to the fallback dir mirrors would be between
+ 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.
 
 Implementation Notes
 



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits