idnits 2.17.1 draft-kuhn-quic-0rtt-bdp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2019) is 1592 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-24 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-24 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Kuhn, Ed. 3 Internet-Draft CNES 4 Intended status: Informational E. Stephan, Ed. 5 Expires: June 19, 2020 Orange 6 G. Fairhurst, Ed. 7 University of Aberdeen 8 December 17, 2019 10 Transport parameters for 0-RTT connections 11 draft-kuhn-quic-0rtt-bdp-05 13 Abstract 15 QUIC 0-RTT enables the optimization of the egress traffic. It relies 16 on the sharing of the "initial_max_data" transport parameter between 17 peer consent. This memo proposes the sharing of additional transport 18 parameters to optimize the ingress traffic. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 19, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. BDP metadata parameters . . . . . . . . . . . . . . . . . . . 3 57 4. Extension activation . . . . . . . . . . . . . . . . . . . . 4 58 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 9. Informative References . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 QUIC 0-RTT enables the optimization of the egress traffic. It relies 68 on the sharing of the "initial_max_data" transport parameter between 69 peers: it indicates to the client the number of bytes it is allowed 70 to send in the first packet sent when reconnecting. 72 This memo proposes the sharing of additional transport parameters to 73 optimize the ingress traffic exchange at both ends. The optimization 74 of the time-to-service duration depends on both direction 75 optimization. QUIC may not be used for the sole use of HTTP3 76 services, but also for symmetrical services. The client device 77 should be able to adapt to the path adaptation chosen by the server. 78 Since there are more and more exchange based on subscription where 79 the server sends data first, with regard to ossification, it is 80 central to dissociate the signalling (aka the initiator of the 81 connection) from the peer which first sends application data. 83 The memo focuses on cases with high Bandwidth Delay Product (BDP) and 84 constrained situations. The extension name is 'BDP metadata'. 85 Candidate transport parameters are discussed in Section 3. 87 2. Rationale 89 QUIC encryption of transport headers prevents the adding of 90 Performance-enhancing proxy (PEP). The BDP metadata extension may be 91 a substitute to PEP proxy [RFC2488] [RFC3135] when time-to-service 92 improvement requires acceleration of the refilling of client 93 application buffers. 95 There are cases where egress acceleration like 0-RTT early data alone 96 does not improve the time-to-service. While initial_max_data 97 improves the egress time to server, the BDP metadata extension aims 98 at improving ingress traffic delivery. In some large BDP deployment 99 scenarios, this can significantly improve page load time. 101 There are reconnection situation where the time-to-service depends 102 only on server data arrival because the service logic does not 103 requires any additional information from the client. 105 Currently each side has its proprietary solution to measure and to 106 store path characteristics. Having a standard way to share these 107 parameters will allow the client to prepare the right resources and 108 should improve the adaptation to non-default path characteristics. 110 Avoid peers to compute the same path characteristics and decide 111 opposed strategies: When the BDP is high the server may decide to 112 increase the data on the flight while a resource-limited client will 113 decide, as the ingress is expected to be slow, to reduce the 114 resources. 116 Having a symmetrical optimization reduces ossification. Having the 117 server to share the path characteristics avoid duplicate works and 118 allows resource-limited client to save resources like CPU, memory and 119 power. Tune the default transport parameters of network paths which 120 have path characteristics that increase the time-to-service. 122 3. BDP metadata parameters 124 Acording to [I-D.ietf-quic-transport], both endpoints store the value 125 of the server transport parameters from a connection and apply them 126 to any 0-RTT packets that are sent in subsequent connections to that 127 peer. Amongst the six mandatory initial parameters that section 128 7.3.1 defines, only initial_max_data improves the time-to-service of 129 the 0-RTT connection. The BDP metadata extension augments the list 130 of server transport parameters that are shared with the client to 131 improve the time-to-service and save resource like CPU, memory and 132 power. 134 Parameters listed below migh be exchanged as transport parameter: 136 o last_bdp (0x000X): The last_bdp parameter is the BDP measured on 137 the previous connection by the server. It is an integer in unit 138 of bytes. Using the min_rtt and congestion_window defined in 139 [I-D.ietf-quic-recovery], last_bdp can be set to 140 min_rtt*congestion_window. 142 o initial_max_pkt_number (0x000X): The maximum amount of packets 143 that the server is allowed to send when reconnecting. It is an 144 integer in unit of packets. 146 When a server measures a large BDP, it may decide to increase the 147 maximum amount of packets it will send when reconnecting. This 148 enables a client which accepts the optimization to adjust its buffers 149 at reconnection time. 151 4. Extension activation 153 Currently, in section 7.3.1 of [I-D.ietf-quic-transport], a client 154 which activates 0-RTT sends back the transport parameters 155 (initial_max_data ...) received from the server during the previous 156 connection. 158 Accept: A client which activates ingress optimization must send back 159 the transport parameters of the BDP metadata extension that it 160 received from the server during the previous connection. 162 Tune: A client may send back a value lower than the 163 initial_max_pkt_number received from the server. 165 Refuse: A client which does not send back these parameters indicates 166 to the server that it does not accept ingress optimisation. A client 167 which disagrees with the BDP measured by the server may refuse the 168 optimization. A limited-resource client may discard the 169 optimization. 171 5. Discussion 173 Other parameters can contribute to the optimization of 0-RTT 174 connection. 176 There are good candidates, like min_rtt, in the Appendix of 177 [I-D.ietf-quic-recovery]. 179 Field measurements showed that tuning the ACK ratio improves the 180 performance of asymmetrical exchange [PANRG106]. 182 6. Acknowledgements 184 The authors would like to thank Gabriel Montenegro, Patrick McManus, 185 Ian Swett, Igor Lubashev and Christian Huitema for their fruitful 186 comments on earlier versions of this document. 188 7. IANA Considerations 190 TBD: text is required to register the extension BDP_metadata field. 191 Parameters are registered using the procedure defined in 192 [I-D.ietf-quic-transport]. 194 8. Security Considerations 196 The security is provided by the 1-RTT phase. The measure of BDP is 197 made during a previous connection. 199 9. Informative References 201 [I-D.ietf-quic-recovery] 202 Iyengar, J. and I. Swett, "QUIC Loss Detection and 203 Congestion Control", draft-ietf-quic-recovery-24 (work in 204 progress), November 2019. 206 [I-D.ietf-quic-transport] 207 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 208 and Secure Transport", draft-ietf-quic-transport-24 (work 209 in progress), November 2019. 211 [PANRG106] 212 Fairhurst, G., "Impact of Asymmetric Path 213 Characteristics", IETF PANRG 106, 2019. 215 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 216 Over Satellite Channels using Standard Mechanisms", 217 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 218 . 220 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 221 Shelby, "Performance Enhancing Proxies Intended to 222 Mitigate Link-Related Degradations", RFC 3135, 223 DOI 10.17487/RFC3135, June 2001, 224 . 226 Authors' Addresses 228 Nicolas Kuhn (editor) 229 CNES 231 Email: nicolas.kuhn@cnes.fr 233 Emile Stephan (editor) 234 Orange 236 Email: emile.stephan@orange.com 237 Gorry Fairhurst (editor) 238 University of Aberdeen 240 Email: gorry@erg.abdn.ac.uk