Internet Engineering Task Force N. Kuhn, Ed. Internet-Draft CNES Intended status: Informational E. Stephan, Ed. Expires: June 25, 2020 Orange G. Fairhurst, Ed. University of Aberdeen December 23, 2019 Transport parameters for 0-RTT connections draft-kuhn-quic-0rtt-bdp-06 Abstract QUIC 0-RTT 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 of the 0-RTT connection. This allows a faster startup of flows and enables adaptated buffer sizes at the server. The traffic that the client sends, i.e. the egress trafic, is improved. This memo proposes the sharing of additional transport parameters to provide a faster startup of flows and a better buffer management for the data that the client receives, i.e. 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 25, 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 Kuhn, et al. Expires June 25, 2020 [Page 1] Internet-Draft Transport for 0-RTT December 2019 (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 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. BDP metadata parameters . . . . . . . . . . . . . . . . . . . 3 4. Extension activation . . . . . . . . . . . . . . . . . . . . 4 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . 6 Appendix A. Example of server solution . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction QUIC 0-RTT 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 of the 0-RTT connection. This allows a faster startup of flows and enables adaptated buffer sizes at the server. The traffic that the client sends, i.e. the egress trafic, is improved. This memo proposes the sharing of additional transport parameters to provide a faster startup of flows and a better buffer management for the data that the client receives, i.e. the ingress traffic. 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 [I-D.ietf-quic-http], 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 (e.g. situations where buffer management at the client is an issue). The extension name is 'BDP metadata'. Candidate transport parameters are discussed in Section 3. Kuhn, et al. Expires June 25, 2020 [Page 2] Internet-Draft Transport for 0-RTT December 2019 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 of [I-D.ietf-quic-transport] 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: Kuhn, et al. Expires June 25, 2020 [Page 3] Internet-Draft Transport for 0-RTT December 2019 o last_bytes_in_flight (0x000X): The bytes in flight measured on the previous connection by the server. It is an integer in unit of bytes. Using the bytes_in_flight defined in [I-D.ietf-quic-recovery], last_bytes_in_flight can be set to bytes_in_flight. o last_min_rtt (0x000X): The minimum RTT measured on the previous connection by the server. It is an integer in unit of milliseconds. Using the min_rtt defined in [I-D.ietf-quic-recovery], last_min_rtt can be set to min_rtt. o 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. 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 The last_bytes_in_flight parameter is higher than the actual BDP since it may include bytes in buffers along the path. The last_bytes_in_flight parameter is still a indication of the end-to- end BDP that is experienced by the congestion control. If the last_bytes_in_flight is high, the server may decide to increase the maximum amount of packets it will send when reconnecting using the initial_max_pkt_number parameter. The maximum number of initial data packets that can be sent without acknowledgement needs to be chosen to avoid congestion collapse. An example of a server solution is proposed in Appendix A. In short: Kuhn, et al. Expires June 25, 2020 [Page 4] Internet-Draft Transport for 0-RTT December 2019 o last_bytes_in_flight indicates the characteristics of the network underneath to both peers that can adapt their buffer sizes or parameter tuning. o last_min_rtt lets both client and server know the minimum RTT of the previous connection. Parameters can then be adapted (e.g. adapt how kInitialRtt is used in the "Setting the Loss Detection Timer" section of [I-D.ietf-quic-recovery]). o initial_max_pkt_number lets the server warn the client that it may increase the amount of packets that it expects to send when reconnecting. This value is negotiated with the client and result in better buffer management and reduced flow start up. Another paramater that could be added to the BDP metadata extension could be the ack_ratio. o ack_ratio (0x000X): The acknowledgment ratio that has been used at the end of the previous connection by the server. It is an integer in unit of packets. Starting with a high ACK ratio may induce bursts of packet in a potentially congested network. That being said, keeping a low ack_ratio may limit performance in case of asymmetry [PANRG106]. The server may want to be recalled the ACK ratio that had been used at the end of the connection but not use it when starting the 0-RTT conection. Other parameters can contribute to the optimization of 0-RTT connection. There are good candidates, like max_ack_delay, in the Appendix of [I-D.ietf-quic-recovery]. 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]. Kuhn, et al. Expires June 25, 2020 [Page 5] Internet-Draft Transport for 0-RTT December 2019 8. Security Considerations The BDP metadata parameters are measured by the server made during a previous connection. BDP extension is protected by the mechanism which protect the exchange of the 0-RTT transport parameters. For the version 1 of QUIC, the BDP extension is protected using the mechanism which already protects the 'initial_max_data' parameter. It is defined in sections 4.5 to 4.7 of [I-D.ietf-quic-tls]. It provides the server with a mean to check that the parameters proposed by the client are those the server sent to the client during the previous connexion. 9. Informative References [I-D.ietf-quic-http] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", draft-ietf-quic-http-24 (work in progress), November 2019. [I-D.ietf-quic-recovery] Iyengar, J. and I. Swett, "QUIC Loss Detection and Congestion Control", draft-ietf-quic-recovery-24 (work in progress), November 2019. [I-D.ietf-quic-tls] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", draft-ietf-quic-tls-24 (work in progress), November 2019. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-24 (work in progress), November 2019. [PANRG106] Fairhurst, G., "Impact of Asymmetric Path Characteristics", IETF PANRG 106, 2019. [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, . [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, . Kuhn, et al. Expires June 25, 2020 [Page 6] Internet-Draft Transport for 0-RTT December 2019 Appendix A. Example of server solution This section details a solution at the server to safely increase the maximum amount of packets that the server sends when receiving a 0-RTT packet from a client. The server keeps a standard initial window to avoid adding congestion to a congested network. After the reception of the acknowledgments for the last packet of the initial window, the server checks that the min_rtt is consistent. It then adapts the congestion window to a higher value that must be paced out. The initial_max_pkt_number is then the amount of data that the server sends during the two firsts RTT. Authors' Addresses Nicolas Kuhn (editor) CNES Email: nicolas.kuhn@cnes.fr Emile Stephan (editor) Orange Email: emile.stephan@orange.com Gorry Fairhurst (editor) University of Aberdeen Email: gorry@erg.abdn.ac.uk Kuhn, et al. Expires June 25, 2020 [Page 7]