[tor-commits] [torspec/master] Add section "Options To Enable The Failure Counter"

[nickm at torproject.org]

commit 60405bca0b96d69def783a3214cc5e511287b5bb
Author: Neel Chauhan <neel at neelc.org>
Date:   Wed Mar 6 17:38:45 2019 -0500

    Add section "Options To Enable The Failure Counter"
---
 proposals/299-ip-failure-count.txt | 33 +++++++++++++++++++++++++--------
 1 file 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.