Prop#324: Update congestion control params

1 files changed, 35 insertions, 31 deletions

diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt
index 9df2f61..5126410 100644
--- a/proposals/324-rtt-congestion-control.txt
+++ b/proposals/324-rtt-congestion-control.txt
@@ -1180,7 +1180,7 @@ We will calibrate the Shadow simulator so that it has similar CDFs for all of
 these metrics as the live network, without using congestion control.
 
 Then, we will want to inspect CDFs of these three metrics for various
-congestion control algorithms and parameters. 
+congestion control algorithms and parameters.
 
 The live network testing will also spot-check performance characteristics of
 a couple algorithm and parameter sets, to ensure we see similar results as
@@ -1502,41 +1502,40 @@ These are sorted in order of importance to tune, most important first.
     - Range: [0, 1000] (except delta, which has max of INT32_MAX)
     - Defaults:
            # OUTBUF_CELLS=62
-           cc_vegas_alpha_exit (2*OUTBUF_CELLS)
+           cc_vegas_alpha_exit (3*OUTBUF_CELLS)
            cc_vegas_beta_exit (4*OUTBUF_CELLS)
            cc_vegas_gamma_exit (3*OUTBUF_CELLS)
-           cc_vegas_delta_exit (6*OUTBUF_CELLS)
+           cc_vegas_delta_exit (5*OUTBUF_CELLS)
            cc_vegas_alpha_onion (3*OUTBUF_CELLS)
-           cc_vegas_beta_onion (7*OUTBUF_CELLS)
-           cc_vegas_gamma_onion (5*OUTBUF_CELLS)
-           cc_vegas_delta_onion (9*OUTBUF_CELLS)
+           cc_vegas_beta_onion (6*OUTBUF_CELLS)
+           cc_vegas_gamma_onion (4*OUTBUF_CELLS)
+           cc_vegas_delta_onion (7*OUTBUF_CELLS)
     - Tuning Notes:
            The amount of queued cells that Vegas should tolerate is heavily
            dependent upon competing congestion control algorithms. The specified
            defaults are necessary to compete against current fixed SENDME traffic,
-           but are much larger than neccessary otherwise. As the number of
-           clients using fixed windows is reduced (or circwindow is lowered), we
-           can reduce these parameters, which will result in less overall queuing
-           and congestion on the network.
+           but are much larger than neccessary otherwise. These values also
+           need a large-ish range between alpha and beta, to allow some degree of
+           variance in traffic, as per [33]. The tuning of these parameters
+           happened in two tickets[34,35]. The onion service parameters were
+           set on the basis that they should increase the queue until as much
+           queue delay as Exits, but tolerate up to 6 hops of outbuf delay.
+           Lack of visibility into onion service congestion window on the live
+           network prevented confirming this.
     - Shadow Tuning Results:
            We found that the best values for 3-hop Exit circuits was to set
-           beta and gamma to the size of the outbufs times the number of hops.
-           This has the effect that Vegas detects congestion and backs off
-           when this much queue delay is detected. Alpha is set to one TLS
-           record/sendme_inc below this value. If the queue length is detected
-           to be below that, we increase the congestion window. We still
-           need to verify that the path length multiplier still holds for
-           other types of circuits, specifically onion services.
-
-  cc_sscap_sbws_{exit,onion,sbws}:
+           alpha and gamma to the size of the outbufs times the number of
+           hops. Beta is set to one TLS record/sendme_inc above this value.
+
+  cc_sscap_{exit,onion,sbws}:
     - Description: These parameters describe the RFC3742 'cap', after which
          congestion window increments are reduced. INT32_MAX disables
          RFC3742.
     - Range: [100, INT32_MAX]
     - Defaults:
          sbws: 400
-         exit: 500
-         onion: 600
+         exit: 600
+         onion: 475
     - Shadow Tuning Results:
          We picked these defaults based on the average congestion window
          seen in Shadow sims for exits and onion service circuits.
@@ -1555,19 +1554,18 @@ These are sorted in order of importance to tune, most important first.
         'cc_sendme_inc' multiples of gap allowed between inflight and
         cwnd, to still declare the cwnd full.
       - Range: [0, INT16_MAX]
-      - Default: 1-2
+      - Default: 4
       - Shadow Tuning Results:
-        A value of 0 resulted in a slight loss of performance, and increased
-        variance in throughput. The optimal number here likely depends on
-        edgeconn inbuf size, edgeconn kernel buffer size, and eventloop
-        behavior.
+        Low values resulted in a slight loss of performance, and increased
+        variance in throughput. Setting this at 4 seemed to achieve a good
+        balance betwen throughput and queue overshoot.
 
    cc_cwnd_full_minpct:
-      - Description: This paramter defines a low watermark in percent. If 
+      - Description: This paramter defines a low watermark in percent. If
         inflight falls below this percent of cwnd, the congestion window
         is immediately declared non-full.
       - Range: [0, 100]
-      - Default: 75
+      - Default: 25
 
    cc_cwnd_full_per_cwnd:
       - Description: This parameter governs how often a cwnd must be
@@ -1618,7 +1616,7 @@ These are sorted in order of importance to tune, most important first.
         This threshold plus the sender's cwnd must be greater than the
         cc_xon_rate value, or a rate cannot be computed. Unfortunately,
         unless it is sent, the receiver does not know the cwnd. Therefore,
-        this value should always be higher than cc_xon_rate minus 
+        this value should always be higher than cc_xon_rate minus
         'cc_cwnd_min' (100) minus the xon threshhold value (0).
 
   cc_xon_rate
@@ -1656,7 +1654,7 @@ These are sorted in order of importance to tune, most important first.
     - Tuning Notes:
         Setting this higher will smooth over changes in the rate field,
         and thus avoid XONs, but will reduce our reactivity to rate changes.
- 
+
 
 6.5.6. External Performance Parameters to Tune
 
@@ -1668,7 +1666,7 @@ These are sorted in order of importance to tune, most important first.
     - Description: Specifies the percentage cutoff for the circuit build
                    timeout mechanism.
     - Range: [60, 80]
-    - Default: 80    
+    - Default: 80
     - Tuning Values: [70, 75, 80]
     - Tuning Notes:
        The circuit build timeout code causes Tor to use only the fastest
@@ -2309,3 +2307,9 @@ receive more data. It is sent to tell the sender to resume sending.
 
 32. RFC3742 Limited Slow Start
     https://datatracker.ietf.org/doc/html/rfc3742#section-2
+
+33. https://people.csail.mit.edu/venkatar/cc-starvation.pdf
+
+34. https://gitlab.torproject.org/tpo/core/tor/-/issues/40642
+
+35. https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/49