Internet-Draft QUIC BDP Signalling February 2024
Kuhn, et al. Expires 8 August 2024 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-kuhn-quic-bdpframe-extension-04
Published:
Intended Status:
Standards Track
Expires:
Authors:
N. Kuhn
Thales Alenia Space
E. Stephan
Orange
G. Fairhurst
University of Aberdeen
R. Secchi
University of Aberdeen
C. Huitema
Private Octopus Inc.

Signalling CC Parameters for Careful Resume using QUIC

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.

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:

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

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.

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

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 

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.

  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.

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.

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.

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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc9002>.
[RFC9040]
Touch, J., Welzl, M., and S. Islam, "TCP Control Block Interdependence", RFC 9040, DOI 10.17487/RFC9040, , <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
Emile Stephan
Orange
Godred Fairhurst
University of Aberdeen
Department of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Raffaello Secchi
University of Aberdeen
Department of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Christian Huitema
Private Octopus Inc.