Transport parameters for 0-RTT connections
draft-kuhn-quic-0rtt-bdp-04

Abstract

The time-to-service duration depends on both peers exchange optimization. The peer initiating the connection may not be the one which send data first. Moreover, clients may be resource-limited, behind a low bandwidth or connected to a long-RTT network and may need to adapt dynamically to improve data reception. Currently, each side has its proprietary solution to measure and to store path characteristics. Having a standard way to share these parameters should improve the adaptation to a non standard path characteristics.

QUIC v1 specification already reflects this approach. Having a symmetrical control of the optimization should reduce protocol ossification. This memo proposes the sharing of the characteristics of the path amongst the peer to reduce HTTP3 time-to-service for non default transport situation.

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 May 7, 2020.

Copyright Notice

Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Reducing ossification with the proposed solution
• 2. Differences between 1-RTT and 0-RTT QUIC connections establishment
• 3. An end-to-end Method
• 3.1. Description of the BDP metadata extension
• 3.2. Usage of the extension in the NewSessionTicket
• 4. Best current practice
• 5. What happens when BDP is used incorrectly?
• 6. Relevance of the solution for QUIC and other protocols
• 7. Acknowledgements
• 8. IANA Considerations
• 9. Security Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

Some network paths experience an increased time-to-service because the default parameters controlling the initialization of the transport and congestion control are not well-suited to the path characteristics. QUIC's default congestion control is based on TCP NewReno [I-D.ietf-quic-recovery] and the recommended initial window is defined by [RFC6928]. A path with a large bandwidth delay product can therefore significantly increase the time-to-service (e.g. a path using satellite communication [IJSCN19] could observe a much longer page load time for complex pages). The 0-RTT mechanism is designed to accelerate the throughput when reconnecting to a peer where it has (recently) learned information about the path characteristics. However, there are cases where egress acceleration like 0-RTT early_data alone does not improve the time-to-service and cases where the data transmission is symmetrical or where clients are capacity-limited: additional information can be beneficial.

As QUIC transport security is based on TLS1.3 [I-D.ietf-quic-tls], this memo describes a solution where a BDP_metadata extension is added to the NewSessionTicket of TLS1.3 [TO DO ADD REF]. The BDP_metadata informs the client about path parameters so that both the client and the server can contribute to the reduction of the time-to-service. This data is protected from in the middle-attack such as the 'early_data' extension.

1. the server learns characteristics of the path during a previous connection;
2. the server sends this information to the client at any time during the current connection, after the BDP_metadata parameters are validated;
3. the client is permitted to discard the information (when the validation period is too short, the information is found to be inconsistent with its own path characteristics measurement, for a device with limited buffer, etc.);
4. the server and the client can exploit the information to improve the time-to-service during subsequent 0-RTT connections.

