rfc9959xml2.original.xml   rfc9959.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!--<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
]>-->
<!---?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>-->
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-tsvwg-careful-resume-24"
ipr="trust200902" consensus="true" submissionType="IETF">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<!-- The abbreviated title is used in the page header tf-tsvwg-careful-resume-24" number="9959" updates="" obsoletes="" ipr="trust2009
- it is only necessary if the 02" consensus="true" submissionType="IETF" tocInclude="true" tocDepth="4" symRef
full title is longer than 39 characters --> s="true" sortRefs="true" version="3" xml:lang="en">
<title abbrev="Careful Resume"> Convergence of Congestion <!-- [rfced] We note that this document's abbreviated title and draft string
Control from Retained State</title> contain the phrase "Careful Resume", but the document's full title (see below)
does not. Would you like to add "Careful Resume" to the title, or update
the abbreviated title at all?
Title:
Convergence of Congestion Control from Retained State
Abbreviated title (which appears in the running header of the PDF):
Careful Resume
-->
<front>
<title abbrev="Careful Resume">Convergence of Congestion Control from Retain
ed State</title>
<seriesInfo name="RFC" value="9959"/>
<author fullname="Nicolas Kuhn" initials="N" surname="Kuhn"> <author fullname="Nicolas Kuhn" initials="N" surname="Kuhn">
<organization>Thales Alenia Space</organization> <organization>Thales Alenia Space</organization>
<address> <address>
<email>nicolas.kuhn.ietf@gmail.com</email> <email>nicolas.kuhn.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Emile Stephan" initials="E" surname="Stephan"> <author fullname="Emile Stephan" initials="E" surname="Stephan">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<email>emile.stephan@orange.com</email> <email>emile.stephan@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Godred Fairhurst" initials="G" surname="Fairhurst"> <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<postal> <postal>
<street>School of Engineering</street> <street>School of Engineering</street>
<street>Fraser Noble Building</street> <street>Fraser Noble Building</street>
<city>Aberdeen</city> <city>Aberdeen</city>
<code>AB24 3UE</code> <code>AB24 3UE</code>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>gorry@erg.abdn.ac.uk</email> <email>gorry@erg.abdn.ac.uk</email>
</address> </address>
</author> </author>
<author fullname="Raffaello Secchi" initials="R" surname="Secchi"> <author fullname="Raffaello Secchi" initials="R" surname="Secchi">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<postal> <postal>
<street>School of Engineering</street> <street>School of Engineering</street>
<street>Fraser Noble Building</street> <street>Fraser Noble Building</street>
<city>Aberdeen</city> <city>Aberdeen</city>
<code>AB24 3UE</code> <code>AB24 3UE</code>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>r.secchi@abdn.ac.uk</email> <email>r.secchi@abdn.ac.uk</email>
</address> </address>
</author> </author>
<author fullname="Christian Huitema" initials="C" surname="Huitema"> <author fullname="Christian Huitema" initials="C" surname="Huitema">
<organization>Private Octopus Inc.</organization> <organization>Private Octopus Inc.</organization>
<address> <address>
<email>huitema@huitema.net</email> <email>huitema@huitema.net</email>
</address> </address>
</author> </author>
<date year="2026" month="April"/>
<date year="2025" /> <area>WIT</area>
<workgroup>tsvwg</workgroup>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will
fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified
for the
purpose of calculating the expiry date). With drafts it is normally sufficient
to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Transport, Congestion Control, QUIC</keyword>
<!-- Keywords will be incorporated into HTML output <keyword>Transport</keyword>
files in a meta tag but they have no effect on text or nroff <keyword>Congestion Control</keyword>
output. If you submit your draft to the RFC Editor, the <keyword>QUIC</keyword>
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This document specifies a cautious method for Internet transports tha t <t>This document specifies a cautious method for Internet transports that
enables fast startup of congestion control for a wide enables fast startup of congestion control for a wide
range of connections, known as "Careful Resume". range of connections, known as "Careful Resume".
It reuses a set of computed congestion control parameters that It reuses a set of computed congestion control parameters that
are based on previously observed path characteristics between are based on previously observed path characteristics between
the same pair of transport endpoints. These parameters the same pair of transport endpoints. These parameters
are saved, allowing them to be later used to modify the are saved, allowing them to be later used to modify the
congestion control behaviour of a subsequent connection.</t> congestion control behaviour of a subsequent connection.</t>
<t>It describes assumptions and defines requirements for how a <t>This document describes the assumptions and defines the requirements fo r how a
sender utilises these parameters to provide opportunities for a sender utilises these parameters to provide opportunities for a
connection to more rapidly get up to speed and rapidly utilise available connection to more rapidly get up to speed and utilise available
capacity. It discusses how use of this method impacts the capacity at a capacity. It discusses how the use of this method impacts the capacity a
t a
shared network bottleneck and the safe response that is needed after any shared network bottleneck and the safe response that is needed after any
indication that the new rate is inappropriate.</t> indication that the new rate is inappropriate.</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section anchor="sec-introduction">
<section anchor="sec-introduction" title="Introduction"> <name>Introduction</name>
<t>All Internet transports are required to either <t>All Internet transports are required to either use a Congestion
use a Congestion Control (CC) algorithm, or Control (CC) algorithm or to constrain their rate of transmission <xref
to constrain their rate of transmission <xref target="RFC2914"></xref><xref target="RFC2914"/> <xref target="RFC8085"/>. In 2010, a survey of
target="RFC8085"></xref>. In 2010, alternative CC algorithms <xref target="RFC5783"/> noted that there are
a survey of alternative CC algorithms <xref target="RFC5783"></xref> noted t challenges when a CC algorithm operates across an Internet path with a
hat there high and/or varying Bandwidth-Delay Product (BDP). The specified method
are challenges when a CC algorithm operates across an Internet path with a h targets a solution for these challenges.</t>
igh and/or <t>A CC algorithm typically takes time to ramp up the sending rate. This i
varying Bandwidth-Delay Product (BDP). The specified method targets a s
solution for these challenges.</t> called the "Slow-Start Phase" and is informally known as the time to "get up
<t>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 during which a sender to speed". This defines a time during which a sender
intentionally uses less capacity than might be available, with the intentionally uses less capacity than might be available, with the
intention to avoid or limit overshoot of the available capacity for the path . intention to avoid or limit overshoot of the available capacity for the path .
In the context of CC, a path is associated with the end-to-end communication between In the context of CC, a path is associated with the end-to-end communication between
a pair of transport endpoints, each identified by a source IP address a pair of transport endpoints, each identified by a source IP address
and a unicast or anycast destination IP address. (This document does not def ine and a unicast or anycast destination IP address. (This document does not def ine
support for broadcast or multicast destination addresses.) A path can support for broadcast or multicast destination addresses.) A path can
also be associated with a specific Differentiated Services Code Point (DSCP) . also be associated with a specific Differentiated Services Code Point (DSCP) .
Below the transport layer, a specific path could be realised in various ways , but this Below the transport layer, a specific path could be realised in various ways , but this
is not normally evident to the transport endpoints. (When known, additional is not normally evident to the transport endpoints. (When known, additional
path information could potentially provide an explicit signal to the CC algo rithm path information could potentially provide an explicit signal to the CC algo rithm
to allow it to detect a change in the path.)</t> to allow it to detect a change in the path.)</t>
<t>Any overshoot of the bottleneck rate can have a
<t>Any overshoot of the bottleneck rate can have a
detrimental effect on other flows that share a common bottleneck. detrimental effect on other flows that share a common bottleneck.
A sender can also use a method that observes the rate of acknowledged data 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++ to seek to avoid an overshoot of this bottleneck capacity (e.g., Hystart++
<xref target="RFC9406"></xref>).</t> <xref target="RFC9406"/>).</t>
<t>In the extreme case, an overshoot can result in persistent congestion
<t>In the extreme case, an overshoot can result in persistent congestion
with unwanted starvation of with unwanted starvation of
other flows that share a common capacity bottleneck other flows that share a common capacity bottleneck
(i.e., preventing other flows (i.e., preventing other flows
from successfully sharing the capacity at a common bottleneck <xref target=" from successfully sharing the capacity at a common bottleneck <xref target="
RFC2914"></xref>).</t> RFC2914"/>).</t>
<t>A separate instance of a CC algorithm typically executes over a transpo
<t>A separate instance of a CC algorithm typically executes over a transport rt path.
path.
This seeks to avoid an increase in the queuing (latency or jitter) and/or This seeks to avoid an increase in the queuing (latency or jitter) and/or
congestion packet loss for the flow. congestion packet loss for the flow.
In the case of a multipath In the case of a multipath
transport, there can be more than one path with a separate CC transport, there can be more than one path with a separate CC
context for each path.</t> context for each path.</t>
<!-- [rfced] How may we adjust the sentence below to make it a complete
sentence? Specifically, what does "That is" refer to?
(The preceding sentence is included for context.)
<t>This document specifies Careful Resume, Original:
This document specifies Careful Resume, a method that seeks to reduce
the time to complete a transfer when the sending rate is limited by
the congestion controller using the congestion window (CWND). 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.
Perhaps:
This document specifies Careful Resume, a method that seeks to reduce
the time to complete a transfer when the sending rate is limited by
the congestion controller using the congestion window (CWND). Specifically,
this 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).
-->
<t>This document specifies Careful Resume,
a method that seeks to reduce the time to complete a method that seeks to reduce the time to complete
a transfer when the sending rate is limited by the congestion controller a transfer when the sending rate is limited by the congestion controller
using the congestion window (CWND). using the congestion window (CWND).
That is, when a transfer seeks to send significantly more data than 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 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 path is also significantly more than the product of the IW and path
Round Trip Time, RTT.</t> Round Trip Time (RTT).</t>
<t>Careful Resume introduces an alternative method to select initial CC pa
<t>Careful Resume introduces an alternative method to select initial CC para rameters that
meters that
seeks to more rapidly and safely grow the sending rate controlled by seeks to more rapidly and safely grow the sending rate controlled by
the CWND.</t> the CWND.</t>
<t>Careful Resume is based on temporal sharing (sometimes known as
<t>Careful Resume is based on temporal sharing (sometimes known as "caching") of a saved set of CC parameters that relate to previous observati
caching) of a saved set of CC parameters that relate to previous observation ons
s
of the same path. The of the same path. The
parameters are saved and used to modify the CC parameters are saved and used to modify the CC
behaviour of a subsequent connection between the behaviour of a subsequent connection between the
same endpoints.</t> same endpoints.</t>
<t>CC algorithms that are rate based can make
<t> CC algorithms that are rate-based can make
similar adjustments to their target sending rate. similar adjustments to their target sending rate.
When saving the observed capacity, When saving the observed capacity,
some CC algorithms might save a different parameter some CC algorithms might save a different parameter
that is equivalent to the saved_cwnd. that is equivalent to the saved_cwnd.
For example, a rate-based CC algorithm, For example, a rate-based CC algorithm
such as BBR <xref target="I-D.ietf-ccwg-bbr"></xref> can retain the such as Bottleneck Bandwidth and Round-trip propagation time (BBR) <xref tar
get="I-D.ietf-ccwg-bbr"/> can retain the
value of the bottleneck bandwidth required to reach the capacity available t o value of the bottleneck bandwidth required to reach the capacity available t o
the flow (e.g., BBR.max_bw). the flow (e.g., BBR.max_bw).
</t> </t>
<!-- In some ways the para below is true that one could use TCB-based meth
<!-- In some ways the para below is true that one could use TCB-based metho ods, but
ds, but
the RFC defining TCB does not say how this would be safely done, this is be tter not said: --> the RFC defining TCB does not say how this would be safely done, this is be tter not said: -->
<!-- <t>When used with the QUIC transport, this provides transport services that resemble <!-- <t>When used with the QUIC transport, this provides transport services that resemble
those that could be implemented in TCP, using methods such as TCP Control Bl ock (TCB) those that could be implemented in TCP, using methods such as TCP Control Bl ock (TCB)
Interdependence <xref target="RFC9040"></xref> caching.</t> --> Interdependence <xref target="RFC9040"></xref> caching.</t> -->
<section anchor="sec-CC-params" title="Use of saved CC parameters by a Sende <section anchor="sec-CC-params">
r"> <name>Use of Saved CC Parameters by a Sender</name>
<t>CC parameters are used by Careful Resume for three functions: <t>CC parameters are used by Careful Resume for three functions:
<list style="numbers"> </t>
<ol spacing="normal" type="1"><li>
<t>Information to confirm whether a saved path corresponds to <t>Information to confirm whether a saved path corresponds to
the current path.</t> the current path.</t>
<t>Information about the utilised path capacity and observed RTT to </li>
<li>
<t>Information about the utilised path capacity and observed RTT to
set CC parameters for the current connection.</t> set CC parameters for the current connection.</t>
<t>Information to check the CC parameters are not too old.</t> </li>
</list></t> <li>
<t>Information to check the CC parameters are not too old.</t>
<t>CC algorithms need to be cautious when using saved CC parameters </li>
on a new path </ol>
(see <xref target="RFC9000"></xref> and <xref target="RFC9040"></xre <t>CC algorithms need to be cautious when using saved CC parameters on a
f>). new path
(see <xref target="RFC9000"/> and <xref target="RFC9040"/>).
Care is therefore needed Care is therefore needed
to assure safe use and to be robust to changes to assure safe use and to be robust to changes
in traffic patterns, network routing, and link/node conditions. in traffic patterns, network routing, and link/node conditions.
There are cases where using the saved parameters of a previous There are cases where using the saved parameters of a previous
connection is not appropriate (see <xref target="guidance"></xref>). connection is not appropriate (see <xref target="guidance"/>).</t>
</t> </section>
</section> <!-- End of using with care -->
<section anchor="rec-choice" title="Receiver Preference"> <section anchor="rec-choice">
<t>Whilst the sender could take optimisation decisions without consi <name>Receiver Preference</name>
dering <t>Whilst the sender could take optimisation decisions without
the receiver's preference, there are cases where a receiver considering the receiver's preference, there are cases where a
could have information that receiver could have information that is not available at the sender or
is not available at the sender, or might benefit from might benefit from understanding that Careful Resume might be used.
understanding that Careful Resume might be used. In these cases, a receiver could use a transport mechanism to
In these cases, a receiver could use a transport mechanism to explicitly ask to either enable or inhibit Careful Resume when an
explicitly ask to either enable or inhibit Careful Resume application initiates a new connection.</t>
when an application initiates a new connection.</t>
<t> Examples where a receiver might request to inhibit using Careful <!-- [rfced] For readability, may we update the introductory text and the
Resume include: third item in the list below?
<list style="numbers">
<t>a receiver that can predict the pattern of traffic Original:
Examples where a receiver might request to inhibit using Careful
Resume include:
1. 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);
2. a receiver with a local indication that a path/local interface
has changed since the CC parameters were saved;
3. knowledge of the current hardware limitations at a receiver;
4. 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).
Perhaps:
Receivers might request the ability to inhibit the use of Careful Resume in
situations like the following:
1. when a receiver 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);
2. when a receiver with a local indication that a path/local interface
has changed since the CC parameters were saved;
3. when a receiver has knowledge of the current hardware limitations;
4. when a receiver 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).
-->
<t>Examples where a receiver might request to inhibit using Careful
Resume include:</t>
<ol spacing="normal" type="1"><li>
<t>a receiver that can predict the pattern of traffic
(e.g., insight into the volume of data to be sent, (e.g., insight into the volume of data to be sent,
the expected length of a connection, or the requested maximum tr ansfer rate);</t> the expected length of a connection, or the requested maximum tr ansfer rate);</t>
<t>a receiver with a local indication that a path/local </li>
<li>
<t>a receiver with a local indication that a path/local
interface has changed since the CC parameters were saved;</t> interface has changed since the CC parameters were saved;</t>
<t>knowledge of the current hardware limitations at a receiver;< </li>
/t> <li>
<t>a receiver that can predict additional capacity will be neede <t>knowledge of the current hardware limitations at a receiver;</t>
d </li>
<li>
<t>a receiver that can predict additional capacity will be needed
for other concurrent or later flows for other concurrent or later flows
(i.e., it prefers to activate Careful Resume for a different con nection).</t> (i.e., it prefers to activate Careful Resume for a different con nection).</t>
</list></t> </li>
</ol>
</section>
</section> <!-- End of Receiver Preference --> <section anchor="sec-transport-design">
<name>Transport Protocol Interaction</name>
<!-- [rfced] May we update "flow credit" to "flow control credit" in the text
below for consistency with RFC 9000?
<section anchor="sec-transport-design" title="Transport Protocol Interaction Original:
"> These include the sender pacing rate and the receiver-advertised
window [RFC9293] or flow credit [RFC9000], see Section 4.7.
Perhaps:
These include the sender pacing rate and the receiver-advertised
window [RFC9293] or flow control credit [RFC9000]; see Section 4.7.
-->
<t>The CWND is one factor that limits the <t>The CWND is one factor that limits the
sending rate of a transport protocol. Other mechanisms also constrain sending rate of a transport protocol. Other mechanisms also constrain
the maximum sending rate. These include the sender pacing rate and the the maximum sending rate. These include the sender pacing rate and the
receiver-advertised window <xref target="RFC9293"></xref> or flow credit receiver-advertised window <xref target="RFC9293"/> or flow credit <xref
<xref target="RFC9000"></xref>, see <xref target="flow-control"></xref>.</t> target="RFC9000"/>; see <xref target="flow-control"/>.</t>
</section> <!-- End of Other factors --> </section>
<section anchor="sec-use_case" title="Examples of Scenarios of Interest">
<section anchor="sec-use_case">
<name>Examples of Scenarios of Interest</name>
<t>This section provides a set of examples where Careful Resume is expec ted <t>This section provides a set of examples where Careful Resume is expec ted
to improve performance. to improve performance.
Either endpoint can assume the role of a Either endpoint can assume the role of a
sender or a receiver. Careful Resume can also be independently used sender or a receiver. Careful Resume can also be independently used
for each direction of a bidirectional connection.</t> for each direction of a bidirectional connection.</t>
<t>For example, consider an application that uses a series of connection s over a path: <t>For example, consider an application that uses a series of connection s over a path:
Without a new method, Without a new method,
each connection would need to individually each connection would need to individually
discover appropriate CC parameters, whereas Careful Resume allows the fl ow discover appropriate CC parameters, whereas Careful Resume allows the fl ow
to use a rate based on the previously observed CC parameters.</t> to use a rate based on the previously observed CC parameters.</t>
<t>Another example considers an application that connects after a disrup tion <t>Another example considers an application that connects after a disrup tion
had temporarily reduced the path had temporarily reduced the path
capacity: When this endpoint capacity: When this endpoint
returns to use the path using Careful Resume, the returns to use the path using Careful Resume, the
sending rate can be based on the previously observed CC parameters.</t> sending rate can be based on the previously observed CC parameters.</t>
<t>There is a particular benefit for <t>There is a particular benefit for
any path with an RTT that is much larger than for typical any path with an RTT that is much larger than for typical
Internet paths. Internet paths.
In a specific example, an application connected via a geo-stationary sat ellite access network In a specific example, an application connected via a geo-stationary sat ellite access network
<xref target="IJSCN"></xref> <xref target="IJSCN"/>
could take 9 seconds to complete a 5.3 MB transfer could take 9 seconds to complete a 5.3 MB transfer
using standard CC, whereas a sender using Careful Resume using standard CC, whereas a sender using Careful Resume
could reduce this transfer time to 4 seconds. The time to complete a 1 M B transfer could could reduce this transfer time to 4 seconds. The time to complete a 1 M B transfer could
similarly be reduced by 62 % <xref target="MAPRG111"></xref>. This benef it is also similarly be reduced by 62 % <xref target="MAPRG111"/>. This benefit is also
expected for other sizes of transfer and for different path expected for other sizes of transfer and for different path
characteristics when a path has a large BDP. characteristics when a path has a large BDP.
<xref target="CR25"></xref> provides further discussion of the method de <xref target="CR25"/> provides further discussion of the method defined
fined in this document and includes analysis over various types of paths.</t>
in this document and includes analysis over various types of path.</t> </section>
</section> <!-- Introduction: End of examples -->
<section anchor="sec-principle" title="Design Principles">
<section anchor="sec-principle">
<name>Design Principles</name>
<t>Resuming a connection with CC parameters that were observed <t>Resuming a connection with CC parameters that were observed
during a previous connection during a previous connection
is inherently a tradeoff between the potential performance is inherently a tradeoff between the potential performance
gains for the new connection and the risks of degraded performance gains for the new connection and the risks of degraded performance
for other connections that share for other connections that share
a common bottleneck. The specified method is designed to obtain good performance when resuming is appropriate, 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 while seeking to minimise the impact on other connections when it is
not appropriate.</t> not appropriate.</t>
<t>The following precautions mitigate the risk of <t>The following precautions mitigate the risk of
a sender adding excessive congestion to a path:</t> a sender adding excessive congestion to a path:</t>
<ol spacing="normal">
<!-- [rfced] For clarity, how may we add an additional verb to the text below?
Does "allows" convey the intended meaning?
<t><list> Original:
<t>The first precaution is to recognise whether the conditions have This provides some protection against aggravating severe congestion and
changed so much that the saved values are no longer valid. We to establish the minimum RTT.
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
<xref target="RFC6928"> </xref> <xref target="RFC9002"></xref>.
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 congest
ion
and to establish the minimum RTT.</t>
Perhaps:
This provides some protection against aggravating severe congestion and
allows establishing the minimum RTT.
-->
<li>
<t>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 <xref target="RFC6928"/> <xref
target="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.</t>
</li>
<li>
<t>The second precaution is to cautiously use the saved parameters <t>The second precaution is to cautiously use the saved parameters
when resuming. This is called the "Unvalidated Phase". when resuming. This is called the "Unvalidated Phase".
For example, For example,
the jump in the size of CWND/rate is restricted to a fraction (1 /2) of the saved_cwnd, 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 to avoid starving other flows that may have started or increased
their capacity after the last capacity measurement. their capacity after the last capacity measurement.
The same principle applies for CC algorithms that use different parameters to classic 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 fr action TCP CC: i.e., a sender must not send faster than allowed by a fr action
of the saved CC parameters. For example, a connection using a ra te-based CC algorithm of the saved CC parameters. For example, a connection using a ra te-based CC algorithm
(e.g., BBR) will set the (e.g., BBR) will set the
pacing rate to half the remembered value of the "bottleneck band width". pacing rate to half the remembered value of the "bottleneck band width".
The sender also needs to pace all unvalidated packets, The sender also needs to pace all unvalidated packets,
to ensure the rate does not exceed the previously used rate. to ensure the rate does not exceed the previously used rate.
This is intended to avoid a sudden influx of This is intended to avoid a sudden influx of
packets that could result in building a bottleneck queue and dis rupting existing flows. packets that could result in building a bottleneck queue and dis rupting existing flows.
Successful validation can allow further increases of the CWND; Successful validation can allow further increases of the CWND,
after first validating that the used rate did not result in cong estion.</t> after first validating that the used rate did not result in cong estion.</t>
</li>
<li>
<t>The third precaution is to enter a "Safe Retreat Phase" if the va <t>The third precaution is to enter a "Safe Retreat Phase" if the validation fai
lidation fails, ls,
for example if congestion is detected during validation. The ris for example, if congestion is detected during validation. The ri
k here is that the sk here is that the
trial use of the saved CC parameters could have disrupted existi ng connections. trial use of the saved CC parameters could have disrupted existi ng connections.
For example, consider a connection using Reno CC: For example, consider a connection using Reno CC:
When exiting "slow start" mode due to loss, When exiting "slow start" mode due to loss,
Reno would normally update the CWND to a Reno would normally update the CWND to a
"slow start threshold" set to half the volume of data in flight. "slow start threshold" set to half the volume of data in flight.
However, during this validation However, during this validation,
the CWND is restored from the saved CC parameters. The resultant sending rate 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 could be much larger than the value that would have been reached by a
"standard" slow start process, resulting in an overload of the p ath that potentially "standard" slow start process, resulting in an overload of the p ath that potentially
could cause significant congestion to other flows. could cause significant congestion to other flows.
Instead of continuing with that "too large" value, the retreat p rocess resets the Instead of continuing with that "too large" value, the retreat p rocess resets the
congestion window (rate) to a value no greater than what a stand ard process would have congestion window (rate) to a value no greater than what a stand ard process would have
discovered. For other CC algorithms, discovered. For other CC algorithms,
such as Cubic <xref target="RFC9438"></xref> or BBR, the impleme such as Cubic <xref target="RFC9438"/> or BBR, the implementatio
ntation n
details may differ, but the principle remains: trying and failin details may differ, but the principle remains: Trying and failin
g should not g should not
unduly disadvantage existing connections that unduly disadvantage existing connections that
share a common bottleneck (e.g., resulting in starving these con nections).</t> share a common bottleneck (e.g., resulting in starving these con nections).</t>
</list></t> </li>
</section> <!-- Principles --> </ol>
</section> <!-- End of introduction and motivation --> </section>
<!-- ***************************************************************************
*************** -->
<!-- The protocol spec follows below here, examples later -->
<!-- ***************************************************************************
*************** -->
<section anchor="notation" title="Language, Notation and Terms">
<t>This subsection provides a brief summary of key terms and the
requirements language.</t>
<section anchor="sec:req_language" title="Requirements Language">
<t>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
<xref target="RFC2119"/>
<xref target="RFC8174"/>
when, and only when, they appear in all
capitals, as shown here.</t>
</section> </section>
<section anchor="endpoint" title="The Remote Endpoint">
<section anchor="notation">
<name>Language, Notation, and Terms</name>
<t>This section provides a brief summary of key terms and the
requirements language.</t>
<section anchor="sec_req_language">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
<section anchor="endpoint">
<name>The Remote Endpoint</name>
<t> The Remote Endpoint is an implementation-dependent value that identi fies the sender's <t> The Remote Endpoint is an implementation-dependent value that identi fies the sender's
view of the network path being used. This is used 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. to match the current path with a set of CC parameters associated with a previously observed path.
It includes: It includes:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>an identifier representing the sending interface (e.g., a globall y <t>an identifier representing the sending interface (e.g., a globall y
assigned address/prefix or other local identifier);</t> assigned address/prefix or other local identifier);</t>
</li>
<li>
<t> an identifier representing the destination (e.g., a unicast or a nycast <t> an identifier representing the destination (e.g., a unicast or a nycast
IP address).</t> IP address).</t>
</list></t> </li>
</ul>
<t>The Remote Endpoint could also include information such as the DSCP. <t>The Remote Endpoint could also include information such as the DSCP.
If included, such information needs to be set consistently for a resumed connection If included, such information needs to be set consistently for a resumed connection
to the same endpoint. to the same endpoint.
Although additional information could improve the path Although additional information could improve the path
differentiation, it could reduce the re-usability of saved parameters.</ differentiation, it could reduce the reusability of saved parameters.</t
t> >
<t>The saved CC parameters can only be used to modify the startup when <t>The saved CC parameters can only be used to modify the startup when
the Remote Endpoint is not known to have changed (see <xref target="sec- the Remote Endpoint is not known to have changed (see <xref target="sec-
phase-rec-phase"></xref>).</t> phase-rec-phase"/>).</t>
</section> <!-- End of A Remote Endpoint --> </section>
<section anchor="sec-QLOG" title="Logging Support"> <section anchor="sec-QLOG">
<name>Logging Support</name>
<t>This document defines triggers to support logging key events. For exa mple, <t>This document defines triggers to support logging key events. For exa mple,
<xref target="I-D.custura-tsvwg-careful-resume-qlog"></xref> provides de finitions that enable a <xref target="I-D.custura-tsvwg-careful-resume-qlog"/> provides definiti ons that enable a
Careful Resume implementation Careful Resume implementation
to generate qlog events when using QUIC.</t> to generate qlog events when using QUIC.</t>
</section> <!-- End of Qlog --> </section>
<section anchor="sec-terms_def" title="Notation and Terms">
<t> The document uses language drawn
from a range of IETF RFCs.
The following terms are defined:
<list>
<!-- GF (Feb 2023): Removed the IW from this information block??? --
>
<!-- it could potentially be in the BDP Frame ID, but is not needed
here -->
<!-- <t>IW: Initial Window <xref target="RFC9002"></xref>, ;</t>
-->
<t>ACK: The indication at the transport-layer that the Remote Endpoi
nt
has correctly received the acknowledged data. In a CC algorithm,
an ACK also confirms that the acknowledged data is no longer in flig
ht.</t>
<t> Beta: A scaling factor between 0.5 and 1, the default value
is 0.5.</t>
<t>Careful Resume (CR): The method specified in this document to sel
ect
initial CC parameters and to more rapidly and safely
increase the initial sending rate.</t>
<t>CC parameters: A set of saved congestion control parameters from
observing the capacity of an established connection (see <xref targe
t="sec-CC-params"/>).</t>
<t>CWND: The congestion window, or equivalent CC variable limiting
the maximum sending rate (see <xref target="RFC5681"></xref>);</t>
<t>current RTT: A sample measurement of the current RTT measured usi
ng the most recent ACK;</t>
<t>flight_size: The current volume of unacknowledged data (see <xref
target="RFC5681"></xref>);</t>
<t>jump_cwnd: The resumed CWND, used in the Unvalidated Phase.</t>
<t>Lifetime: The configured time after which a set of saved CC param
eters can no longer be safely re-used.</t>
<t>max_jump: The configured maximum jump_cwnd;</t>
<t>PipeSize: A measure of the validated available capacity based on
the acknowledged data;</t>
<t>Remote Endpoint: The endpoint corresponding to a connection; see
<xref target="endpoint"></xref>;</t>
<t>saved_cwnd: A CC parameter with the preserved capacity derived fr <section anchor="sec-terms_def">
om observation of a <name>Notation and Terms</name>
previous connection (see <xref target="req-observe"></xref>);</t>
<t>saved_remote_endpoint: The Remote Endpoint that was associated wi <!-- [rfced] Section 2.4: FYI, we have made slight adjustments to the
th a set of saved CC parameters;</t> terminology list for readability and consistency with other list items.
-->
<t>saved_rtt: A CC parameter with the preserved minimum RTT (see <xr <t> The document uses language drawn from a range of RFCs. The
ef target="req-observe"></xref>).</t> following terms are defined:</t>
<t>unvalidated packet: A packet sent when the CWND has been increase <dl spacing="normal" newline="false">
d <dt>ACK:</dt><dd>The indication at the transport layer that the
beyond the size normally permitted by the CC algorithm; Remote Endpoint has correctly received the acknowledged data. In a
if such a packet is acknowledged by an ACK, it contributes to the Pi CC algorithm, an ACK also confirms that the acknowledged data is no
peSize, but longer in flight.</dd>
if congestion is detected, it triggers entry to the Safe Retreat Pha <dt>Beta:</dt><dd>A scaling factor between 0.5 and 1; the default
se.</t> value is 0.5.</dd>
</list></t> <dt>Careful Resume (CR):</dt><dd>The method specified in this
</section> <!-- End of Notation: End of terms --> document to select initial CC parameters and to more rapidly and
</section><!-- End of Notation --> safely increase the initial sending rate.</dd>
<dt>Congestion Control (CC) parameters:</dt><dd>A set of saved CC
parameters from observing the capacity of an established connection
(see <xref target="sec-CC-params"/>).</dd>
<dt>congestion window (CWND):</dt><dd>The congestion window or equival
ent CC variable
limiting the maximum sending rate (see <xref
target="RFC5681"/>).</dd>
<dt>current Round Trip Time (RTT):</dt><dd>A sample measurement of the
current RTT measured using the most recent ACK.</dd>
<dt>flight_size:</dt><dd>The current volume of unacknowledged data (se
e <xref target="RFC5681"/>).</dd>
<dt>jump_cwnd:</dt><dd>The resumed CWND, used in the Unvalidated Phase
.</dd>
<dt>Lifetime:</dt><dd>The configured time after which a set of saved C
C parameters can no longer be safely reused.</dd>
<dt>max_jump:</dt><dd>The configured maximum jump_cwnd.</dd>
<dt>PipeSize:</dt><dd>A measure of the validated available capacity ba
sed on the acknowledged data.</dd>
<dt>Remote Endpoint:</dt><dd>The endpoint corresponding to a connectio
n; see <xref target="endpoint"/>.</dd>
<dt>saved_cwnd:</dt><dd>A CC parameter with the preserved capacity
derived from observation of a previous connection (see <xref
target="req-observe"/>).</dd>
<dt>saved_remote_endpoint:</dt><dd>The Remote Endpoint that was associ
ated with a set of saved CC parameters.</dd>
<dt>saved_rtt:</dt><dd>A CC parameter with the preserved minimum RTT (
see <xref target="req-observe"/>).</dd>
<dt>unvalidated packet:</dt><dd>A packet sent when the CWND has been
increased beyond the size normally permitted by the CC algorithm; if
such a packet is acknowledged by an ACK, it contributes to the
PipeSize, but if congestion is detected, it triggers entry to the
Safe Retreat Phase.</dd>
</dl>
</section>
</section>
<section anchor="sec-phase" title="The Phases of CC using Careful Resume"> <section anchor="sec-phase">
<t>This section defines a series of phases that the <name>The Phases of CC Using Careful Resume</name>
<t>This section defines a series of phases that the
congestion controller moves through as a connection congestion controller moves through as a connection
uses Careful Resume. Each rule is prefixed by the uses Careful Resume. Each rule is prefixed by the
name of the relevant phase.</t> name of the relevant phase.</t>
<!-- [rfced] Figure 1: There are minor discrepancies between the SVG and
ASCII art as follows. Should the SVG be updated to match the ASCII art?
If so, please provide the updated SVG; or, if the updates are only to the
text elements in the SVG, we can update it.
<t> SVG vs. ascii-art:
<figure title="Key transitions between Phases in Careful Resume">
<artset> Observing vs. Normal CC
<artwork type="svg" name="figure 1.svg"> (Normal) vs. (Observing)
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height
="192" width="560" viewBox="0 0 560 192" class="diagram" text-anchor="middle" fo Normal vs. Normal CC
nt-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 208,48 L 208,64" fill="none" stroke="black"/>
<path d="M 208,96 L 208,160" fill="none" stroke="black"/
>
<path d="M 264,96 L 264,112" fill="none" stroke="black"/
>
<path d="M 336,128 L 336,160" fill="none" stroke="black"
/>
<path d="M 504,48 L 504,160" fill="none" stroke="black"/
>
<path d="M 336,32 L 496,32" fill="none" stroke="black"/>
<path d="M 296,80 L 504,80" fill="none" stroke="black"/>
<path d="M 264,112 L 288,112" fill="none" stroke="black"
/>
<path d="M 392,112 L 504,112" fill="none" stroke="black"
/>
<path d="M 208,160 L 360,160" fill="none" stroke="black"
/>
<path d="M 480,160 L 504,160" fill="none" stroke="black"
/>
<polygon class="arrowhead" points="512,48 500,42.4 500,5
3.6" fill="black" transform="rotate(270,504,48)"/>
<polygon class="arrowhead" points="504,32 492,26.4 492,3
7.6" fill="black" transform="rotate(0,496,32)"/>
<polygon class="arrowhead" points="368,160 356,154.4 356
,165.6" fill="black" transform="rotate(0,360,160)"/>
<polygon class="arrowhead" points="296,112 284,106.4 284
,117.6" fill="black" transform="rotate(0,288,112)"/>
<polygon class="arrowhead" points="216,64 204,58.4 204,6
9.6" fill="black" transform="rotate(90,208,64)"/>
<g class="text">
<text x="164" y="36">Observing ...&gt; Connect -&gt;
Reconnaissance</text>
<text x="532" y="36">Normal</text>
<text x="36" y="52">(Normal)</text>
<text x="240" y="84">Unvalidated</text>
<text x="340" y="116">Validating</text>
<text x="420" y="164">Safe Retreat</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art" align="left" alt=""><![CDATA[
Please see
https://www.rfc-editor.org/authors/rfc9959.html#figure-1 vs.
https://www.rfc-editor.org/authors/rfc9959.txt (Figure 1)
-->
<figure anchor="fig1">
<name>Key Transitions Between Phases in Careful Resume</name>
<artset>
<artwork type="svg" name="" alt="" src="">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192" width="560" v
iewBox="0 0 560 192" class="diagram" text-anchor="middle" font-family="monospace
" font-size="13px" stroke-linecap="round">
<path d="M 208,48 L 208,64" fill="none" stroke="black"/>
<path d="M 208,96 L 208,160" fill="none" stroke="black"/>
<path d="M 264,96 L 264,112" fill="none" stroke="black"/>
<path d="M 336,128 L 336,160" fill="none" stroke="black"/>
<path d="M 504,48 L 504,160" fill="none" stroke="black"/>
<path d="M 336,32 L 496,32" fill="none" stroke="black"/>
<path d="M 296,80 L 504,80" fill="none" stroke="black"/>
<path d="M 264,112 L 288,112" fill="none" stroke="black"/>
<path d="M 392,112 L 504,112" fill="none" stroke="black"/>
<path d="M 208,160 L 360,160" fill="none" stroke="black"/>
<path d="M 480,160 L 504,160" fill="none" stroke="black"/>
<polygon class="arrowhead" points="512,48 500,42.4 500,53.6" fill="black" transf
orm="rotate(270,504,48)"/>
<polygon class="arrowhead" points="504,32 492,26.4 492,37.6" fill="black" transf
orm="rotate(0,496,32)"/>
<polygon class="arrowhead" points="368,160 356,154.4 356,165.6" fill="black" tra
nsform="rotate(0,360,160)"/>
<polygon class="arrowhead" points="296,112 284,106.4 284,117.6" fill="black" tra
nsform="rotate(0,288,112)"/>
<polygon class="arrowhead" points="216,64 204,58.4 204,69.6" fill="black" transf
orm="rotate(90,208,64)"/>
<g class="text">
<text x="164" y="36">Observing ...&gt; Connect -&gt; Reconnaissance</text>
<text x="532" y="36">Normal</text>
<text x="36" y="52">(Normal)</text>
<text x="240" y="84">Unvalidated</text>
<text x="340" y="116">Validating</text>
<text x="420" y="164">Safe Retreat</text>
</g>
</svg>
</artwork>
<artwork name="" type="ascii-art" alt="" src=""><![CDATA[
Normal CC...> Connect -> Reconnaissance --------------------> Normal CC Normal CC...> Connect -> Reconnaissance --------------------> Normal CC
(Observing) | ^ (Observing) | ^
v | v |
Unvalidated --------------------------+ Unvalidated --------------------------+
| | | | | |
| +--> Validating --------------+ | +--> Validating --------------+
| | | | | |
| | | | | |
+---------------+--> Safe Retreat ---+ +---------------+--> Safe Retreat ---+]]></artwork>
</artset>
]]></artwork> </figure>
</artset> <t>
</figure> The key phases of Careful Resume are illustrated in <xref target="fig1"/>.
</t>
<t>
The key phases of Careful Resume are illustrated in Figure 1.
Examples of transitions between these phases Examples of transitions between these phases
are provided in <xref target="Notes"></xref> and <xref target="Examples"></x are provided in Appendices <xref target="Notes" format="counter"/> and <xref
ref>.</t> target="Examples" format="counter"/>.</t>
<!-- These subsections to match next section format -->
<section title="Observing"> <section>
<name>Observing</name>
<t>An established connection can save a set of CC parameters for the spe cific path <t>An established connection can save a set of CC parameters for the spe cific path
to the current endpoint. A set of CC parameters includes a to the current endpoint. A set of CC parameters includes a
Lifetime (e.g., as a timestamp after which the parameters must not be us ed), Lifetime (e.g., as a timestamp after which the parameters must not be us ed)
and corresponds to one saved_remote_endpoint.</t> and corresponds to one saved_remote_endpoint.</t>
<t>The following rules apply to observing a connection:</t>
<t>The following rules apply to observing a connection:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>Observing (saved_cwnd):
<t>Observing (saved_cwnd):
The currently utilised capacity for the connection is The currently utilised capacity for the connection is
measured as the volume of bytes sent during an RTT and is recorded in th e measured as the volume of bytes sent during an RTT and is recorded in th e
saved_cwnd. This could be computed saved_cwnd. This could be computed
by measuring the volume of data acknowledged in one RTT. by measuring the volume of data acknowledged in one RTT.
If the measured CWND is less than four times the IW, If the measured CWND is less than four times the IW,
the sender can choose to not save the CC parameters, because the additio nal actions associated with the sender can choose to not save the CC parameters, because the additio nal actions associated with
performing Careful Resume for a small CWND would not justify its use.</t > performing Careful Resume for a small CWND would not justify its use.</t >
</li>
<t>Observing (saved_rtt): The minimum RTT at the time of observation is <li>
saved as the saved_rrt.</t> <t>Observing (saved_rtt): The minimum RTT at the time of observation
<t>Observing (Updating saved CC parameters): A sender MUST NOT retain mo is saved as the saved_rrt.</t>
re than one </li>
<li>
<t>Observing (updating saved CC parameters): A sender <bcp14>MUST NO
T</bcp14> retain more than one
set of CC parameters for a Remote Endpoint, set of CC parameters for a Remote Endpoint,
but the set of CC parameters SHOULD be updated (or replaced) but the set of CC parameters <bcp14>SHOULD</bcp14> be updated (or replac ed)
after a later observation of a path to the same Remote Endpoint.</t> after a later observation of a path to the same Remote Endpoint.</t>
</li>
</ul>
<t>Implementation notes are provided in <xref target="req-observe"/>.</t
>
</section>
</list></t> <section anchor="sec-phase-rec-phase">
<name>Reconnaissance Phase</name>
<t>Implementation notes are provided in <xref target="req-observe"><
/xref>.</t>
</section> <!-- End of define Observing:-->
<section anchor="sec-phase-rec-phase" title="Reconnaissance Phase">
<t>During this phase, the sender attempts to retrieve CC <t>During this phase, the sender attempts to retrieve CC
parameters that were previously saved, then determine whether the path i s parameters that were previously saved, then determine whether the path i s
consistent with a previously observed path (i.e, match the consistent with a previously observed path (i.e, match the
saved_remote_endpoint in a set of saved CC parameters).</t> saved_remote_endpoint in a set of saved CC parameters).</t>
<t> The sender enters the Reconnaissance Phase after connection setup (u sing normal CC). <t> The sender enters the Reconnaissance Phase after connection setup (u sing normal CC).
In this phase, the CWND is initialised to the IW, and the sender transmi ts any initial data.</t> In this phase, the CWND is initialised to the IW, and the sender transmi ts any initial data.</t>
<!-- -->
<t> In the Reconnaissance Phase, the sender performs the following <t> In the Reconnaissance Phase, the sender performs the following
actions:</t> action:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Reconnaissance Phase (Received acknowledgment): <t>Reconnaissance Phase (received acknowledgment):
The CWND is increased using normal CC as each ACK The CWND is increased using normal CC as each ACK
confirms delivery of previously unacknowledged data confirms delivery of previously unacknowledged data
(i.e., the base congestion control algorithm continues to operate norm ally).</t> (i.e., the base congestion control algorithm continues to operate norm ally).</t>
</list></t> </li>
<t>The sender exits the Reconnaissance Phase and stops using Careful Resume </ul>
when one of the following events occurs:<list style="symbols"> <t>The sender exits the Reconnaissance Phase and stops using Careful Res
ume
<t>Reconnaissance Phase (Detected congestion): If the sender detects when one of the following events occurs:</t>
<ul spacing="normal">
<li>
<t>Reconnaissance Phase (detected congestion): If the sender detects
congestion (e.g., packet loss or ECN-CE marking), congestion (e.g., packet loss or ECN-CE marking),
this indicates that this indicates that
use of the saved CC parameters is inappropriate. use of the saved CC parameters is inappropriate.
The sender stops using Careful Resume and MUST continue using normal CC to The sender stops using Careful Resume and <bcp14>MUST</bcp14> continue using normal CC to
react to the detected congestion. </t> react to the detected congestion. </t>
</li>
<t>Reconnaissance Phase (Using saved_cwnd): <li>
<t>Reconnaissance Phase (using saved_cwnd):
Only one connection can use a specific set of saved CC parameters. Only one connection can use a specific set of saved CC parameters.
If another connection has already started to use the saved_cwnd, the sen der If another connection has already started to use the saved_cwnd, the sen der
MUST exit Careful Resume and return to use normal CC.</t> <bcp14>MUST</bcp14> exit Careful Resume and return to use normal CC.</t>
</li>
<t>Reconnaissance Phase (Path change): If the Remote Endpoint is not <li>
<t>Reconnaissance Phase (path change): If the Remote Endpoint is not
the same as any saved_remote_endpoint, or the sender receives a the same as any saved_remote_endpoint, or the sender receives a
signal from the local stack indicating that the path is now signal from the local stack indicating that the path is now
different to the observed path, the sender MUST stop using different to the observed path, the sender <bcp14>MUST</bcp14> stop using
Careful Resume and returns to use normal CC.</t> Careful Resume and returns to use normal CC.</t>
</li>
<!-- [rfced] In the text below, how may we clarify what must stop using
careful resume (is it the sender)?
<t>Reconnaissance Phase (Lifetime of saved CC parameters): The CC In addition, may we update "returns to use" to "return to using" (to be
parallel with the verb "using")? We note this language appears
elsewhere in this document, so please let us know if we may update those
instances as well.
Original:
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.
Perhaps:
If the Lifetime of the observed CC parameters is exceeded, this set of CC
parameters is not used. The saved CC parameters are deleted, and
the sender MUST stop using Careful Resume and return to using normal CC.
-->
<li>
<t>Reconnaissance Phase (lifetime of saved CC parameters): The CC
parameters are temporal. If the Lifetime of the observed CC parameters are temporal. If the Lifetime of the observed CC
parameters is exceeded, this set of CC parameters are not used, parameters is exceeded, this set of CC parameters is not used;
the saved CC parameters are deleted and MUST stop using the saved CC parameters are deleted and <bcp14>MUST</bcp14> stop using
Careful Resume and returns to use normal CC.</t> Careful Resume and returns to use normal CC.</t>
</li>
<t>Reconnaissance Phase (Minimum RTT too small): If the minimum <li>
<t>Reconnaissance Phase (minimum RTT too small): If the minimum
RTT recorded in the Reconnaissance Phase is less than or equal to RTT recorded in the Reconnaissance Phase is less than or equal to
(saved_rtt / 2) (see Section 4.2.1), the sender MUST stop (saved_rtt / 2) (see <xref target="sec-confirm-rtt"/>), the sender <bcp14> MUST</bcp14> stop
using Careful Resume using Careful Resume
(e.g., logged as rtt_not_validated in [LOG]) and returns to use normal CC. (e.g., logged as rtt_not_validated in <xref target="I-D.custura-tsvwg-care ful-resume-qlog"/>) and returns to use normal CC.
This is because the This is because the
calculation of a sending rate from a saved_cwnd is directly calculation of a sending rate from a saved_cwnd is directly
impacted by the RTT, therefore a significant change in the RTT is impacted by the RTT; therefore, a significant change in the RTT is
a strong indication that the previously observed CC parameters are a strong indication that the previously observed CC parameters are
not valid for the current path.</t> not valid for the current path.</t>
</list></t> </li>
</ul>
<t>Note: When a path is not confirmed, Careful Resume does not modify the C <t>Note: When a path is not confirmed, Careful Resume does not modify th
WND e CWND
before it exits to use normal CC.</t> before it exits to use normal CC.</t>
<t>The sender is permitted to enter the Unvalidated Phase as described b
<t>The sender is permitted to enter the Unvalidated Phase as described belo elow:</t>
w:<list style="symbols"> <ul spacing="normal">
<li>
<t>Reconnaissance Phase (Path confirmed): <t>Reconnaissance Phase (path confirmed):
When the sender has When the sender has
received an ACK that acknowledges all the initial data (usually the IW) received an ACK that acknowledges all the initial data (usually the IW)
without reported congestion, without reported congestion, it <bcp14>MAY</bcp14> then enter the Unvali
it MAY then enter the Unvalidated Phase. dated Phase.
Although a sender can immediately transition to 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 this transition <bcp14>MAY</bcp14> be deferred to the time at which more
than would have normally permitted by the CC algorithm.</t> data is sent
</list></t> than would have been normally permitted by the CC algorithm.</t>
</li>
<t>Implementation notes are provided in <xref target="req-recon"></xref> </ul>
.</t> <t>Implementation notes are provided in <xref target="req-recon"/>.</t>
</section>
</section> <!-- End of Reconnaissance Phase -->
<section anchor="sec-phase-unv-phase" title="Unvalidated Phase"> <section anchor="sec-phase-unv-phase">
<name>Unvalidated Phase</name>
<t>The Unvalidated Phase is designed to enable the CWND <t>The Unvalidated Phase is designed to enable the CWND
to more rapidly get up to speed by using paced transmission of a tentati vely increased CWND.</t> to more rapidly get up to speed by using paced transmission of a tentati vely increased CWND.</t>
<!-- -->
<t>On entry to the Unvalidated Phase, the following actions are perfor med:</t> <t>On entry to the Unvalidated Phase, the following actions are perfor med:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Unvalidated Phase (Initialising PipeSize): <li>
<t>Unvalidated Phase (initialising PipeSize):
The variable PipeSize is initialised to the flight_size on The variable PipeSize is initialised to the flight_size on
entry to the Unvalidated Phase. This records the used portion of the entry to the Unvalidated Phase. This records the used portion of the
CWND before a jump is applied.</t> CWND before a jump is applied.</t>
</li>
<t>Unvalidated Phase (Setting the jump_cwnd): <li>
<t>Unvalidated Phase (setting the jump_cwnd):
To avoid starving other flows that could have either started To avoid starving other flows that could have either started
or increased their use of capacity since observing the capacity o f a path, or increased their use of capacity since observing the capacity o f a path,
the jump_cwnd MUST be no more than half of the saved_cwnd. the jump_cwnd <bcp14>MUST</bcp14> be no more than half of the sav ed_cwnd.
Hence, jump_cwnd is less than or equal to Min(max_jump,(saved_cw nd/2)). Hence, jump_cwnd is less than or equal to Min(max_jump,(saved_cw nd/2)).
CWND = jump_cwnd. </t> CWND = jump_cwnd. </t>
</li>
</list></t> <!-- --> </ul>
<t> <t>
In the Unvalidated Phase, the sender performs the following actions:</ t> In the Unvalidated Phase, the sender performs the following actions:</ t>
<t><list style="symbols"> <ul spacing="normal">
<t>Unvalidated Phase (Pacing transmission): All packets sent in t <li>
he <t>Unvalidated Phase (pacing transmission): All packets sent in the
Unvalidated Phase MUST use pacing based on the current RTT.</t> Unvalidated Phase <bcp14>MUST</bcp14> use pacing based on the cur
rent RTT.</t>
<t>Unvalidated Phase (Tracking PipeSize): </li>
<li>
<t>Unvalidated Phase (tracking PipeSize):
The variable PipeSize is increased by the volume of data that is newly acknowledged The variable PipeSize is increased by the volume of data that is newly acknowledged
by each received ACK. (This indicates a previously unvalidated pa cket has been by each received ACK. (This indicates a previously unvalidated pa cket has been
successfully sent over the path.)</t> successfully sent over the path.)</t>
</li>
</list></t><!-- End of list of actions --> </ul>
<t>The sender exits the Unvalidated Phase and enters the Safe Retreat Ph ase <t>The sender exits the Unvalidated Phase and enters the Safe Retreat Ph ase
when one of the following events occurs:<list style="symbols"> when one of the following events occurs:</t>
<ul spacing="normal">
<li>
<t>Unvalidated Phase (Confirming the path during transmission): <!-- [rfced] We were unable to find the term "path_changed" mentioned in the
reference [LOG]. Should this reference be changed below?
Original:
* 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 (e.g., logged as path_changed in
[LOG]).
-->
<t>Unvalidated Phase (confirming the path during transmission):
If the sender determines that it is not valid to use the previous CC parameters 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 due to a detected path change (e.g., a change in the RTT
or an explicit signal indicating a path change), or an explicit signal indicating a path change),
the Safe Retreat Phase MUST be entered (e.g., logged as the Safe Retreat Phase <bcp14>MUST</bcp14> be entered (e.g., logg
path_changed in [LOG]).</t> ed as
path_changed in <xref target="I-D.custura-tsvwg-careful-resume-ql
<t>Unvalidated Phase (Detected congestion): If the sender detects og"/>).</t>
</li>
<li>
<t>Unvalidated Phase (detected congestion): If the sender detects
congestion (e.g., packet loss or ECN-CE marking), congestion (e.g., packet loss or ECN-CE marking),
the Safe Retreat Phase MUST be entered the Safe Retreat Phase <bcp14>MUST</bcp14> be entered
(e.g., logged as either packet_loss or ECN_CE in [LOG]). (e.g., logged as either packet_loss or ECN_CE in <xref target="I-
D.custura-tsvwg-careful-resume-qlog"/>).
(Note that insufficient time has passed in the Unvalidated Phase for a (Note that insufficient time has passed in the Unvalidated Phase for a
sender to receive any feedback validating the jump in CWND. sender to receive any feedback validating the jump in the CWND.
Therefore, any detected congestion must have resulted from packet s Therefore, any detected congestion must have resulted from packet s
sent before the Unvalidated Phase.)</t> sent before the Unvalidated Phase.)</t>
</li>
</list></t><!-- End of list of actions --> </ul>
<t>The sender exits the Unvalidated Phase and evaluates whether to enter the <t>The sender exits the Unvalidated Phase and evaluates whether to enter the
Validating Phase when one of the following events occurs:<list style="sym Validating Phase when one of the following events occurs:</t>
bols"> <ul spacing="normal">
<li>
<t>Unvalidated Phase (Completed sending all unvalidated packets): <t>Unvalidated Phase (completed sending all unvalidated packets):
The sender enters the Validating Phase when the flight_size equal s the CWND The sender enters the Validating Phase when the flight_size equal s the CWND
(e.g., logged as last_unvalidated_packet_sent in [LOG]). For an (e.g., logged as last_unvalidated_packet_sent in <xref target="I- D.custura-tsvwg-careful-resume-qlog"/>). For an
implementation that measures the CWND in bytes, this cond ition is implementation that measures the CWND in bytes, this cond ition is
also true when the remaining unused CWND is less than one also true when the remaining unused CWND is less than one
maximum- maximum-sized packet.</t>
sized packet.</t> </li>
<li>
<t>Unvalidated Phase (Receiving acknowledgement for an unvalidate <t>Unvalidated Phase (receiving acknowledgment for an unvalidated pa
d packet): cket):
The sender enters the Validating Phase when an ACK is The sender enters the Validating Phase when an ACK is
received that acknowledges the first packet number (or higher) received that acknowledges the first packet number (or higher)
that was sent in the Unvalidated Phase that was sent in the Unvalidated Phase
(e.g., logged as first_unvalidated_packet_acknowledged in [LOG]). (e.g., logged as first_unvalidated_packet_acknowledged in <xref t
</t> arget="I-D.custura-tsvwg-careful-resume-qlog"/>).</t>
</li>
<t>Unvalidated Phase (Limiting time in the Unvalidated Phase): Th <li>
e sender enters the <t>Unvalidated Phase (limiting time in the Unvalidated Phase): The s
ender enters the
Validating Phase if more than one RTT has elapsed while in the Un validated Phase Validating Phase if more than one RTT has elapsed while in the Un validated Phase
(e.g., logged as rtt_exceeded in [LOG]).</t> (e.g., logged as rtt_exceeded in <xref target="I-D.custura-tsvwg-
careful-resume-qlog"/>).</t>
</li>
</ul>
<!-- [rfced] For readability, how may we update the sentence below to reduce the
amount of text in parentheses?
</list></t> <!-- End of list of actions --> Original:
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 (e.g., logged as rate_limited in [LOG]) and the
sender stops using Careful Resume and returns to use normal CC.
<t>Unvalidated Phase (Check flight_size): Perhaps:
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 the following: If flight_size is less than th
e IW or
if flight_size is less than or equal to the PipeSize, then the CWND is
reset to the PipeSize (e.g., logged as rate_limited in [LOG]) and the
sender stops using Careful Resume and returns to use normal CC.
-->
<t>Unvalidated Phase (check flight_size):
Upon any of these events (and Upon any of these events (and
after processing any Acknowledgments that update the PipeSize 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), the sender checks if (flight_size is less than the IW) o r
(flight_size is less than or equal to the PipeSize) then the CWND is (flight_size is less than or equal to the PipeSize) then the CWND is
reset to the PipeSize (e.g., logged as rate_limited in [LOG]) and the reset to the PipeSize (e.g., logged as rate_limited in <xref target="I -D.custura-tsvwg-careful-resume-qlog"/>) and the
sender stops using Careful Resume and returns to use normal CC. In sender stops using Careful Resume and returns to use normal CC. In
the absence of detected congestion, CWND is not reduced below IW. the absence of detected congestion, the CWND is not reduced below the IW.
(The PipeSize does not include the (The PipeSize does not include the
part of the jump_cwnd that was not utilised.) Otherwise, the CWND MUST be set to part of the jump_cwnd that was not utilised.) Otherwise, the CWND <bcp 14>MUST</bcp14> be set to
the flight_size and the sender progresses to the Validating Phase.</t> the flight_size and the sender progresses to the Validating Phase.</t>
<t>Implementation notes are provided in <xref target="req-unvalid"/>. </
t>
<t>Notes for BBR are
provided in <xref target="sec-phase-unval-bbr"/>.</t>
</section>
<t>Implementation notes are provided in <xref target="req-unvalid"></x <section anchor="sec-phase-val-phase">
ref>. </t> <name>Validating Phase</name>
<t>The Validating Phase checks whether all packets
<t>Notes for BBR are
provided in <xref target="sec-phase-unval-bbr"></xref>.</t>
</section> <!-- End of define Unvalidated Phase -->
<section anchor="sec-phase-val-phase" title="Validating Phase">
<t>The Validating Phase checks whether all packets
sent in the Unvalidated Phase were received without inducing congestio n. sent in the Unvalidated Phase were received without inducing congestio n.
The CWND remains unvalidated and the sender typically remains in this phase for one RTT.</t> The CWND remains unvalidated and the sender typically remains in this phase for one RTT.</t>
<t>In the Validating Phase, the sender performs the following actions:</
<t>In the Validating Phase, the sender performs the following actions: t>
</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>Validating Phase (tracking PipeSize):
<t>Validating Phase (Tracking PipeSize):
The PipeSize is increased by the volume of acknowledged data for eac h The PipeSize is increased by the volume of acknowledged data for eac h
received ACK that indicates a packet was received ACK that indicates a packet was
successfully sent over the path.</t> successfully sent over the path.</t>
</li>
<t>Validating Phase (Updating CWND): The CWND is updated using the <li>
normal rules for the current congestion controller, <t>Validating Phase (updating the CWND): The CWND is updated using t
this typically will use "slow start", which he
allows CWND to be increased for each received ACK that normal rules for the current congestion controller.
This typically will use "slow start", which
allows the CWND to be increased for each received ACK that
indicates a packet has been successfully sent across the path.</t> indicates a packet has been successfully sent across the path.</t>
</list></t> <!-- End of list of actions --> </li>
</ul>
<t>The sender exits the Validating Phase when one of the following event s <t>The sender exits the Validating Phase when one of the following event s
occurs:<list> occurs:</t>
<ul spacing="normal">
<t>Validating Phase (Detected congestion): <li>
<t>Validating Phase (detected congestion):
If the sender determines that congestion was detected If the sender determines that congestion was detected
(e.g., packet loss or ECN-CE marking), Careful Resume (e.g., packet loss or ECN-CE marking), Careful Resume
enters the Safe Retreat Phase enters the Safe Retreat Phase
(e.g., logged as either packet_loss or ECN_CE in [LOG]).</t> (e.g., logged as either packet_loss or ECN_CE in <xref target="I-D.c
ustura-tsvwg-careful-resume-qlog"/>).</t>
<t>Validating Phase (Receiving acknowledgement of the unvalidated pa </li>
ckets): <li>
<t>Validating Phase (receiving acknowledgment of the unvalidated pac
kets):
The sender stops using Careful Resume when an ACK is The sender stops using Careful Resume when an ACK is
received that acknowledges the last packet number (or higher) received that acknowledges the last packet number (or higher)
that was sent in the Unvalidated Phase that was sent in the Unvalidated Phase
(e.g., logged as last_unvalidated_packet_acknowledged in [LOG]). (e.g., logged as last_unvalidated_packet_acknowledged in <xref targe t="I-D.custura-tsvwg-careful-resume-qlog"/>).
This means that the packets sent in the Unvalidated Phase were ackno wledged This means that the packets sent in the Unvalidated Phase were ackno wledged
without congestion.</t> without congestion.</t>
</list></t> <!-- End of list of actions --> </li>
</ul>
<t>Notes for BBR are <t>Notes for BBR are
provided in <xref target="sec-phase-val-bbr"></xref>.</t> provided in <xref target="sec-phase-val-bbr"/>.</t>
</section> <!-- End of define Validating Phase --> </section>
<section anchor="sec-phase-ret-phase" title="Safe Retreat Phase">
<section anchor="sec-phase-ret-phase">
<name>Safe Retreat Phase</name>
<t>This phase is entered when congestion is <t>This phase is entered when congestion is
detected for an unvalidated packet. detected for an unvalidated packet.
It drains the path of other unvalidated packets.</t> It drains the path of other unvalidated packets.</t>
<t>On entry to the Safe Retreat Phase, the following actions are perform ed:</t> <t>On entry to the Safe Retreat Phase, the following actions are perform ed:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Safe Retreat Phase (Removing saved information): <t>Safe Retreat Phase (removing saved information):
The set of saved CC parameters for The set of saved CC parameters for
the path are deleted, to prevent these the path are deleted, to prevent these
from being used again by later flows.</t> from being used again by later flows.</t>
</li>
<t>Safe Retreat Phase (Re-initializing CWND): <li>
The CWND MUST be reduced to <t>Safe Retreat Phase (re-initializing the CWND):
The CWND <bcp14>MUST</bcp14> be reduced to
no more than (PipeSize/2). no more than (PipeSize/2).
This avoids persistent starvation by allowing capacity for other flo ws to regain This avoids persistent starvation by allowing capacity for other flo ws to regain
their share of the total capacity. their share of the total capacity.
(Note: The minimum CWND in QUIC is 2 packets, see: <xref target="RFC (Note: The minimum CWND in QUIC is 2 packets; see <xref target="RFC9
9002"></xref> section 4.8).</t> 002" sectionFormat="comma" section="4.8"/>).</t>
</li>
<t>Safe Retreat Phase (Loss Recovery): <li>
<t>Safe Retreat Phase (loss recovery):
Loss recovery commences using the newly reduced CWND Loss recovery commences using the newly reduced CWND
that was set on entry to the Safe Retreat Phase. that was set on entry to the Safe Retreat Phase.
When the CWND is reduced, When the CWND is reduced,
a QUIC sender can immediately send a single packet prior to the redu ction a QUIC sender can immediately send a single packet prior to the redu ction
<xref target="RFC9002"></xref> to speed up loss <xref target="RFC9002"/> to speed up loss
recovery. A recovery. A
similar method for TCP is described in Section 5 of <xref target="RF C6675"></xref>. similar method for TCP is described in <xref target="RFC6675" sectio n="5"/>.
The loss recovery continues The loss recovery continues
until acknowledgment of the last packet number (or a later packet) s ent in the until acknowledgment of the last packet number (or a later packet) s ent in the
Unvalidated or Validating Phase. Unvalidated or Validating Phase.
Note: If the last unvalidated packet is not cumulatively acknowledge (Note: If the last unvalidated packet is not cumulatively acknowledg
d, then ed, then
additional packets might also need to be retransmitted.</t> additional packets might also need to be retransmitted.)</t>
</list></t> </li>
</ul>
<t>In the Safe Retreat Phase, the sender performs the following actions: </t> <t>In the Safe Retreat Phase, the sender performs the following actions: </t>
<t><list style="symbols"> <ul spacing="normal">
<li>
<t>Safe Retreat Phase (Tracking PipeSize): <t>Safe Retreat Phase (tracking PipeSize):
The sender continues to update The sender continues to update
the PipeSize after processing each ACK. the PipeSize after processing each ACK.
(The PipeSize will be used to update the ssthresh when (The PipeSize will be used to update the ssthresh when
leaving this phase, but does not affect the CWND.)</t> leaving this phase, but it does not affect the CWND.)</t>
</li>
<t>Safe Retreat Phase (Maintaining CWND): <li>
The CWND MUST NOT be increased in the Safe Retreat Phase.</t> <t>Safe Retreat Phase (maintaining the CWND):
The CWND <bcp14>MUST NOT</bcp14> be increased in the Safe Retreat Ph
<t>Safe Retreat Phase (Acknowledgement of unvalidated packets): ase.</t>
</li>
<li>
<t>Safe Retreat Phase (acknowledgment of unvalidated packets):
When the last packet (or a later packet) sent during the When the last packet (or a later packet) sent during the
Unvalidated Phase has been acknowledged, Unvalidated Phase has been acknowledged,
the sender stops using Careful Resume and returns to use normal CC.< /t> the sender stops using Careful Resume and returns to use normal CC.< /t>
</list></t> </li>
<t>On leaving </ul>
the Safe Retreat Phase, the ssthresh MUST be set to no larger than
<t>On leaving
the Safe Retreat Phase, the ssthresh <bcp14>MUST</bcp14> be set to n
o larger than
the most recently measured PipeSize * Beta, where Beta the most recently measured PipeSize * Beta, where Beta
is a scaling factor between 0.5 and 1. The default value is a scaling factor between 0.5 and 1. The default value
is 0.5, chosen to reduce the probability of inducing is 0.5, chosen to reduce the probability of inducing
a second round of congestion. Cubic defines a a second round of congestion. Cubic defines a
Beta__cubic of 0.7 <xref target="RFC9438"></xref> Beta__cubic of 0.7 <xref target="RFC9438"/>
(e.g., logged as exit_recovery in [LOG]).</t> (e.g., logged as exit_recovery in <xref target="I-D.custura-tsvwg-ca
reful-resume-qlog"/>).</t>
<t>Implementation notes are provided in <xref target="req-retreat"></xre <t>Implementation notes are provided in <xref target="req-retreat"/>.</t
f>.</t> >
<t>Notes for BBR are described in <xref target="sec-BBR-SR"></xref>.</t> <t>Notes for BBR are described in <xref target="sec-BBR-SR"/>.</t>
</section> <!-- End of Safe Retreat Phase --> </section>
<section title="Detecting Persistent Congestion while using Careful Resume">
<t> 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 u
sing 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 <xre
f target="sec-BBR-SR"></xref>.</t>
<section>
<name>Detecting Persistent Congestion While Using Careful Resume</name>
<t>A sender that experiences persistent congestion (e.g., a
Retransmission Time Out (RTO) or 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 <xref target="sec-BBR-SR"/>.</t>
<t> As in loss recovery, data sent in the <t> As in loss recovery, data sent in the
Unvalidated Phase could be later acknowledged after an RTO event.</t> Unvalidated Phase could be later acknowledged after an RTO event.</t>
</section> <!-- End of section: RTO Expiry --> </section>
<section anchor="Normal_Phase" title="Returning to use normal CC">
<section anchor="Normal_Phase">
<name>Returning to Use Normal CC</name>
<t>After exiting Careful Resume, the sender returns to using <t>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 the normal CC algorithm (e.g., in congestion avoidance when the CWND is more than ssthresh, or slow start when
less than or equal to ssthresh).</t> less than or equal to ssthresh).</t>
<t>Implementation notes are provided in <xref target="req-normal"/>.</t>
</section>
<t>Implementation notes are provided in <xref target="req-normal"></xref </section>
>.</t>
</section> <!-- End of define "normal:" -->
</section>
<!-- ***************************************************************************
*************** -->
<!--- Here we provide guidance on implementation -->
<section anchor="guidance" title="Implementation Notes and Guidelines">
<t>This section provides guidance for implementation and use.</t>
<section anchor="req-observe" title="Observing the Path Capacity">
<section anchor="guidance">
<name>Implementation Notes and Guidelines</name>
<t>This section provides guidance for implementation and use.</t>
<section anchor="req-observe">
<name>Observing the Path Capacity</name>
<t>There are various approaches to measuring the capacity used by a conn ection. <t>There are various approaches to measuring the capacity used by a conn ection.
Congestion controllers, such as such as Reno <xref target="RFC5681"></xr ef> or Cubic <xref target="RFC9438"></xref>, could estimate the Congestion controllers, such as such as Reno <xref target="RFC5681"/> o r Cubic <xref target="RFC9438"/>, could estimate the
capacity based on the capacity based on the
CWND, flight_size, acknowledged rate, etc. A different approach could CWND, flight_size, acknowledged rate, etc. A different approach could
estimate the same parameters for a rate-based congestion estimate the same parameters for a rate-based congestion
controller, such as BBR <xref target="I-D.ietf-ccwg-bbr"></xref>, controller, such as BBR <xref target="I-D.ietf-ccwg-bbr"/>,
or by observing the rate at which data is acknowledged by the Remote End point.</t> or by observing the rate at which data is acknowledged by the Remote End point.</t>
<t>Implementations are required to calculate a saved_rtt, measuring <t>Implementations are required to calculate a saved_rtt, measuring
the minimum RTT while observing the capacity. For example, this could be the minimum 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.</t> of a set RTT of measurements measured over the previous 5 minutes.</t>
<ul spacing="normal">
<t> <list style="symbols"> <li>
<!-- Avoid unhelpful use of the Careful Resume for small CWNDs.--> <t>There are cases where the current CWND does not reflect the
path capacity. At the end of slow start, the CWND can be
<t>There are cases where the current CWND significantly larger than needed to fully utilise the path (i.e.,
does not reflect the path capacity. At the end of slow a CWND overshoot). It is inappropriate to use an overshoot in the
start, the CWND can be significantly larger than CWND as a basis for estimating the capacity. In most cases, the
needed to fully utilise the path (i.e., a CWND CWND will converge to a stable value after several more RTTs. One
overshoot). It is inappropriate to use an mitigation when a connection is in Slow Start could be to set the
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).</t> saved_cwnd based on the validated pipe size (i.e., CWND / 2).</t>
</li>
<li>
<t>When the sender <t>When the sender
is rate-limited, or in the RTT following a burst of is rate limited or in the RTT following a burst of
transmission, a sender typically transmits transmission, a sender typically transmits
less data than allowed by the CWND. Such observations could be disco unted when less data than allowed by the CWND. Such observations could be disco unted when
estimating the saved_cwnd (e.g., when a previous estimating the saved_cwnd (e.g., when a previous
observation recorded a higher value.)</t> observation recorded a higher value).</t>
</list></t> </li>
</section> <!-- Observing (measuring) --> </ul>
</section>
<section anchor="req-recon" title="Confirming the Path in the Reconnaissanc <section anchor="req-recon">
e Phase"> <name>Confirming the Path in the Reconnaissance Phase</name>
<t>In the Reconnaissance Phase, the sender initiates a connection <t>In the Reconnaissance Phase, the sender initiates a connection
and starts sending initial data, while measuring the current RTT. and starts sending initial data, while measuring the current RTT.
The CC is not modified. The CC is not modified.
A sender therefore needs to limit the initial data, A sender therefore needs to limit the initial data,
sent in the first RTT of transmitted data, sent in the first RTT of transmitted data,
to not more than the IW <xref target="RFC9002"></xref>. to no more than the IW <xref target="RFC9002"/>.
This transmission using the IW is This transmission using the IW is
assumed to be a safe starting point for any path to avoid assumed to be a safe starting point for any path to avoid
adding excessive load to a potentially congested path.</t> adding excessive load to a potentially congested path.</t>
<t>Careful Resume does not permit multiple concurrent reuse of <t>Careful Resume does not permit multiple concurrent reuse of
the saved CC parameters. When multiple new concurrent connections the saved CC parameters. When multiple new concurrent connections
are made to a server, each can have a valid saved_remote_endpoint, are made to a server, each can have a valid saved_remote_endpoint,
but the saved_cwnd can only be used by one connection at a time. but the saved_cwnd can only be used by one connection at a time.
This is to prevent the sender from performing multiple jumps in the CWND , 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 each individually based on the same saved_cwnd, and hence creating an
excessive aggregate load at the bottleneck.</t> excessive aggregate load at the bottleneck.</t>
<t>The method that is used to prevent re-use of the saved CC parameters <!-- [rfced] May we break up the sentence below for readability?
Also note that we have removed the two closing parentheses at the end of this
text; please review.
Original:
For example, if a simple sender receives multiple connections from a Remote
Endpoint, then the sender process could use a hash table to manage the CC
parameters, whereas when using some types of load balancing, a distributed
system might be needed to ensure this invariant when the load balancing hashe
s
connections by 4-tuple and hence multiple connections from the same client
device are served by different server processes, see also Section 4.2.))
Perhaps:
For example, if a simple sender receives multiple connections from a Remote
Endpoint, then the sender process could use a hash table to manage the CC
parameters, whereas when using some types of load balancing, a distributed
system might be needed to ensure this invariant when the load balancing hashe
s
connections by 4-tuple. Hence, multiple connections from the same client
device are served by different server processes; see also Section 4.2.
-->
<t>The method that is used to prevent reuse of the saved CC parameters
will depend upon the design of the server. will depend upon the design of the server.
For example, For example,
if a simple sender receives multiple connections from a Remote Endpoint, if a simple sender receives multiple connections from a Remote Endpoint,
then the sender process could use a hash table to manage the CC paramete rs, then the sender process could use a hash table to manage the CC paramete rs,
whereas when using some types of load whereas when using some types of load
balancing, a distributed system might be needed to ensure this balancing, a distributed system might be needed to ensure this
invariant when the load balancing hashes invariant when the load balancing hashes
connections by 4-tuple and hence multiple connections from the same connections by 4-tuple and hence multiple connections from the same
client device are served by different server processes, client device are served by different server processes;
see also <xref target="req-recon"></xref>.))</t> see also <xref target="req-recon"/>.</t>
<t>A sender that is rate limited <xref target="RFC7661"/> sends
<t> A sender that is rate-limited <xref target="RFC7661"></xref>, insufficient data to be able to validate transmission at a higher
sends insufficient data rate. Such a sender is allowed to remain in the Reconnaissance Phase
to be able to validate transmission at a higher rate. and to not transition to the Unvalidated Phase until there is more
Such a sender is allowed to remain in the Reconnaissance Phase and to data in the transmission buffer than would normally be permitted by
not the CC algorithm.
transition to the Unvalidated Phase until there is </t>
more data in the transmission buffer <section anchor="sec-confirm-rtt">
than would normally be permitted by the CC algorithm. <name>Confirming the Path</name>
</t> <t>Path characteristics can change over time for many reasons.
<section anchor="sec-confirm-rtt" title="Confirming the Path">
<t>Path characteristics can change over time for many reasons.
This can result in the previously observed CC parameters This can result in the previously observed CC parameters
becoming irrelevant. To help confirm the path, the sender compares t he becoming irrelevant. To help confirm the path, the sender compares t he
saved_rrt with each current RTT sample.</t> saved_rrt with each current RTT sample.</t>
<t>If the current RTT sample is less than a half of the
<t>If the current RTT sample is less than a half of the
saved_rrt, this is regarded as too small. This is an indicator of a path change. 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 ha This factor of two arises because the jump_cwnd is calculated as hal
lf the f the
measured saved_cwnd and measured saved_cwnd and the sending rate ought not to exceed the obs
sending rate ought not to exceed the observed rate when erved rate when
the saved_cwnd was measured.</t> the saved_cwnd was measured.</t>
<t>If the current RTT is larger than the saved_rtt,
<t> If the current RTT is larger than the saved_rtt,
this would result this would result
in a proportionally lower rate for the unvalidated packets, because the transmission 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. is paced based on the current RTT. Hence, this rate is still safe.
If the current RTT has been incorrectly measured as larger If the current RTT has been incorrectly measured as larger
than the actual path RTT, the sender will receive an ACK for an than the actual path RTT, the sender will receive an ACK for an
unvalidated packet before it has completed the Unvalidated Phase, th is unvalidated packet before it has completed the Unvalidated Phase. Th is
ACK resets the CWND to reflect the flight_size, ACK resets the CWND to reflect the flight_size,
and the sender then enters the Validating Phase. and the sender then enters the Validating Phase.
The flight_size reflects the amount of outstanding data The flight_size reflects the amount of outstanding data
in the network rather than the in the network rather than the
maximum that is permitted by the CWND.</t> maximum that is permitted by the CWND.</t>
<t>A current RTT that is more than ten times the <t>A current RTT that is more than ten times the
saved_rrt is indicative of a path change. saved_rrt is indicative of a path change.
The value of ten accommodates both increases in latency from bufferi ng The value of ten accommodates both increases in latency from bufferi ng
on a path and any variation between RTT samples.</t> on a path and any variation between RTT samples.</t>
<t>Note 1: In the Reconnaissance Phase, the sender calculates a minimu
<t>Note 1: In the Reconnaissance Phase, the sender calculates a mini m RTT over the phase
mum RTT over the phase
and checks this on entry to the Unvalidated Phase. and checks this on entry to the Unvalidated Phase.
This avoids a need to check after each current RTT sample.</t> This avoids a need to check after each current RTT sample.</t>
<t> Note 2: During the Unvalidated Phase, the <t> Note 2: During the Unvalidated Phase, the
minimum RTT cannot increase, and hence the minimum RTT can never be larger minimum RTT cannot increase, and hence the minimum RTT can never be larger
than than (saved_rtt x 10) during the Unvalidated Phase.</t> than (saved_rtt x 10) during the Unvalidated Phase.</t>
<!-- [rfced] Please clarify "revert to stop using" in the text below.
<t>The sender also verifies that the initial data was acknowledged. Original:
Designs need to consider if such an indication is a suitable trigger to
revert to stop using Careful Resume.
Perhaps:
Designs need to consider if such an indication is a suitable trigger to
revert and stop using Careful Resume.
Or:
Designs need to consider if such an indication is a suitable trigger to
revert to not using Careful Resume.
-->
<t>The sender also verifies that the initial data was acknowledged.
Any loss could be indicative of persistent congestion. Any loss could be indicative of persistent congestion.
If a sender in Reconnaissance Phase detects congestion, it stops usi ng Careful Resume If a sender in the Reconnaissance Phase detects congestion, it stops using Careful Resume
and returns to using normal CC. and returns to using normal CC.
Some transport protocols implement CC mechanisms that infer potentia l congestion Some transport protocols implement CC mechanisms that infer potentia l congestion
from an increase in the current RTT. Designs need to consider if suc h an indication is from an increase in the current RTT. Designs need to consider if suc h an indication is
a suitable trigger to revert to stop using Careful Resume.</t> a suitable trigger to revert to stop using Careful Resume.</t>
</section> <!-- End of Reconnaissance:Confirming the Path --> </section>
</section> <!-- End of Reconnaissance(req-recon) --> </section>
<section anchor="req-unvalid" title="Safety in the Unvalidated Phase"> <section anchor="req-unvalid">
<name>Safety in the Unvalidated Phase</name>
<t>This section considers the safety <t>This section considers the safety
for using saved CC parameters to tentatively update the CWND. for using saved CC parameters to tentatively update the CWND.
This seek to avoid starving other flows that could have either started This seeks to avoid starving other flows that could have either started
or increased their use of capacity since observing the capacity of a pat or increased their use of capacity since observing the capacity of a pat
h</t> h.</t>
<t>To avoid inducing significant congestion to any connections that <t>To avoid inducing significant congestion to any connections that
have started to use a shared bottleneck, a sender must not directly use the previously have started to use a shared bottleneck, a sender must not directly use the previous
saved_cwnd to directly initialise a new flow causing it to resume sendin g at the same saved_cwnd to directly initialise a new flow causing it to resume sendin g at the same
rate. The jump_cwnd is therefore limited to half the previously saved_cw nd.</t> rate. The jump_cwnd is therefore limited to half the previously saved_cw nd.</t>
<section anchor="req-lifetime">
<section anchor="req-lifetime" title="Lifetime of CC Parameters"> <name>Lifetime of CC Parameters</name>
<t>The long-term use of the previously observed parameters is not appr
<t>The long-term use of the previously observed parameters is not ap opriate;
propriate,
a Lifetime defines the duration during a Lifetime defines the duration during
which a set of saved CC parameters can be safely re-used. which a set of saved CC parameters can be safely reused.
The maximum Lifetime is a configurable parameter for a sender. The maximum Lifetime is a configurable parameter for a sender.
An implementation also needs to provide a method to flush the set of saved CC parameters An implementation also needs to provide a method to flush the set of saved CC parameters
following a configuration change.</t> following a configuration change.</t>
<t><xref target="RFC9040"/> provides guidance on the implementation of
<t><xref target="RFC9040"></xref> provides guidance on the implement TCP Control Block Interdependence, but it does not specify how long
ation of a saved
TCP Control Block Interdependence, but does not specify how long a s
aved
parameter can safely be reused. parameter can safely be reused.
<xref target="RFC7661"></xref> specifies a method for managing an <xref target="RFC7661"/> specifies a method for managing an
unvalidated CWND. This states: unvalidated CWND. It states:</t>
"After a fixed period of time (the non-validated period (NVP)), the <blockquote>After a fixed period of time (the non-validated period (
sender NVP)), the sender
adjusts the CWND (Section 4.4.3). The NVP SHOULD NOT exceed five min adjusts the CWND (Section 4.4.3). The NVP <bcp14>SHOULD NOT</bcp14>
utes." exceed five minutes.</blockquote>
Section 5 of <xref target="RFC7661"></xref> discusses the rationale <t><xref target="RFC7661" section="5"/> discusses the rationale for
for
choosing that period. choosing that period.
However, RFC 7661 targets rate-limited connections using normal However, <xref target="RFC7661"/> targets rate-limited connections u sing normal
CC. Careful Resume includes additional CC. Careful Resume includes additional
mechanisms to avoid and mitigate the effects of overshoot, and there fore mechanisms to avoid and mitigate the effects of overshoot, and there fore
a longer period can be justified when using a saved_cwnd with a longer period can be justified when using a saved_cwnd with
Careful Resume.</t> Careful Resume.</t>
<t>When the path characteristics are known to be dynamic, or the path
<t>When the path characteristics are known to be dynamic, or the pat varies,
h varies,
a small Lifetime is desirable (e.g., measured in minutes). For stabl e paths, a small Lifetime is desirable (e.g., measured in minutes). For stabl e paths,
and where the sender does not expect the path to be shared by many s enders, and where the sender does not expect the path to be shared by many s enders,
a longer Lifetime (e.g., measured in hours) could be used. a longer Lifetime (e.g., measured in hours) could be used.
A bottleneck that is shared A bottleneck that is shared
by a large number of senders brings greater risk that CR connections could by a large number of senders brings greater risk that CR connections could
contribute congestion that leads to prolonged overload with starvati on, this can contribute congestion that leads to prolonged overload with starvati on. This can
be mitigated by setting a small Lifetime.</t> be mitigated by setting a small Lifetime.</t>
</section>
</section> <!-- End of Reconnaissance:Liftetime of Params --> <section anchor="req-pace">
<name>Pacing in the Unvalidated Phase</name>
<section anchor="req-pace" title="Pacing in the Unvalidated Phase"> <t>A sender needs to avoid any step increase in the CWND resulting in
a burst of
<t>A sender needs to avoid any step-increase in the CWND resulting in
a burst of
packets that is greater than the size of the CC algorithm's IW. packets that is greater than the size of the CC algorithm's IW.
This is consistent with <xref target="RFC8085"></xref>, This is consistent with <xref target="RFC8085"/> and
<xref target="RFC9000"></xref>.</t> <xref target="RFC9000"/>.</t>
<t>Pacing packets as a function of
<t> Pacing packets as a function of the current RTT, rather than the saved_rrt, provides additional safe
the current RTT, rather than the saved_rrt provides additional safet ty during the
y during the
Unvalidated Phase, because it avoids a smaller saved_rrt inflating t he sending rate. Unvalidated Phase, because it avoids a smaller saved_rrt inflating t he sending rate.
The lower bound to the minimum acceptable current RTT The lower bound to the minimum acceptable current RTT
avoids sending unvalidated packets at a rate that would be higher th an was previously observed.</t> avoids sending unvalidated packets at a rate that would be higher th an was previously observed.</t>
<t>The following example provides a relevant pacing rhythm:
<t>The following example provides a relevant pacing rhythm:
An Inter-packet Transmission Time (ITT) is determined An Inter-packet Transmission Time (ITT) is determined
by using the current Maximum Packet Size (MPS), including headers, by using the current Maximum Packet Size (MPS), including headers,
the saved_cwnd and the current RTT. A safety the saved_cwnd, and the current RTT. A safety
margin can be configured to avoid sending more than a maximum margin can be configured to avoid sending more than a maximum
(max_jump): (max_jump):
<list> </t>
<t>jump_cwnd = Min(max_jump,saved_cwnd/2)</t> <artwork>
<t>ITT = (current RTT x MPS)/jump_cwnd</t> jump_cwnd = Min(max_jump,saved_cwnd/2)
</list></t>
<t>This follows the idea presented in <xref target="RFC4782"></xref> ITT = (current RTT x MPS)/jump_cwnd
, </artwork>
<xref target="I-D.irtf-iccrg-sallantin-initial-spreading"></xref> an <t>This follows the idea presented in <xref target="RFC4782"/>,
d <xref target="I-D.irtf-iccrg-sallantin-initial-spreading"/>, and
<xref target="CONEXT15"></xref>. <xref target="CONEXT15"/>.
Other sender mitigations have also been suggested to Other sender mitigations have also been suggested to
avoid line-rate bursts (e.g., <xref target="I-D.hughes-restart"></xr avoid line-rate bursts (e.g., <xref target="I-D.hughes-restart"/>).<
ef>).</t> /t>
</section> <!-- Unvalidated Phase: Pacing --> </section>
<section title="Exit from the Unvalidated Phase because of Variable Netw <section>
ork Conditions"> <name>Exit from the Unvalidated Phase Because of Variable Network Cond
<t><list style="symbols"> itions</name>
<t>Careful Resume has been designed to be robust to <ul spacing="normal">
<li>
<t>Careful Resume has been designed to be robust to
changes in network conditions changes in network conditions
due to variations in the forwarding path due to variations in the forwarding path (see <xref target="sec-p
<xref target="sec-principle"></xref>, such as reconfiguration of rinciple"/>), such as reconfiguration of
equipment, or changes in the link conditions. This is mitigated equipment or changes in the link conditions. This is mitigated
by path confirmation.</t> by path confirmation.</t>
</li>
<t>Careful Resume has been designed to be robust to changes <li>
<t>Careful Resume has been designed to be robust to changes
in network traffic, including the in network traffic, including the
arrival of new flows that compete for capacity at a shared bottl eneck. arrival of new flows that compete for capacity at a shared bottl eneck.
This is mitigated by jumping to no more than a half of This is mitigated by jumping to no more than a half of
the saved_cwnd and by pacing.</t> the saved_cwnd and by pacing.</t>
</li>
<t>Careful Resume has been designed to avoid unduly suppressing <li>
flows <t>Careful Resume has been designed to avoid unduly suppressing fl
ows
that have used the capacity since the capacity was observed. Thi s is further that have used the capacity since the capacity was observed. Thi s is further
mitigated by bounding the duration of the Unvalidated Phase and the following mitigated by bounding the duration of the Unvalidated Phase and the following
Validating Phase, and the conservative design of the Safe Retrea t Phase.</t> Validating Phase, and the conservative design of the Safe Retrea t Phase.</t>
</list></t> </li>
</section> <!-- Unvalidated Phase: Subsection: Network Conditions --> </ul>
</section>
</section> <!-- Unvalidated Phase --> </section>
<section anchor="req-val" title="The Validating Phase"> <section anchor="req-val">
<name>The Validating Phase</name>
<t>The purpose of the Validating Phase is to trigger an <t>The purpose of the Validating Phase is to trigger an
entry to the Safe Retreat Phase if the capacity is not validated.</t> entry to the Safe Retreat Phase if the capacity is not validated.</t>
<t>When the sender completes the Unvalidated Phase, either by sending a jump_cwnd of data <t>When the sender completes the Unvalidated Phase, either by sending a jump_cwnd of data
or after one RTT or an acknowledgment for an unvalidated packet, or after one RTT or an acknowledgment for an unvalidated packet,
it ceases to use the unvalidated CWND.</t> it ceases to use the unvalidated CWND.</t>
<t>If the flight_size was less than or equal to the PipeSize, the <t>If the flight_size was less than or equal to the PipeSize, the
sender resets the CWND to the PipeSize, and stops using Careful Resume. Otherwise, if the CWND is larger than the flight_size, sender resets the CWND to the PipeSize and stops using Careful Resume. O therwise, if the CWND is larger than the flight_size,
the CWND is reset to the flight_size. the CWND is reset to the flight_size.
The sender then awaits reception of ACKs to validate the The sender then awaits reception of ACKs to validate the
use of this capacity.</t> use of this capacity.</t>
<t>New packets are sent when previously <t>New packets are sent when previously
sent data is newly acknowledged. sent data is newly acknowledged.
The CWND is increased during the Validating Phase, The CWND is increased during the Validating Phase,
based on received ACKs. This allows new data to be sent, based on received ACKs. This allows new data to be sent,
but this does not have any final impact on the CWND but this does not have any final impact on the CWND
if congestion is subsequently detected.</t> if congestion is subsequently detected.</t>
</section>
</section> <!-- Validating Phase --> <section anchor="req-retreat">
<name>Safety in the Safe Retreat Phase</name>
<section anchor="req-retreat" title="Safety in the Safe Retreat Phase">
<t>This section considers the safety <t>This section considers the safety
after congestion has been detected for unvalidated packets.</t> after congestion has been detected for unvalidated packets.</t>
<t>The Safe Retreat Phase sets a safe CWND value to drain any unvalidate d packets <t>The Safe Retreat Phase sets a safe CWND value to drain any unvalidate d packets
from the path after a packet loss has been detected or when ACKs that in dicate the sent from the path after a packet loss has been detected or when ACKs that in dicate the sent
packets were marked as ECN-CE. The CC parameters that were used are inva lid, packets were marked as ECN-CE. The CC parameters that were used are inva lid
and are removed.</t> and are removed.</t>
<t>The Safe Retreat reaction differs from a traditional <t>The Safe Retreat reaction differs from a traditional
reaction to detected congestion, because reaction to detected congestion, because
a jump_cwnd can result in a significantly higher rate than would be allo wed by a jump_cwnd can result in a significantly higher rate than would be allo wed by
Slow-Start. Such a jump could aggressively feed a congested bottleneck, Slow-Start. Such a jump could aggressively feed a congested bottleneck,
resulting in overshoot where a disproportionate number of packets resulting in overshoot where a disproportionate number of packets
from existing flows are displaced from the buffer at the congested bottl eneck. from existing flows are displaced from the buffer at the congested bottl eneck.
For this reason, a sender in the Safe Retreat Phase needs to react to de tected congestion by For this reason, a sender in the Safe Retreat Phase needs to react to de tected congestion by
reducing CWND significantly below the saved_cwnd.</t> reducing the CWND significantly below the saved_cwnd.</t>
<t>During loss recovery, a receiver can cumulatively acknowledge data
<t>During loss recovery, a receiver can cumulatively acknowledge that was previously sent in the Unvalidated Phase in addition to
data that was previously sent in the Unvalidated Phase in addition acknowledging the successful retransmission of data. <xref
to acknowledging the successful retransmission of data. target="RFC3465"/> describes how to appropriately account for such
<xref target="RFC3465"></xref> describes how to appropriately ACKs. The sender tracks received ACKs that acknowledge the reception
account for such ACKs. of the unvalidated packets to measure the maximum available capacity,
The sender tracks received ACKs that acknowledge called the "PipeSize". (The first unvalidated packet can be
the reception of the unvalidated packets to determined by recording the sequence number of the first packet sent
measure the maximum available capacity, called the "PipeSize" in the Unvalidated Phase.) This calculated PipeSize is later used to
(The first unvalidated packet can be determined by reset the ssthresh. However, note that this is not a safe measure of
recording the sequence number the currently available share of the capacity whenever there was also
of the first packet sent in the Unvalidated Phase.) a significant overshoot at the bottleneck, and it must not be used to
This calculated PipeSize is later used to reset the ssthresh. reinitialise the CWND.</t>
However, note that this is not a safe measure of the currently <t>Proportional Rate Reduction (PRR) <xref target="RFC9937"/>
available share of the capacity whenever
there was also a significant overshoot at the bottleneck,
and must not be used to reinitialise the CWND.</t>
<t>Proportional Rate Reduction (PRR) <xref target="I-D.ietf-tcpm-prr-rfc
6937bis"></xref>
assumes that it is safe to reduce assumes that it is safe to reduce
the rate gradually when in congestion avoidance. the rate gradually when in congestion avoidance.
PRR is therefore not appropriate PRR is therefore not appropriate
when there might be significant overshoot in the use of the capacity, wh ich can when there might be significant overshoot in the use of the capacity, wh ich can
be the case when the Safe Retreat Phase is entered.</t> be the case when the Safe Retreat Phase is entered.</t>
<t>The recovery from loss depends on the design of a transport protocol. <t>The recovery from loss depends on the design of a transport protocol.
A TCP or SCTP sender is required to retransmit A TCP or SCTP sender is required to retransmit
all lost data <xref target="RFC5681"></xref>. all lost data <xref target="RFC5681"/>.
For some transports (e.g., QUIC and DCCP), the need for loss recovery For some transports (e.g., QUIC and DCCP), the need for loss recovery
depends on the sender policy for retransmission. depends on the sender policy for retransmission.
On entry to the Safe Retreat Phase, the CWND can be On entry to the Safe Retreat Phase, the CWND can be
significantly reduced. When there was multiple loss, significantly reduced. When there were multiple losses,
a sender recovering all lost data could then take multiple RTTs to compl ete.</t> a sender recovering all lost data could then take multiple RTTs to compl ete.</t>
</section>
</section><!-- End of Safety for the Safe Retreat Phase --> <section anchor="req-normal">
<name>Returning to Normal Congestion Control</name>
<section anchor="req-normal" title="Returning to Normal Congestion Control">
<t>After using Careful Resume, the CC controller returns to using normal CC.</t> <t>After using Careful Resume, the CC controller returns to using normal CC.</t>
<t>The CWND at entry to the phase will have been <t>The CWND at entry to the phase will have been
increased when a sender has passed through the Unvalidated Phase, increased when a sender has passed through the Unvalidated Phase,
unless the sender was rate-limited, which causes the CWND to be unless the sender was rate limited, which causes the CWND to be
reset based on the used capacity. reset based on the used capacity.
The CWND is not reduced below IW, unless congestion was The CWND is not reduced below the IW, unless congestion was
detected. detected.
However, note that in some cases the value of the CWND However, note that in some cases the value of the CWND
could be significantly lower than the could be significantly lower than the
jump_cwnd (e.g., when a sender did not utilise jump_cwnd (e.g., when a sender did not utilise
the entire CWND in the Unvalidated Phase). The implementation details fo r different CC algorithms depend on the the entire CWND in the Unvalidated Phase). The implementation details fo r different CC algorithms depend on the
design of the algorithm.</t> design of the algorithm.</t>
<!---<list> <!---<list>
<t>For NewReno and CUBIC, it is recommended to exit Slow-Start <t>For NewReno and CUBIC, it is recommended to exit Slow-Start
and enter the congestion avoidance phase of the CC algorithm.</t> and enter the congestion avoidance phase of the CC algorithm.</t>
<t>For BBR CC, it is recommended to enter the "Drain" <t>For BBR CC, it is recommended to enter the "Drain"
state <xref target="bbr"</xref>.</t> state <xref target="bbr"</xref>.</t>
</list></t>--> </list></t>-->
<t>Once a sender is no longer using Careful Resume, the sender is permit ted to start <t>Once a sender is no longer using Careful Resume, the sender is permit ted to start
observing the capacity of the path.</t> observing the capacity of the path.</t>
</section>
</section> <!-- End of normal --> <section anchor="flow-control">
<name>Limitations from Transport Protocols</name>
<section anchor="flow-control" title="Limitations from Transport Protocols">
<t>The CWND is one factor that limits the <t>The CWND is one factor that limits the
sending rate of the sender. Other mechanisms can also constrain sending rate of the sender. Other mechanisms can also constrain
the maximum sending rate of a transport protocol. the maximum sending rate of a transport protocol.
A transport protocol might need to update these mechanisms A transport protocol might need to update these mechanisms
to fully utilise the CWND made available by Careful Resume: to fully utilise the CWND made available by Careful Resume:
<list> </t>
<ul spacing="normal">
<li>
<t>A TCP sender is limited by the receiver window (rwnd). <t>A TCP sender is limited by the receiver window (rwnd).
Unless configured at a receiver, the rwnd constrains the rate Unless configured at a receiver, the rwnd constrains the rate
of increase for a connection and reduces the benefit of Careful Resu me.</t> of increase for a connection and reduces the benefit of Careful Resu me.</t>
</li>
<li>
<t>QUIC includes flow control mechanisms and mechanisms to prevent a mplification <t>QUIC includes flow control mechanisms and mechanisms to prevent a mplification
attacks. In particular, a QUIC receiver might need to issue proactiv e attacks. In particular, a QUIC receiver might need to issue proactiv e
MAX_DATA frames to increase the flow control limits of a connection MAX_DATA frames to increase the flow control limits of a connection
that is started when using Careful Resume to gain the expected benef it.</t> that is started when using Careful Resume to gain the expected benef it.</t>
</list></t> </li>
</section> <!-- End of flow control, etc --> </ul>
</section> <!-- End of Guidelines --> </section>
</section>
<section anchor="ops" title="Operational Considerations"> <section anchor="ops">
<t>This section provides some operational consideration for network <name>Operational Considerations</name>
<t>This section provides some operational considerations for network
providers. As noted above, using CC parameters that were observed providers. As noted above, using CC parameters that were observed
during a previous connection is inherently a tradeoff between the during a previous connection is inherently a tradeoff between the
potential performance gains for the new connection and the risks of potential performance gains for the new connection and the risks of
degraded performance for other connections that share a common degraded performance for other connections that share a common
bottleneck. bottleneck.
A transport endpoint often has no visibility of changes in the level of A transport endpoint often has no visibility of changes in the level of
network traffic, nor the forwarding path over which the transport path network traffic, nor the forwarding path over which the transport path
is supported. is supported.
Careful Resume is therefore a sender-side transport change that Careful Resume is therefore a sender-side transport change that
has been designed so that any potential "harm" to has been designed so that any potential "harm" to
other flows is constrained. It seeks to detect whether the transport other flows is constrained. It seeks to detect whether the transport
path has changed since the observation of that capacity. path has changed since the observation of that capacity.
Importantly whenever a sender detects Importantly, whenever a sender detects
that assumptions about the capacity are not valid, the sender that assumptions about the capacity are not valid, the sender
safely responds to reduce the impact on other flows (see <xref target="sec-p safely responds to reduce the impact on other flows (see <xref target="sec-p
rinciple"></xref>.</t> rinciple"/>).</t>
<t>There are three ways that the use of Careful Resume can be constrained:
<t>There are three ways that the use of Careful Resume can be constrained: </t>
<list> <ul spacing="normal">
<t>The maximum configured jump window (max_jump), see <xref target="sec- <li>
phase-unv-phase"></xref>;</t> <t>The maximum configured jump window (max_jump) (see <xref target="se
<t>The Remote Endpoint identifying the client and the the server that ar c-phase-unv-phase"/>),</t>
e permitted to use a specific set of saved CC parameters, see <xref target="endp </li>
oint"></xref>;</t> <li>
<t>The configured Lifetime for a set of saved CC parameters, see <xref t <t>The Remote Endpoint identifying the client and the server that are
arget="req-lifetime"></xref>.</t> permitted to use a specific set of saved CC parameters (see <xref target="endpoi
</list></t> nt"/>),</t>
</li>
<t>Network methods such <li>
as Equal Cost Multipath Routing, Anycast Routing and Network Address Transla <t>The configured Lifetime for a set of saved CC parameters (see <xref
tion target="req-lifetime"/>).</t>
</li>
</ul>
<t>Network methods such
as Equal Cost Multipath Routing, Anycast Routing, and Network Address Transl
ation
can result in changes to the forwarding path. The impact of these can result in changes to the forwarding path. The impact of these
methods on Careful Resume can be minimized when the network is configured methods on Careful Resume can be minimised when the network is configured
so that the alternative paths are so that the alternative paths are
provisioned to support equivalent capacity (i.e., a change to provisioned to support equivalent capacity (i.e., a change to
the forwarding path does not introduce a significant reduction in the capaci ty the forwarding path does not introduce a significant reduction in the capaci ty
of the smallest bottleneck on the end-to-end path).</t> of the smallest bottleneck on the end-to-end path).</t>
<t>For many network paths, the smallest bottleneck is located in the acces
<t>For many network paths, the smallest bottleneck is located in the access s
part of the end-to-end path. part of the end-to-end path.
As an example, consider a typical client on an access network As an example, consider a typical client on an access network
could connects to a remote server with a capacity bottleneck located in the could connect to a remote server with a capacity bottleneck located in the
access part of this path. When the client access part of this path. When the client
connects to a server using an anycast destination address, the anycast connects to a server using an anycast destination address, the anycast
routing would be configured to distribute connections to a routing would be configured to distribute connections to a
corresponding server. A client would then be unaware of whether corresponding server. A client would then be unaware of whether
different instances of the client's different instances of the client's
connections (with the same address pair) would terminate at the same or connections (with the same address pair) would terminate at the same or
different servers, or at servers locate at different "server farms". different servers, or at servers located at different "server farms".
Hence, if a server is configured to Hence, if a server is configured to
send using Careful Resume, there is an onus to appropriately manage the send using Careful Resume, there is an onus to appropriately manage the
use of saved CC parameters (see <xref target="req-recon"></xref>).</t> use of saved CC parameters (see <xref target="req-recon"/>).</t>
<t>The way in which this is realised will depend upon the design choices i
<t>The way in which this is realised will depend upon the design choices in n
configuring the network and the servers. configuring the network and the servers.
On the one hand, if all the servers responding to a On the one hand, if all the servers responding to a
given IP address share the same location, e.g., are in the same data center, given IP address share the same location (e.g., are in the same data center) ,
then a method could be provided to coordinate their sharing of the CC parame ters then a method could be provided to coordinate their sharing of the CC parame ters
that are used to send data using Careful Resume. that are used to send data using Careful Resume.
On the other hand, if the service configuration is such that subsquent use o f the On the other hand, if the service configuration is such that subsquent use o f the
IP anycast address might IP anycast address might
result in a very different path to a server (e.g., at a different result in a very different path to a server (e.g., at a different
location where the path would be unable to support the same capacity), location where the path would be unable to support the same capacity),
a sender should not use Careful Resume based on saved CC parameters.</t> a sender should not use Careful Resume based on saved CC parameters.</t>
</section> </section>
<section anchor="sec-IANA">
<section anchor="sec-IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>No current parameters are required to be registered by IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="sec-security">
<section anchor="sec-security" title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations are the same as for other <t>The security considerations are the same as for other
sender-based congestion control methods. Such methods sender-based congestion control methods. Such methods
rely on the receiver appropriately acknowledging receipt rely on the receiver appropriately acknowledging receipt
of data. The ability of an on-path or off-path attacker of data. The ability of an on-path or off-path attacker
to influence congestion control depends upon the security to influence congestion control depends upon the security
properties of the transport protocol being used.</t> properties of the transport protocol being used.</t>
<!-- Security considerations for the <!-- Security considerations for the
interactions with the receiver are discussed in interactions with the receiver are discussed in
<xref target="I-D.kuhn-quic-bdpframe-extension"></xref>.--> <xref target="I-D.kuhn-quic-bdpframe-extension"></xref>.-->
</section> <!-- Sec Considerations -->
<section anchor="sec-acknowledgments" title="Acknowledgments">
<t>The authors would like to thank John Border, Gabriel Montenegro, Patrick
McManus,
Ian Swett, Igor Lubashev, Robin Marx, Roland Bless, Franklin Simo, Kazuho Ok
u, Tong,
Ana Custura, Neal Cardwell, Marten Seemann, Matthias Hofstaetter, Nicolai Fi
scher
Yi Huang, Mihail Yanev and Joerg Deutschmann for
their fruitful comments in developing this specification. They
also thank Mike Bishop for his careful suggestions on the structure
to describe the phases.
Thanks also to Mohamed Boucadair and to Dan Harkins for his secdir review.</
t>
<t>The authors would like to thank Tom Jones for co-authoring
several previous versions of this document.</t>
</section> </section>
</middle> </middle>
<!-- BACK MATTER -->
<back> <back>
<!-- References split into informative and normative --> <displayreference target="I-D.custura-tsvwg-careful-resume-qlog" to="LOG"/>
<displayreference target="I-D.hughes-restart" to="TCP-SSR"/>
<displayreference target="I-D.ietf-ccwg-bbr" to="BBR-CC"/>
<displayreference target="I-D.irtf-iccrg-sallantin-initial-spreading" to="IN
IT-SPREADING"/>
<!-- References:
<!-- There are 2 ways to insert reference entries from the citation librarie x) [I-D.irtf-iccrg-sallantin-initial-spreading-00]:
s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as s
hown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?>
here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files i
n the same
directory as the including file. You can also define the XML_LIBRARY environment
variable
with a value containing a set of directories to search. These can be either in
the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<displayreference target="I-D.custura-tsvwg-careful-resume-qlog" to="LOG"/> We note that this reference has been replaced by
draft-sallantin-iccrg-initial-spreading.
Would you like to update this reference to point to this newest draft?
<references title="Normative References"> x) [LOG]
<?rfc include="reference.RFC.2119.xml"?> We note that this reference (draft-custura-tsvwg-careful-resume-qlog-02) has
<?rfc include="reference.RFC.2914.xml"?> been replaced by draft-ietf-tsvwg-careful-resume-qlog. Would you like to
<!-- <?rfc include="reference.RFC.6349.xml"?> --> update this reference to point to this newest draft?
<?rfc include="reference.RFC.8085.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<!-- <?rfc include="reference.RFC.9001.xml"?> -->
<!-- <?rfc include="reference.RFC.8610.xml"?> -->
</references>
<references title="Informative References"> x)
<!--- <?rfc include="reference.I-D.ietf-quic-qlog-quic-events.xml"?> --> -->
<!-- ?rfc include="reference.I-D.kuhn-quic-bdpframe-extension.xml"? --> <references>
<?rfc include="reference.I-D.irtf-iccrg-sallantin-initial-spreading.xml" <name>References</name>
?> <references>
<?rfc include="reference.I-D.ietf-ccwg-bbr.xml"?> <name>Normative References</name>
<?rfc include="reference.I-D.custura-tsvwg-careful-resume-qlog.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="reference.RFC.3465.xml"?> 119.xml"/>
<?rfc include="reference.RFC.4782.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="reference.RFC.5681.xml"?> 914.xml"/>
<?rfc include="reference.RFC.9000.xml"?> <!-- QUIC --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.9438.xml"?> <!-- Cubic --> 085.xml"/>
<?rfc include="reference.RFC.5783.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.6675.xml"?> 174.xml"/>
<?rfc include="reference.RFC.6928.xml"?> </references>
<?rfc include="reference.RFC.9293.xml"?> <!-- TCP --> <references>
<!-- <?rfc include="reference.RFC.6937.xml"?>--> <name>Informative References</name>
<?rfc include="reference.I-D.ietf-tcpm-prr-rfc6937bis.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.99
37.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
irtf-iccrg-sallantin-initial-spreading.xml"/>
<?rfc include="reference.RFC.7661.xml"?> <!-- [I-D.ietf-ccwg-bbr]
<!-- ?rfc include="reference.RFC.8867.xml"?--> draft-ietf-ccwg-bbr-04
<?rfc include="reference.RFC.9002.xml"?> IESG State: I-D Exists as of 12/01/25
<?rfc include="reference.RFC.9040.xml"?> -->
<?rfc include="reference.RFC.9406.xml"?> <reference anchor="I-D.ietf-ccwg-bbr" target="https://datatracker.ietf.org/doc/h
tml/draft-ietf-ccwg-bbr-04">
<front>
<title>BBR Congestion Control</title>
<author initials="N." surname="Cardwell" fullname="Neal Cardwell" role="ed
itor">
<organization>Google</organization>
</author>
<author initials="I." surname="Swett" fullname="Ian Swett" role="editor">
<organization>Google</organization>
</author>
<author initials="J." surname="Beshay" fullname="Joseph Beshay" role="edit
or">
<organization>Meta</organization>
</author>
<date month="October" day="20" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ccwg-bbr-04" />
<!--- A manual format reference to over-ride broken ID Archive reference </reference>
(missing authors, noted by J.Touch). --> <!-- [LOG]
<reference anchor="I-D.hughes-restart" target="https://www.ietf.org/arch draft-custura-tsvwg-careful-resume-qlog-02
ive/id/draft-hughes-restart-00.txt"> Replaced by draft-ietf-tsvwg-careful-resume-qlog -->
<front>
<title>Issues in TCP Slow-Start Restart After Idle</title>
<author initials="A" surname="Hughes" fullname="Amy S Hughes">
<organization>ISI</organization>
</author>
<author initials="J" surname="Touch" fullname="Joe Touch">
<organization>ISI</organization>
</author>
<author initials="J" surname="Heidemann" fullname="John Heideman
n">
<organization>ISI</organization>
</author>
<date month="December" year="2001" />
</front>
<seriesInfo name="Work in Progress, Internet-Draft," value="draft-hu
ghes-restart-00" />
<refcontent></refcontent>
</reference>
<reference anchor="MAPRG111"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<front> custura-tsvwg-careful-resume-qlog.xml"/>
<title>Feedback from using QUIC's 0-RTT-BDP extension over SATCOM <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
465.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
782.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
681.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
000.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
438.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
783.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
675.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
928.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
293.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
661.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
002.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
406.xml"/>
<!--- A manual format reference to over-ride broken ID Archive reference
(missing authors, noted by J.Touch). -->
<!-- [I-D.hughes-restart]
draft-hughes-restart-00
IESG State: Expired as of 12/01/25
-->
<reference anchor="I-D.hughes-restart" target="https://datatracker.ietf.
org/doc/html/draft-hughes-restart-00">
<front>
<title>Issues in TCP Slow-Start Restart After Idle</title>
<author initials="A" surname="Hughes" fullname="Amy S Hughes">
<organization>ISI</organization>
</author>
<author initials="J" surname="Touch" fullname="Joe Touch">
<organization>ISI</organization>
</author>
<author initials="J" surname="Heidemann" fullname="John Heidemann">
<organization>ISI</organization>
</author>
<date month="December" year="2001"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hughes-restart-00"/>
</reference>
<reference anchor="MAPRG111" target="https://www.ietf.org/proceedings/11
1/slides/slides-111-maprg-feedback-from-using-quics-0-rtt-bdp-extension-over-sat
com-public-access-00.pdf">
<front>
<title>Feedback from using QUIC's 0-RTT-BDP extension over SATCOM
public access</title> public access</title>
<author initials="N" surname="Kuhn"/>
<author initials="E" surname="Stephan"/>
<author initials="G" surname="Fairhurst"/>
<author initials="T" surname="Jones"/>
<author initials="C" surname="Huitema"/>
<date month="July" year="2021"/>
</front>
<refcontent>IETF 111 Proceedings</refcontent>
</reference>
<reference anchor="IJSCN">
<front>
<title>Google QUIC performance over a public SATCOM access</title>
<author initials="L" surname="Thomas"/>
<author initials="E" surname="Dubois"/>
<author initials="N" surname="Kuhn"/>
<author initials="E" surname="Lochin"/>
<date year="2019"/>
</front>
<refcontent>International Journal of Satellite Communications and Netw
orking, vol. 37, no. 6, pp. 601-611</refcontent>
<seriesInfo name="DOI" value="10.1002/sat.1301"/>
</reference>
<reference anchor="CONEXT15">
<front>
<title>Halfback: Running Short Flows Quickly and Safely</title>
<author initials="Q" surname="Li"/>
<author initials="M" surname="Dong"/>
<author initials="P. B" surname="Godfrey"/>
<date year="2015"/>
</front>
<seriesInfo name="DOI" value="10.1145/2716281.2836107"/>
<refcontent>CoNEXT '15: Proceedings of the 11th ACM Conference on Emer
ging Networking Experiments and Technologies</refcontent>
</reference>
<author initials="N" surname="Kuhn"></author> <reference anchor="CR25" target="https://www.sciencedirect.com/science/a
rticle/abs/pii/S1389128625009156">
<author initials="E" surname="Stephan"></author> <front>
<title>Analysis of Careful Resumption of Internet Congestion Control
<author initials="G" surname="Fairhurst"></author> from Retained Path State</title>
<author initials="M" surname="Yanev"/>
<author initials="T" surname="Jones"></author> <author initials="A" surname="Custura"/>
<author initials="R" surname="Secchi"/>
<author initials="C" surname="Huitema"></author> <author initials="G" surname="Fairhurst"/>
<date year="2026"/>
<date year="2022" /> </front>
</front> <seriesInfo name="DOI" value="10.1016/j.comnet.2025.111950"/>
<refcontent>Computer Networks, vol. 276</refcontent>
<seriesInfo name="IETF 111 - MAPRG meeting" value="" /> </reference>
</reference> </references>
<reference anchor="IJSCN">
<front>
<title>Google QUIC performance over a public SATCOM access</title>
<author initials="L" surname="Thomas"></author>
<author initials="E" surname="Dubois"></author>
<author initials="N" surname="Kuhn"></author>
<author initials="E" surname="Lochin"></author>
<date year="2019" />
</front>
<seriesInfo name="International Journal of Satellite Communications and
Networking"
value="10.1002/sat.1301" />
</reference>
<reference anchor="CONEXT15">
<front>
<title>Halfback: Running Short Flows Quickly and Safely</title>
<author initials="Q" surname="Li"></author>
<author initials="M" surname="Dong"></author>
<author initials="P B" surname="Godfrey"></author>
<date year="2015" />
</front>
<seriesInfo name="ACM CoNEXT" value="" />
</reference>
<reference anchor="CR25">
<front>
<title>Careful Resumption of Internet Congestion Control from Retained
Path State</title>
<author initials="M" surname="Yanev"></author>
<author initials="A" surname="Custura"></author>
<author initials="R" surname="Secchi"></author>
<author initials="G" surname="Fairhurst"></author>
<date year="2025" />
</front>
<seriesInfo name="SSRN" value="https://papers.ssrn.com/sol3/papers.cfm?a
bstract_id=5240200" />
</reference>
</references> </references>
<section anchor="Notes">
<section anchor="Notes" title="Notes on the Careful Resume Phases"> <name>Notes on the Careful Resume Phases</name>
<t> The table below is provided to illustrate the operation of Careful Res
<t> The table below is provided to illustrate the operation of Careful Resum ume.
e. This table is informative; please refer to the body of the document
This table is informative, please refer to the body of the document
for the normative specification. The description is based on a normal for the normative specification. The description is based on a normal
CC that uses Reno. The PipeSize tracks the validated CWND.</t> CC that uses Reno. The PipeSize tracks the validated CWND.</t>
<t>The table uses the folowing abbreviations: <!-- [rfced] Regarding Table 1 (previously Figure 2):
SS = Slow-Start; FS = flight_size; PS = PipeSize; ACK = highest acknowledged
packet.</t>
<t> a) In "PS+=ACked", should "ACked" be "ACKed" (capital K)?
<figure title="Illustration of the operation of Careful Resume">
<artwork align="left" name="table" type="" alt=""><![CDATA[
+------+---------+---------+------------+-----------+--------- +
|Phase |Normal |Recon. |Unvalidated |Validating |Safe Ret. |
+------+---------+---------+------------+-----------+----------+
| |Observing|Confirm |Send faster |Validate |Drain |
| |CC params|path |using |new CWND; |path; |
| | | |saved_cwnd |Update PS |Update PS |
+------+---------+---------+------------+-----------+----------+
|On | - |CWND=IW |PS=FS |If (FS>PS) |CWND= |
|entry:| | |jump_cwnd |{CWND=FS} |(PS/2) |
| | | |=saved_cwnd |else | |
| | | |/2; |{CWND=PS; | |
| | | |CWND |use | |
| | | |=jump_cwnd |Normal CC} | |
+------+---------+---------+------------+-----------+----------+
|CWND: |When in |CWND |CWND is not |CWND can |CWND is |
| |observe, |increases|increased |increase |not |
| |measure |using SS | |using |increased |
| |saved | | |normal CC | |
| |_cwnd | | | | |
+------+---------+---------+------------+-----------+----------+
|PS: | - | - | PS+=ACked |
+------+---------+---------+------------+-----------+----------+
|RTT: |Measure |Measure | - | - | - |
| |saved_rtt|current | | | |
| | |RTT | | | |
+------+---------+---------+------------+-----------+----------+
|If |Normal CC|Normal | Enter | - |
|loss | |CC; | Safe | |
|or | |CR is not| Retreat | |
|ECNCE:| |allowed | | |
+------+---------+---------+------------+-----------+----------+
|Next |Observing|If ( |If(FS>CWND |If (ACK |If (ACK |
|Phase:|(as |CWND, |or >1 RTT |>= last |>= last |
| |needed) |Lifetime,|has passed |unvalidated|unvalid |
| | |and RTT |or ACK |packet), |ated |
| | |confirmed|>= first |use |packet), |
| | |), enter |unvalidated |Normal CC |ssthresh= |
| | |Unvalidat|packet), | |PS x Beta;|
| | |ed; else |If((FS>CWND)| |and use |
| | |CWND=Max |or(FS<=PS)) | |Normal CC |
| | |(PS,IW); |cwnd=PS; and| | |
| | |and use |use Normal | | |
| | |Normal CC|CC else | | |
| | | |cwnd=FS; | | |
| | | |enter | | |
| | | |Validating | | |
+------+---------+---------+------------+-----------+----------+
]]></artwork> b) FYI, we updated "ECNCE" to "ECN-CE" to match other usage in this
</figure></t> document and other RFCs.
</section>
<section anchor="Examples" title="Examples of the Careful Resume Phases"> c) In the opening text, would you like to add a sentence such as
'The phases in Table 1 correspond to Sections 3.2 through 3.5.' or similar?
<t>The following examples consider an implementation that keeps track of transmi d) Would you like to add any abbreviations and/or terms to
tted data in terms of packets and provide informative examples of use.</t> the legend (e.g., CWND, IW)?
-->
<t>In the Unvalidated Phase, the first unvalidated packet corresponds to <t>The table uses the following abbreviations:</t>
the <dl spacing="compact">
<dt>SS</dt><dd>= Slow-Start</dd>
<dt>FS</dt><dd>= flight_size</dd>
<dt>PS</dt><dd>= PipeSize</dd>
<dt>ACK</dt><dd>= highest acknowledged packet</dd>
</dl>
<table>
<name>Illustration of the Operation of Careful Resume</name>
<thead>
<tr>
<th>Phase</th>
<th>Normal</th>
<th>Recon.</th>
<th>Unvalidated</th>
<th>Validating</th>
<th>Safe Ret.</th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
<td>Observing CC params</td>
<td>Confirm path</td>
<td>Send faster using saved_cwnd</td>
<td>Validate new CWND; Update PS</td>
<td>Drain path; Update PS</td>
</tr>
<tr>
<td>On entry:</td>
<td align="center">-</td>
<td>CWND=IW</td>
<td>PS=FS jump_cwnd =saved_cwnd /2; CWND =jump_cwnd</td>
<td>If (FS>PS) {CWND=FS} else {CWND=PS; use Normal CC}</td>
<td>CWND=(PS/2)</td>
</tr>
<tr>
<td>CWND:</td>
<td>When in observe, measure saved _cwnd</td>
<td>CWND increases using SS</td>
<td>CWND is not increased</td>
<td>CWND can increase using normal CC</td>
<td>CWND is not increased</td>
</tr>
<tr>
<td>PS:</td>
<td align="center">-</td>
<td align="center">-</td>
<td colspan="3">PS+=ACked</td>
</tr>
<tr>
<td>RTT:</td>
<td>Measure saved_rtt</td>
<td>Measure current RTT</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">-</td>
</tr>
<tr>
<td>If loss or ECNCE:</td>
<td>Normal CC</td>
<td>Normal CC; CR is not allowed</td>
<td colspan="2">Enter Safe Retreat</td>
<td align="center">-</td>
</tr>
<tr>
<td>Next Phase:</td>
<td>Observing (as needed)</td>
<td>If (CWND, Lifetime, and RTT confirmed), enter Unvalidated; else C
WND=Max (PS,IW); and use Normal CC</td>
<td>If (FS>CWND or >1 RTT has passed or ACK >= first unvalidated pack
et), If ((FS>CWND) or (FS&lt;=PS)) cwnd=PS; and use Normal CC else cwnd=FS; ente
r Validating</td>
<td>If (ACK >= last unvalidated packet), use Normal CC</td>
<td>If (ACK >= last unvalidated packet), ssthresh = PS x Beta; and us
e Normal CC</td>
</tr>
</tbody>
</table>
</section>
<section anchor="Examples">
<name>Examples of the Careful Resume Phases</name>
<t>The following examples consider an implementation that keeps track of t
ransmitted data in terms of packets and provide informative examples of use.</t>
<t>In the Unvalidated Phase, the first unvalidated packet corresponds to t
he
highest sent packet recorded on entry to this phase. highest sent packet recorded on entry to this phase.
In the Validating Phase and Safe Retreat Phase, the sender tracks the la st unvalidated packet In the Validating Phase and Safe Retreat Phase, the sender tracks the la st unvalidated packet
(this is also the highest sent packet number recorded on entry to this p hase). (this is also the highest sent packet number recorded on entry to this p hase).
The PS tracks the validated portion of the CWND. The PS is set to the CW ND The PipeSize (PS) tracks the validated portion of the CWND. The PS is se t to the CWND
on entry to the Unvalidated Phase. on entry to the Unvalidated Phase.
It is updated after receiving an ACK for each additional packet. The def ault value of Beta is 0.5.</t> It is updated after receiving an ACK for each additional packet. The def ault value of Beta is 0.5.</t>
<t>Note:
<t>Note:
To simplify the description, these examples To simplify the description, these examples
are described using packet numbers (whereas QLOG variables are expressed in bytes).</t> are described using packet numbers (whereas QLOG variables are expressed in bytes).</t>
<section anchor="Examples-no_loss">
<section anchor="Examples-no loss" title="Example with No Loss"> <name>Example with No Loss</name>
<t>In the first example of using Careful Resume, <t>In the first example of using Careful Resume,
the sender starts by sending IW packets, assumed to be 10 packets, in th e Reconnaissance Phase, the sender starts by sending IW packets, assumed to be 10 packets, in th e Reconnaissance Phase,
and then continues in a subsequent RTT to send more packets until the se nder and then continues in a subsequent RTT to send more packets until the se nder
becomes CWND-limited (i.e., flight_size = CWND).</t> becomes CWND limited (i.e., flight_size = CWND).</t>
<t>The sender in the Reconnaissance Phase then <t>The sender in the Reconnaissance Phase then
confirms the RTT and other conditions for using Careful Resume. confirms the RTT and other conditions for using Careful Resume.
In this example, this is confirmed when the sender has 29 packets in fli ght.</t> In this example, this is confirmed when the sender has 29 packets in fli ght.</t>
<t>The sender then enters the Unvalidated Phase. <t>The sender then enters the Unvalidated Phase.
(This path confirmation could have happened earlier if data had been ava ilable to send.) The (This path confirmation could have happened earlier if data had been ava ilable to send.) The
sender initialises the PipeSize to the flight_size sender initialises the PipeSize to the flight_size
(in this case, 29 packets) (in this case, 29 packets)
and then sets the CWND to 150 packets (based upon half of the previously and then sets the CWND to 150 packets (based upon half of the previously
observed saved_cwnd of 300 packets).</t> observed saved_cwnd of 300 packets).</t>
<t>The sender now sends 121 unvalidated packets (the unused portion of t he current CWND). <t>The sender now sends 121 unvalidated packets (the unused portion of t he current CWND).
Each time a packet is sent, the sender checks whether 1 RTT has passed s ince entering the Each time a packet is sent, the sender checks whether 1 RTT has passed s ince entering the
Unvalidated Phase (otherwise, the Validating Phase is entered). This che ck triggers only Unvalidated Phase (otherwise, the Validating Phase is entered). This che ck triggers only
for cases where the sender is rate-limited, as shown in the following ex for cases where the sender is rate limited, as shown in the following ex
ample:</t> ample: The PipeSize increases after each ACK is received.</t>
<t>When the first unvalidated packet is acknowledged (packet number 30),
<t>The PipeSize increases after each ACK is received.</t> the sender
enters the Validating Phase. (This transition would also occur if the fl
<t>When the first unvalidated packet is acknowledged (packet number 30) ight_size increased to equal the CWND.)
the sender
enters the Validating Phase. (This transition would also occur if the fl
ight_size increased to equal CWND.)
During this phase, the CWND can be increased for each ACK that acknowled ges an unvalidated packet, because During this phase, the CWND can be increased for each ACK that acknowled ges an unvalidated packet, because
this indicates that the packet was validated.</t> this indicates that the packet was validated.</t>
<t>When an ACK is received that acknowledges the last packet that was se nt in the <t>When an ACK is received that acknowledges the last packet that was se nt in the
Unvalidated Phase, the sender stops using Careful Resume. Unvalidated Phase, the sender stops using Careful Resume.
For example, if the CWND is less than ssthresh, For example, if the CWND is less than ssthresh,
a Reno or Cubic sender using normal CC is permitted to use Slow-Start to grow the CWND towards a Reno or Cubic sender using normal CC is permitted to use Slow-Start to grow the CWND towards
the ssthresh, and will then enter congestion avoidance.</t> the ssthresh and will then enter congestion avoidance.</t>
</section> </section>
<section anchor="Examples-dl">
<section anchor="Examples-dl" title="Example with No Loss, Rate-Limited"> <name>Example with No Loss, Rate Limited</name>
<t>A rate-limited sender will not fully utilise the available CWND when using Careful Resume, <t>A rate-limited sender will not fully utilise the available CWND when using Careful Resume,
and CWND is therefore reset on entry to the Validating Phase, as describ and the CWND is therefore reset on entry to the Validating Phase, as des
ed below.</t> cribed below.</t>
<t>The sender starts by sending up to IW packets (10) in the Reconnaissa nce Phase. <t>The sender starts by sending up to IW packets (10) in the Reconnaissa nce Phase.
It commences as described in the first example, transitioning to the Unv alidated Phase, It commences as described in the first example, transitioning to the Unv alidated Phase,
where the CWND is set to 150 packets, and the PipeSize is set to the fli ght_size (i.e., 29 packets).</t> where the CWND is set to 150 packets, and the PipeSize is set to the fli ght_size (i.e., 29 packets).</t>
<t>The sender then becomes rate limited, because the example only sends
<t>The sender then becomes rate-limited, because the example only sends 50 unvalidated packets.</t>
50 unvalidated packets.</t>
<t> After about one RTT (e.g., by comparing the current time with local timestamps for each sent packet <t> After about one RTT (e.g., by comparing the current time with local timestamps for each sent packet
or by receiving an ACK for the first or by receiving an ACK for the first
unvalidated packet), the sender will still not have fully-used the CWND. unvalidated packet), the sender will still not have fully used the CWND.
It then enters It then enters
the Validating Phase and resets the CWND to the current flight_size, (i. the Validating Phase and resets the CWND to the current flight_size (i.e
e., 50 packets). ., 50 packets).
During this phase, the CWND can be increased for each received ACK During this phase, the CWND can be increased for each received ACK
that validates reception of an unvalidated packet. that validates reception of an unvalidated packet.
The PipeSize also increases with each ACK received, to reflect the disco vered capacity.</t> The PipeSize also increases with each ACK received, to reflect the disco vered capacity.</t>
<t>The sender completes using Careful Resume
<t>The sender completes using Careful Resume,
when a received ACK acknowledges the last packet that was sent in the Un validated Phase. when a received ACK acknowledges the last packet that was sent in the Un validated Phase.
It then stops using Careful Resume, as in the example with no loss.</t> It then stops using Careful Resume, as in the example with no loss.</t>
</section> </section>
<section anchor="Examples-loss-recon">
<section anchor="Examples-loss-recon" title="Example with Loss detected in t <name>Example with Loss Detected in the Reconnaissance Phase</name>
he Reconnaissance Phase">
<t>When a sender detects that a packet was lost in the Reconnaissance Ph ase, <t>When a sender detects that a packet was lost in the Reconnaissance Ph ase,
it will stop using Careful Resume it will stop using Careful Resume
and recover the loss using the normal loss recovery algorithm and normal CC. and recover the loss using the normal loss recovery algorithm and normal CC.
It is considered that the sender may have discovered a capacity limit and i t is not It is considered that the sender may have discovered a capacity limit and i t is not
allowed to continue to use Careful Resume. In this case, there is no cha nge to allowed to continue to use Careful Resume. In this case, there is no cha nge to
the CC algorithm and the CWND is the same as if Careful Resume had not been attempted.</t> the CC algorithm and the CWND is the same as if Careful Resume had not been attempted.</t>
</section> </section>
<section anchor="Examples-loss-unval">
<section anchor="Examples-loss-unval" title="Example with Loss detected in <name>Example with Loss Detected in the Validating Phase</name>
the Validating Phase">
<t>As in the first example, the sender enters the Unvalidated Phase with a CWND of 150 packets <t>As in the first example, the sender enters the Unvalidated Phase with a CWND of 150 packets
and with the PipeSize initialised to the flight_size (i.e., 29 packets). </t> and with the PipeSize initialised to the flight_size (i.e., 29 packets). </t>
<t>The sender now sends 121 unvalidated packets (consuming the remaining unused CWND). <t>The sender now sends 121 unvalidated packets (consuming the remaining unused CWND).
This example considers the case when one of the unvalidated packets is l ost. We assume This example considers the case when one of the unvalidated packets is l ost. We assume
in the example, that the lost packet is 64 (the 35th packet sent in the in the example that the lost packet is 64 (the 35th packet sent in the U
Unvalidated Phase).</t> nvalidated Phase).</t>
<t>The received ACKs acknowledge the reception of the first 34 unvalidat ed packets. <t>The received ACKs acknowledge the reception of the first 34 unvalidat ed packets.
The PipeSize at this time is equal to 63 (29 + 34) packets.</t> The PipeSize at this time is equal to 63 (29 + 34) packets.</t>
<t>A loss is then detected (by a timer or by receiving three ACKs that <t>A loss is then detected (by a timer or by receiving three ACKs that
do not acknowledge packet number 35). do not acknowledge packet number 35).
The sender then enters the Safe Retreat Phase because the CWND was not v alidated. The sender then enters the Safe Retreat Phase because the CWND was not v alidated.
The PipeSize at this point is equal to 63 (29 + 34) packets. Assuming th at the IW was 10 packets, The PipeSize at this point is equal to 63 (29 + 34) packets. Assuming th at the IW was 10 packets,
the CWND is reset to Max(10,PS/2) = Max(10,63/2) = 31 packets. the CWND is reset to Max(10,PS/2) = Max(10,63/2) = 31 packets.
This CWND is used during the Safe Retreat Phase, because congestion was detected and the This CWND is used during the Safe Retreat Phase, because congestion was detected and the
sender still does not yet know if the remaining unvalidated packets will be sender still does not yet know if the remaining unvalidated packets will be
successfully acknowledged. This conservative CWND calculation ensures th e sender drains successfully acknowledged. This conservative CWND calculation ensures th e sender drains
the path after this potentially severe congestion event. the path after this potentially severe congestion event.
There is no further increase in CWND in this phase.</t> There is no further increase in the CWND in this phase.</t>
<t>The sender continues to receive ACKs that acknowledge the remaining 8 6 (121-35) unvalidated packets. <t>The sender continues to receive ACKs that acknowledge the remaining 8 6 (121-35) unvalidated packets.
Recall that the 35th unvalidated packet was lost and had packet number 6 4 (29+35). Recall that the 35th unvalidated packet was lost and had packet number 6 4 (29+35).
The PipeSize tracks the The PipeSize tracks the
capacity discovered by ACKs that acknowledge the unvalidated packets (i. e., the PipeSize capacity discovered by ACKs that acknowledge the unvalidated packets (i. e., the PipeSize
is increased for each received ACK that acknowledges new data). is increased for each received ACK that acknowledges new data).
Although this PipeSize cannot be used to safety initialise the CWND (bec ause it was measured when the sender Although this PipeSize cannot be used to safety initialise the CWND (bec ause it was measured when the sender
had aggressively created overload), the estimated PipeSize had aggressively created overload), the estimated PipeSize
(which, in this case, is 121-1 = 120 packets) can be used to set the sst hresh on exit (which, in this case, is 121-1 = 120 packets) can be used to set the sst hresh on exit
from Safe Retreat, since it does indicate a measured upper limit to the current capacity.</t> from Safe Retreat, since it does indicate a measured upper limit to the current capacity.</t>
<t>At the point where all the unvalidated packets that were sent in the Unvalidated Phase <t>At the point where all the unvalidated packets that were sent in the Unvalidated Phase
have been either acknowledged have been either acknowledged
or have been declared lost, the sender updates the ssthresh to be no lar ger than the recently or have been declared lost, the sender updates the ssthresh to be no lar ger than the recently
measured PipeSize multiplied by Beta (the final action of the Safe Retre at Phase), and measured PipeSize multiplied by Beta (the final action of the Safe Retre at Phase), and
the sender stops using Careful Resume. the sender stops using Careful Resume.
Because CWND will now be less than ssthresh, a sender using normal CC is permitted to use Because the CWND will now be less than ssthresh, a sender using normal C C is permitted to use
Slow-Start to grow the CWND towards the ssthresh, Slow-Start to grow the CWND towards the ssthresh,
after which it will enter congestion avoidance.</t> after which it will enter congestion avoidance.</t>
</section> </section>
</section>
</section> <!--- Worked examples--> <section anchor="bbr">
<section anchor="bbr" title="Implementation Notes for using BBR"> <name>Implementation Notes for Using BBR</name>
<t>Bottleneck Bandwidth and Round-trip propagation time (BBR) uses recent
<t>Bottleneck Bandwidth and Round-trip propagation time (BBR) uses recent me measurements of a transport connection's delivery rate, Round Trip Time (RTT), a
asurements of a transport connection's delivery rate, round-trip time, and packe nd packet loss rate to build an explicit model of the network path. BBR then use
t loss rate to build an explicit model of the network path. BBR then uses this m s this model to control both how fast it sends data and the maximum volume of da
odel to control both how fast it sends data and the maximum volume of data it al ta it allows in flight in the network at any time <xref target="I-D.ietf-ccwg-bb
lows in flight in the network at any time<xref target="I-D.ietf-ccwg-bbr"></xref r"/>.</t>
>.</t> <t>When the flow is controlled using BBR <xref target="bbr"/>, Careful Res
ume is implemented
<t>When the flow is controlled using BBR <xref target="bbr"></xref>, Careful
Resume is implemented
by setting the pacing rate from the saved CC parameters, by setting the pacing rate from the saved CC parameters,
with the following precautions:</t> with the following precautions:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>The flag "carefully-resuming" is added to the BBR state <li>
to indicate that the sender is allowed to send unvalidated <t>The flag "carefully-resuming" is added to the BBR state to
packets. indicate that the sender is allowed to send unvalidated packets.
This is initialised to "False" when a BBR flow starts;</t> This is initialised to False when a BBR flow starts.</t>
<t>Prerequisites for using Careful Resume are described in </li>
<xref target="sec-phase-rec-phase"></xref>.</t> <li>
</list></t> <t>Prerequisites for using Careful Resume are described in
<xref target="sec-phase-rec-phase"/>.</t>
<section anchor="sec-phase-unval-bbr" title="Sending unvalidated packets usi </li>
ng BBR"> </ul>
<section anchor="sec-phase-unval-bbr">
<t>Careful Resume is allowed to transmit unvalidated packets <name>Sending Unvalidated Packets Using BBR</name>
<t>Careful Resume is allowed to transmit unvalidated packets
only when the BBR flow is in the Startup state.</t> only when the BBR flow is in the Startup state.</t>
<t>The probing rate is configured to 1/2 of the bottleneck
<t>The probing rate is configured to 1/2 of the bottleneck
bandwidth, derived from the CWND calculation specified in the bandwidth, derived from the CWND calculation specified in the
saved CC parameters according to the saved CC parameters according to the
requirements in <xref target="sec-phase-unv-phase"></xref>.</t> requirements in <xref target="sec-phase-unv-phase"/>.</t>
<t>The sender starts the Unvalidated Phase at the beginning of a BBR rou
<t>The sender starts the Unvalidated Phase at the beginning of a BBR roun nd,
d, and sets the "carefully-resuming" flags to True.
and sets the "carefully-resuming" flags to "True".
When this "carefully-resuming" flag is set, the BBR congestion When this "carefully-resuming" flag is set, the BBR congestion
controller sets the BBR pacing rate controller sets the BBR pacing rate
to the larger of the nominal pacing rate (BBR.bw multiplied bytes to the larger of the nominal pacing rate (BBR.bw multiplied bytes
BBRStartupPacingGain) or the calculated probing rate. BBRStartupPacingGain) or the calculated probing rate.
Then, CWND is set to the larger of BBR.bw Then, the CWND is set to the larger of BBR.bw
and the probing rate, multiplied by BBR.rtt_min times and the probing rate, multiplied by BBR.rtt_min times
BBRStartupCwndGain.</t> BBRStartupCwndGain.</t>
<t>The "carefully-resuming" flag is reset to False two rounds after it
<t>The "carefully-resuming" flag is reset to False two rounds after is set (i.e., after all the packets sent in the first round of
it is set, i.e., after all the packets sent in the first round "carefully resuming" have been received and acknowledged by the peer).
of "carefully resuming" At that stage (after the capacity has been validated), the measured
have been received and acknowledged by the peer. delivery rate is expected to reflect the probing rate.</t>
At that stage (after the capacity has been validated), <t>If congestion is detected while the "carefully-resuming" flag
the measured delivery rate is expected to reflect the probing rate.</
t>
<t>If congestion is detected while the "carefully-resuming" flag
is True, BBR exits the Startup state is True, BBR exits the Startup state
and enters the Drain state (implementing the Safe Retreat Phase). </t> and enters the Drain state (implementing the Safe Retreat Phase). </t>
</section> <!-- Unvalidated Phase for BBR --> </section>
<section anchor="sec-phase-val-bbr" title="Validation for BBR"> <section anchor="sec-phase-val-bbr">
<t>When using BBR, the Validation Phase is realised using the <name>Validation for BBR</name>
<t>When using BBR, the Validation Phase is realised using the
BBR rules for exiting Startup. Upon exiting Startup, the connection BBR rules for exiting Startup. Upon exiting Startup, the connection
estimates that the measured delivery rate will reflect the flow's share of estimates that the measured delivery rate will reflect the flow's share of
the actual bottleneck bandwidth. If congestion is detected the actual bottleneck bandwidth. If congestion is detected
while using Careful Resume (i.e, the "carefully-resuming" flag is True), while using Careful Resume (i.e, the "carefully-resuming" flag is True),
BBR then exits the Startup state and enters the Drain state.</t> BBR then exits the Startup state and enters the Drain state.</t>
</section> <!-- Validating Phase for BBR --> </section>
<section anchor="sec-BBR-SR" title="Safe Retreat for BBR">
<t>When using BBR, the Safe Retreat Phase is entered if the Drain <section anchor="sec-BBR-SR">
state is entered while the "carefully-resuming" flag (see <xref target="bbr"> <name>Safe Retreat for BBR</name>
</xref>) is still <t>When using BBR, the Safe Retreat Phase is entered if the Drain
True, i.e., if less than 2 full rounds have elapsed after state is entered while the "carefully-resuming" flag (see <xref target="bbr"/
the sender entered the Unvalidated Phase. The delivery rates measured in >) is still
True (i.e., if less than 2 full rounds have elapsed after
the sender entered the Unvalidated Phase). The delivery rates measured in
these conditions are tainted, because packets sent during the attempt these conditions are tainted, because packets sent during the attempt
are still queued at the bottleneck buffer and could have "pushed out" packets are still queued at the bottleneck buffer and could have "pushed out" packets
belong to any belonging to any
competing flows. Therefore any delivery rates measured in the Drain state competing flows. Therefore, any delivery rates measured in the Drain state
MUST be discarded if the "carefully-resuming" flag is set to True. <bcp14>MUST</bcp14> be discarded if the "carefully-resuming" flag is set to T
rue.
This flag is cleared upon exiting the Drain state.</t> This flag is cleared upon exiting the Drain state.</t>
</section> </section>
</section>
</section> <!-- End of define Implementation Notes for using BBR --> <section anchor="sec-acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="John Border"/>,
<contact fullname="Gabriel Montenegro"/>, <contact fullname="Patrick
McManus"/>, <contact fullname="Ian Swett"/>, <contact fullname="Igor
Lubashev"/>, <contact fullname="Robin Marx"/>, <contact fullname="Roland
Bless"/>, <contact fullname="Franklin Simo"/>, <contact fullname="Kazuho
Oku"/>, <contact fullname="Tong"/>, <contact fullname="Ana Custura"/>,
<contact fullname="Neal Cardwell"/>, <contact fullname="Marten
Seemann"/>, <contact fullname="Matthias Hofstaetter"/>, <contact
fullname="Nicolai Fischer"/>, <contact fullname="Yi Huang"/>, <contact
fullname="Mihail Yanev"/>, and <contact fullname="Joerg Deutschmann"/>
for their fruitful comments in developing this specification. They also
thank <contact fullname="Mike Bishop"/> for his careful suggestions on
the structure to describe the phases. Thanks also to <contact
fullname="Mohamed Boucadair"/> and to <contact fullname="Dan Harkins"/>
for his secdir review.</t>
<t>The authors would like to thank <contact fullname="Tom Jones"/> for
co-authoring previous draft versions of this document.</t>
</section>
<section anchor="rev" title="Internet Draft Revision details"> </back>
<t>RFC Editor -- please remove this section prior to publication.</t> <!-- [rfced] Please review whether any of the notes in this document
<t>Previous individual submissions were discussed in TSVWG and QUIC. should be in the <aside> element. It is defined as "a container for
<list> content that is semantically less important or tangential to the
<t>WG -00 included clarifications and restructuring to form the 1st WG d content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
raft.</t> .
<t>WG -01 included review comments and suggestions from John Border,
and follows the setting of the TSVWG milestone
with an intended status of "Proposed Standard".</t>
<t>WG -02 includes steps to complete the spec. In particular, considerat
ion of rate-limited
senders; selection of reasoned parameters; specification of the Safe Ret
reat Phase; and
improvements to the consistency throughout. Added the Validating Phase.<
/t>
<t>WG -03, explain entry to Validating Phase, editorial tidy.</t>
<t>WG -04, update based on review comments from Kazuho Oku.</t>
<t>WG-05, update based on review comments from Neal Cardwell. WG feedbac
k from IETF-118.
Reviewed the requirements v. guidelines; clarified that CC is not change
d in recon., but
the recon. info is used to steer the next phase; clarified saved_cwnd ca
n be computed
from ACK rate; use jump once; that real server platforms are complex.
Clarified lifetime for saved CC params. Incorporates comments from Tong.
</t>
<t>WG-06, SR updated following Hackathon comments from Kazuho Oku, and r
ework of use of PipeSize.
Added an informative summary of actions, on suggestion by Tong.
Added examples based on text by Ana Custura. </t>
<t>WG-07, Use "rate-limited" uniformly instead of application and data l
imited.</t>
<t>Updated to exit early when the unvalidated CWND not utilised,
detected in tests by Q Misell. Change
pipe_size to be PipeSize.</t>
<t>WG-08, Updated CDDL, and made constraints to Observing into guidance,
they say what
makes sense - but do not need to be followed for conformance. Updated ta
ble in the appendix to align
with text.</t>
<t>WG-09, Cleaning text to separate guidelines and specification
and adjust wording to improve clarity based on questions received during
implementation.
</t>
<t>WG-10, CH developed text to explain expected operation with BBR.
This also fixed some typos introduced in previous edits. Fix XML and fix
CDDL bugs for submission.</t>
<t>Changed the ssthresh value used after an exit of Safe Retreat to be (
PipeSize/2).</t>
<t>WG-11, JD fixed mistakes. GF clarified text. RS added that after SR,
ssthresh ought to match the behaviour of Cubic/Reno.
updated the text to be allow for an implementation to update CWND ahead of
entering
the Unvalidated Phase, and to clarify that the Unvalidated Phase starts
when the first
unvalidated packet is actually sent.</t>
<t>WG-12, JD, MH and GF clarified text, and checked for typos.</t>
<t>WG-13, After WGLC including NC and MK's review comments.</t>
<t>WG-14, removed qlog to a separate ID (LP), made relevant to other transp
orts (MK).</t>
<t>WG-15, fixes typos and aligns with new rev of the Qlog spec.</t>
<t>WG-16, updated after review by Kazuho, Nicolai Fischer and aligns with l
atest rev of the CR Qlog I-D.</t>
<t>WG-17, updated comments from Joerg Deutschman, harmonised use of "conges
tion detected" and mentions of ECN. Updated reference to PRR.bis.</t>
<t>WG-18, NiTs fixed to reconcile with logging in qlog. Removed "current_re
mote_endpoint" as requested by Doc Shepherd.</t>
<t>WG-19, after WG Shepherd review.</t>
<t>WG-20, after AD review. Requested renaming Normal Phase to normal CC; re
structured each phase to have a
consistent classification of events (with no intended change of algorithm).
</t>
<t>WG-21, fixed typos. </t>
<t>WG-22, updated following IETF-LC comment from Yi Huang. </t>
<t>WG-23, updated following IESG feedback. </t>
<t>WG-24, update requested by RFC-Ed to fix math error (from MY).</t>
</list></t>
</section> <!-- End of Revisions --> For example:
Note: To simplify the description, these examples are described using
packet numbers (whereas QLOG variables are expressed in bytes).
-->
<!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the comments
will be deleted prior to publication.
-->
<!-- [rfced] Terminology and abbreviations:
a) We note different uses of the terms below. Please review and let us know
if/how to update these terms for consistency.
Slow-Start
Slow Start
slow start
"slow start" mode
qlog
QLOG
b) Would you like to update instances of "Cubic" to "CUBIC" for consistency
with RFC 9438?
c) We note that abbreviations are introduced for the following two terms. Howeve
r,
this document switches between using their expanded and abbreviated forms
throughout. For consistency, should expansions of "Careful Resume" and
"Congestion Control" be updated to their respective abbreviations "CR" and
"CC" (after their abbreviations are first introduced)?
d) Where do you prefer to expand "ECN-CE" - upon first use in Section 3.1,
or add it to the list in Section 2.4?
Original (Section 3.1):
* Reconnaissance Phase (Detected congestion): If the sender detects
congestion (e.g., packet loss or ECN-CE marking), this indicates ...
Perhaps:
* Reconnaissance Phase (Detected congestion): If the sender detects
congestion (e.g., packet loss or Explicit Congestion Notification-
Congestion Experienced (ECN-CE) marking), this indicates ...
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether "traditional" should be updated in the
text below for clarity:
The Safe Retreat reaction differs from a traditional reaction to
Note that while the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
ibrary/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone. -->
</back>
</rfc> </rfc>
 End of changes. 305 change blocks. 
1231 lines changed or deleted 1369 lines changed or added

This html diff was produced by rfcdiff 1.48.