idnits 2.17.1 draft-kuhn-quic-0rtt-bdp-04.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 3, 2019) is 1629 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-ticketrequests' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'ICCRG100' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'NCT13' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC6349' is defined on line 493, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 == Outdated reference: A later version (-07) exists of draft-ietf-tls-ticketrequests-03 == Outdated reference: A later version (-02) exists of draft-kuehlewind-quic-substrate-01 == Outdated reference: A later version (-05) exists of draft-pauly-quic-datagram-04 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). 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: May 6, 2020 Orange 6 G. Fairhurst, Ed. 7 University of Aberdeen 8 November 3, 2019 10 Transport parameters for 0-RTT connections 11 draft-kuhn-quic-0rtt-bdp-04 13 Abstract 15 The time-to-service duration depends on both peers exchange 16 optimization. The peer initiating the connection may not be the one 17 which send data first. Moreover, clients may be resource-limited, 18 behind a low bandwidth or connected to a long-RTT network and may 19 need to adapt dynamically to improve data reception. Currently, each 20 side has its proprietary solution to measure and to store path 21 characteristics. Having a standard way to share these parameters 22 should improve the adaptation to a non standard path characteristics. 24 QUIC v1 specification already reflects this approach. Having a 25 symmetrical control of the optimization should reduce protocol 26 ossification. This memo proposes the sharing of the characteristics 27 of the path amongst the peer to reduce HTTP3 time-to-service for non 28 default transport situation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 6, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Reducing ossification with the proposed solution . . . . 4 66 2. Differences between 1-RTT and 0-RTT QUIC connections 67 establishment . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. An end-to-end Method . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Description of the BDP metadata extension . . . . . . . . 5 70 3.2. Usage of the extension in the NewSessionTicket . . . . . 6 71 4. Best current practice . . . . . . . . . . . . . . . . . . . . 6 72 5. What happens when BDP is used incorrectly? . . . . . . . . . 8 73 6. Relevance of the solution for QUIC and other protocols . . . 9 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Some network paths experience an increased time-to-service because 85 the default parameters controlling the initialization of the 86 transport and congestion control are not well-suited to the path 87 characteristics. QUIC's default congestion control is based on TCP 88 NewReno [I-D.ietf-quic-recovery] and the recommended initial window 89 is defined by [RFC6928]. A path with a large bandwidth delay product 90 can therefore significantly increase the time-to-service (e.g. a path 91 using satellite communication [IJSCN19] could observe a much longer 92 page load time for complex pages). The 0-RTT mechanism is designed 93 to accelerate the throughput when reconnecting to a peer where it has 94 (recently) learned information about the path characteristics. 96 However, there are cases where egress acceleration like 0-RTT 97 early_data alone does not improve the time-to-service and cases where 98 the data transmission is symmetrical or where clients are capacity- 99 limited: additional information can be beneficial. 101 As QUIC transport security is based on TLS1.3 [I-D.ietf-quic-tls], 102 this memo describes a solution where a BDP_metadata extension is 103 added to the NewSessionTicket of TLS1.3 [TO DO ADD REF]. The 104 BDP_metadata informs the client about path parameters so that both 105 the client and the server can contribute to the reduction of the 106 time-to-service. This data is protected from in the middle-attack 107 such as the 'early_data' extension. 109 1. the server learns characteristics of the path during a previous 110 connection; 112 2. the server sends this information to the client at any time 113 during the current connection, after the BDP_metadata parameters 114 are validated; 116 3. the client is permitted to discard the information (when the 117 validation period is too short, the information is found to be 118 inconsistent with its own path characteristics measurement, for a 119 device with limited buffer, etc.); 121 4. the server and the client can exploit the information to improve 122 the time-to-service during subsequent 0-RTT connections. 124 The current focus of this use is QUIC. However, the method can be 125 used with TLS1.3 over any transport (e.g., using this with TCP Fast 126 Open [RFC7413] or DTLS [RFC6347]. 128 This proposal follows both the approach of the extension field 129 'early_data' of the NewSessionTicket of TLS1.3 and its mapping in 130 QUIC. While 'early_data' improves the egress traffic of a client, 131 the 'BDP_metadata' provides information that can be used to improve 132 ingress traffic towards the client. This can result in significant 133 improvement to the quality-of-experience. For example, it enables 134 sending measured characteristics of the path, such as the RTT, PMTU 135 and BDP. This information can be used to adapt the initial data 136 transmission of a 0-RTT connection. In the case of a deployment 137 scenario with a large BDP, this can halve the page load time of a web 138 page download [TODO ADD REF]. 140 The proposal proposes to consider the same method for integrating 141 TLS1.3 extension in QUIC as it is done for early_data. For the 142 mapping of NewSessionTicket in QUIC, QUIC transports the 'early_data' 143 value outside the NewSessionTicket in the "initial_max_data" 144 transport parameters (see section 4.5 of [I-D.ietf-quic-tls]). 146 1.1. Reducing ossification with the proposed solution 148 While each client and server could implement a dedicated solution to 149 exchange and store path parameters, providing a standard method to 150 exchange this information helps provide symmetrical control of the 151 optimisation. This reduces protocol ossification. A client using 152 the method is informed about path parameters: allowing both the 153 client and the server to reduce the time-to-service for subsequent 154 connections. This improves symmetrical transmission of data and 155 reduces ossification of the protocol. Some advantages of the 156 proposed solution are the following. 158 1. It provides symmetrical control of the optimisation: as 159 extensions to HTTP3 envision server initiated request 160 [I-D.ietf-quic-http] the path adaptation ought to be symmetrical 161 and ought not to depend on policy of the peer in establishment. 162 The QUIC transport can be used for services beyond HTTP3, 163 including symmetrical services: where QUIC is considered as a 164 relevant candidate for setting up proxies or tunnels 165 [I-D.kuehlewind-quic-substrate] or for transmiting unreliable 166 datagram services [I-D.pauly-quic-datagram]. A client device 167 sought to be able to adapt to the path chosen by the server. A 168 subscription where the server sends data first, it is important 169 to dissociate the signalling (aka the initiator of the 170 connection) from the peer that first sends application data. 172 2. Using the path information reduces the need for operators to 173 deploy TCP-proxy and middleboxes, such as Performance-Enhancing 174 Proxy (PEP) [RFC2488][RFC3135] to compensate for the 175 characteristics of the paths: if both the client and server have 176 learned appropriate transport parameters, they can themselves 177 optimize the transport service by adapting the end-to-end 178 transport protocol to the current path. As example, specific 179 client-based adaptations can be developed, such as adapting the 180 ACK-ratio or increasing the receive buffer size. This reduces 181 the need to deploy middelboxes, and will result in less 182 ossifiication along Internet paths. 184 3. Improve inter-operability: while each client and server can have 185 their dedicated solution to store path parameters, having a 186 standard way of exchanging this information helps in reducing the 187 time-to-service when clients and servers are not provided by the 188 same company. Both sides can independently propose optimizations 189 to improve the ingress traffic. 191 2. Differences between 1-RTT and 0-RTT QUIC connections establishment 193 This section recalls how 1-RTT and 0-RTT operate in QUIC 194 [I-D.ietf-quic-transport]. 196 QUIC leverages the two handshakes of TLS1.3 [I-D.ietf-quic-tls]: The 197 1-RTT handshake initiates a first set of credentials. When this 198 handshake successfully completes, the server pushes the learned 199 information about the session to the client in an opaque session 200 ticket (see section 4.6.1 of [RFC8446]). The information within the 201 opaque ticket is encrypted by the server. When received, the 202 encrypted information is stored by the client (but is not readable by 203 the client). A session ticket can be sent at any time during the 204 connection and a server can send several session tickets in one 205 connection. A client wishing to establish a fast re-open of the 206 session pushes back the (stored) opaque ticket in its 0-RTT handshake 207 and sends early application data. 209 In practice, the server sends the 'ticket' in a NewSessionTicket 210 record [I-D.ietf-quic-tls]. The structure of the NewSessionTicket 211 includes the opaque 'ticket' and an 'extensions' field. The 212 NewSessionTicket carries an additional field named 'early_data' that 213 indicates to the client the maximum size of application data to 214 insert in the 0-RTT message. 216 3. An end-to-end Method 218 QUIC encryption of transport headers prevents the adding of 219 Performance-enhancing proxy (PEP). The BDP metadata extension may be 220 a substitute to PEP proxy [RFC2488], [RFC3135] when time-to-service 221 improvement requires acceleration of the refilling of client 222 application buffers. 224 The BDP_metadata extension allows a cient to recall the BDP metadata 225 previously measured by the server during the 1-RTT handshake when it 226 initializes a 0-RTT connection. The approach enables changes to a 227 congestion control method (e.g., tuning of the initial window for 228 high BDP networks, as described in 229 [I-D.irtf-iccrg-sallantin-initial-spreading]. This has been shown to 230 improve performance both for paths with a high BDP and a more common 231 BDP [CONEXT15][ICC16]. 233 3.1. Description of the BDP metadata extension 235 This section defines an extension named "BDP_metadata" for the 236 NewSessionTicket. This structure contains the following parameters: 237 BDP, MTU, RTT, loss-rate. 239 3.2. Usage of the extension in the NewSessionTicket 241 At the end of a 1-RTT connection, a server can send information in a 242 NewSessionTicket that describes the path to the client. The message 243 includes an additional 'extensions' field named 'BDP_metadata'. The 244 client stores this session ticket together with and the 245 'BDP_metadata' field. 247 When the client reconnects to the same server in 0-RTT mode, it 248 pushes back this session ticket in the ClientHello and prepares 249 itself to receive data in the context given by the 'BDP_metadata' 250 field. The client does not send the 'BDP_metadata' field back to the 251 server. The server receives the session ticket and extracts the BDP 252 context. As example, it can use this message to provide information 253 that may allow the congestion controller to provide a throughput 254 closer to the capacity of the path. 256 The path characteristics can and do change over time. The path 257 information can therefore become invalid for use in a subsequent 258 connection. The server MUST set the age of the ticket (see section 259 4.2.11.1 of [RFC8446]) to a short duration. To help ensure that the 260 ticket is still valid, the server SHOULD also verify the IP address 261 of the client. A server MAY update the ticket when the path 262 characteristics of connection are known to have changed. 264 4. Best current practice 266 This section provides examples of data that could be added in the 267 opaque session ticket field by the server. The details added by the 268 server in the session ticket do not need to be standardized for 269 interoperability between QUIC clients and servers because this 270 information is opaque to the client. The presence of the 271 "BDP_metadata" extension field in the NewSessionTicket informs the 272 client that the server can actively take action to improve its 273 throughput when the session will restart. 275 The following list describes information elements set by the server 276 in the session ticket to accompany the signaling of field. These 277 examples are illustrated in Figure 1 and their purpose is detailed in 278 this section. 280 o A client aware of a high BDP path: Section 7.3.1 of 281 [I-D.ietf-quic-transport] indicates that the "A client that 282 attempts to send 0-RTT data MUST remember the transport parameters 283 used by the server". In addition to the default transport 284 parameters used by the server, a server that knows that the path 285 has a large BDP can let the client adapt its parameters. 287 o PMTU: Knowledge of the PMTU of a previous path improves the time 288 to service because it reduces the duration of the path validation 289 process described in section 8.2 of [I-D.ietf-quic-transport]. 291 o Connection RTT: The knowledge of the characteristics of a previous 292 connection RTT can improve the throughput because a server can 293 safely improve the slow start: e.g. using the pacing models of 294 [I-D.irtf-iccrg-sallantin-initial-spreading] can utilise a larger 295 IW for high RTT paths and a default IW for paths with smaller RTT. 296 The results presented in [ICC16] show that for both files of 15 KB 297 and 750 KB, the proposed solution reduces the time to download by 298 approximatively 2 seconds whether the RTT is 50ms or 500ms. 300 o Ticket_lifetime: The server sets a shorter validity duration to 301 avoid receiving obsolete path characteristics; (e.g., this could 302 reduce the validity to one day). 304 CLIENT SERVER 305 +-----------------------------------+ 306 | 1 RTT connection | 307 +-----------------------------------+ 308 | | 309 +<---1-RTT TLS1.3 HANDSHAKE--->+ 310 | | +------------+ 311 +<-----data transmission------>+ |path charact| 312 | | |record | 313 | | +------------+ 314 |<-------------NewSessionTicket+ 315 +----------+ | +ticket_lifetime | 316 |client | | +'opaque' field | 317 |aware of | | +'extension' field | 318 |path | | + early_data | 319 |charat. | | + BDP_metadata | 320 +----------+ | + BDP | 321 | + RTT | 322 | + loss-rate | 323 | + MTU | 324 +-----------------------------------+ 325 | 0 RTT connection | 326 +-----------------------------------+ 327 | | 328 +ClientHello------------------>| 329 |+'opaque' field | 330 | | +-------------------+ 331 | | |server aware of | 332 | | |path charact. | 333 | | +-------------------+ 334 | | 335 +<----+data transmission+----->+ 336 | | 337 + + 339 Figure 1: Example of opaque ticket content 341 5. What happens when BDP is used incorrectly? 343 This section discusses the impact of a server activating the 344 'BDP_metadata' field when the network underneath actually has a small 345 BDP. This could happen when the server BDP estimate was incorrect, 346 when a client has multiple paths to choose from and uses the ticket 347 on a different path to which it was requested, or when the path 348 characteristics have changed significantly. 350 Incorrectly exploiting the BDP_metadata could result in pre-assigning 351 additional resources (e.g. transport buffer space) that later fails 352 to be used. Many endpoints implementations do not statically pre- 353 assign buffer space, so increasing the limit does not have an impact 354 when the resource is unused. Some cases could be resource-limited. 356 The server could adapt the initial window because it expects a high 357 BDP path, when the actual BDP is significantly smaller. This issue 358 can be mitigated when packets are paced from the server over the 359 associated RTT, since the server would receive an acknowledgment 360 after the actual RTT period, and before it has used the complete 361 initial window. 363 6. Relevance of the solution for QUIC and other protocols 365 The QUIC framework would allow solutions to have been proposed. As 366 an example, the NEW_TOKEN frame could be used to send the path 367 characteristics information to the client. However, this would 368 require specifying its content, consistently with QUIC transport 369 parameters, so that any client can exploit the information 370 transmitted by any server in a standard way. Moreover, the NEW_TOKEN 371 frame is not symmetrical (Clients MUST NOT send NEW_TOKEN frames) 372 does not enable the support of a symmetrical control of the 373 optimisation. 375 The proposed solution has been proposed with QUIC standardization in 376 mind, but is applicable to any transport under TLS1.3. 378 7. Acknowledgements 380 The authors would like to thank Gabriel Montenegro, Patrick McManus, 381 Ian Swett, Igor Lubashev and Christian Huitema for their fruitful 382 comments on earlier versions of this document. 384 8. IANA Considerations 386 TBD: text is required to register the extension BDP_metadata field. 388 9. Security Considerations 390 The security is provided by the 1-RTT phase. The measure of BDP is 391 made during a previous connection. The exchange and the information 392 are protected both by the TLS encryption and the NewSessionTicket 393 (see section 4.6.1 of [RFC8446]). 395 The BDP information the server will received is protected in the 396 opaque session ticket. The 'BDP_metadata' field is visible by the 397 client only. An client that does not trust the server transport 398 adaptation ignores any session ticket associated to a 'BDP_metadata' 399 field. 401 The server does not have to honour all the received requests (e.g. 402 when it is resource-limited). 404 10. References 406 10.1. Normative References 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 10.2. Informative References 415 [CONEXT15] 416 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 417 Flows Quickly and Safely", ACM CoNEXT , 2015. 419 [I-D.ietf-quic-http] 420 Bishop, M., "Hypertext Transfer Protocol Version 3 421 (HTTP/3)", draft-ietf-quic-http-23 (work in progress), 422 September 2019. 424 [I-D.ietf-quic-recovery] 425 Iyengar, J. and I. Swett, "QUIC Loss Detection and 426 Congestion Control", draft-ietf-quic-recovery-23 (work in 427 progress), September 2019. 429 [I-D.ietf-quic-tls] 430 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 431 draft-ietf-quic-tls-23 (work in progress), September 2019. 433 [I-D.ietf-quic-transport] 434 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 435 and Secure Transport", draft-ietf-quic-transport-23 (work 436 in progress), September 2019. 438 [I-D.ietf-tls-ticketrequests] 439 Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket 440 Requests", draft-ietf-tls-ticketrequests-03 (work in 441 progress), October 2019. 443 [I-D.irtf-iccrg-sallantin-initial-spreading] 444 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 445 E., and A. Beylot, "Safe increase of the TCP's Initial 446 Window Using Initial Spreading", draft-irtf-iccrg- 447 sallantin-initial-spreading-00 (work in progress), January 448 2014. 450 [I-D.kuehlewind-quic-substrate] 451 Kuehlewind, M., Sarker, Z., Fossati, T., and L. Pardue, 452 "Use Cases and Requirements for QUIC as a Substrate", 453 draft-kuehlewind-quic-substrate-01 (work in progress), 454 July 2019. 456 [I-D.pauly-quic-datagram] 457 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 458 Datagram Extension to QUIC", draft-pauly-quic-datagram-04 459 (work in progress), October 2019. 461 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 462 E., and A-L. Beylot, "Reducing web latency through TCP IW: 463 Be smart", IEEE ICC , 2016. 465 [ICCRG100] 466 Kuhn, N., "MPTCP and BBR performance over Internet 467 satellite paths", IETF ICCRG 100, 2017. 469 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 470 QUIC performance over a public SATCOM access", 471 International Journal of Satellite Communications and 472 Networking , 2019. 474 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 475 performances over geostationary satellite link", Network 476 and Communication Technologies , 2013. 478 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 479 Over Satellite Channels using Standard Mechanisms", 480 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 481 . 483 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 484 Shelby, "Performance Enhancing Proxies Intended to 485 Mitigate Link-Related Degradations", RFC 3135, 486 DOI 10.17487/RFC3135, June 2001, 487 . 489 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 490 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 491 January 2012, . 493 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 494 "Framework for TCP Throughput Testing", RFC 6349, 495 DOI 10.17487/RFC6349, August 2011, 496 . 498 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 499 "Increasing TCP's Initial Window", RFC 6928, 500 DOI 10.17487/RFC6928, April 2013, 501 . 503 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 504 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 505 . 507 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 508 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 509 . 511 Authors' Addresses 513 Nicolas Kuhn (editor) 514 CNES 516 Email: nicolas.kuhn@cnes.fr 518 Emile Stephan (editor) 519 Orange 521 Email: emile.stephan@orange.com 523 Gorry Fairhurst (editor) 524 University of Aberdeen 526 Email: gorry@erg.abdn.ac.uk