The current focus of this use is QUIC. However, the method can be used with TLS1.3 over any transport (e.g., using this with TCP Fast Open [RFC7413] or DTLS [RFC6347].

This proposal follows both the approach of the extension field 'early_data' of the NewSessionTicket of TLS1.3 and its mapping in QUIC. While 'early_data' improves the egress traffic of a client, the 'BDP_metadata' provides information that can be used to improve ingress traffic towards the client. This can result in significant improvement to the quality-of-experience. For example, it enables sending measured characteristics of the path, such as the RTT, PMTU and BDP. This information can be used to adapt the initial data transmission of a 0-RTT connection. In the case of a deployment scenario with a large BDP, this can halve the page load time of a web page download [TODO ADD REF].

The proposal proposes to consider the same method for integrating TLS1.3 extension in QUIC as it is done for early_data. For the mapping of NewSessionTicket in QUIC, QUIC transports the 'early_data' value outside the NewSessionTicket in the "initial_max_data" transport parameters (see section 4.5 of [I-D.ietf-quic-tls]).

1.1. Reducing ossification with the proposed solution

While each client and server could implement a dedicated solution to exchange and store path parameters, providing a standard method to exchange this information helps provide symmetrical control of the optimisation. This reduces protocol ossification. A client using the method is informed about path parameters: allowing both the client and the server to reduce the time-to-service for subsequent connections. This improves symmetrical transmission of data and reduces ossification of the protocol. Some advantages of the proposed solution are the following.

1. It provides symmetrical control of the optimisation: as extensions to HTTP3 envision server initiated request [I-D.ietf-quic-http] the path adaptation ought to be symmetrical and ought not to depend on policy of the peer in establishment. The QUIC transport can be used for services beyond HTTP3, including symmetrical services: where QUIC is considered as a relevant candidate for setting up proxies or tunnels [I-D.kuehlewind-quic-substrate] or for transmiting unreliable datagram services [I-D.pauly-quic-datagram]. A client device sought to be able to adapt to the path chosen by the server. A subscription where the server sends data first, it is important to dissociate the signalling (aka the initiator of the connection) from the peer that first sends application data.
2. Using the path information reduces the need for operators to deploy TCP-proxy and middleboxes, such as Performance-Enhancing Proxy (PEP) [RFC2488][RFC3135] to compensate for the characteristics of the paths: if both the client and server have learned appropriate transport parameters, they can themselves optimize the transport service by adapting the end-to-end transport protocol to the current path. As example, specific client-based adaptations can be developed, such as adapting the ACK-ratio or increasing the receive buffer size. This reduces the need to deploy middelboxes, and will result in less ossifiication along Internet paths.
3. Improve inter-operability: while each client and server can have their dedicated solution to store path parameters, having a standard way of exchanging this information helps in reducing the time-to-service when clients and servers are not provided by the same company. Both sides can independently propose optimizations to improve the ingress traffic.

2. Differences between 1-RTT and 0-RTT QUIC connections establishment

This section recalls how 1-RTT and 0-RTT operate in QUIC [I-D.ietf-quic-transport].

QUIC leverages the two handshakes of TLS1.3 [I-D.ietf-quic-tls]: The 1-RTT handshake initiates a first set of credentials. When this handshake successfully completes, the server pushes the learned information about the session to the client in an opaque session ticket (see section 4.6.1 of [RFC8446]). The information within the opaque ticket is encrypted by the server. When received, the encrypted information is stored by the client (but is not readable by the client). A session ticket can be sent at any time during the connection and a server can send several session tickets in one connection. A client wishing to establish a fast re-open of the session pushes back the (stored) opaque ticket in its 0-RTT handshake and sends early application data.

In practice, the server sends the 'ticket' in a NewSessionTicket record [I-D.ietf-quic-tls]. The structure of the NewSessionTicket includes the opaque 'ticket' and an 'extensions' field. The NewSessionTicket carries an additional field named 'early_data' that indicates to the client the maximum size of application data to insert in the 0-RTT message.

3. An end-to-end Method

QUIC encryption of transport headers prevents the adding of Performance-enhancing proxy (PEP). The BDP metadata extension may be a substitute to PEP proxy [RFC2488], [RFC3135] when time-to-service improvement requires acceleration of the refilling of client application buffers.

The BDP_metadata extension allows a cient to recall the BDP metadata previously measured by the server during the 1-RTT handshake when it initializes a 0-RTT connection. The approach enables changes to a congestion control method (e.g., tuning of the initial window for high BDP networks, as described in [I-D.irtf-iccrg-sallantin-initial-spreading]. This has been shown to improve performance both for paths with a high BDP and a more common BDP [CONEXT15][ICC16].

3.1. Description of the BDP metadata extension

This section defines an extension named "BDP_metadata" for the NewSessionTicket. This structure contains the following parameters: BDP, MTU, RTT, loss-rate.

3.2. Usage of the extension in the NewSessionTicket

At the end of a 1-RTT connection, a server can send information in a NewSessionTicket that describes the path to the client. The message includes an additional 'extensions' field named 'BDP_metadata'. The client stores this session ticket together with and the 'BDP_metadata' field.

When the client reconnects to the same server in 0-RTT mode, it pushes back this session ticket in the ClientHello and prepares itself to receive data in the context given by the 'BDP_metadata' field. The client does not send the 'BDP_metadata' field back to the server. The server receives the session ticket and extracts the BDP context. As example, it can use this message to provide information that may allow the congestion controller to provide a throughput closer to the capacity of the path.

The path characteristics can and do change over time. The path information can therefore become invalid for use in a subsequent connection. The server MUST set the age of the ticket (see section 4.2.11.1 of [RFC8446]) to a short duration. To help ensure that the ticket is still valid, the server SHOULD also verify the IP address of the client. A server MAY update the ticket when the path characteristics of connection are known to have changed.

4. Best current practice

This section provides examples of data that could be added in the opaque session ticket field by the server. The details added by the server in the session ticket do not need to be standardized for interoperability between QUIC clients and servers because this information is opaque to the client. The presence of the "BDP_metadata" extension field in the NewSessionTicket informs the client that the server can actively take action to improve its throughput when the session will restart.

The following list describes information elements set by the server in the session ticket to accompany the signaling of field. These examples are illustrated in Figure 1 and their purpose is detailed in this section.

• A client aware of a high BDP path: Section 7.3.1 of [I-D.ietf-quic-transport] indicates that the "A client that attempts to send 0-RTT data MUST remember the transport parameters used by the server". In addition to the default transport parameters used by the server, a server that knows that the path has a large BDP can let the client adapt its parameters.
• PMTU: Knowledge of the PMTU of a previous path improves the time to service because it reduces the duration of the path validation process described in section 8.2 of [I-D.ietf-quic-transport].
• Connection RTT: The knowledge of the characteristics of a previous connection RTT can improve the throughput because a server can safely improve the slow start: e.g. using the pacing models of [I-D.irtf-iccrg-sallantin-initial-spreading] can utilise a larger IW for high RTT paths and a default IW for paths with smaller RTT. The results presented in [ICC16] show that for both files of 15 KB and 750 KB, the proposed solution reduces the time to download by approximatively 2 seconds whether the RTT is 50ms or 500ms.
• Ticket_lifetime: The server sets a shorter validity duration to avoid receiving obsolete path characteristics; (e.g., this could reduce the validity to one day).

           CLIENT                         SERVER
           +-----------------------------------+
           |          1 RTT connection         |
           +-----------------------------------+
             |                              |
             +<---1-RTT TLS1.3 HANDSHAKE--->+
             |                              | +------------+
             +<-----data transmission------>+ |path charact|
             |                              | |record      |
             |                              | +------------+
             |<-------------NewSessionTicket+  
+----------+ |           +ticket_lifetime   |
|client    | |           +'opaque' field    |
|aware of  | |           +'extension' field |
|path      | |            + early_data      |
|charat.   | |            + BDP_metadata    |
+----------+ |              + BDP           |
             |              + RTT           |
             |              + loss-rate     |
             |              + MTU           |
           +-----------------------------------+
           |          0 RTT connection         |
           +-----------------------------------+
             |                              |
             +ClientHello------------------>|
             |+'opaque' field               | 
             |                              | +-------------------+
             |                              | |server aware of    |
             |                              | |path charact.      |
             |                              | +-------------------+
             |                              |
             +<----+data transmission+----->+
             |                              |
             +                              +
				

Figure 1: Example of opaque ticket content

5. What happens when BDP is used incorrectly?

This section discusses the impact of a server activating the 'BDP_metadata' field when the network underneath actually has a small BDP. This could happen when the server BDP estimate was incorrect, when a client has multiple paths to choose from and uses the ticket on a different path to which it was requested, or when the path characteristics have changed significantly.

Incorrectly exploiting the BDP_metadata could result in pre-assigning additional resources (e.g. transport buffer space) that later fails to be used. Many endpoints implementations do not statically pre-assign buffer space, so increasing the limit does not have an impact when the resource is unused. Some cases could be resource-limited.

The server could adapt the initial window because it expects a high BDP path, when the actual BDP is significantly smaller. This issue can be mitigated when packets are paced from the server over the associated RTT, since the server would receive an acknowledgment after the actual RTT period, and before it has used the complete initial window.

6. Relevance of the solution for QUIC and other protocols

The QUIC framework would allow solutions to have been proposed. As an example, the NEW_TOKEN frame could be used to send the path characteristics information to the client. However, this would require specifying its content, consistently with QUIC transport parameters, so that any client can exploit the information transmitted by any server in a standard way. Moreover, the NEW_TOKEN frame is not symmetrical (Clients MUST NOT send NEW_TOKEN frames) does not enable the support of a symmetrical control of the optimisation.

The proposed solution has been proposed with QUIC standardization in mind, but is applicable to any transport under TLS1.3.

7. Acknowledgements

The authors would like to thank Gabriel Montenegro, Patrick McManus, Ian Swett, Igor Lubashev and Christian Huitema for their fruitful comments on earlier versions of this document.

8. IANA Considerations

TBD: text is required to register the extension BDP_metadata field.

9. Security Considerations

The security is provided by the 1-RTT phase. The measure of BDP is made during a previous connection. The exchange and the information are protected both by the TLS encryption and the NewSessionTicket (see section 4.6.1 of [RFC8446]).

The BDP information the server will received is protected in the opaque session ticket. The 'BDP_metadata' field is visible by the client only. An client that does not trust the server transport adaptation ignores any session ticket associated to a 'BDP_metadata' field.

The server does not have to honour all the received requests (e.g. when it is resource-limited).

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses