Careful Convergence of Congestion Control from Retained State
draft-ietf-tsvwg-careful-resume-01

Internet Engineering Task Force                                  N. Kuhn
Internet-Draft                                       Thales Alenia Space
Intended status: Standards Track                              E. Stephan
Expires: 6 January 2024                                           Orange
                                                            G. Fairhurst
                                                  University of Aberdeen
                                                              C. Huitema
                                                    Private Octopus Inc.
                                                             5 July 2023

     Careful Convergence of Congestion Control from Retained State
                   draft-ietf-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 Round Trip Time (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 6 January 2024                 [Page 1]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   This Internet-Draft will expire on 6 January 2024.

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:  . . . . . . . . . . . . . . . . . . .   9
     3.4.  Safe Retreat Phase  . . . . . . . . . . . . . . . . . . .   9
     3.5.  Normal Phase  . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Congestion Control Guidelines and Requirements  . . . . . . .  10
     4.1.  Determining the current Path Capacity in the Observe
           Phase . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Confirming the Path in the Reconnaissance Phase . . . . .  11
       4.2.1.  Confirming the Path . . . . . . . . . . . . . . . . .  11
     4.3.  Safety Requirements for the Unvalidated Phase . . . . . .  12
       4.3.1.  Exit for the Unvalidated Phase because of Variable
               Network Conditions  . . . . . . . . . . . . . . . . .  13
       4.3.2.  Pacing in the Unvalidated Phase . . . . . . . . . . .  13
     4.4.  Safety Requirements for the Safe Retreat Phase  . . . . .  14
     4.5.  Returning to Normal Congestion Control  . . . . . . . . .  14
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15

Kuhn, et al.             Expires 6 January 2024                 [Page 2]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Appendix: An Endpoint Token  . . . . . . . . . . . .  17
     A.1.  Creating an Endpoint Token  . . . . . . . . . . . . . . .  17
   Appendix B.  Summary  . . . . . . . . . . . . . . . . . . . . . .  18
   Appendix C.  Appendix: Revision details . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

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 mechanism targets these
   challenges.

   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 increase 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 behavior 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 6 January 2024                 [Page 3]
Internet-Draft   Careful Congestion Control Convergence        July 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 transferring the
   information to a receiver, it also releases the sender from needing
   to retain CC parameter state for each receiver.

Kuhn, et al.             Expires 6 January 2024                 [Page 4]
Internet-Draft   Careful Congestion Control Convergence        July 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 reduce the time to complete a transfer when
   the transfer sends 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 variant of this example is when the application reconnects after a
   disruption that had temporarily reduced the path capacity (e.g.,
   after 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 6 January 2024                 [Page 5]
Internet-Draft   Careful Congestion Control Convergence        July 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 6 January 2024                 [Page 6]
Internet-Draft   Careful Congestion Control Convergence        July 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;

   *  jump_cwnd: The resumed congestion window,used in the Unvalidated
      Phase.

   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 characterize 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.  One 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, and monitors its reception in the
   acknowledgements from the receiver.  This phase checks whether the
   current path is consistent with the saved path information.  The

Kuhn, et al.             Expires 6 January 2024                 [Page 7]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   sender measures the path characteristics of the present path to
   confirm that the path is consistent with the previously characterized
   path (including a similar RTT) Section 4.2.

      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
      acknowledged or congestion was detected, then 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.

   The Reconnaissance Phase calculates a jump_cwnd based on the saved CC
   parameters.  The correct reception of packets sent using the
   jump_cwnd is monitored during the Unvalidated Phase.

   To avoid starving other flows that started or increased their
   capacity after the Observation Phase, the sender MUST NOT set a
   jump_cwnd that corresponds to all the capacity that it previously
   used.

   {XXX-Editor note: 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 or 1/2 appropriate?  Could this be a
   MUST NOT for the part about not using the values without somehow
   curbing them, with maybe a SHOULD for a specific value?  Do we need
   to factor-in the degree of the indication?  This could be nice, but
   then it makes it even harder to pick something useful? }

   {XXX-Editor Note: It is possible that an implementation can start
   sending data using the jump_cwnd while still in the Reconnaissance
   Phase, before the all initial data is acknowledged.  In this method,
   the cwnd is increased for each new ACK received, in proportion to the
   acknowledged volume of initial data, i.e.
   cwnd+=(jump_cwnd*(acknowledged_bytes/Initial_Window)).  Transmission
   of this unvalidated data still requires pacing (see section XXX), and
   is tentative based on the rules for the Reconnaisance Phase.  This
   proprtional method reduces the impact of delayed acknowledgements,
   which could otherwise delay the start of transmisison using the
   jump_cwnd, it also reduces additional delay when the IW was paced.}

Kuhn, et al.             Expires 6 January 2024                 [Page 8]
Internet-Draft   Careful Congestion Control Convergence        July 2023

3.3.  Unvalidated Phase:

   In the Unvalidated Phase, a sender monitors the tentaive use of the
   updated CC parameters.  (These CC parameters are based on saved path
   information and allow 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 Safe Retreat Phase
      (see below).

   *  If acknowledgments show that the data sent at the unvalidated rate
      was successful without inducing significant congestion to the
      path, then the sender is permitted to continue at the rate in the
      Unvalidated Phase when it enters the Normal Phase.

3.4.  Safe Retreat Phase

   In the Safe 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-initialize 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 need
   be removed from any cache, to prevent the parameters being used again
   with other flows.

   When the sender transitions to the Safe Retreat Phase, there could
   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.

Kuhn, et al.             Expires 6 January 2024                 [Page 9]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   The sender then enters the Normal phase with re-initialized CC
   parameters.

3.5.  Normal Phase

   The sender continues transmisison using the normal CC method.

   If the sender experiences a 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.

   As in QUIC, a TCP sender is limited by the receiver window (rwnd).
   The rwnd may need to be increased for 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.

   *  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

Kuhn, et al.             Expires 6 January 2024                [Page 10]
Internet-Draft   Careful Congestion Control Convergence        July 2023

      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 sender 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.

   *  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.

Kuhn, et al.             Expires 6 January 2024                [Page 11]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   *  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 in the Reconnaissance Phase 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.

   *  The sender MUST NOT use the parameters if any packet sent in the
      IW is detected as lost or acknowledgments indicate these packets
      were ECN CE-marked.  The first indication of potential congestion
      therefore MUST result in a transition to the Normal Phase.

   {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.

   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.}

Kuhn, et al.             Expires 6 January 2024                [Page 12]
Internet-Draft   Careful Congestion Control Convergence        July 2023

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 Safe 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.

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.

   Identifing 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)

Kuhn, et al.             Expires 6 January 2024                [Page 13]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   This follows the idea presented in [RFC4782],
   [I-D.irtf-iccrg-sallantin-initial-spreading] and [CONEXT15].

4.4.  Safety Requirements for the Safe 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 needs to 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.

   {XXX-Editor note: A later revision will guide on the entering normal
   CC.}

   {XXX-Editor note: It would be good to have a discussing about
   updating the saved values, whether used or not, after reaching normal
   operation for use the next time even if that update is to just
   refresh the expiration time.}

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.

Kuhn, et al.             Expires 6 January 2024                [Page 14]
Internet-Draft   Careful Congestion Control Convergence        July 2023

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>.

   [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

Kuhn, et al.             Expires 6 January 2024                [Page 15]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   [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., Emile, S., 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/doc/html/draft-kuhn-quic-
              bdpframe-extension-02>.

   [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>.

Kuhn, et al.             Expires 6 January 2024                [Page 16]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   [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.  Appendix: 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 Token could 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 needs to include a unique identifier for itself (e.g., a
      globally assigned address/prefix; or randomly chosen value).

   *  it needs to include an identifier for the destination (e.g., a
      destination IP address or name).

   *  it needs to 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 information might
      improve the path differentiation, but that this can can reduce the
      re-usability of the token);

   *  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 ought to be encoded in a way that hides the component
       information from the recipient and any eavesdropper on the path.

Kuhn, et al.             Expires 6 January 2024                [Page 17]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   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

Appendix C.  Appendix: Revision details

   Previous individual submissions were discussed in TSVWG and QUIC.

      WG -00 included clarifications and restructuring to form the 1st
      WG draft.

      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".

Authors' Addresses

   Nicolas Kuhn
   Thales Alenia Space
   Email: nicolas.kuhn.ietf@gmail.com

Kuhn, et al.             Expires 6 January 2024                [Page 18]
Internet-Draft   Careful Congestion Control Convergence        July 2023

   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 6 January 2024                [Page 19]