[tor-commits] [torspec] 01/04: Prop 324: Describe RFC3742 Limited Slow Start
gitolite role
git at cupani.torproject.org
Thu Aug 11 13:19:34 UTC 2022
This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main
in repository torspec.
commit 7c186cf1e562cd3bee84f7c35525204bd0bedf0c
Author: Mike Perry <mikeperry-git at torproject.org>
AuthorDate: Wed Aug 10 21:26:11 2022 +0000
Prop 324: Describe RFC3742 Limited Slow Start
---
proposals/324-rtt-congestion-control.txt | 137 +++++++++++++++++++------------
1 file changed, 85 insertions(+), 52 deletions(-)
diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt
index 78b6789..78d526d 100644
--- a/proposals/324-rtt-congestion-control.txt
+++ b/proposals/324-rtt-congestion-control.txt
@@ -535,13 +535,29 @@ SENDME ack arrival, as an immediate congestion signal.
ideas/xxx-backward-ecn.txt, but this is not implemented. It is likely only of
any benefit during Slow Start, and even that benefit is likely small.)
-Congestion signals from RTT, blocked OR connections, or ECN are processed only
-once per congestion window. This is achieved through the next_cc_event flag,
-which is initialized to a cwnd worth of SENDME acks, and is decremented
-each ack. Congestion signals are only evaluated when it reaches 0.
-
-Here is the complete pseudocode for TOR_VEGAS, which is run every time
-an endpoint receives a SENDME ack:
+During Slow Start, we use RFC3742 Limited Slow Start[32], which checks the
+congestion signals from RTT, blocked OR connections, or ECN every single
+SENDME ack. It also provides a `cc_sscap_*` parameter for each path length,
+which reduces the congestion window increment rate after it is crossed, as
+per the rules in RFC3742:
+ rfc3742_ss_inc(cwnd):
+ if cwnd <= cc_ss_cap_pathtype:
+ # Below the cap, we increment as per cc_cwnd_inc_pct_ss percent:
+ return round(cc_cwnd_inc_pct_ss*cc_sendme_inc/100)
+ else:
+ # This returns an increment equivalent to RFC3742, rounded:
+ # K = int(cwnd/(0.5 max_ssthresh));
+ # inc = int(MSS/K);
+ return round((cc_sendme_inc*cc_ss_cap_pathtype)/(2*cwnd));
+
+After Slow Start, congestion signals from RTT, blocked OR connections, or ECN
+are processed only once per congestion window. This is achieved through the
+next_cc_event flag, which is initialized to a cwnd worth of SENDME acks, and
+is decremented each ack. Congestion signals are only evaluated when it reaches
+0.
+
+Here is the complete pseudocode for TOR_VEGAS with RFC3742, which is run every
+time an endpoint receives a SENDME ack:
# Update acked cells
inflight -= cc_sendme_inc
@@ -554,38 +570,45 @@ an endpoint receives a SENDME ack:
if clock_stalled_or_jumped:
return
- if next_cc_event == 0:
- if BDP > cwnd:
- queue_use = 0
- else:
- queue_use = cwnd - BDP
-
- if in_slow_start:
- if queue_use < cc_vegas_gamma and not orconn_blocked:
- # Increment by slow start %, or at least 2 sendme_inc's worth
- cwnd = cwnd + MAX(cwnd * cc_cwnd_inc_pct_ss, 2*cc_sendme_inc)
- # If our BDP estimator thinks the BDP is still larger, use that
- cwnd = MAX(cwnd, BDP)
- else:
- cwnd = BDP + cc_vegas_gamma
- in_slow_start = 0
- else:
- if queue_use > cc_vegas_delta:
- cwnd = BDP + cc_vegas_delta - cc_cwnd_inc
- elif queue_use > cc_vegas_beta or orconn_blocked:
- cwnd -= cc_cwnd_inc
- elif queue_use < cc_vegas_alpha:
- cwnd += cc_cwnd_inc
-
- cwnd = MAX(cwnd, cc_circwindow_min)
-
- # Count the number of sendme acks until next update of cwnd,
- # rounded to nearest integer
- if in_slow_start:
- next_cc_event = round(cwnd / cc_sendme_inc)
- else
- # Never increment faster in slow start, only steady state.
- next_cc_event = round(cwnd / (cc_cwnd_inc_rate * cc_sendme_inc))
+ if BDP > cwnd:
+ queue_use = 0
+ else:
+ queue_use = cwnd - BDP
+
+ if in_slow_start:
+ if queue_use < cc_vegas_gamma and not orconn_blocked:
+ inc = rfc3742_ss_inc(cwnd);
+ cwnd += inc
+ next_cc_event = 1
+
+ # If the RFC3742 increment drops below steady-state increment
+ # over a full cwnd worth of acks, exit slow start
+ if inc*SENDME_PER_CWND(cwnd) <= cc_cwnd_inc:
+ in_slow_start = 0
+ next_cc_event = round(cwnd / (cc_cwnd_inc_rate * cc_sendme_inc))
+ else:
+ in_slow_start = 0
+ cwnd = BDP + cc_vegas_gamma
+ next_cc_event = round(cwnd / (cc_cwnd_inc_rate * cc_sendme_inc))
+
+ # Provide an emergency hard-max on slow start:
+ if cwnd >= cc_ss_max:
+ cwnd = cc_ss_max
+ in_slow_start = 0
+ next_cc_event = round(cwnd / (cc_cwnd_inc_rate * cc_sendme_inc))
+ else if next_cc_event == 0:
+ if queue_use > cc_vegas_delta:
+ cwnd = BDP + cc_vegas_delta - cc_cwnd_inc
+ elif queue_use > cc_vegas_beta or orconn_blocked:
+ cwnd -= cc_cwnd_inc
+ elif queue_use < cc_vegas_alpha:
+ cwnd += cc_cwnd_inc
+
+ cwnd = MAX(cwnd, cc_circwindow_min)
+
+ # Count the number of sendme acks until next update of cwnd,
+ # rounded to nearest integer
+ next_cc_event = round(cwnd / (cc_cwnd_inc_rate * cc_sendme_inc))
3.4. Tor NOLA: Direct BDP tracker [TOR_NOLA]
@@ -1395,20 +1418,27 @@ These are sorted in order of importance to tune, most important first.
need to verify that the path length multiplier still holds for
other types of circuits, specifically onion services.
- cc_vegas_bdp_mix:
- - Description: This parameter allows us to specify a weighted percent
- average between the cwnd BDP estimator and the piecewise
- estimator.
- - Range: [0, 100]
- - Default: 100 (use 100% CWND estimator)
- - Tuning Notes:
- The original Vegas literature specified the CWND estimator, but
- the Piecewise estimator is very likely more suited for our use
- case. This parameter allows us to average them. We're unlikely to
- need it.
+ cc_sscap_sbws_{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
- Shadow Tuning Results:
- Because the BDP estimator had ack compression and over-estimation,
- we the CWND estimator.
+ We picked these defaults based on the average congestion window
+ seen in Shadow sims for exits and onion service circuits.
+
+ cc_ss_max:
+ - Description: This parameter provides a hard-max on the congestion
+ window in slow start.
+ - Range: [500, INT32_MAX]
+ - Default: 5000
+ - Shadow Tuning Results:
+ The largest congestion window seen in Shadow is ~3000, so this was
+ set as a safety valve above that.
6.5.4. NOLA Parameters
@@ -2133,3 +2163,6 @@ receive more data. It is sent to tell the sender to resume sending.
31. KIST: Kernel-Informed Socket Transport for Tor
https://matt.traudt.xyz/static/papers/kist-tops2018.pdf
+
+32. RFC3742 Limited Slow Start
+ https://datatracker.ietf.org/doc/html/rfc3742#section-2
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
More information about the tor-commits
mailing list