aboutsummaryrefslogtreecommitdiff
path: root/proposals/299-ip-failure-count.txt
diff options
context:
space:
mode:
authorNeel Chauhan <neel@neelc.org>2019-03-06 17:38:45 -0500
committerNeel Chauhan <neel@neelc.org>2019-03-06 18:04:38 -0500
commit60405bca0b96d69def783a3214cc5e511287b5bb (patch)
treeb4f1848674e1a904224d791d0d3133eae7d7871a /proposals/299-ip-failure-count.txt
parent9a4380f2c9884e8195ed8f9174d7390996094f5b (diff)
downloadtorspec-60405bca0b96d69def783a3214cc5e511287b5bb.tar.gz
torspec-60405bca0b96d69def783a3214cc5e511287b5bb.zip
Add section "Options To Enable The Failure Counter"
Diffstat (limited to 'proposals/299-ip-failure-count.txt')
-rw-r--r--proposals/299-ip-failure-count.txt33
1 files changed, 25 insertions, 8 deletions
diff --git a/proposals/299-ip-failure-count.txt b/proposals/299-ip-failure-count.txt
index efd4aa7..496217e 100644
--- a/proposals/299-ip-failure-count.txt
+++ b/proposals/299-ip-failure-count.txt
@@ -29,7 +29,24 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
in the random decision used for choosing an IP family and the data fields
used by the algorithm.
-2. Failure Counter Design
+2. Options To Enable The Failure Counter
+
+ To enable the failure counter, we will add a flags to ClientAutoIPv6ORPort.
+ The new format for ClientAutoIPv6ORPort is:
+
+ ClientAutoIPv6ORPort 0|1 [flags]
+
+ The first argument is to enable the automatic selection between IPv4 and
+ IPv6 if it is 1. The second argument is a list of optional flags.
+
+ The only flag so far is "TrackFailures", which enables the tracking of
+ failures to make a better decision when selecting between IPv4 and IPv6.
+ The tracking of failures will be described in the rest of this proposal.
+
+ However, we should be open to more flags from future proposals as they
+ are written and implemented.
+
+3. Failure Counter Design
I propose that the failure counter uses the following fields:
@@ -47,7 +64,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
statefile, and when a session is closed, the failure counts from the current
session will be stored in the statefile.
-3. Failure Probability Calculation
+4. Failure Probability Calculation
The failure count of one IP version will increase the probability of the
other IP version. For instance, a failure of IPv4 will increase the IPv6
@@ -93,7 +110,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
WiFi to cellular) which may be more or less reliable in terms of a
particular IP family when compared to the previous network of the client.
-4. Initial Failure Point Calculation
+5. Initial Failure Point Calculation
When a client starts without failure points or if the FP value drops to 0,
we need a SFPV value to start with. The Initial SFPV value will be counted
@@ -129,7 +146,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
If we are starting a new session, we should use the existing failure points
to generate a SFPV unless the counts for IPv4 or IPv6 are zero.
-5. Forgetting Old Sessions
+6. Forgetting Old Sessions
We should be able to forget old failures as clients could change networks.
For instance, a mobile phone could switch between WiFi and cellular. Keeping
@@ -161,7 +178,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
If the FP value for one IP version goes down to zero, we will re-calculate
the SFPV for that version using the methods described in Section 4.
-6. Separate Concurrent Connection Limits
+7. Separate Concurrent Connection Limits
Right now, there is a limit for three concurrent connections from a client.
at any given time. This limit includes both IPv4 and IPv6 connections.
@@ -174,7 +191,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
packets for a particular IP family while still preventing potential denial
of service attacks.
-7. Pathbias and Failure Probability
+8. Pathbias and Failure Probability
If ClientAutoIPv6ORPort is in use, and pathbias is triggered, we should
ignore "no route" warnings. The reason for this is because we would be
@@ -183,7 +200,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
competing IP family over the failed one versus than adding a single failure
point on a normal failure.
-8. Counting Successful Connections
+9. Counting Successful Connections
If a connection to a particular IP version is successful, we should use
it. This ensures that clients have a reliable connection to Tor. Accounting
@@ -200,7 +217,7 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/27491
Even on adding successes, we will still halve the failure counters as
described in Section 5.
-9. Acknowledgements
+10. Acknowledgements
Thank you teor for aiding me with the implementation of Happy Eyeballs in
Tor. This would not have been possible if it weren't for you.