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

Abstract

QUIC 0-RTT enables the optimization of the egress traffic. It relies on the sharing of the "initial_max_data" transport parameter between peer consent. This memo proposes the sharing of additional transport parameters to optimize the ingress traffic.

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 June 19, 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
• 2. Rationale
• 3. BDP metadata parameters
• 4. Extension activation
• 5. Discussion
• 6. Acknowledgements
• 7. IANA Considerations
• 8. Security Considerations
• 9. Informative References
• Authors' Addresses

1. Introduction

QUIC 0-RTT enables the optimization of the egress traffic. It relies on the sharing of the "initial_max_data" transport parameter between peers: it indicates to the client the number of bytes it is allowed to send in the first packet sent when reconnecting.

This memo proposes the sharing of additional transport parameters to optimize the ingress traffic exchange at both ends. The optimization of the time-to-service duration depends on both direction optimization. QUIC may not be used for the sole use of HTTP3 services, but also for symmetrical services. The client device should be able to adapt to the path adaptation chosen by the server. Since there are more and more exchange based on subscription where the server sends data first, with regard to ossification, it is central to dissociate the signalling (aka the initiator of the connection) from the peer which first sends application data.

The memo focuses on cases with high Bandwidth Delay Product (BDP) and constrained situations. The extension name is 'BDP metadata'. Candidate transport parameters are discussed in Section 3.

2. Rationale

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.

There are cases where egress acceleration like 0-RTT early data alone does not improve the time-to-service. While initial_max_data improves the egress time to server, the BDP metadata extension aims at improving ingress traffic delivery. In some large BDP deployment scenarios, this can significantly improve page load time.

There are reconnection situation where the time-to-service depends only on server data arrival because the service logic does not requires any additional information from the client.

Currently each side has its proprietary solution to measure and to store path characteristics. Having a standard way to share these parameters will allow the client to prepare the right resources and should improve the adaptation to non-default path characteristics.

Avoid peers to compute the same path characteristics and decide opposed strategies: When the BDP is high the server may decide to increase the data on the flight while a resource-limited client will decide, as the ingress is expected to be slow, to reduce the resources.

Having a symmetrical optimization reduces ossification. Having the server to share the path characteristics avoid duplicate works and allows resource-limited client to save resources like CPU, memory and power. Tune the default transport parameters of network paths which have path characteristics that increase the time-to-service.

3. BDP metadata parameters

Acording to [I-D.ietf-quic-transport], both endpoints store the value of the server transport parameters from a connection and apply them to any 0-RTT packets that are sent in subsequent connections to that peer. Amongst the six mandatory initial parameters that section 7.3.1 defines, only initial_max_data improves the time-to-service of the 0-RTT connection. The BDP metadata extension augments the list of server transport parameters that are shared with the client to improve the time-to-service and save resource like CPU, memory and power.

Parameters listed below migh be exchanged as transport parameter:

• last_bdp (0x000X): The last_bdp parameter is the BDP measured on the previous connection by the server. It is an integer in unit of bytes. Using the min_rtt and congestion_window defined in [I-D.ietf-quic-recovery], last_bdp can be set to min_rtt*congestion_window.
• initial_max_pkt_number (0x000X): The maximum amount of packets that the server is allowed to send when reconnecting. It is an integer in unit of packets.

When a server measures a large BDP, it may decide to increase the maximum amount of packets it will send when reconnecting. This enables a client which accepts the optimization to adjust its buffers at reconnection time.

4. Extension activation

Currently, in section 7.3.1 of [I-D.ietf-quic-transport], a client which activates 0-RTT sends back the transport parameters (initial_max_data ...) received from the server during the previous connection.

Accept: A client which activates ingress optimization must send back the transport parameters of the BDP metadata extension that it received from the server during the previous connection.

Tune: A client may send back a value lower than the initial_max_pkt_number received from the server.

Refuse: A client which does not send back these parameters indicates to the server that it does not accept ingress optimisation. A client which disagrees with the BDP measured by the server may refuse the optimization. A limited-resource client may discard the optimization.

5. Discussion

Other parameters can contribute to the optimization of 0-RTT connection.

There are good candidates, like min_rtt, in the Appendix of [I-D.ietf-quic-recovery].

Field measurements showed that tuning the ACK ratio improves the performance of asymmetrical exchange [PANRG106].

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

7. IANA Considerations

TBD: text is required to register the extension BDP_metadata field. Parameters are registered using the procedure defined in [I-D.ietf-quic-transport].

8. Security Considerations

The security is provided by the 1-RTT phase. The measure of BDP is made during a previous connection.

9. Informative References

Authors' Addresses