idnits 2.17.1 draft-kuhn-quic-0rtt-bdp-08.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 226: '...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 (February 22, 2021) is 1152 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 (-11) exists of draft-ietf-tcpm-2140bis-07 Summary: 1 error (**), 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 3 Internet-Draft CNES 4 Intended status: Informational E. Stephan 5 Expires: August 26, 2021 Orange 6 G. Fairhurst 7 T. Jones 8 University of Aberdeen 9 February 22, 2021 11 Transport parameters for 0-RTT connections 12 draft-kuhn-quic-0rtt-bdp-08 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 August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 2.1. Optimizing client's requests . . . . . . . . . . . . . . 4 65 2.2. Safe jump start . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Sharing transport information accross multiple 67 connections . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. BDP metadata parameters . . . . . . . . . . . . . . . . . . . 5 69 4. Extension activation . . . . . . . . . . . . . . . . . . . . 5 70 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Relevance of the transport parameter . . . . . . . . . . 6 72 5.2. The client point-of-view . . . . . . . . . . . . . . . . 6 73 5.3. BDP extension protected as Much as initial_max_data . . . 6 74 5.4. Congestion control safety . . . . . . . . . . . . . . . . 6 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 9. Informative References . . . . . . . . . . . . . . . . . . . 7 79 Appendix A. Example of server solution . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Each transport connection typically starts without knowledge of the 85 path between the endpoints. Transport protocols use implicit signals 86 from the network to discover the properties of the path. This 87 information is used to adapt the transport mechanisms to the network 88 path. For example, an Internet transport endpoint is unable to 89 determine a safe rate at which to start or continue their 90 transmission, and uses slow-start to determine a safe rate. This 91 applies to the 1-RTT mode of QUIC. 93 QUIC supports the sending of data in two different modes, after the 94 transport handshake has completed, 1-RTT mode, and sending data along 95 with handshake packets, 0-RTT mode. Using 0-RTT data an application 96 is able to send transport parameters with the handshake packets, 97 making it possible to reduce the latency of the connection setup. 99 In 0-RTT mode, a QUIC server must store a copy of a number of flow 100 control related transport parameters, or receives an integrity- 101 protected copy of these values in the ticket the client includes in 102 the first message of the handshake, to enable the use of 0-RTT data. 103 The setting or omission of one of these parameters can result in QUIC 104 creating a connection, but flow control can still prevent any data 105 being sent by the client. 107 For 0-RTT data to be sent, the QUIC server must record the values of: 109 o initial_max_data 111 o initial_max_stream_data_bidi_local 113 o initial_max_stream_data_bidi_remote 115 o initial_max_stream_data_uni 117 o initial_max_streams_bidi 119 o initial_max_streams_uni 121 These values set the flow control limits within which a connection 122 must operate. The server has to store these parameters for a client 123 to send data when resuming during 0-RTT. The stored values are used 124 for any data that is transmitted before the handshake has completed 125 and 1-RTT data is able to be sent on the connection. Once the 126 handshake has completed, these values are discarded and the values 127 established during the handshake are used. 129 This document proposes an extension to the transport parameters that 130 are shared during the 0-RTT phase to allow resumption using 131 additionnal transport and connection properties that were discovered 132 in previous connections. 134 2. Motivation 136 Reducing the number of round-trips required to start a connection is 137 an important way to reduce setup time and lower overall connection 138 latency. 0-RTT mechanisms that allow a client to feed requests to a 139 server in the first RTT do not alone improve the total time-to- 140 service. The BDP extension described in this document aims to 141 improve traffic delivery by allowing the connection to short-cut slow 142 RTT-based processes that grow connection parameters. 144 Currently each side has a proprietary solution to measure and to 145 store path characteristics. Recalling the parameters of a previous 146 would allow the use-cases presented in this section. 148 2.1. Optimizing client's requests 150 In cases with Dynamic Adaptive Streaming over HTTPS (DASH), clients 151 may encounter issues in knowing the available bandwidth or DASH can 152 encounter issues in reaching the best available video playback 153 quality. The client's requests could be adapted and specific traffic 154 could use information from the paths characteristics (such as trying 155 to impress the client with high quality videos, to fill the buffers 156 and avoid video blocking or to send high quality adds). 158 In other cases, applications may provide additionnal services if 159 clients can know the server's estimation of the path characteristics. 161 2.2. Safe jump start 163 The server could use information from the paths characteristics to 164 adapt to non-default path characteristics. Moreover, some transport 165 parameters ma not need to be re-estimated (i.e. minRTT, MTU, 166 bottleneck capacity, etc.). 168 CDNs currently exploit a very high Initial Window [TMA18]. Using the 169 knowledge of previous path characteristics, CDN could: 171 o adapt these values to save resource at the server and increase 172 safely the initial congestion window such as proposed in 173 [I-D.irtf-iccrg-sallantin-initial-spreading][CONEXT15]; 175 o consider client's limitation if the client decided to reject the 176 extension. 178 2.3. Sharing transport information accross multiple connections 180 There is an interest in sharing transport information across multiple 181 connections. [I-D.ietf-tcpm-2140bis] considers the sharing of 182 transport parameters between connections originating from the same 183 host. The proposal in this document have the advantage of storing 184 the information at the client and not requiring the server to retain 185 additional state for each client. 187 3. BDP metadata parameters 189 Section 7.3.1 of [I-D.ietf-quic-transport] describes the parameters 190 that must be remembered if a client wishes to send 0-RTT data. Both 191 endpoints store the value of the server transport parameters from a 192 previous connection and apply them to any 0-RTT packets that are sent 193 in subsequent connections to the same peer. Of the six mandatory 194 parameters, only initial_max_data improves the time-to-service of the 195 0-RTT connection. The BDP metadata extension augments the list of 196 server transport parameters that are shared with the client to 197 improve the time-to-service and save resources such as CPU, memory 198 and power. 200 The BDP extension proposes two new parameters 202 o recon_bytes_in_flight (0x000X): The bytes in flight measured on 203 the previous connection by the server. Integer number of bytes. 204 Using the bytes_in_flight defined in [I-D.ietf-quic-recovery], 205 recon_bytes_in_flight can be set to bytes_in_flight. 207 o recon_min_rtt (0x000X): The minimum RTT measured on the previous 208 connection by the server. Integer number of milliseconds. Using 209 the min_rtt defined in [I-D.ietf-quic-recovery], recon_min_rtt can 210 be set to min_rtt. The min_rtt parameter may not track a 211 decreasing RTT: the min_rtt that is reported here may not be the 212 actual minimum RTT measured during the 1-RTT connection, but still 213 reflects the characteristics of the latency on the network. 215 4. Extension activation 217 The BDP extension is protected by the same mechanism that protects 218 the exchange of the 0-RTT transport parameters. A client that 219 activates 0-RTT data sends back the transport parameters received 220 from the server during the previous connection (see Section 7.3.1 of 221 [I-D.ietf-quic-transport]). 223 The client reads the parameters in the BDP metadata extension, but 224 can not change them. 226 Accept: A client MAY use the extension parameters. Then, it 227 activates ingress optimization and sends back the transport 228 parameters of the BDP metadata extension that it received from the 229 server during the previous connection. 231 Refuse: A client could choose not to use there parameters. Then, it 232 does not support ingress optimisation and drops the extension signal. 233 A client that disagrees with the extension parameters received from 234 the server refuses the optimization. 236 5. Discussion 238 5.1. Relevance of the transport parameter 240 The recon_bytes_in_flight parameter is higher than the number of 241 bytes in the actual BDP since it may include bytes in buffers along 242 the path. That being said, the recon_bytes_in_fight may be lower 243 than the actual value at the end of a connection since there may be a 244 low amount of data to send to terminate the transmission. 246 5.2. The client point-of-view 248 The client can read the values of the extension. The client may want 249 to reject the extension, to accept and adapt the resource and flow 250 control parameters or adapt requests. The client cannot change the 251 values of the extension. 253 5.3. BDP extension protected as Much as initial_max_data 255 The BDP metadata parameters are measured by the server during a 256 previous connection. The BDP extension is protected by the mechanism 257 that protects the exchange of the 0-RTT transport parameters. For 258 the version 1 of QUIC, the BDP extension is protected using the 259 mechanism that already protects the "initial_max_data" parameter. 260 This is defined in sections 4.5 to 4.7 of [I-D.ietf-quic-tls]. It 261 provides the server with a way to check the parameters proposed by 262 the client are those that the server sent to the client during the 263 previous connection. 265 5.4. Congestion control safety 267 The maximum number of initial data packets that can be sent without 268 acknowledgment needs to be chosen to avoid congestion collapse. A 269 mechanism is needed to ensure that the information sent by the server 270 is relevant and that network conditions have not changed. The client 271 cannot change the values of the extension. 273 The initial window is considered a safe starting point for an unknown 274 path to avoid adding congestion to a congested network. If the 275 reception of IW is confirmed for the first RTT of data, and also the 276 path is determined to be similar to that of a recent previous session 277 (e.g., similar RTT), the method permits the sender to use the 278 previous path information as an input to help determine a new safe 279 rate. Another safety net could be the pacing of packets as a 280 function of the estimated RTT. This follows the ideas of 281 [I-D.cardwell-iccrg-bbr-congestion-control] and [RFC4782]. 283 6. Acknowledgments 285 The authors would like to thank Gabriel Montenegro, Patrick McManus, 286 Ian Swett, Igor Lubashev, Christian Huitema and Tom Jones for their 287 fruitful comments on earlier versions of this document. 289 7. IANA Considerations 291 TBD: Text is required to register the extension BDP_metadata field. 292 Parameters are registered using the procedure defined in 293 [I-D.ietf-quic-transport]. 295 8. Security Considerations 297 The BDP metadata parameters are measured by the server during a 298 previous connection. 300 The BDP extension is protected by the mechanism that protects the 301 exchange of the 0-RTT transport parameters. For the version 1 of 302 QUIC, the BDP extension is protected using the mechanism that already 303 protects the "initial_max_data" parameter. This is defined in 304 sections 4.5 to 4.7 of [I-D.ietf-quic-tls]. It provides the server 305 with a way to check the parameters proposed by the client are those 306 that the server sent to the client during the previous connexion. 308 9. Informative References 310 [CONEXT15] 311 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 312 Flows Quickly and Safely", ACM CoNEXT , 2015. 314 [I-D.cardwell-iccrg-bbr-congestion-control] 315 Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, 316 "BBR Congestion Control", draft-cardwell-iccrg-bbr- 317 congestion-control-00 (work in progress), July 2017. 319 [I-D.ietf-quic-recovery] 320 Iyengar, J. and I. Swett, "QUIC Loss Detection and 321 Congestion Control", draft-ietf-quic-recovery-34 (work in 322 progress), January 2021. 324 [I-D.ietf-quic-tls] 325 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 326 draft-ietf-quic-tls-34 (work in progress), January 2021. 328 [I-D.ietf-quic-transport] 329 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 330 and Secure Transport", draft-ietf-quic-transport-34 (work 331 in progress), January 2021. 333 [I-D.ietf-tcpm-2140bis] 334 Touch, J., Welzl, M., and S. Islam, "TCP Control Block 335 Interdependence", draft-ietf-tcpm-2140bis-07 (work in 336 progress), December 2020. 338 [I-D.irtf-iccrg-sallantin-initial-spreading] 339 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 340 E., and A. Beylot, "Safe increase of the TCP's Initial 341 Window Using Initial Spreading", draft-irtf-iccrg- 342 sallantin-initial-spreading-00 (work in progress), January 343 2014. 345 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 346 RFC 2914, DOI 10.17487/RFC2914, September 2000, 347 . 349 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 350 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 351 January 2007, . 353 [TMA18] Ruth, J. and O. Hohlfeld, "Demystifying TCP Initial Window 354 Configurations of Content Distribution Networks", 2018 355 Network Traffic Measurement and Analysis Conference 356 (TMA) , 2018. 358 Appendix A. Example of server solution 360 This section details a solution at the server to safely increase the 361 maximum amount of packets that the server sends when receiving a 362 0-RTT packet from a client. 364 The initial window is considered a safe starting point for an unknown 365 path to avoid adding congestion to a congested network. The general 366 assumption is that a path does not currently suffer persistent 367 congestion, and therefore the initial window is applicable until 368 feedback about the path is received. The resulting initial sending 369 rate is only tentative until the capacity is confirmed to be 370 available. If there is loss within this initial transmission, then 371 this could be evidence that the path is congested, and the sender 372 needs to adjust to this congestion. 374 Significant loss could be an indication of congestion collapse - i.e. 375 persistent loss, requiring back-off of the sending rate. 377 If however, the reception of IW is confirmed for the first RTT of 378 data, and also the path is determined to be similar to that of a 379 recent previous session (e.g., similar RTT), the method permits the 380 sender to use the previous path information as an input to help 381 determine a new safe rate. One possibility is to immediately jump to 382 a new sending rate that is derived from the previously sustained 383 rate. This follows the ideas of 384 [I-D.cardwell-iccrg-bbr-congestion-control] and [RFC4782]. 386 The QoS mechanisms that are deployed in the networks can help in 387 prevent the congestion collapse from occurring. However, the sender 388 must provide a significant reduction if there is evidence of 389 potential congestion collapse [RFC2914] from his point of view. 390 Precautions can be taken to guarantee that it is reasonably safe to 391 jump to a high sending rate : measuring that network conditions did 392 not change, allowing some space for other flows that have started and 393 pace transmission of packets. The sender might need to rapidly 394 reduce its rate, if the higher sending rate does not prove to be 395 supported. It if is supported, the sender can resume standard 396 congestion control. 398 Authors' Addresses 400 Nicolas Kuhn 401 CNES 403 Email: nicolas.kuhn@cnes.fr 405 Emile Stephan 406 Orange 408 Email: emile.stephan@orange.com 410 Gorry Fairhurst 411 University of Aberdeen 413 Email: gorry@erg.abdn.ac.uk 415 Tom Jones 416 University of Aberdeen 418 Email: tom@erg.abdn.ac.uk