Signalling CC Parameters for Careful Resume using QUIC
draft-kuhn-quic-bdpframe-extension-04

Internet Engineering Task Force                                  N. Kuhn
Internet-Draft                                       Thales Alenia Space
Intended status: Standards Track                              E. Stephan
Expires: 8 August 2024                                            Orange
                                                            G. Fairhurst
                                                               R. Secchi
                                                  University of Aberdeen
                                                              C. Huitema
                                                    Private Octopus Inc.
                                                         5 February 2024

         Signalling CC Parameters for Careful Resume using QUIC
                 draft-kuhn-quic-bdpframe-extension-04

Abstract

   This document describes an extension for QUIC.  This enables the
   exchange of Congestion Control (CC) parameters related to the path
   characteristics between the receiver and the sender during a
   connection.  These CC parameters allow a receiver to prepare to use
   additional capacity that is made available when using Careful Resume.
   It can also allow a receiver to request that previously computed CC
   parameters, are not used when the receiver has additional information
   about the current path or traffic that is to be sent.

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

   This Internet-Draft will expire on 8 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Kuhn, et al.              Expires 8 August 2024                 [Page 1]
Internet-Draft             QUIC BDP Signalling             February 2024

   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.  Three approaches  . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Example Cases where a Receiver might decide not to request
           use of saved CC Params  . . . . . . . . . . . . . . . . .   3
     1.3.  Example Cases where a Receiver might tune based on saved CC
           Params  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Notation and Terms  . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   3.  Signalling CC Parameters  . . . . . . . . . . . . . . . . . .   5
     3.1.  Extension Activation
           (enable_careful_resume_indication)  . . . . . . . . . . .   6
     3.2.  The CC Params . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Transporting the CC Params (careful_resume_indication)  .   7
     3.4.  Request to use the saved CC Params
           (careful_resume_request)  . . . . . . . . . . . . . . . .   8
     3.5.  Request to avoid using the saved CC Params
           (careful_resume_avoid)  . . . . . . . . . . . . . . . . .   8
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Use of the saved CC Params  . . . . . . . . . . . . . . .   8
     4.2.  Identifying the Path  . . . . . . . . . . . . . . . . . .  10
     4.3.  Example use of an Endpoint Token  . . . . . . . . . . . .  11
     4.4.  Security Topics Related to use of the Endpoint Token  . .  11
     4.5.  Using the CC Params with Care . . . . . . . . . . . . . .  12
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     7.1.  Protection from Malicious Receivers . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Kuhn, et al.              Expires 8 August 2024                 [Page 2]
Internet-Draft             QUIC BDP Signalling             February 2024

1.  Introduction

   This document extends the Careful Resume method
   [I-D.ietf-tsvwg-careful-resume] to allow sender-generated Congestion
   Control parameters (CC params) to be stored at the receiver, and used
   by a the sender to resume a subsequent connection.

   Transferring these CC Paremeters (CC params) to a receiver, can
   release the sender from needing to retain CC parameter state for each
   receiver.  The method also allows a receiver to implement a policy
   that informs a sender whether the receiver desires the sender to
   reuse previously saved CC params.

   This method specifies both sender and receiver changes.  If a sender
   does not support the method, it must ignore the requests made by the
   user.  It can independently decide whether to use Careful Resume.  If
   a receiver does not support the method, the sender does not receive
   any of the specified requests, and can independently decide whether
   to use Careful Resume.

