]> Thales Alenia Space

nicolas.kuhn.ietf@gmail.com

Orange

emile.stephan@orange.com

University of Aberdeen

Department of Engineering Fraser Noble Building Aberdeen AB24 3UE UK gorry@erg.abdn.ac.uk

University of Aberdeen

Department of Engineering Fraser Noble Building Aberdeen AB24 3UE UK r.secchi@erg.abdn.ac.uk

Private Octopus Inc.

huitema@huitema.net

Transport Internet Engineering Task Force QUIC, CC, careful resume 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.

This document extends the Careful Resume method 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.

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.

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

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.

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.

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 when, and only when, they appear in all capitals, as shown here. Variable-length integer encoding is defined in section 16 of .

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

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 . The encoding for this Transport Parameter is described in Section 18 of . Note: This signal has no action when the sender does not support this specification.

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

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 , and is discussed in the context of this protocol exchange in a later section. Careful use of the CC params is discussed in .

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 , and the format for the CC params is specified in .

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

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.

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 , and the format for the CC params is shown in . Note: This signal has no action when the sender does not support this specification.

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.

| ... | | |- careful_resume_indication --> | ... Connection Terminates New Connection | <-- careful_resume_request -| or | <-- careful_resume_avoid -| ]]>

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. When transmitted, the careful_resume_indication is encrypted by QUIC transport using TLS . The secured hash is used by a sender to verify that the returned CC params were not modified by the receiver. 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 ). 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. 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. 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.

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 . An example implementation where the sender computes an Endpoint Token to uniquely identify the receiver is provided in . 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 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, 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).

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. The Sender transmits the Endpoint Token to the Receiver; The Receiver holds an Endpoint Token; The Receiver transmits the Endpoint Token to the Sender.

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.

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 therefore notes "Generally, implementations are advised to be cautious when using previous values on a new path."

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.

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

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

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.

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.