Internet-Draft | Careful congestion control convergence | March 2023 |
Kuhn, et al. | Expires 4 September 2023 | [Page] |
This document discusses careful convergence of Congestion Control (CC) in QUIC, providing a cautious method that enables fast startup in a wide range of connections : reconnections using previous transport security credentials (0-RTT context), reconnections between 2 peers (prior knowledge of transport context), application-limited traffic.¶
The method provides QUIC with transport services that resemble those currently available in TCP, such as TCP Control Block (TCB) [RFC9040] caching or updates to support application-limited traffic.¶
The method reuses a set of computed CC parameters that are based on the previously observed path characteristics between the the same pair of transport endpoints, such as the bottleneck bandwidth, available capacity, or the RTT. These parameters are stored, allowing then to be later used to modify the CC behavior of a subsequent connection. The document also discusses assumptions and defines requirements around how a sender utilizes these parameters to provide opportunities for a new connection to more quickly get up to speed (i.e. utilize the available capacity). It discusses how these changes impact the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
All Internet transports are required to either use a CC method, or to constrain there rate of transmission [RFC8085]. In 2010, a survey of alternative CC methods [RFC5783], noted that there are challenges when a CC operates across an Internet path with a high and/or variable bandwidth-delay product (BDP).¶
A CC method typically takes time to ramp-up the packet rate, called the "slow-start phase", informally known as the time to "Get up to speed". This slow start phase is a period in which a sender intentionally uses less capacity than might be available, with the intention to avoid or limit overshooting the actual capacity at a bottleneck. This can result in increased queuing (latency/jitter) and/or congestion packet loss to the flow. Any overshoot in the capacity can also have a detrimental effect on other flows sharing a common bottleneck. In the extreme case, persistent congestion could result in unwanted starvation of other flows [RFC8867] (i.e., Preventing other flows from successfully sharing a common bottleneck).¶
This document specifies a method that can improve performance by reducing the time to get up to speed, and hence can reduce the total duration of a transfer. It introduces an alternative method to select initial CC parameters, including a way to more rapidly and safely grow the congestion window (cwnd). This method is based on temporal sharing (sometimes known as caching) of a set of computed CC parameters that relate to a previously observed path, such as the bottleneck bandwidth, available capacity, and RTT. These parameters are stored and used to modify the CC behaviour of a subsequent connection between the same local and remote endpoints.¶
Care is needed in the use of any temporal information to assure safe use of the Internet and to be robust to changes in traffic patterns, network routing and link/node failures. There are also cases where using the parameters of a previous connection are not appropriate, and a need to evaluate the potential for malicious use of the method. The specification for the QUIC transport protocol [RFC9000] therefore notes "Generally, implementations are advised to be cautious when using previous values on a new path."¶
Whilst a sender could take optimization decisions without considering the receiver's preference, there are cases where a client at the receiver could have information that is not available at the sender. In these cases, a client could could explicitely ask for tuning the slow start when the application continues transmission, or to to inhibit tuning. Examples where this could have benfit include:¶
A related document complements this CC method by allowing the sender-generated transport information to be stored at the receiver [I-D.kuhn-quic-bdpframe-extension]. This enables a receiver to implement a policy that informs a sender whether the receiver desires the sender to reuse the CC parameters. By transfering the information to a receiver, it also releases the sender from needing to retain CC parameter state for each receiver.¶
This secion provides a set of examples where the method is expected to improve performance.¶
QUIC introduces the concept of transport parameters (Section 4 of [RFC9000]). The present document adds to this by noting that a new connection can utilize a set of key transport parameters from a previous connection to reduce the completion time for a transfer. This is expected to have benefit when the transfer is significantly larger than the IW, and the BDP is also significantly more than the IW. This benefit is particularly evident for a path where the RTT is much larger than for typical Internet paths.¶
The method can be used by a sender performing a unidirectional data transfer towards the receiver, (e.g., a receiver downloading a file or a web page). This applies to a CC that sends data to a remote endpoint and that remote endpoint resumes the connection, which is the focus of the current version of the document.¶
Both endpoints can assume the role of a sender or a receiver. Receivers can therefore also perform a bidirectional data transfer, where both endpoints simulatenously send data to each other (e.g., remote execution of an application, or a bidirectional video conference call).¶
Examples where temporal sharing of CC parameters can eliminate round-trip times at the start of a new connection include the following:¶
In a specific example of high BDP path, a satellite access network, takes up to 9 seconds to complete a 5.3 MB transfer using standard CC, whereas using the specified method the transfer time could reduce to 4 seconds [IJSCN]; and the time to complete a 1 MB transfer could be reduced by 62 % [MAPRG111]. Benefit is also expected for other sizes of transfer and for different path characteristics that also result in a path with high BDP.¶
{XXX-Editor note: A future revision can provide other Path Examples here.}¶
This section provides a brief summary of key terms and the requirements language that is used.¶
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Sender-generated information is used in this document for two functions:¶
The document uses language drawn from a range of IETF RFCs. It defines current, and saved values for a set of CC parameters:¶
The Endpoint Token is described in Appendix A.¶
This section defines a series of phases through that the CC algorithm moves through as a connection gets up to speed when uit uses the Careful Resume method.¶
Reconnaissance Phase: When a sender resumes between the same pair of endpoints, (aka the same path) it enters the Reconnaissance Phase. The sender only enters this phase when there are saved CC parameters for the same pair of endpoints and this information is currnetly valid (i.e., the parameters have not expired.) When a method is provided (such as the BDP_Frame), a receiver can request the sender to not enter this phase. The sender is send iniial data, limited by the Initial Window. This phase checks whether the current path is consistent with the saved path information. The sender then measures the path characteristics of the present path to confirm that the path is consistent with the previously characterised path (including a similar RTT).¶
Unvalidated Phase: In the Unvalidated Phase, a sender can utilize the saved path information to update its CC parameters. This phase a rate higher than allowed by a traditional slow-start mechanism. The convergence towards the previous rate is expected to be faster, but should not be instantaneous, to avoid adding congestion to an already congested bottleneck. In this phase, the sender continues to check the saved and current path information are consistent.¶
Retreat Phase: In the Retreat Phase, the sender stops using the saved CC parameters. This phase is designed to mitigate the impact on other flows that might have been sharing a congested bottleneck when in the Unvalidated Phase. The sender needs to re-initialised CC parameters to drain any queue built at the bottleneck duing the Unvalidated Phase and allow other flows to then regain their share of the available capacity. This reaction differs to a traditional CC reaction to congestion, because in this case the capacity estimate was unvalidated. Saved CC parameters for this path should be removed, to prevent the parameters being used again with other flows.¶
The sender is limited by any rate-limitation of the transport protocol with which the method is used. For QUIC this includes: flow control mechanisms or amplification attack prevention. In particular, a QUIC receiver may need to issue proactive MAX_DATA frames to increase the flow control limits of a connection that is started with this method.¶
Congestion controllers, such as CUBIC or RENO, could estimate the saved_bb and current_bb values by utilizing a combination of the cwnd/flight_size and the minimum RTT. A different method could be used to estimate the same values when using a rate-based congestion controller, such as BBR [I-D.cardwell-iccrg-bbr-congestion-control].¶
The sender sends the first data limited by the IW - this is assumed a safe starting point for any path where there is no path information or congestion control information. This limit avoids adding excessive congestion to a potentially congested path.¶
The sender monitors reception of the IW data. If the path characteristics resemble those of a recent previous connection from to the same sender (i.e., current_rtt < 1.2*saved_rtt) and all data was acknowledged without reported congestion, the method permits the sender to utilize the saved_bb as an input to adapt current_bb to rapidly determine a new safe rate.¶
When used in a controlled network, additional information about local path characteristics could be known, which might be used to configure a non-standard IW.¶
Paths change with respect to time for many reasons. This could result in previously measured CC parameters becoming irelevant.¶
{NOTE: A future revision of this document needs to specify how long CC Parameters can be cached, possibly based on TCP-new-CWV or TCB}.¶
{XXX-Editor-note: RTT check should be a range rather than an inequality (current_rtt < 1.2*saved_rtt).}¶
This section defines the safety requirements for using saved CC parameters.¶
{XXX-Editor note: The sender ought not to re-utilize all the capacity it previously used, to avoid starving other flows that started or increased their capacity after the last measurement. How strong should this be stated: ... MUST or SHOULD ... What safety factor is appropriate for the resuming sender? If using slow-start it would anyway double the rate on the next RTT, so is capacity/2 appropriate to initially try?}¶
The method needs to be designed to avoid sending excessive data into a congested bottleneck, because this can have a material impact on any flows sharing that bottleneck, and the ability of those flows to control their own sending rate.¶
The network conditions for the same path can also change over time. Bottleneck bandwidth and network traffic can change at any time. An Internet method needs to be robust to network conditions that can differ from one connection to the next, due to variations in the forwarding path, reconfiguration of equipment or changes in the link conditions.¶
{NOTE: A later revision needs to define how to decide a significant change.}¶
These safety guidelines are designed to mitigate the risk that sender adds excessive congestion to an already congested path. The following mechanisms help in fulfilling this objective:¶
{XXX-Editor note: Decide on the mitigation for Starvation of New Flows.}¶
The following mechanisms could be implemented.¶
The sender needs to avoid sending a burst of packets as a result of a step-increase in the congestion window [RFC9000]. Pacing the packets as a function of the current_rtt can provide this additional safety during the unvalidated period.¶
Identify a relevant pacing rhythm:¶
The sender estimates a pacing rhythm using saved_rtt and saved_bb. The Inter-packet Transmission Time (ITT) is determined from the ratio between the current Maximum Message Size (MMS) and the ratio between the saved_bb and saved_rtt. A tunable safety margin can avoid sending more than a recommended maximum IW (recom_iw):¶
This follows the idea presented in [RFC4782], [I-D.irtf-iccrg-sallantin-initial-spreading] and [CONEXT15].¶
This section defines the safety requirements after a path change or congestion is detected in the Unvalidated Phase.¶
After transport parameters are set to a previously estimated bottleneck bandwidth, if the slow-start mechanisms continue with parameters set by Carfeul Resume, the sender might then overshoot the bottleneck capacity. This can occur even when using the safety check described in this section.¶
The impact of a mistaken decision to use Careful Resume can be mitigated by 2 potential solutions:¶
{XXX-Editor note: Decide on the mitigation after detected congestion.}¶
At the end of Carfeul Resume, the CC controller returns to the Normal Phase.¶
The authors would like to thank John Border, Gabriel Montenegro, Patrick McManus, Ian Swett, Igor Lubashev, Robin Marx, Roland Bless and Franklin Simo for their fruitful comments on earlier versions of this document.¶
The authors would like to particularly thank Tom Jones for co-authoring previous versions of this document.¶
{XXX-Editor note: Text is required to register any IANA Considerations.¶
This document does not exhibit specific security considerations since only sender level considerations are proposed. Security considerations for the interactions with the receiver are discussed in [I-D.kuhn-quic-bdpframe-extension].¶
This proposes an Endpoint Token to allow a sender to identify its own view of the network path that it is using. In [I-D.kuhn-quic-bdpframe-extension] this Endpoint Tokencould be shared and used as an opaque path identifier to other parties and the sender can verify if this is one of its current paths.¶
When computing the Endpoint Token, the sender includes information to identify the path on which it sends, for example:¶
When creating an Endpoint Token, the sender has to ensure the following:¶
+---------+-----------+----------------+---------------+-----------+ |Rationale| Solution | Advantage | Drawback | Comment | +---------+-----------+----------------+---------------+-----------+ |#1 |#1 | | | | |Variable |set |Ingress optim. |Risk of adding |MUST NOT | |Network |current_* | | congestion |implement | | |to saved_* | | | | | +-----------+----------------+---------------+-----------+ | |#2 | | | | | |Implement |Reduce risk of |Negative impact|MUST | | |safety | adding | on ingress |implement | | |check | congestion | optim. |Section 3 | +---------+-----------+----------------+---------------+-----------+