1.1.  Three approaches

   This section identifies three approaches to implement the storage of
   CC params:

      (1) The saved CC params are stored at the sender ("Local
      storage").  They are not sent to a receiver, this does not use the
      method in this specification;

      (2) The saved CC params are transmitted to the receiver in an
      opaque record.  A receiver can choose to use the CC params when
      reconnecting, but is unable to read the value of the CC params;

      (3) The saved CC params are transmitted to a receiver, in a format
      that allows parameters to be read.  A receiver can choose to use
      CC params when reconnecting, and is able to read the value of the
      CC params to decide whether to accept or not the use of these
      parameters.

1.2.  Example Cases where a Receiver might decide not to request use of
      saved CC Params

   A receiver using approaches 2 or 3 can choose whether to request use
   or no of the saved CC params, based on local knowledge of the network
   conditions, connectivity, or connection requirements.

   Four cases are identified where Careful Resume would not be
   appropriate and using the saved CC params could increase congestion:

Kuhn, et al.              Expires 8 August 2024                 [Page 3]
Internet-Draft             QUIC BDP Signalling             February 2024

   1.  The network path has changed and the new path is different.  This
       might be evident from a change of local interface, a change in
       the sender IP address, or similar indication from the network.
       The saved CC params are not appropriate to the new path.

   2.  Measured data indicates a change in the network path
       characteristics, but the path has not changed.  This case might
       be indicated by a change in the RTT, or evident by loss observed
       at the start of the new connection.  (This case could also be
       detected in the Careful Resume Reconnaissance Phase.)  The saved
       CC params are no longer appropriate to use.

   3.  There is a notification that the path characteristics have
       changed and it is expected that the current capacity has reduced.
       Examples include: notification of changes in the link propagation
       conditions, notification of a change in the operational mode of a
       link, or awareness of a new limitation in the hardware platform.

   4.  The saved CC params are not within the stated LifeTime.  It is no
       longer reasonable to expect the path to have same
       characteristics.

   In all these examples, use of the saved CC params could increase
   congestion, and a receiver could wish to reject the use of the saved
   CC params.  The sender needs to return to the normal QUIC CC behavior
   [RFC9002].

1.3.  Example Cases where a Receiver might tune based on saved CC Params

   Where a receiver is aware it is using a path with a high Bandwidth-
   Delay Product (BDP), Using approach 3, it can also adapt other
   protocol parameters to better utilize the available capacity, e.g.,
   to estimate a larger size for the flow credit.

   Some designs of application do not use long-lasting transport
   connections.  Instead, they use a series of shorter connections,
   typically each using the same path.  This style of application can
   benefit when the receiver provides an estimate of the expected
   characteristics (e.g., to adapt the content of quality for a video
   application; or anticipate the time taken to complete the
   transmission of an object).  An example scenario considers a client
   using Dynamic Adaptive Streaming over HTTPS (DASH) that is unable to
   receive sufficient data to reach the desired video playback quality
   supported by the path, because for each video chunk, the video
   transport needs to independently determine the path capacity.  In
   this example, a lower transfer rate is safe, but could lead to an
   overly conservative requested rate when the rate is based on the
   video transport performance (i.e., the client could fail to increase

Kuhn, et al.              Expires 8 August 2024                 [Page 4]
Internet-Draft             QUIC BDP Signalling             February 2024

   the requested quality of video chunks, or to fill buffers to avoid
   stalling playback or to send high quality advertisements).  Using the
   CC param information, the client requests could be adapted based on
   the previously observed path characteristics, enabling a client to
   increase the requested quality of video chunks, to fill receiver
   buffers and avoid stalling playback.

   Even if the capacity on the forward and return paths can be
   significantly different, clients experiencing a high BDP for their
   forward path would typically also experience a high BDP for the
   return path.  The CC params related to the forward path could
   potentially be used to initially adjust the transmission of data
   using the return path.

2.  Notation and Terms

   *  BDP: Bandwidth Delay Product of the path (maximum path capacity);

   *  saved_cwnd: The capacity preserved from a previous connection,
      measured in bytes per RTT;

   *  saved_rtt: The preserved minimum RTT, corresponding to the minimum
      of a set RTT of measurements taken at the time when the saved_cwnd
      was estimated;

   *  LifeTime: The time at which CC params are no longer to be used;

   *  endpoint_token: An Endpoint Token for a receiver;

   *  secured hash: hash generated by the sender covering the list of CC
      params.  The sender uses a private key to protect this hash.

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.

   Variable-length integer encoding is defined in section 16 of
   [RFC9000].

3.  Signalling CC Parameters

   {XXX Editor Note: This presents the current transport method to
   signal use and to send CC params.  There are various alternatives and
   the final choice is to be confirmed.}

Kuhn, et al.              Expires 8 August 2024                 [Page 5]
Internet-Draft             QUIC BDP Signalling             February 2024

   The following subsections define four signals to carry transport
   control information.  The transmission of these signals is not
   limited by flow control limits of the underlying QUIC transport.  If
   a sender or receiver does not implement this specification, the
   signals MUST be ignored.

3.1.  Extension Activation (enable_careful_resume_indication)

   A receiver indicates its willingness to accept the transmission of
   careful_resume_indications from the sender by sending a
   enable_careful_resume_indication (0xTBD).  This is a transport
   parameter sent in the 1 RTT connection.

   *  0: Default value.  BY default the receiver does not support, or
      does not wish to activate, the transmission of indications.

   *  1: The value of 1 requests transmission of
      careful_resume_indications (enabled) to the receiver.  When the
      receiver activates the extension, it agrees to receive
      careful_resume_indications carrying CC params.

   *  All values larger than 1 are reserved for future use, and the
      receipt of these values MUST be treated as a connection error of
      type TRANSPORT_PARAMETER_ERROR [RFC9000].

   The encoding for this Transport Parameter is described in Section 18
   of [RFC9000].

   Note: This signal has no action when the sender does not support this
   specification.

3.2.  The CC Params

   CC_params {
     Lifetime (i),
     Saved Capacity (i),
     Saved RTT (i),
     Saved Endpoint Token (...)
   }

                     Figure 1: Format of the CC Params

   The CC params comprise the following fields:

   *  LifeTime (lifetime): The extension_lifetime is a timestamp in
      milliseconds, encoded as a variable-length integer.  This
      represents the validity in time of this extension.

Kuhn, et al.              Expires 8 August 2024                 [Page 6]
Internet-Draft             QUIC BDP Signalling             February 2024

   *  Saved CWND (saved_cwnd): The saved_cwnd is a value in bytes per
      RTT, encoded as a variable-length integer.  This is based on the
      available capacity estimated for a connection by the sender.

   *  Saved RTT (saved_rtt): The saved_rtt is a value in milliseconds,
      encoded as a variable-length integer.  The saved_rtt is set to the
      min_rtt.

   *  Saved Endpoint Token (saved_endpoint_token) : Note: The Endpoint
      Token is defined in [I-D.ietf-tsvwg-careful-resume], and is
      discussed in the context of this protocol exchange in a later
      section.

   Careful use of the CC params is discussed in
   [I-D.ietf-tsvwg-careful-resume].

3.3.  Transporting the CC Params (careful_resume_indication)

   This section describes the careful_resume_indication.  Once the
   extension has been activated, a sender MAY send a
   careful_resume_indication to the receiver with CC params during the
   Careful Resume Observe Phase.  A sender MAY update the CC params by
   sending additional careful_resume_indications within a connection.
   The rate of update SHOULD be limited (e.g., much less frequent than
   once for several RTTs).

   The format of a careful_resume_indication is shown in Figure 2, and
   the format for the CC params is specified in Section 3.2.

   BDP_FRAME {
     Type (i) = 0xXXX,
     Hash (...),
     CC_params,
   }

              Figure 2: Format of a Careful Resume Indication

   *  Hash (secured_hash): The secured_hash is generated by the sender
      using CC params.  The sender constructs the secured hash over the
      set of CC params.  A sender uses this hash to detect whether
      received CC params were modified.  A sender MUST verify the
      secured hash for the CC params, and MUST NOT use the CC params
      when it cannot verify the secured hash.

   Note: This signal ought not to be sent when the receiver did not
   request its use.

Kuhn, et al.              Expires 8 August 2024                 [Page 7]
Internet-Draft             QUIC BDP Signalling             February 2024

3.4.  Request to use the saved CC Params (careful_resume_request)

   This section describes the careful_resume_request.

   A receiver MAY send a careful_resume_request to the sender requesting
   use of saved CC params when the server is expected to be in the
   Careful Resume Reconnaissance Phase.  This returns a previously
   received set of CC params for the same pair of endpoints, using CC
   params structure.  This request is an input to the sender, and the
   decision to use or not use the CC params is taken by the sender.

   Note: A receiver ought to treat the transmission of this signal as an
   indication that the path may have a higher BDP, and therefore might
   accordingly allocate additional flow credit to prevent potential use
   of the Careful Resume method becoming limited by flow control.

   The format of a careful_resume_request is shown in Figure 2, and the
   format for the CC params is shown in Figure 1.

   Note: This signal has no action when the sender does not support this
   specification.

3.5.  Request to avoid using the saved CC Params (careful_resume_avoid)

   This section describes a signal to the sender that requests to avoid
   using the saved cc params.  No parameters are exchanged.  This is a
   transport parameter sent in the 1-RTT connection.  The sender
   determines whether to use or not Careful Resume.

   Note: This signal has no action when the sender does not support this
   specification.

4.  Discussion

4.1.  Use of the saved CC Params

Kuhn, et al.              Expires 8 August 2024                 [Page 8]
Internet-Draft             QUIC BDP Signalling             February 2024

              Sender                                 Receiver
                |                                       |
                | <-- enable_careful_resume_indication -|
                |                                       |
                |- careful_resume_indication -->        |
                        ...
                |                                       |
                |- careful_resume_indication -->        |
                        ...
                        Connection Terminates

                        New Connection

                |           <-- careful_resume_request -|
                            or
                |             <-- careful_resume_avoid -|

                         Figure 3: Sequence Diagram

   1.  When a receiver sends a enable_careful_resume_indication, a
       sender in the Observe Phase of the Careful Resume method is
       permitted to start sending CC params in a
       careful_resume_indication, transported to the receiver using the
       QUIC connection.  Each indication includes the current RTT,
       measured capacity, requested lifetime, and receiver Endpoint
       Token are computed and are respectively stored as the saved_rtt,
       saved_cwnd, LifeTime and saved_endpoint_token.  These form a set
       of CC params.  The sender also computes a secured hash over these
       CC params and includes this within the careful_resume_indication.

   2.  When transmitted, the careful_resume_indication is encrypted by
       QUIC transport using TLS [RFC8446] [RFC9001].  The secured hash
       is used by a sender to verify that the returned CC params were
       not modified by the receiver.

   3.  A receiver is unable to verify the hash and is not permitted to
       modify any CC params, but it is expected to store these params
       and their hash.  Access to this information would normally be
       indexed on the receiver's view of the path to the server.  It can
       read any non-encrypted CC params (see Section 1.3).

   4.  When the receiver makes a subsequent connection, it can send the
       CC params (and the saved hash) using a careful_resume_request to
       the sender at the start of a new connection.  These CC params
       need to be received during the Reconnaissance Phase of the
       Careful Resume method.

Kuhn, et al.              Expires 8 August 2024                 [Page 9]
Internet-Draft             QUIC BDP Signalling             February 2024

   5.  Upon reception, a sender MUST verify the hash, and only use the
       CC params when this is valid.  The Careful Resume method
       specifies the rules for utilizing verified CC params.

   6.  The receiver is permitted to utlize local information and then
       decide to send a careful_resume_request or a
       careful_resume_avoid.  The latter requests the sender does not
       use Careful Resume.  A receiver could alternatively decide to not
       send a careful_resume_request expressing no preference.

4.2.  Identifying the Path

   This extension is designed do not provide an opportunity for the
   current connection to be a vector for an amplification attack.  The
   QUIC address validation process, used to prevent amplification
   attacks, SHOULD be performed [RFC9000].

   An example implementation where the sender computes an Endpoint Token
   to uniquely identify the receiver is provided in Section 4.3.

   In a simple network scenario, the sending endpoint could use the IP
   source address to identify a path.  This could work when one
   globally-allocated IP address is set per interface.  There are many
   cases where the IP address would not an acceptable to identify a
   path.  Section 8 of [RFC9040] describes cases where the IP address is
   not a suitable value when performing TCP control block sharing.  In
   general the IP address of the sender is made public in the network-
   layer header of IP packets.  When sharing internal state, [RFC6973]
   identifies relevant privacy considerations.

   Examples of network uses where a source address is not a suitable
   endpoint token include:

   *  The sending endpoint might not be remotely identifiable from its
      IP address because a device on the network path translates the
      address using a form of NAT/NAPT.  In this case, a private IP
      address might be used, which does not identify a specific
      endpoint.

   *  In some cases, a sender can choose to vary the source address over
      time to avoid linkability in the observable IP header, e.g., when
      the source address embeds private information, such as an
      endpoint's MAC address/EIDID.

Kuhn, et al.              Expires 8 August 2024                [Page 10]
Internet-Draft             QUIC BDP Signalling             February 2024

   Note: There are use-cases where for the purpose of identifying a
   path, the token does not need to be globally unique, but needs to be
   sufficiently unique to prevent attempts to misrepresent the path
   being used such as an attack on the congestion controller.  Using a
   smaller size of token can add to the ambiguity set, reducing this
   likability.

   NOTE: A different Endpoint Token is used for each direction of
   transmission.  A receiver might decide not to provide an Endpoint
   Token to a sender, to avoid exposing additional link-able information
   (but also preventing use of any mechanism that relies on the token).

4.3.  Example use of an Endpoint Token

   The sender computes an Endpoint Token that seeks to uniquely identify
   the path that it uses to communicate with the receiver (1) this is
   associated with the path information it sends.  The Endpoint Token
   ought to be encrypted to avoid sending link-able information
   observable to eavesdroppers on the path.  The receiver stores the
   path information together with the Endpoint Token, together with the
   sender's address/name (2).  When the receiver later wishes the sender
   to use this, it returns the information to the sender (3) together
   with the Endpoint Token.  The sender recomputes the Endpoint Token
   and compares this with the received Endpoint Token before using the
   CC params.

   1.  The Sender transmits the Endpoint Token to the Receiver;

   2.  The Receiver holds an Endpoint Token;

   3.  The Receiver transmits the Endpoint Token to the Sender.

4.4.  Security Topics Related to use of the Endpoint Token

   A number of security-related topics have been identified concerning
   the potential exposure of the identity on the path.  This information
   can also be visible in the IP source address or higher-layer data,
   but can be hidden from a remote endpoint using methods such as MASQUE
   proxy.  When used to inform the transport system using a layered
   proxy, the transport endpoint token refers to the endpoints of the
   outer QUIC header, and hence the proxy itself, not the end-to-end
   communication relayed by the proxy.

Kuhn, et al.              Expires 8 August 2024                [Page 11]
Internet-Draft             QUIC BDP Signalling             February 2024

   A sender might decide to not use this method if it has a strong
   requirement to prevent flows being link-able with previous flows to
   the same endpoint.  A decision not to provide an Endpoint Token
   necessarily prevents the sender from requesting the receiver to
   return path information to allow the same CC parameters to be re-
   used, potentially strengthening privacy but consequently eliminating
   any performance benefits.

4.5.  Using the CC Params with Care

   Care is needed in the use of any temporal information to assure safe
   use of the Internet and to be robust to changes in traffic patterns,
   network routing and link/node failures.  There are cases where using
   the CC parameters of a previous connection are not appropriate, and a
   need to evaluate the potential for malicious use of this method.  The
   specification for the QUIC transport protocol [RFC9000] therefore
   notes "Generally, implementations are advised to be cautious when
   using previous values on a new path."

5.  Acknowledgments

   The authors thank Gabriel Montenegro, Patrick McManus, Ian Swett,
   Igor Lubashev, Robin Marx, Roland Bless, Franklin Simo, Kazuho Oku, Q
   Misell, and Marten Seeman for their fruitful comments on earlier
   versions of this document.

   The authors particularly thank Tom Jones for co-authoring previous
   versions of this document.

6.  IANA Considerations

   {XXX-Editor note: Text is required to register the four signals.
   Parameters are registered using the procedure defined in [RFC9000].}

7.  Security Considerations

   Security considerations for the CC method are discussed in the
   Security Considerations section of Careful Resume.

7.1.  Protection from Malicious Receivers

   The sender is required to check the integrity of the CC params using
   the hash computed over the block of CC params.  Whilst data in
   transit is protected by TLS, this has is intended to protect the data
   at rest at the receiver.  No specific hash algorithm is specified,
   because the value is only computed at the sender, and a sender can
   choose any suitable algorithm to meet its own security objectives.

Kuhn, et al.              Expires 8 August 2024                [Page 12]
Internet-Draft             QUIC BDP Signalling             February 2024

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

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

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

8.2.  Informative References

   [I-D.ietf-tsvwg-careful-resume]
              Kuhn, N., Emile, S., Fairhurst, G., Secchi, R., and C.
              Huitema, "Convergence of Congestion Control from Retained
              State", Work in Progress, Internet-Draft, draft-ietf-
              tsvwg-careful-resume-06, 19 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
              careful-resume-06>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/info/rfc9001>.

   [RFC9002]  Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
              and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
              May 2021, <https://www.rfc-editor.org/info/rfc9002>.

Kuhn, et al.              Expires 8 August 2024                [Page 13]
Internet-Draft             QUIC BDP Signalling             February 2024

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

Appendix A.  Change Log

   This section to be removed prior to publication.

      -00 Introduced session tickets and BDP_FRAMEs

      -01 Reviewed receiver actions when a receiver holds CC parameters

      -02 Interim version to align with terminology in Careful Resume

      -03 Rewritten to align with Careful Resume and use the BDP_FRAME
      method.  Removed annexe 1, and discussion of session tickets,
      preferring BDP_FRAMEs.

      -04 (1) To align with Careful Resume to use saved_cwnd, after
      review of CR from Neil Cardwell.  (2) To fix the alternative of
      using resumption tokens as proposed by Marten Seeman and Kazuho
      Oku.  (3) To detail the client point of view and associated use-
      cases.

      (4) Rewritten to clarify story and separately identify: format;
      transport; use; discussion.  This rev.  would also allow a change
      of transport method if the WG advises this.

      (5) Specify two control frames and two actions sending cc params.

Authors' Addresses

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

   Emile Stephan
   Orange
   Email: emile.stephan@orange.com

Kuhn, et al.              Expires 8 August 2024                [Page 14]
Internet-Draft             QUIC BDP Signalling             February 2024

   Godred Fairhurst
   University of Aberdeen
   Department of Engineering
   Fraser Noble Building
   Aberdeen
   AB24 3UE
   United Kingdom
   Email: gorry@erg.abdn.ac.uk

   Raffaello Secchi
   University of Aberdeen
   Department of Engineering
   Fraser Noble Building
   Aberdeen
   AB24 3UE
   United Kingdom
   Email: r.secchi@erg.abdn.ac.uk

   Christian Huitema
   Private Octopus Inc.
   Email: huitema@huitema.net

Kuhn, et al.              Expires 8 August 2024                [Page 15]