Internet DRAFT - draft-kuhn-tsvwg-careful-resume
draft-kuhn-tsvwg-careful-resume
Internet Engineering Task Force N. Kuhn
Internet-Draft Thales Alenia Space
Intended status: Informational E. Stephan
Expires: 11 November 2023 Orange
G. Fairhurst
University of Aberdeen
C. Huitema
Private Octopus Inc.
10 May 2023
Careful convergence of congestion control from retained state
draft-kuhn-tsvwg-careful-resume-01
Abstract
This document specifies careful convergence of Congestion Control
(CC), providing a cautious method that enables fast startup for a
wide range of connections or reconnections.
The method reuses a set of computed CC parameters that are based on
the previously observed path characteristics between the same pair of
transport endpoints, such as the bottleneck bandwidth, available
capacity, or the RTT. These parameters are stored, allowing them to
be later used to modify the CC behavior of a subsequent connection.
The document also discusses assumptions and defines requirements
around how a sender utilizes these parameters to provide
opportunities for a connection to more quickly get up to speed (i.e.
utilize the available capacity). It discusses how these changes
impact the capacity at a shared network bottleneck and the safe
response that is needed after any indication that the new rate is
inappropriate. The method is expected to be appropriate to IETF
transports.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Kuhn, et al. Expires 11 November 2023 [Page 1]
Internet-Draft Careful congestion control convergence May 2023
This Internet-Draft will expire on 11 November 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Using the Information with Care . . . . . . . . . . . . . 4
1.2. Receiver Preference . . . . . . . . . . . . . . . . . . . 4
1.3. Examples of Scenarios of Interest . . . . . . . . . . . . 5
1.3.1. An Example of a Moving Endpoint . . . . . . . . . . . 5
1.3.2. A Satellite Access Network Example using QUIC . . . . 5
1.3.3. Another Network Example . . . . . . . . . . . . . . . 6
2. Language, notations and terms . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2.2. Use of CC Information collected by the Sender . . . . . . 6
2.3. Notations and Terms . . . . . . . . . . . . . . . . . . . 6
3. The Phases of CC using Careful Resume . . . . . . . . . . . . 7
3.1. Observe Phase . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Reconnaissance Phase . . . . . . . . . . . . . . . . . . 7
3.3. Unvalidated Phase: . . . . . . . . . . . . . . . . . . . 8
3.4. Retreat Phase . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Normal Phase . . . . . . . . . . . . . . . . . . . . . . 9
4. Congestion Control Guidelines and Requirements . . . . . . . 9
4.1. Determining the current Path Capacity in the Observe
Phase . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Confirming the Path in the Reconnaissance Phase . . . . . 10
4.2.1. Confirming the Path . . . . . . . . . . . . . . . . . 10
4.3. Safety Requirements for the Unvalidated Phase . . . . . . 11
4.3.1. Exit for the Unvalidated Phase because of Variable
Network Conditions . . . . . . . . . . . . . . . . . 12
4.3.2. Pacing in the Unvalidated Phase . . . . . . . . . . . 13
4.4. Safety Requirements for the Retreat Phase . . . . . . . . 13
4.5. Returning to Normal Congestion Control . . . . . . . . . 13
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Kuhn, et al. Expires 11 November 2023 [Page 2]
Internet-Draft Careful congestion control convergence May 2023
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Annexe: An Endpoint Token . . . . . . . . . . . . . 16
A.1. Creating an Endpoint Token . . . . . . . . . . . . . . . 16
Appendix B. Summary . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
All Internet transports are required to either use a CC method, or to
constrain their rate of transmission [RFC8085]. In 2010, a survey of
alternative CC methods [RFC5783], noted that there are challenges
when a CC operates across an Internet path with a high and/or
variable bandwidth-delay product (BDP), this mechanisms targets this
challenge.
A CC method typically takes time to ramp-up the packet rate, called
the "slow-start phase", informally known as the time to "Get up to
speed". This slow start phase is a period in which a sender
intentionally uses less capacity than might be available, with the
intention to avoid or limit overshooting the actual capacity at a
bottleneck. This can result in increased queuing (latency/jitter)
and/or congestion packet loss to the flow. Any overshoot in the
capacity can also have a detrimental effect on other flows sharing a
common bottleneck. In the extreme case, persistent congestion could
result in unwanted starvation of other flows [RFC8867] (i.e.,
Preventing other flows from successfully sharing a common
bottleneck).
The method can improve performance by reducing the time to get up to
speed, and hence can reduce the total duration of a transfer. It
introduces an alternative method to select initial CC parameters,
including a way to more rapidly and safely grow the congestion window
(cwnd). This method is based on temporal sharing (sometimes known as
caching) of a set of computed CC parameters that relate to a
previously observed path, such as the bottleneck bandwidth, available
capacity, and RTT. These parameters are stored and used to modify
the CC behaviour of a subsequent connection between the same local
and remote endpoints.
When used with the QUIC transport, it provides transport services
that resemble those currently available in TCP, such as TCP Control
Block (TCB) [RFC9040] caching or updates to support application-
limited traffic.
Kuhn, et al. Expires 11 November 2023 [Page 3]
Internet-Draft Careful congestion control convergence May 2023
1.1. Using the Information with Care
"Generally, implementations are advised to be cautious when using
previous values on a new path", as stated in [RFC9000]. This advice
is appropriate for any IETF transport protocol.
Care is therefore needed in the use of any temporal information to
assure safe use of the Internet and to be robust to changes in
traffic patterns, network routing and link/node failures. There are
also cases where using the parameters of a previous connection are
not appropriate, and a need to evaluate the potential for malicious
use of the method.
1.2. Receiver Preference
Whilst a sender could take optimization decisions without considering
the receiver's preference, there are cases where a client at the
receiver could have information that is not available at the sender.
In these cases, a client could explicitly ask for tuning the slow
start when the application continues transmission, or to to inhibit
tuning. Examples where this could have benefit include:
1. when a receiver understands that the pattern of traffic that a
connection will use is different (e.g., the volume of data to be
sent, the length of the session, or the maximum transfer rate
required);
2. when a receiver has a local indication that the path/local
interface has changed since CC parameters were stored;
3. when there is information related to the current hardware
limitations at the receiver;
4. where the receiver understands the capacity that will be needed
for other concurrent flows that might be expected to share the
capacity of the path.
A related document complements this CC method by allowing the sender-
generated transport information to be stored at the receiver
[I-D.kuhn-quic-bdpframe-extension]. This enables a receiver to
implement a policy that informs a sender whether the receiver desires
the sender to reuse the CC parameters. By transfering the
information to a receiver, it also releases the sender from needing
to retain CC parameter state for each receiver.
Kuhn, et al. Expires 11 November 2023 [Page 4]
Internet-Draft Careful congestion control convergence May 2023
1.3. Examples of Scenarios of Interest
This section provides a set of examples where the method is expected
to improve performance.
The method is expected to have benefit when a transfer sendd
significantly more data than allowed by the IW, and the BDP is also
significantly more than the IW.
An application could use a series of connections over the same path
(i.e. resumes a connection to the same endpoint). This can be used
by a sender that performs a unidirectional data transfer towards the
receiver, (e.g., a receiver downloading a file or a web page).
Without the method, each connection would otherwise need to
individually discover the CC parameters.
Either or both endpoints can assume the role of a sender or a
receiver. The method supports a bidirectional data transfer, where
both endpoints simultaneously send data to each other (e.g., remote
execution of an application, or a bidirectional video conference
call).
1.3.1. An Example of a Moving Endpoint
In this example, an application resumes using capacity after a pause
in transmission. Without the method, the application that pauses
would otherwise need to discover new CC parameters each time it
connects to the same endpoint.
A varient of this exmaple is when the application reconnects after a
disruption that had temporarily reduced the path capacity (e.g.,
after to a link propagation impairment, or where a user on a train
journey travels through different areas of connectivity) before the
endpoint returns to use a path with the original characteristics.
1.3.2. A Satellite Access Network Example using QUIC
QUIC introduces the concept of transport parameters (Section 4 of
[RFC9000]). The present document adds to this by noting that a new
connection can utilize a set of key transport parameters from a
previous connection to reduce the completion time for a transfer.
This benefit is particularly evident for a path where the RTT is much
larger than for typical Internet paths. In a specific example of
high BDP path, a satellite access network, takes up to 9 seconds to
complete a 5.3 MB transfer using standard CC, whereas using the
specified method the transfer time could reduce to 4 seconds [IJSCN];
and the time to complete a 1 MB transfer could be reduced by 62 %
Kuhn, et al. Expires 11 November 2023 [Page 5]
Internet-Draft Careful congestion control convergence May 2023
[MAPRG111]. Benefit is also expected for other sizes of transfer and
for different path characteristics that also result in a path with
high BDP.
1.3.3. Another Network Example
{XXX-Editor note: A future revision can provide further Path Examples
here.}
2. Language, notations and terms
This section provides a brief summary of key terms and the
requirements language that is used.
2.1. Requirements Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Use of CC Information collected by the Sender
Sender-generated information is used in this document for two
functions:
Information to characterize the saved path, to allow a sender to
establish if the saved information indicates the saved path is
consistent with the current path.
Information about the capacity that was available on a saved path,
to allow a later sender to determine an appropriate set of CC
parameters for its current path.
2.3. Notations and Terms
The document uses language drawn from a range of IETF RFCs. It
defines current, and saved values for a set of CC parameters:
* current_bb : The current estimated bottleneck bandwidth;
* saved_bb: The estimated bottleneck bandwidth preserved from a
previous connection;
* current_rtt: The current RTT;
* saved_rtt: The measured RTT, preserved from a previous connection;
Kuhn, et al. Expires 11 November 2023 [Page 6]
Internet-Draft Careful congestion control convergence May 2023
* endpoint_token: The Endpoint Token of the receiver;
* current_endpoint_token: The current Endpoint Token of the
receiver;
* saved_endpoint_token: The Endpoint Token of a previous connection
by the receiver;
* remembered BDP parameters: A combination of the saved_rtt and
saved_bb.
The Endpoint Token is described in Appendix A.
3. The Phases of CC using Careful Resume
This section defines a series of phases that the CC algorithm moves
through as a connection gets up to speed when it uses the Careful
Resume method.
3.1. Observe Phase
During a previous connection, information about the specific path to
an endpoint is saved. This is used to characterise the path and to
indicate the capacity that was available. It includes the current
RTT (current_rtt), bottleneck bandwidth (current_bb) and current
receiver Endpoint Token (current_endpoint_token) stored as saved_rtt,
saved_bb and saved_endpoint_token Section 4.1. An implementation
solution could be to store the information at the server. Different
implementation solutions are detailed in
[I-D.kuhn-quic-bdpframe-extension].
3.2. Reconnaissance Phase
When a sender resumes between the same pair of endpoints, (aka the
same path) it enters the Reconnaissance Phase. The sender only
enters this phase when there are saved CC parameters for the same
pair of endpoints and this information is currently valid (i.e., the
parameters have not expired.) When a method is provided (such as the
BDP_Frame), a receiver can request the sender to not enter this
phase.
In the Reconnaissance Phase, the sender sends initial data, limited
by the Initial Window. This phase checks whether the current path is
consistent with the saved path information. The sender measures the
path characteristics of the present path to confirm that the path is
consistent with the previously characterised path (including a
similar RTT) Section 4.2.
Kuhn, et al. Expires 11 November 2023 [Page 7]
Internet-Draft Careful congestion control convergence May 2023
If the sender determines that the path RTT or the other saved path
information are not consistent with the current path, then the
sender continues using the standard CC, and enters the Normal
Phase.
To ensure a sender avoids resuming under severely congested
conditions, if any sent initial data was not correctly received,
the sender continues using the standard CC, and enters the Normal
Phase.
If the sender confirms both that the saved and current path
information are consistent and that the sent initial data was
correctly received, the sender enters the Unvalidated Phase.
3.3. Unvalidated Phase:
In the Unvalidated Phase, a sender can utilize the saved path
information to update its CC parameters. This phase allows a rate
higher than allowed by a traditional slow-start mechanism. The
convergence towards the previous rate is expected to be faster, but
should not be instantaneous, to avoid adding congestion to an already
congested bottleneck. In this phase, the sender continues to check
the saved and current path information are consistent Section 4.3.
* If a sender determines either that previous parameters are not
valid (due to a detected change in the path) or congestion was
experienced, then the sender needs to enter the Retreat Phase (see
below).
* If acknowledgments show that the unvalidated rate was succesfully
used without inducing significant congestion to the path, then the
sender is permitted to continue at the rate used in in the
unvalidated phase when it continues in the Normal Phase.
3.4. Retreat Phase
In the Retreat Phase, the sender stops using the saved CC parameters.
This phase is designed to mitigate the impact on other flows that
might have been sharing a congested bottleneck when in the
Unvalidated Phase. The sender needs to re-initialise CC parameters
to drain any queue that has built at the bottleneck during the
Unvalidated Phase and allow other flows to then regain their share of
the available capacity. This reaction differs to a traditional CC
reaction to congestion, because in this case the capacity estimate
was unvalidated Section 4.4. Saved CC parameters for this path
should be removed from any cache, to prevent the parameters being
used again with other flows.
Kuhn, et al. Expires 11 November 2023 [Page 8]
Internet-Draft Careful congestion control convergence May 2023
When the sender transitions to the Safe Retreat Phase, there may
still be packets that were sent in the Unvalidated Phase that have
not yet been acknowledged. If these packets from the Unvalidated
Phase are declared lost, they do not trigger an additional CC
reaction.
If the data in the packets that are lost in the Unvalidated Phase
needs to be recovered, this recovery commences using the reduced
window set on entry to the Safe Retreat Phase. In the case of
multiple loss, this could require multiple RTTs to complete
successful resending of data that lost in the Unvalidated Phase. The
loss of the packets used to resend data is considered a separate
congestion event, and this does also trigger another CC reaction.
The sender then enters the Normal phase with re-initialised CC
parameters.
3.5. Normal Phase
The sender resumes using the normal CC method.
If the sender experiences an Retransmission Time Out (RTO) expiry,
the sender returns to the normal CC phase and processes the RTO
expiry.
4. Congestion Control Guidelines and Requirements
The sender is limited by any rate-limitation of the transport
protocol being used. For QUIC this includes: flow control mechanisms
or amplification attack prevention. In particular, a QUIC receiver
might need to issue proactive MAX_DATA frames to increase the flow
control limits of a connection that is started with this method to
gain the expected benefit.
4.1. Determining the current Path Capacity in the Observe Phase
Congestion controllers, such as CUBIC or RENO, can estimate the
saved_bb and current_bb values by utilizing a combination of the
cwnd/flight_size and the minimum RTT. A different method could be
used to estimate the same values when using a rate-based congestion
controller, such as BBR [I-D.cardwell-iccrg-bbr-congestion-control].
* Observe Phase: The sender SHOULD NOT store and/or send CC
parameter information related to an estimated bottleneck bandwidth
(saved_bb) (see Section 2.3 for more details on bottleneck
bandwidth definition), if the cwnd is not at least four times
larger than the IW.
Kuhn, et al. Expires 11 November 2023 [Page 9]
Internet-Draft Careful congestion control convergence May 2023
* Observe Phase: The sender SHOULD update the stored CC parameters
and/or send updated CC parameter information related to an
estimated bottleneck bandwidth (saved_bb) (see Section 2.3 for
more details on bottleneck bandwidth definition), if there are
significant changes in the CC parameters that the session has
measured. The rate of the updates transmission SHOULD be limited
to at most one update for several RTTs of time.
* Observe Phase: There are cases where the current cwnd does not
reflect the bottleneck bandwidth. At the end of the CC slow start
phase, the value of cwnd can be significantly larger than the
minimum value needed to utilize the path (i.e., a cwnd overshoot).
In most case, the cwnd finally converges to a stable value after
several more RTTs. It would be inappropriate to use an overshoot
in the cwnd as a basis for estimating the bottleneck bandwidth.
NOTE: One mitigation could be to further restrict to only a
fraction (e.g., 1/2) of the previously used cwnd; another
mitigation might be to calculate the bottleneck bandwidth based on
the flight_size or an averaged cwnd.
4.2. Confirming the Path in the Reconnaissance Phase
The sender sends initial data limited by the IW - this value is
assumed a safe starting point for any path where there is no path
information or congestion control information. This limit avoids
adding excessive congestion to a potentially congested path.
The sender monitors the reception of the initial data. If the path
characteristics resemble those of a previously observed connection
(i.e., current_rtt < 1.2*saved_rtt) and all data was acknowledged
without reported congestion, the method permits the sender to utilize
the saved_bb as an input to adapt current_bb to rapidly determine a
new safe rate.
* Reconnaissance Phase: A snder MUST limit the initial data, sent in
the first RTT of transmitted data, to not more than the IW
[RFC9000].
When used in a controlled network, additional information about local
path characteristics could be known, which might be used to configure
a non-standard IW.
4.2.1. Confirming the Path
Paths can change with respect to time for many reasons. This could
result in previously measured CC parameters becoming irrelevant.
Kuhn, et al. Expires 11 November 2023 [Page 10]
Internet-Draft Careful congestion control convergence May 2023
* Endpoint Token change: If the Endpoint Token changes (i.e., the
saved_endpoint_token is different from the
current_endpoint_token), the different Endpoint Token can be
assumed as an indication of a different network path. This new
path does not necessarily exhibit the same characteristics as the
old one.
* RTT change: A significant change in RTT is regarded as an
indication that the network conditions have changed. Since the CC
information is directly impacted by the RTT, a significant change
in the RTT is a strong indication that the previously estimated
BDP parameters are likely to not be valid for the current path.
* Lifetime of the information: The CC information is temporal.
Frequent connections to the same endpoint are likely to track
changes, but long-term use of previous values is not appropriate.
{NOTE: A future revision of this document needs to specify how long
CC Parameters can be cached, possibly based on TCP-new-CWV or TCB}.
* Reconnaissance Phase: The sender MUST compare the measured
transport parameters (in particular current_rtt) of the new
session with those of the previous session (in particular
saved_rtt). The method MUST NOT be used when the path fails to be
validated.
* Reconnaissance Phase: The sender MUST NOT use the parameters
unless the first IW packets when packets are detected as lost or
acknowledgments indicate the packets were ECN CE-marked. These
are indication of potential congestion and therefore the method
MUST NOT be used;
{XXX-Editor-note: RTT check should be a range rather than an
inequality (current_rtt < 1.2*saved_rtt).}
4.3. Safety Requirements for the Unvalidated Phase
This section defines the safety requirements for using saved CC
parameters to update the cwnd. These safety guidelines are designed
to mitigate the risk that sender adds excessive congestion to an
already congested path.
Kuhn, et al. Expires 11 November 2023 [Page 11]
Internet-Draft Careful congestion control convergence May 2023
{XXX-Editor note: The sender ought not to re-utilize all the capacity
it previously used, to avoid starving other flows that started or
increased their capacity after the last measurement. How strong
should this be stated: ... MUST or SHOULD ... What safety factor is
appropriate for the resuming sender? If using slow-start it would
anyway double the rate on the next RTT, so is capacity*2/3
appropriate to initially try?}
The method needs to be designed to avoid sending excessive data into
a congested bottleneck, because this can have a material impact on
any flows sharing that bottleneck, and the ability of those flows to
control their own sending rate.
* Unvalidated Phase: A new connection MUST NOT directly use the
previously measured saved_rtt and saved_bb to simply initialize a
new flow to resume sending at the same rate. The method needs to
set cwnd less than or equal to 2/3 the previous value
{NOTE: A later revision needs to define how to decide a significant
change.}
4.3.1. Exit for the Unvalidated Phase because of Variable Network
Conditions
The network conditions for the same path can also change over time.
Bottleneck bandwidth and network traffic can change at any time. An
Internet method needs to be robust to network conditions that can
differ from one connection to the next, due to variations in the
forwarding path, reconfiguration of equipment or changes in the link
conditions.
* Unvalidated Phase: Careful Resume MUST be robust to changes in
network traffic, including the arrival of new traffic flows that
compete for the bottleneck capacity.
* Unvalidated Phase: Preventing Starvation of New Flows. It would
not be appropriate to fully use a bottleneck bandwidth estimate
based on a previous measurement of capacity, because new flows
might have started using the available capacity since that
measurement was made. The mitigation could be to restrict to only
a fraction (e.g., 1/2) of the previously used cwnd.
* Unvalidated Phase: The sender MUST transition to the Retreat Phase
when packets are detected as lost or acknowledgments indicate the
packets were ECN CE-marked. These are indication of potential
congestion and therefore the method is not used.
Kuhn, et al. Expires 11 November 2023 [Page 12]
Internet-Draft Careful congestion control convergence May 2023
4.3.2. Pacing in the Unvalidated Phase
The sender needs to avoid sending a burst of packets as a result of a
step-increase in the congestion window [RFC8085], [RFC9000]. Various
modifications to the sender to avoid line-rate bursts have been
suggested (e.g., [I-D.hughes-restart]). Pacing the packets as a
function of the current_rtt can provide this additional safety during
the unvalidated period.
Identify a relevant pacing rhythm:
* The sender estimates a pacing rhythm using saved_rtt and saved_bb.
The Inter-packet Transmission Time (ITT) is determined from the
ratio between the current Maximum Message Size (MMS) and the ratio
between the saved_bb and saved_rtt. A tunable safety margin can
avoid sending more than a recommended maximum IW (recom_iw):
- current_iw = min(recom_iw,saved_bb)
- ITT = MSS/(current_iw/saved_rtt)
This follows the idea presented in [RFC4782],
[I-D.irtf-iccrg-sallantin-initial-spreading] and [CONEXT15].
4.4. Safety Requirements for the Retreat Phase
This section defines the safety requirements after a path change or
congestion has been detected during the Unvalidated Phase.
The transport parameters are adjusted in the Unvalidated Phase,
resulting in a higher cwnd. If there are indications of congestion,
this also indicates that the parameters no longer reflect the current
path, and the cwnd must be reduced to avoid overshoot of the
bottleneck capacity. This can result from changes in traffic at the
bottleneck and/or changes in the path capacity.
{XXX-Editor note: A later revision will guide on the mitigation after
detected congestion.}
4.5. Returning to Normal Congestion Control
The CC controller returns to the Normal Phase.
* For NewReno and CUBIC, it is recommended to exit slow-start and
enter the congestion avoidance phase.
* For BBR CC, it is recommended to enter the "probe bandwidth"
state.
Kuhn, et al. Expires 11 November 2023 [Page 13]
Internet-Draft Careful congestion control convergence May 2023
{XXX-Editor note: A later revision will guide on the entering normal
CC.}
5. Acknowledgments
The authors would like to thank John Border, Gabriel Montenegro,
Patrick McManus, Ian Swett, Igor Lubashev, Robin Marx, Roland Bless
and Franklin Simo for their fruitful comments on earlier versions of
this document.
The authors would like to particularly thank Tom Jones for co-
authoring previous versions of this document.
6. IANA Considerations
{XXX-Editor note: Text is required to register any IANA
Considerations.
7. Security Considerations
This document does not exhibit specific security considerations since
only sender level considerations are proposed. Security
considerations for the interactions with the receiver are discussed
in [I-D.kuhn-quic-bdpframe-extension].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Kuhn, et al. Expires 11 November 2023 [Page 14]
Internet-Draft Careful congestion control convergence May 2023
[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/info/rfc8801>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9040] Touch, J., Welzl, M., and S. Islam, "TCP Control Block
Interdependence", RFC 9040, DOI 10.17487/RFC9040, July
2021, <https://www.rfc-editor.org/info/rfc9040>.
8.2. Informative References
[CONEXT15] Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running
Short Flows Quickly and Safely", ACM CoNEXT , 2015.
[I-D.cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-02, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-02>.
[I-D.hughes-restart]
Hughes, A., "Issues in TCP Slow-Start Restart After Idle",
Work in Progress, Internet-Draft, draft-hughes-restart-00,
30 November 2001, <https://datatracker.ietf.org/doc/html/
draft-hughes-restart-00>.
[I-D.irtf-iccrg-sallantin-initial-spreading]
Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput,
E., and A. Beylot, "Safe increase of the TCP's Initial
Window Using Initial Spreading", Work in Progress,
Internet-Draft, draft-irtf-iccrg-sallantin-initial-
spreading-00, 15 January 2014,
<https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-
sallantin-initial-spreading-00>.
[I-D.kuhn-quic-bdpframe-extension]
Kuhn, N., Stephan, E., Fairhurst, G., and C. Huitema, "BDP
Frame Extension", Work in Progress, Internet-Draft, draft-
kuhn-quic-bdpframe-extension-02, 10 May 2023,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
kuhn-quic-bdpframe-extension/>.
Kuhn, et al. Expires 11 November 2023 [Page 15]
Internet-Draft Careful congestion control convergence May 2023
[IJSCN] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google
QUIC performance over a public SATCOM access",
International Journal of Satellite Communications and
Networking 10.1002/sat.1301, 2019.
[MAPRG111] Kuhn, N., Stephan, E., Fairhurst, G., Jones, T., and C.
Huitema, "Feedback from using QUIC's 0-RTT-BDP extension
over SATCOM public access", IETF 111 - MAPRG meeting ,
2022.
[RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC
Series", RFC 5783, DOI 10.17487/RFC5783, February 2010,
<https://www.rfc-editor.org/info/rfc5783>.
[RFC8867] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating Congestion Control for Interactive
Real-Time Media", RFC 8867, DOI 10.17487/RFC8867, January
2021, <https://www.rfc-editor.org/info/rfc8867>.
Appendix A. Annexe: An Endpoint Token
This proposes an Endpoint Token to allow a sender to identify its own
view of the network path that it is using. In
[I-D.kuhn-quic-bdpframe-extension] this Endpoint Tokencould be shared
and used as an opaque path identifier to other parties and the sender
can verify if this is one of its current paths.
A.1. Creating an Endpoint Token
When computing the Endpoint Token, the sender includes information to
identify the path on which it sends, for example:
* it must include a unique identifier for itself (e.g., a globally
assigned address/prefix; or randomly chosen value).
* it must include an identifier for the destination (e.g., a
destination IP address or name).
* it must include an interface identifier (e.g., an index value or a
MAC address to associate the endpoint with the interface on which
the path starts);
* it could include other information such as the DSCP, ports, flow
label, etc (recognising that this additional infromation might
improve the path differentiation, but that this can can reduce the
re-usability of the token);
Kuhn, et al. Expires 11 November 2023 [Page 16]
Internet-Draft Careful congestion control convergence May 2023
* it could include any other information the sender chooses to
include, and potentially including PvD information [RFC8801] or
information relating to its public-facing IP address;
* it could include a nonce;
* it could include a time-dependent value to define the validity
period of the token.
When creating an Endpoint Token, the sender has to ensure the
following:
1. To reduce the likelihood of misuse of the Endpoint Token, the
value should be encoded in a way that hides the component
information from the recipient and any eavesdropper on the path.
2. The sender can recalculate the Endpoint Token if it needs to
validate a previously issued token; and that the Endpoint Token
itself can be included in the computed integrity check for any
path information it provides.
3. The Endpoint Token is designed so that if shared, it prevents
another party from deriving private data from the token, or to
use the token to perform unwanted likability with other
information. This implies that the Endpoint Token MUST
necessarily be different when used to identify paths using
different interfaces.
Appendix B. Summary
+---------+-----------+----------------+---------------+-----------+
|Rationale| Solution | Advantage | Drawback | Comment |
+---------+-----------+----------------+---------------+-----------+
|#1 |#1 | | | |
|Variable |set |Ingress optim. |Risk of adding |MUST NOT |
|Network |current_* | | congestion |implement |
| |to saved_* | | | |
| +-----------+----------------+---------------+-----------+
| |#2 | | | |
| |Implement |Reduce risk of |Negative impact|MUST |
| |safety | adding | on ingress |implement |
| |check | congestion | optim. |Section 3 |
+---------+-----------+----------------+---------------+-----------+
Figure 1: Comparing Careful Resume solutions
Authors' Addresses
Kuhn, et al. Expires 11 November 2023 [Page 17]
Internet-Draft Careful congestion control convergence May 2023
Nicolas Kuhn
Thales Alenia Space
Email: nicolas.kuhn.ietf@gmail.com
Emile Stephan
Orange
Email: emile.stephan@orange.com
Godred Fairhurst
University of Aberdeen
Department of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
Christian Huitema
Private Octopus Inc.
Email: huitema@huitema.net
Kuhn, et al. Expires 11 November 2023 [Page 18]
