BDP Frame Extension

This document proposes a method to exchange values between a client and the server in a interoperable manner: For an established connection, the current RTT (current_rtt), bottleneck bandwidth (current_bb) and current client IP (current_client_ip) are stored as saved_rtt, saved_bb and saved_client_ip within a BDP_FRAME; The BDP_FRAME can be sent to the client and the client can also be notified of the values of the BDP_FRAME parameters; When resuming a session to the same IP address, the client is allowed to send the BDP_FRAME; The server can then utilise the parameters from the BDP_FRAME in a later new connection to the same endpoint. This method applies to any resumed QUIC session: both a saved_session and a recon_session can be a 0-RTT QUIC connection or a 1-RTT QUIC connection.

BDP: defined below CWND: the congestion window used by server (maximum number of bytes allowed in flight by the CC) current_bb : Current estimated bottleneck bandwidth saved_bb: Estimated bottleneck bandwidth preserved from a previous connection RTT: Round-Trip Time current_rtt: Current RTT saved_rtt: RTT preserved from a previous connection client_ip : IP address of the client current_client_ip : Current IP address of the client saved_client_ip : IP address of the client preserved from a previous connection remembered BDP parameters: a combination of saved_rtt and saved_bb defines the BDP as follows: "Derived from Round-Trip Time (RTT) and network Bottleneck Bandwidth (BB), the Bandwidth-Delay Product (BDP) determines the Send and Received Socket buffer sizes required to achieve the maximum TCP Throughput." This document considers the BDP estimated by a server that includes all buffering along the network path. The estimated BDP estimated is related to the amount of bytes in flight and the measured path RTT. A QUIC connection could use the procedure detailed in to measure the BDP, but is permitted to choose another method . A server might be able to utilise an other information to provide an estimate of the BDP. Congestion controllers, such as CUBIC or RENO, could 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 . It is important to consider whether the methods could result in over-estimating the bottleneck bandwidth, and the preserved values there ought to be used with caution.

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.

This section describes the use of a new Frame, the BDP Frame. The BDP Frame MUST be considered by the congestion controller and its data is not be limited by flow control limits. The server and the client MAY send multiple BDP Frames in both 1-RTT and 0-RTT connections.

A BDP Frame is formatted as shown in .

BDP Frame { Type (i) = 0xXXX, Lifetime (i), Saved BB (i), Saved RTT (i), Saved IP length (i), Saved IP (...) } A BDP Frame contains the following fields: Lifetime (extension_lifetime): The extension_lifetime is a value in milliseconds, encoded as a variable length integer. This follows the design of a NewSessionTicket of TLS . This represents the validity in time of this extension. Saved BB (saved_bb): The saved_bb is a value in bytes, encoded as a variable length integer. The bottleneck bandwidth estimated for the previous connection by the server. Using the previous values of bytes_in_flight defined in can result in overshoot of the bottleneck capacity and is not advised. Saved RTT (saved_rtt): The saved_rtt is a value in milliseconds, encoded as a variable length integer. This could be set to the minimum RTT (min_rtt). The saved_rtt can be set to the min_rtt. NOTE: The min_rtt defined in , does not track a decreasing RTT: therefore the min_rtt reported might be larger than the actual minimum RTT measured during the 1-RTT connection. Saved IP length (saved_ip_length) : The length of the IP address in octets is set to either 4 (IPv4) or 16 (IPv6). Saved IP (saved_client_ip) : The saved_client_ip could be set to the IP address of the client.

The client can accept the transmission of BDP Frames from the server by using the enable_bdp transport extension. enable_bdp (0xTBD): in the 1-RTT connection, the client indicates to the server that it wishes to receive BDP extension Frames for improving ingress of 0-RTT connection. The default value is 0. Values larger than 3 are invalid, and receipt of these values MUST be treated as a connection error of type TRANSPORT_PARAMETER_ERROR. 0: Default value. If the client does not send this parameter, the server considers that the client does not support or does not wish to activate the BDP extension. 1: The client indicates to the server that it wishes to receive BDP Frame and activates the ingress optimization for the 0-RTT connection. 2: The client indicates that it does not wish to receive BDP Frames but activates ingress optimization. 3: The client indicates that it wishes to receive BDP Frames, but does not activate ingress optimization. This Transport Parameter is encoded as described in Section 18 of .

With the BDP Frame extension, the client has the choice of accepting the reuse of the previous parameters or not. The BDP metadata parameters are measured by the server during a previous connection. The BDP extension is protected by the mechanism that protects the exchange of the 0-RTT transport parameters. For version 1 of QUIC, the BDP extension is protected using the mechanism that already protects the "initial_max_data" parameter. This is defined in sections 4.5 to 4.7 of . This provides a way for the server to verify that the parameters proposed by the client are the same as those that the server sent to the client during the previous connection. The server SHOULD NOT trust the client. Indeed, even if 0-RTT packets containing the BDP Frame are encrypted, a client could modify the values within the extension and encrypt the 0-RTT packet. Authentication mechanisms might not guarantee that the values are safe. It is not an easy operation for a client to modify authenticated or encrypted data without this being detected by a server. Modification could be realized by malicious clients. One way to avoid this is for a server to also store the saved_rtt and saved_bb parameters.

The authors would like to thank 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.

TBD: Text is required to register the BDP Frame and the enable_bdp transport parameter. Parameters are registered using the procedure defined in .

Security considerations are discussed in .