idnits 2.17.1 draft-kuhn-quic-0rtt-bdp-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '...Accept: A client MAY use the extension...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2020) is 1431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-cardwell-iccrg-bbr-congestion-control-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-2140bis-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Kuhn 3 Internet-Draft CNES 4 Intended status: Informational E. Stephan 5 Expires: November 19, 2020 Orange 6 G. Fairhurst 7 T. Jones 8 University of Aberdeen 9 May 18, 2020 11 Transport parameters for 0-RTT connections 12 draft-kuhn-quic-0rtt-bdp-07 14 Abstract 16 0-RTT mechanisms reduce the time it takes for the first bytes of 17 application data to be processed in a transport connection and can 18 greatly reduce connection latency during setup. The 0-RTT transport 19 features described by quic-transport help clients establish secure 20 connections with a minimal number of round-trips. 22 This document describes a generic method to exchange path parameters 23 relating to transport. The additional transport parameters can help 24 a connection that continues after an interruption or restarts by 25 sharing connection properties. They can be used to increase the 26 performance for a path with large RTT. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 19, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. BDP metadata parameters . . . . . . . . . . . . . . . . . . . 4 65 4. Extension activation . . . . . . . . . . . . . . . . . . . . 5 66 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 9. Informative References . . . . . . . . . . . . . . . . . . . 6 71 Appendix A. Example of server solution . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Each transport connection typically starts without knowledge of the 77 path between the endpoints. Transport protocols use implicit signals 78 from the network to discover the properties of the path. This 79 information is used to adapt the transport mechanisms to the network 80 path. For example, an Internet transport endpoint is unable to 81 determine a safe rate at which to start or continue their 82 transmission, and uses slow-start to determine a safe rate. This 83 applies to the 1-RTT mode of QUIC. 85 QUIC supports the sending of data in two different modes, after the 86 transport handshake has completed, 1-RTT mode, and sending data along 87 with handshake packets, 0-RTT mode. Using 0-RTT data an application 88 is able to send transport parameters with the handshake packets, 89 making it possible to reduce the latency of the connection setup. 91 In 0-RTT mode, a QUIC server must store a copy of a number of flow 92 control related transport parameters, or receives an integrity- 93 protected copy of these values in the ticket the client includes in 94 the first message of the handshake, to enable the use of 0-RTT data. 95 The setting or omission of one of these parameters can result in QUIC 96 creating a connection, but flow control can still prevent any data 97 being sent by the client. 99 For 0-RTT data to be sent, the QUIC server must record the values of: 101 o initial_max_data 103 o initial_max_stream_data_bidi_local 105 o initial_max_stream_data_bidi_remote 107 o initial_max_stream_data_uni 109 o initial_max_streams_bidi 111 o initial_max_streams_uni 113 These values set the flow control limits within which a connection 114 must operate. The server has to store these parameters for a client 115 to send data when resuming during 0-RTT. The stored values are used 116 for any data that is transmitted before the handshake has completed 117 and 1-RTT data is able to be sent on the connection. Once the 118 handshake has completed, these values are discarded and the values 119 established during the handshake are used. 121 This document proposes an extension to the transport parameters that 122 are shared during the 0-RTT phase to allow resumption using 123 additionnal transport and connection properties that were discovered 124 in previous connections. These additional parameters aim to provide 125 faster startup of flows and better buffer management. The BDP 126 metadata extension is proposed and candidate parameters are discussed 127 in Section 3. 129 2. Motivation 131 Reducing the number of round-trips required to start a connection is 132 an important way to reduce setup time and lower overall connection 133 latency. 0-RTT mechanisms that allow a client to feed requests to a 134 server in the first RTT do not alone improve the total time-to- 135 service. The BDP extension described in this document aims to 136 improve traffic delivery by allowing the connection to short-cut slow 137 RTT-based processes that grow connection parameters. 139 Currently each side has a proprietary solution to measure and to 140 store path characteristics. Recalling the parameters of a previous 141 connection would allow: 143 o Server and client to re-initialise the state from previously 144 established parameters (i.e., minRTT, MTU, bottleneck capacity, 145 etc.) 147 o The client to prepare the right resources 149 o The server to adapt to non-default path characteristics 151 There is an interest in sharing transport information across multiple 152 connections. As one example, [I-D.ietf-tcpm-2140bis] considers the 153 sharing of transport parameters between connections originating from 154 the same host. The proposal in this document has the advantage of 155 storing the information at the client and not requiring the server to 156 retain additional state for each client. 158 3. BDP metadata parameters 160 Section 7.3.1 of [I-D.ietf-quic-transport] describes the parameters 161 that must be remembered if a client wishes to send 0-RTT data. Both 162 endpoints store the value of the server transport parameters from a 163 connection and apply them to any 0-RTT packets that are sent in 164 subsequent connections to the same peer. Of the six mandatory 165 parameters, only initial_max_data improves the time-to-service of the 166 0-RTT connection. The BDP metadata extension augments the list of 167 server transport parameters that are shared with the client to 168 improve the time-to-service and save resources such as CPU, memory 169 and power. 171 The BDP extension proposes three new parameters that help a 172 connection startup in a minimal number of RTTs: 174 o recon_bytes_in_flight (0x000X): The bytes in flight measured on 175 the previous connection by the server. Integer number of bytes. 176 Using the bytes_in_flight defined in [I-D.ietf-quic-recovery], 177 recon_bytes_in_flight can be set to bytes_in_flight. 179 o recon_min_rtt (0x000X): The minimum RTT measured on the previous 180 connection by the server. Integer number of milliseconds. Using 181 the min_rtt defined in [I-D.ietf-quic-recovery], recon_min_rtt can 182 be set to min_rtt. The min_rtt parameter may not track a 183 decreasing RTT: the min_rtt that is reported here may not be the 184 actual minimum RTT measured during the 1-RTT connection, but still 185 reflects the characteristics of the latency on the network. 187 o recon_max_pkt_number (0x000X): The maximum amount of packets that 188 the server is allowed to send when reconnecting. Integer unit of 189 packets. 191 4. Extension activation 193 The BDP extension is protected by the same mechanism that protects 194 the exchange of the 0-RTT transport parameters. A client that 195 activates 0-RTT data sends back the transport parameters received 196 from the server during the previous connection (see Section 7.3.1 of 197 [I-D.ietf-quic-transport]). 199 The client reads the parameters in the BDP metadata extension, but 200 can not change them. 202 Accept: A client MAY use the extension parameters. Then, it 203 activates ingress optimization and sends back the transport 204 parameters of the BDP metadata extension that it received from the 205 server during the previous connection. 207 Refuse: A client could choose not to use there parameters. Then, it 208 does not support ingress optimisation and drops the extension signal. 209 A client that disagrees with the extension parameters received from 210 the server refuses the optimization. 212 5. Discussion 214 The recon_bytes_in_flight parameter is higher than the number of 215 bytes in the actual BDP since it may include bytes in buffers along 216 the path. 218 The recon_bytes_in_flight parameter is an indication of the end-to- 219 end BDP that is experienced by the congestion and flow control. If 220 the recon_bytes_in_flight is high, the server may decide to increase 221 the maximum amount of packets it will send when reconnecting using 222 the recon_max_pkt_number parameter. 224 The maximum number of initial data packets that can be sent without 225 acknowledgment needs to be chosen to avoid congestion collapse. An 226 example of a server solution is proposed in Appendix A. In short: 228 o recon_bytes_in_flight indicates the characteristics of the network 229 underneath to both peers that can adapt their buffer sizes or 230 parameter tuning. 232 o recon_min_rtt lets both a client and a server know the minimum RTT 233 of the previous connection. Parameters can then be adapted (e.g., 234 to adapt usage of kInitialRtt in "Setting the Loss Detection 235 Timer", see section of [I-D.ietf-quic-recovery]). 237 o recon_max_pkt_number lets the server warn the client that it may 238 increase the amount of packets that it expects to send when 239 reconnecting. This value is negotiated with the client and result 240 in better buffer management and reduced flow start up. 242 Other parameters can contribute to the optimization of 0-RTT 243 connection. There are good candidates, like max_ack_delay, in the 244 Appendix of [I-D.ietf-quic-recovery]. 246 6. Acknowledgments 248 The authors would like to thank Gabriel Montenegro, Patrick McManus, 249 Ian Swett, Igor Lubashev, Christian Huitema and Tom Jones for their 250 fruitful comments on earlier versions of this document. 252 7. IANA Considerations 254 TBD: Text is required to register the extension BDP_metadata field. 255 Parameters are registered using the procedure defined in 256 [I-D.ietf-quic-transport]. 258 8. Security Considerations 260 The BDP metadata parameters are measured by the server during a 261 previous connection. 263 The BDP extension is protected by the mechanism that protects the 264 exchange of the 0-RTT transport parameters. For the version 1 of 265 QUIC, the BDP extension is protected using the mechanism that already 266 protects the "initial_max_data" parameter. This is defined in 267 sections 4.5 to 4.7 of [I-D.ietf-quic-tls]. It provides the server 268 with a way to check the parameters proposed by the client are those 269 that the server sent to the client during the previous connexion. 271 9. Informative References 273 [I-D.cardwell-iccrg-bbr-congestion-control] 274 Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, 275 "BBR Congestion Control", draft-cardwell-iccrg-bbr- 276 congestion-control-00 (work in progress), July 2017. 278 [I-D.ietf-quic-recovery] 279 Iyengar, J. and I. Swett, "QUIC Loss Detection and 280 Congestion Control", draft-ietf-quic-recovery-27 (work in 281 progress), March 2020. 283 [I-D.ietf-quic-tls] 284 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 285 draft-ietf-quic-tls-27 (work in progress), February 2020. 287 [I-D.ietf-quic-transport] 288 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 289 and Secure Transport", draft-ietf-quic-transport-27 (work 290 in progress), February 2020. 292 [I-D.ietf-tcpm-2140bis] 293 Touch, J., Welzl, M., and S. Islam, "TCP Control Block 294 Interdependence", draft-ietf-tcpm-2140bis-05 (work in 295 progress), April 2020. 297 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 298 RFC 2914, DOI 10.17487/RFC2914, September 2000, 299 . 301 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 302 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 303 January 2007, . 305 Appendix A. Example of server solution 307 This section details a solution at the server to safely increase the 308 maximum amount of packets that the server sends when receiving a 309 0-RTT packet from a client. 311 The initial window is considered a safe starting point for an unknown 312 path to avoid adding congestion to a congested network. The general 313 assumption is that a path does not currently suffer persistent 314 congestion, and therefore the initial window is applicable until 315 feedback about the path is received. The resulting initial sending 316 rate is only tentative until the capacity is confirmed to be 317 available. If there is loss within this initial transmission, then 318 this could be evidence that the path is congested, and the sender 319 needs to adjust to this congestion. 321 Significant loss could be an indication of congestion collapse - i.e. 322 persistent loss, requiring back-off of the sending rate. 324 If however, the reception of IW is confirmed for the first RTT of 325 data, and also the path is determined to be similar to that of a 326 recent previous session (e.g., similar RTT), the method permits the 327 sender to use the previous path information as an input to help 328 determine a new safe rate. One possibility is to immediately jump to 329 a new sending rate that is derived from the previously sustained 330 rate. This follows the ideas of 331 [I-D.cardwell-iccrg-bbr-congestion-control] and [RFC4782]. 333 The QoS mechanisms that are deployed in the networks can help in 334 prevent the congestion collapse from occurring. However, the sender 335 must provide a significant reduction if there is evidence of 336 potential congestion collapse [RFC2914] from his point of view. 337 Precautions can be taken to guarantee that it is reasonably safe to 338 jump to a high sending rate : measuring that network conditions did 339 not change, allowing some space for other flows that have started and 340 pace transmission of packets. The sender might need to rapidly 341 reduce its rate, if the higher sending rate does not prove to be 342 supported. It if is supported, the sender can resume standard 343 congestion control. 345 Authors' Addresses 347 Nicolas Kuhn 348 CNES 350 Email: nicolas.kuhn@cnes.fr 352 Emile Stephan 353 Orange 355 Email: emile.stephan@orange.com 357 Gorry Fairhurst 358 University of Aberdeen 360 Email: gorry@erg.abdn.ac.uk 362 Tom Jones 363 University of Aberdeen 365 Email: tom@erg.abdn.ac.uk