| Internet-Draft | Careful Resume | August 2025 |
| Kuhn, et al. | Expires 26 February 2026 | [Page] |
This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections, known as "Careful Resume". It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the congestion control behaviour of a subsequent connection.¶
It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of this method impacts 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 26 February 2026.¶
Copyright (c) 2025 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 Congestion Control (CC) algorithm, or to constrain their rate of transmission [RFC8085]. In 2010, a survey of alternative CC algorithms [RFC5783] noted that there are challenges when a CC algorithm operates across an Internet path with a high and/or varying Bandwidth-Delay Product (BDP). The specified method targets a solution for these challenges.¶
A CC algorithm typically takes time to ramp up the sending rate, called the "Slow-Start Phase", informally known as the time to "Get up to speed". This defines a time in which a sender intentionally uses less capacity than might be available, with the intention to avoid or limit overshoot of the available capacity for the path. This seeks to avoid an increase queuing (latency or jitter) and/or congestion packet loss for the flow. Any overshoot of the bottleneck rate can have a detrimental effect on other flows that share a common bottleneck. A sender can also use a method that observes the rate of acknowledged data to seek to avoid an overshoot of this bottleneck capacity (e.g., Hystart++ [RFC9406]). In the extreme case, an overshoot can result in persistent congestion with unwanted starvation of other flows [RFC8867] (i.e., preventing other flows from successfully sharing the capacity at a common bottleneck).¶
This document specifies Careful Resume. The method seeks to reduce the time to complete a transfer when the sending rate is limited by the congestion controller. That is, when a transfer seeks to send significantly more data than allowed by the Initial congestion Window (IW) and where the BDP of the path is also significantly more than the product of the IW and path Round Trip Time, RTT.¶
Careful Resume introduces an alternative method to select initial CC parameters that seeks to more rapidly and safely grow the sending rate controlled by the congestion window (CWND).¶
Careful Resume is based on temporal sharing (sometimes known as caching) of a saved set of CC parameters that relate to previous observations of the same path. The parameters include: the saved_cwnd for the path, the minimum RTT, and a Lifetime for using these parameters. The parameters are saved and used to modify the CC behaviour of a subsequent connection between the same endpoints.¶
CC algorithms that are rate-based can make similar adjustments to their target sending rate. When saving the observed capacity, some CC algorithms might save a different parameter that is equivalent to the saved_cwnd. For example, a rate-based CC algorithm, such as BBR [I-D.ietf-ccwg-bbr] can retain the value of the bottleneck bandwidth required to reach the capacity available to the flow (e.g., BBR.max_bw).¶
CC parameters are used by Careful Resume for three functions:¶
Information to confirm whether a saved path corresponds to the current path.¶
Information about the utilised path capacity and observed RTT to set CC parameters for the current connection.¶
Information to check the CC parameters are not too old.¶
"Generally, implementations are advised to be cautious when using saved CC parameters on a new path", as stated in [RFC9000]. While this statement was in the context of the QUIC transport protocol, this advice is also appropriate for any IETF transport protocol. Care is therefore needed to assure safe use and to be robust to changes in traffic patterns, network routing, and link/node conditions. There are cases where using the saved parameters of a previous connection is not appropriate (see Section 4).¶
Whilst the sender could take optimisation decisions without considering the receiver's preference, there are cases where a receiver could have information that is not available at the sender, or might benefit from understanding that Careful Resume might be used. In these cases, a receiver could explicitly ask to either enable or inhibit Careful Resume when an application initiates a new connection.¶
Examples where a receiver might request to inhibit using Careful Resume include:¶
a receiver that can predict the pattern of traffic (e.g., insight into the volume of data to be sent, the expected length of a connection, or the requested maximum transfer rate);¶
a receiver with a local indication that a path/local interface has changed since the CC parameters were saved;¶
knowledge of the current hardware limitations at a receiver;¶
a receiver that can predict additional capacity will be needed for other concurrent or later flows (i.e., it prefers to activate Careful Resume for a different connection).¶
The CWND is one factor that limits the sending rate of a transport protocol. Other mechanisms also constrain the maximum sending rate. These include the sender pacing rate and the receiver-advertised window (or flow credit), see Section 4.7.¶
This section provides a set of examples where Careful Resume is expected to improve performance. Either endpoint can assume the role of a sender or a receiver. Careful Resume also supports a bidirectional data transfer, where both endpoints simultaneously send data (e.g., remote execution of an application, or a bidirectional video conference call).¶
For example, consider an application that uses a series of connections over a path: Without a new method, each connection would need to individually discover appropriate CC parameters, whereas Careful Resume allows the flow to use a rate based on the previously observed CC parameters.¶
Another example considers an application that connects after a disruption had temporarily reduced the path capacity: When this endpoint returns to use the path using Careful Resume, the sending rate can be based on the previously observed CC parameters.¶
There is a particular benefit for any path with an RTT that is much larger than for typical Internet paths. In a specific example, an application connected via a satellite access network [IJSCN] could take 9 seconds to complete a 5.3 MB transfer using standard CC, whereas a sender using Careful Resume could reduce this transfer time to 4 seconds. The time to complete a 1 MB transfer could similarly be reduced by 62 % [MAPRG111]. This benefit is also expected for other sizes of transfer and for different path characteristics when a path has a large BDP.¶
Resuming a connection with CC parameters that were observed during a previous connection is inherently a tradeoff between the potential performance gains for the new connection and the risks of degraded performance for other connections that share a common bottleneck. The specified method is designed to obtain good performance when resuming is appropriate, while seeking to minimise the impact on other connections when it is not appropriate.¶
The following precautions mitigate the risk of a sender adding excessive congestion to a path:¶
The first precaution is to recognise whether the conditions have changed so much that the saved values are no longer valid. We describe that as the "Reconnaissance Phase". During that phase, the sender will not send more data than allowed for any new connection, e.g., using the recommended maximum IW for the first RTT of transmitting data [RFC6928] [RFC9002]. The sender will only proceed with the resume process if the reconnaissance succeeds. If it fails, for example if previous packets in a connection experience congestion or the RTT is significantly different, the sender will follow the standard process for a new connection. This provides some protection against aggravating severe congestion and to establish the minimum RTT.¶
The second precaution is to cautiously use the saved parameters when resuming. This is called the "Unvalidated Phase". For example, the jump in the size of CWND/rate is restricted to a fraction (1/2) of the saved_cwnd, to avoid starving other flows that may have started or increased their capacity after the last capacity measurement. The same principle applies for CC algorithms that use different parameters to classic TCP CC: i.e., a sender must not send faster than allowed by a fraction of the saved CC parameters. For example, a connection using a rate-based CC algorithm (e.g., BBR) will set the pacing rate to half the remembered value of the "bottleneck bandwidth". The sender also needs to pace all unvalidated packets, to ensure the rate does not exceed the previously used rate. This is intended to avoid a sudden influx of packets that could result in building a bottleneck queue and disrupting existing flows. Successful validation can allow further increases of the CWND; after first validating that the used rate did not result in congestion.¶
The third precaution is to enter a "Safe Retreat Phase" if the validation fails, for example if congestion is detected during validation. The risk here is that the trial use of the saved CC parameters could have disrupted existing connections. For example, consider a connection using Reno TCP CC: When exiting "slow start" mode due to loss, Reno would normally update the CWND to a "slow start threshold" set to half the volume of data in flight. However, during this validation the CWND is restored from the saved CC parameters. The resultant sending rate could be much larger than the value that would have been reached by a "standard" slow start process, resulting in an overload of the path that potentially could cause significant congestion to other flows. Instead of continuing with that "too large" value, the retreat process resets the congestion window (rate) to a value no greater than what a standard process would have discovered. For other CC algorithms, such as Cubic [RFC9438] or BBR, the implementation details may differ, but the principle remains: trying and failing should not unduly disadvantage existing connections that share a common bottleneck (e.g., resulting in starving these connections).¶
This subsection provides a brief summary of key terms and the requirements language.¶
The key words "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.¶
The Remote Endpoint is an implementation-dependent value that identifies the sender's view of the network path being used. This is used to match the current path with a set of CC parameters associated with a previously observed path. It includes:¶
an identifier representing the sending interface (e.g., a globally assigned address/prefix or other local identifier);¶
an identifier representing the destination (e.g., a name or IP address).¶
The Remote Endpoint could also include information such as the DSCP, the transport ports, etc. If included, such information needs to be set consistently for a resumed connection to the same endpoint. Although additional information could improve the path differentiation, it could reduce the re-usability of saved parameters.¶
The saved CC parameters can only be used to modify the startup when the Remote Endpoint is not known to have changed (see Section 3.2).¶
This document defines triggers to support logging key events. [LOG] provides definitions that enable a Careful Resume implementation to generate qlog events when using QUIC.¶
The document uses language drawn from a range of IETF RFCs. The following terms are defined:¶
Beta: A scaling factor between 0.5 and 1, the default value is 0.5.¶
Careful Resume (CR): The method specified in this document to select initial CC parameters and to more rapidly and safely increase the initial sending rate.¶
CC parameters: A set of saved congestion control parameters from observing the capacity of an established connection (see Section 1.1).¶
CWND: The congestion window, or equivalent CC variable limiting the maximum sending rate (see [RFC5681]);¶
current rtt: A sample measurement of the current RTT;¶
flight_size: The current volume of unacknowledged data (see [RFC5681]);¶
jump_cwnd: The resumed CWND, used in the Unvalidated Phase.¶
Lifetime: The time after which a set of saved CC parameters can no longer be safely re-used.¶
max_jump: The configured maximum jump_cwnd;¶
PipeSize: A measure of the validated available capacity based on the acknowledged data;¶
Remote Endpoint: The endpoint corresponding to a connection; see Section 2.2;¶
saved_cwnd: A CC parameter with the preserved capacity derived from observation of a previous connection (see Section 4.1);¶
saved_remote_endpoint: The Remote Endpoint that was associated with a set of saved CC parameters;¶
saved_rtt: A CC parameter with the preserved minimum RTT (see Section 4.1).¶
unvalidated packet: A packet sent when the CWND has been increased beyond the size normally permitted by the CC algorithm; if such a packet is acknowledged, it contributes to the PipeSize, but if congestion is detected, it triggers entry to the Safe Retreat Phase.¶
This section defines a series of phases that the congestion controller moves through as a connection uses Careful Resume. Each rule is prefixed by the name of the relevant phase.¶
Normal CC...> Connect -> Reconnaissance --------------------> Normal CC
(Observing) | ^
v |
Unvalidated --------------------------+
| | |
| +--> Validating --------------+
| | |
| | |
+---------------+--> Safe Retreat ---+
The key phases of Careful Resume are illustrated in Figure 1. Examples of transitions between these phases are provided in Appendix A.¶
An established connection can save a set of CC parameters for the specific path to the current endpoint. A set of CC parameters includes the Lifetime (e.g., as a timestamp after which the parameters must not be used), and corresponds to one saved_remote_endpoint.¶
The following rules apply to observing a flow:¶
Observing (saved_cwnd): The currently utilised capacity for the connection is measured as the volume of bytes sent during an RTT and is recorded in the saved_cwnd. This could be computed by measuring the volume of data acknowledged in one RTT. If the measured CWND is less than four times the Initial Window (IW) the sender can choose to not save the CC parameters, because the additional actions associated with performing Careful Resume for a small CWND would not justify its use.¶
Observing (saved_rtt): The minimum RTT at the time of observation is saved as the saved_rrt.¶
Observing (Updating saved CC parameters): A sender MUST NOT retain more than one set of CC parameters for a Remote Endpoint, but the set of CC parameters SHOULD be updated (or replaced) after a later observation of a path to the same Remote Endpoint.¶
Implementation notes are provided in Section 4.1.¶
During this phase, the sender attempts to retrieve congestion control parameters that were previously saved, then determine whether the path is consistent with a previously observed path (i.e, match the saved_remote_endpoint in a set of saved CC parameters).¶
The sender enters the Reconnaissance Phase after connection setup (using normal CC). In this phase, the CWND is initialised to the IW, and the sender transmits any initial data.¶
In the Reconnaissance Phase, the sender performs the following actions:¶
Reconnaissance Phase (Received acknowledgment): The CWND is increased using normal CC as each ACK confirms delivery of previously unacknowledged data (i.e., the base congestion control algorithm continues to operate normally).¶
The sender exits the Reconnaissance Phase and stops using Careful Resume when one of the following events occurs:¶
Reconnaissance Phase (Detected congestion): If the sender detects congestion (e.g., packet loss or ECN-CE marking), this indicates that use of the saved CC parameters is inappropriate. The sender stops using Careful Resume and MUST continue using normal CC to respond to the detected congestion.¶
Reconnaissance Phase (Using saved_cwnd): Only one connection can use a specific set of saved CC parameters. If another connection has already started to use the saved_cwnd, the sender MUST exit Careful Resume and return to use normal CC.¶
Reconnaissance Phase (Path change): If the Remote Endpoint is not the same as any saved_remote_endpoint, or the sender receives a signal from the local stack indicating that the path is now different to the observed path, the sender MUST stop using Careful Resume and returns to use normal CC.¶
Reconnaissance Phase (Lifetime of saved CC parameters): The CC parameters are temporal. If the Lifetime of the observed CC parameters is exceeded, this set of CC parameters are not used, the saved CC parameters are deleted and MUST stop using Careful Resume and returns to use normal CC.¶
Reconnaissance Phase (Minimum RTT too small): If the minimum RTT recorded in the Reconnaissance Phase is less than or equal to (saved_rtt / 2) (see Section 4.2.1), the sender MUST enter stop using Careful Resume (logged as rtt_not_validated in [LOG]) and returns to use normal CC. This is because the calculation of a sending rate from a saved_cwnd is directly impacted by the RTT, therefore a significant change in the RTT is a strong indication that the previously observed CC parameters are not valid for the current path.¶
Note: When a path is not confirmed, Careful Resume does not modify the CWND before it exits to use normal CC.¶
The sender is permitted to enter the Unvalidated Phase as described below:¶
Reconnaissance Phase (Path confirmed): When the sender has received an acknowledgement for all the initial data (usually the IW) without reported congestion, it MAY then enter the Unvalidated Phase. Although a sender can immediately transition to the Unvalidated Phase, this transition MAY be deferred to the time at which more data is sent than would have normally permitted by the CC algorithm.¶
Implementation notes are provided in Section 4.2.¶
The Unvalidated Phase is designed to enable the CWND to more rapidly get up to speed by using paced transmission of a tentatively increased CWND.¶
On entry to the Unvalidated Phase, the following actions are performed:¶
Unvalidated Phase (Initialising PipeSize): The variable PipeSize is initialised to the flight_size on entry to the Unvalidated Phase. This records the used portion of the CWND before a jump is applied.¶
Unvalidated Phase (Setting the jump_cwnd): To avoid starving other flows that could have either started or increased their use of capacity since observing the capacity of a path, the jump_cwnd MUST be no more than half of the saved_cwnd. Hence, jump_cwnd is less than or equal to Min(max_jump,(saved_cwnd/2)). CWND = jump_cwnd.¶
In the Unvalidated Phase, the sender performs the following actions:¶
Unvalidated Phase (Pacing transmission): All packets sent in the Unvalidated Phase MUST use pacing based on the current rtt.¶
Unvalidated Phase (Tracking PipeSize): The variable PipeSize is increased by the volume of data acknowledged by each received ACK. (This indicates a previously unvalidated packet has been successfully sent over the path.)¶
The sender exits the Unvalidated Phase and enters the Safe Retreat Phase when one of the following events occurs:¶
Unvalidated Phase (Confirming the path during transmission): If the sender determines that it is not valid to use the previous CC parameters due to a detected path change (e.g., a change in the RTT or an explicit signal indicating a path change), the Safe Retreat Phase MUST be entered (logged as path_changed in [LOG]).¶
Unvalidated Phase (Detected congestion): If the sender detects congestion (e.g., packet loss or ECN-CE marking), the Safe Retreat Phase MUST be entered (logged as packet_loss or ECN_CE in [LOG]). (Note that insufficient time has passed in the Unvalidated Phase for a sender to receive any feedback validating the jump in CWND. Therefore, any detected congestion must have resulted from packets sent before the Unvalidated Phase.)¶
The sender exits the Unvalidated Phase and evaluates whether to enter the Validating Phase when one of the following events occurs:¶
Unvalidated Phase (Completed sending all unvalidated packets): The sender enters the Validating Phase when the flight_size equals the CWND (logged as last_unvalidated_packet_sent in [LOG]). For an implementation that measures the CWND in bytes, this condition is also true when the remaining unused CWND is less than one maximum-sized packet.¶
Unvalidated Phase (Receiving acknowledgement for an unvalidated packet): The sender enters the Validating Phase when an acknowledgement is received for the first packet number (or higher) that was sent in the Unvalidated Phase (logged as first_unvalidated_packet_acknowledged, see Section 2.3).¶
Unvalidated Phase (Limiting time in the Unvalidated Phase): The sender enters the Validating Phase if more than one RTT has elapsed while in the Unvalidated Phase (logged as rtt_exceeded, see Section 2.3).¶
Unvalidated Phase (Check flight_size): Upon any of these events (and after processing any Acknowledgments that update the PipeSize and flight_size), the sender checks if (flight_size is less than IW) or (flight_size is less than or equal to the PipeSize) then the CWND is reset to the PipeSize (logged as rate_limited in [LOG]) and the sender stops using Careful Resume and returns to use normal CC. In the absence of detected congestion, CWND is not reduced below IW. (The PipeSize does not include the part of the jump_cwnd that was not utilised.) Otherwise, the CWND MUST be set to the flight_size and the sender progresses to the Validating Phase.¶
Implementation notes are provided in Section 4.3.¶
Notes for BBR are provided in Appendix B.1.¶
The Validating Phase checks whether all packets sent in the Unvalidated Phase were received without inducing congestion. The CWND remains unvalidated and the sender typically remains in this phase for one RTT.¶
In the Validating Phase, the sender performs the following actions:¶
Validating Phase (Tracking PipeSize): The PipeSize is increased by the volume of acknowledged data for each received ACK that indicates a packet was successfully sent over the path.¶
Validating Phase (Updating CWND): The CWND is updated using the normal rules for the current congestion controller, this typically will use "slow start", which allows CWND to be increased for each received acknowledgement that indicates a packet has been successfully sent across the path.¶
The sender exits the Validating Phase when one of the following events occurs:¶
Validating Phase (Detected congestion): If the sender determines that congestion was detected (e.g., packet loss or ECN-CE marking), Careful Resume enters the Safe Retreat Phase (logged as packet_loss or ECN_CE, see Section 2.3).¶
Validating Phase (Receiving acknowledgement of the unvalidated packets): The sender enters stops using Careful Resume when an acknowledgement is received for the last packet number (or higher) that was sent in the Unvalidated Phase (logged as last_unvalidated_packet_acknowledged, see Section 2.3). This means that the packets sent in the Unvalidated Phase were acknowledged without congestion.¶
Notes for BBR are provided in Appendix B.2.¶
This phase is entered when congestion is detected for an unvalidated packet. It drains the path of other unvalidated packets.¶
On entry to the Safe Retreat Phase, the following actions are performed:¶
Safe Retreat Phase (Removing saved information): The set of saved CC parameters for the path are deleted, to prevent these from being used again by later flows.¶
Safe Retreat Phase (Re-initializing CWND): The CWND MUST be reduced to no more than (PipeSize/2). This avoids persistent starvation by allowing capacity for other flows to regain their share of the total capacity. (Note: The minimum CWND in QUIC is 2 packets, see: [RFC9002] section 4.8).¶
Safe Retreat Phase (Loss Recovery): Loss recovery commences using the newly reduced CWND that was set on entry to the Safe Retreat Phase. When the CWND is reduced, a QUIC sender can immediately send a single packet prior to the reduction [RFC9002] to speed up loss recovery. A similar method for TCP is described in Section 5 of [RFC6675]. The loss recovery continues until acknowledgment of the last packet number (or a later packet) sent in the Unvalidated or Validating Phase. Note: If the last unvalidated packet is not cumulatively acknowledged, then additional packets might also need to be retransmitted.¶
In the Safe Retreat Phase, the sender performs the following actions:¶
Safe Retreat Phase (Tracking PipeSize): The sender continues to update the PipeSize after processing each acknowledgement. (The PipeSize will be used to update ssthresh when leaving this phase, but does not affect the CWND.)¶
Safe Retreat Phase (Maintaining CWND): The CWND MUST NOT be increased in the Safe Retreat Phase.¶
Safe Retreat Phase (Acknowledgement of unvalidated packets): When the last packet (or a later packet) sent during the Unvalidated Phase has been acknowledged, the sender stops using Careful Resume and returns to use normal CC.¶
On leaving the Safe Retreat Phase, the ssthresh MUST be set to no larger than the most recently measured PipeSize * Beta, where Beta is a scaling factor between 0.5 and 1. The default value is 0.5, chosen to reduce the probability of inducing a second round of congestion. Cubic defines a Beta__cubic of 0.7 [RFC9438] (logged as exit_recovery in [LOG]).¶
Implementation notes are provided in Section 4.5.¶
Notes for BBR are described in Appendix B.3.¶
A sender that experiences persistent congestion (e.g., a Retransmission Time Out, RTO, expiry in TCP) ceases to use Careful Resume. The sender stops using Careful Resume and returns to use normal CC. If using BBR, the normal processing of packet losses will cause it to enter the Drain state while the "carefully-resuming" flag is set to True, see Appendix B.3.¶
As in loss recovery, data sent in the Unvalidated Phase could be later acknowledged after an RTO event.¶
After exiting Careful Resume, the sender returns to using the normal CC algorithm (e.g., in congestion avoidance when CWND is more than ssthresh, or slow start when less than or equal to ssthresh).¶
Implementation notes are provided in Section 4.6.¶
This section provides guidance for implementation and use.¶
There are various approaches to measuring the capacity used by a connection. Congestion controllers, such as such as Reno [RFC5681] or Cubic [RFC9438], could estimate the capacity based on the CWND, flight_size, acknowledged rate, etc. A different approach could estimate the same parameters for a rate-based congestion controller, such as BBR [I-D.ietf-ccwg-bbr], or by observing the rate at which data is acknowledged by the Remote Endpoint.¶
Implementations are required to calculate a saved_rtt, measuring the minimum RTT while observing the capacity. For example, this could be the minimum of a set RTT of measurements measured over the previous 5 minutes.¶
There are cases where the current CWND does not reflect the path capacity. At the end of slow start, the CWND can be significantly larger than needed to fully utilise the path (i.e., a CWND overshoot). It is inappropriate to use an overshoot in the CWND as a basis for estimating the capacity. In most cases, the CWND will converge to a stable value after several more RTTs. One mitigation when a connection is in Slow Start could be to set the saved_cwnd based on the validated pipe size (i.e., CWND / 2).¶
When the sender is rate-limited, or in the RTT following a burst of transmission, a sender typically transmits less data than allowed by the CWND. Such observations could be discounted when estimating the saved_cwnd (e.g., when a previous observation recorded a higher value.)¶
In the Reconnaissance Phase, the sender initiates a connection and starts sending initial data, while measuring the current rtt. The CC is not modified. A sender therefore needs to limit the initial data, sent in the first RTT of transmitted data, to not more than the IW [RFC9002]. This transmission using the IW is assumed to be a safe starting point for any path to avoid adding excessive load to a potentially congested path.¶
Careful Resume does not permit multiple concurrent reuse of the saved CC parameters. When multiple new concurrent connections are made to a server, each can have a valid saved_remote_endpoint, but the saved_cwnd can only be used for one connection at a time. This is to prevent the sender from performing multiple jumps in the CWND, each individually based on the same saved_cwnd, and hence creating an excessive aggregate load at the bottleneck.¶
The method that is used to prevent re-use of the saved CC parameters will depend upon the design of the server (e.g., if all connections from a given client IP arrive at the same server process, then the server process could use a hash table, whereas when using some types of load balancing, a distributed system might be needed to ensure this invariant when the load balancing hashes connections by 4-tuple and hence multiple connections from the same client device are served by different server processes.)¶
A sender that is rate-limited [RFC7661], sends insufficient data to be able to validate transmission at a higher rate. Such as sender is allowed to remain in the Reconnaissance Phase and to not transition to the Unvalidated Phase until there is more data in the transmission buffer than would normally be permitted by the CC algorithm.¶
Path characteristics can change over time for many reasons. This can result in the previously observed CC parameters becoming irrelevant.¶
To help confirm the path, the sender compares the saved_rrt with each current rtt sample.¶
If the current rtt is less than a half of the saved_rrt, this is regarded as too small. This is an indicator of a path change. This factor of two arises, because the jump_cwnd is calculated as half the measured saved_cwnd and sending rate ought not to exceed the observed rate when the saved_cwnd was measured.¶
If the current RTT is larger than the saved_rtt, this would result in a proportionally lower rate for the unvalidated packets, because the transmission is paced based on the current rtt. Hence this rate is still safe. If the current rtt has been incorrectly measured as larger than the actual path RTT, the sender will receive an ACK for an unvalidated packet before it has completed the Unvalidated Phase, this ACK resets the CWND to reflect the flight_size, and the sender then enters the Validating Phase. The flight_size reflects the amount of outstanding data in the network rather than the maximum that is permitted by the CWND.¶
A current rtt that is more than ten times the saved_rrt is indicative of a path change. The value of ten accommodates both increases in latency from buffering on a path and any variation between RTT samples.¶
Note 1: In the Reconnaissance Phase, the sender calculates a minimum RTT over the phase and checks this on entry to the Unvalidated Phase. This avoids needing to check after each current rtt sample.¶
Note 2: During the Unvalidated Phase, the minimum RTT cannot increase, and hence the minimum RTT can never be larger than than (saved_rtt x 10) during the Unvalidated Phase.¶
The sender also verifies that the initial data was acknowledged. Any loss could be indicative of persistent congestion. If a sender in Reconnaissance Phase detects congestion, it stops using Careful Resume and returns to using normal CC. Some transport protocols implement CC mechanisms that infer potential congestion from an increase in the current rtt. Designs need to consider if such an indication is a suitable trigger to revert to stop using Careful Resume.¶
This section considers the safety for using saved CC parameters to tentatively update the CWND. This seek to avoid starving other flows that could have either started or increased their use of capacity since observing the capacity of a path¶
To avoid inducing significant congestion to any connections that have started to use a shared bottleneck, a sender must not directly use the previously saved_cwnd to directly initialise a new flow causing it to resume sending at the same rate. The jump_cwnd is therefore limited to half the previously saved_cwnd.¶
The long-term use of the previously observed parameters is not appropriate, a Lifetime needs to define the duration during which a set of saved CC parameters can be safely re-used.¶
[RFC9040] provides guidance on the implementation of TCP Control Block Interdependence, but does not specify how long a saved parameter can safely be reused. [RFC7661] specifies a method for managing an unvalidated CWND. This states: "After a fixed period of time (the non-validated period (NVP)), the sender adjusts the CWND (Section 4.4.3). The NVP SHOULD NOT exceed five minutes." Section 5 of [RFC7661] discusses the rationale for choosing that period. However, RFC 7661 targets rate-limited connections using normal CC. Careful Resume includes additional mechanisms to avoid and mitigate the effects of overshoot, and therefore a longer period can be justified when using a saved_cwnd with Careful Resume.¶
When the path characteristics are known to be dynamic, or the path varies, a small Lifetime is desirable (e.g., measured in minutes). For stable paths, and where the sender does not expect the path to be shared by many senders, a longer Lifetime (e.g., measured in hours) could be used. A bottleneck that is shared by a large number of senders brings greater risk that CR connections could contribute congestion that leads to prolonged overload with starvation, this can be mitigated by setting a small Lifetime.¶
The sender needs to avoid sending a burst of packets greater than IW as a result of a step-increase in the CWND. This is consistent with [RFC8085], [RFC9000].¶
Pacing packets as a function of the current rtt, rather than the saved_rrt provides additional safety during the Unvalidated Phase, because it avoids a smaller saved_rrt inflating the sending rate. The lower bound to the minimum acceptable current RTT avoids sending unvalidated packets at a rate that would be higher than was previously observed.¶
The following example provides a relevant pacing rhythm: An Inter-packet Transmission Time (ITT) is determined by using the current Maximum Packet Size (MPS), including headers, the saved_cwnd and the current RTT. A safety margin can be configured to avoid sending mo