idnits 2.17.1 draft-kuhn-quic-0rtt-bdp-01.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 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 (March 11, 2019) is 1870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-ticketrequests' is defined on line 355, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 == Outdated reference: A later version (-07) exists of draft-ietf-tls-ticketrequests-00 Summary: 0 errors (**), 0 flaws (~~), 8 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: September 12, 2019 Orange 6 March 11, 2019 8 Transport parameters for 0-RTT connections 9 draft-kuhn-quic-0rtt-bdp-01 11 Abstract 13 0-RTT is designed to accelerate the egress throughput at the 14 establishment of a connection. There are cases where 0-RTT alone 15 does not improve the time-to-service. 17 This memo discusses a solution where a fundamental characteristic of 18 the path is learned during the 1-RTT phase and shared with the 0-RTT 19 phase to accelerate the initial throughput during subsequent 0-RTT 20 connections. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. QUIC connection establishment . . . . . . . . . . . . . . . . 3 58 3. Large BDP connections . . . . . . . . . . . . . . . . . . . . 3 59 4. TCP split solution . . . . . . . . . . . . . . . . . . . . . 4 60 5. End-to-end solution . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Description of the extension in the NewSessionTicket . . 4 62 5.2. Usage of the extension in the NewSessionTicket . . . . . 5 63 6. Best current practice . . . . . . . . . . . . . . . . . . . . 5 64 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 12.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 0-RTT is designed to accelerate the throughput at the establishment 77 of a connection. There are cases where 0-RTT alone does not improve 78 the time-to-service. 80 As shown in [IJSCN19], the usage of a congestion control and 81 transport initialization not adapted to satellite communication 82 results in higher page loading time for heavy pages in a SATCOM 83 context. QUIC's congestion control is based on TCP NewReno 84 [I-D.ietf-quic-recovery] and the recommended initial window is 85 defined by [RFC6928]. This may not be suitable for good quality of 86 experience for users in high Bandwidth Delay-Product (BDP) networks. 88 This memo discusses a solution where a fundamental characteristic of 89 the path is learned during the 1-RTT phase and shared with the 0-RTT 90 phase to accelerate the initial throughput during subsequent 0-RTT 91 connections. 93 2. QUIC connection establishment 95 This section recalls how 1-RTT and 0-RTT work. 97 QUIC leverages the 2 handshakes of TLS1.3 [I-D.ietf-quic-tls]. The 98 1-RTT handshake initiates a first set of credentials. When a 99 handshake achieves successfully, the server pushes information 100 learned about the session to the client in an opaque session ticket 101 (see section 4.6.1 of [RFC8446]). The pieces of information of the 102 ticket are meaningless to the client. A client willing to establish 103 a fast re-opening of the session pushes back this opaque 'ticket' in 104 a 0-RTT handshake and sends early application data. 106 In practice, the server sends the 'ticket' in a NewSessionTicket 107 record [I-D.ietf-quic-tls]. The structure of the NewSessionTicket 108 includes the opaque 'ticket' and an 'extensions' field. The 109 NewSessionTicket carries an additional field named 'early_data' which 110 indicates to the client the maximal size of application data to 111 insert in the 0-RTT message. 113 3. Large BDP connections 115 GEO-satellite based systems characteristics differ from terrestrial 116 networks with: 118 o A large propagation delay of at least 250ms one-way delay; 120 o A high bit-rate in case of mobile users or when a user connects 121 behind a box using Wi-Fi; 123 o Highly asymmetric links. 125 These characteristics have an impact on end-to-end congestion 126 controls: 128 o Transport initialization: the 3-way handshake takes a long time 129 reducing the time at which actual data can be transmitted; 131 o Maximum windows sizing: to fully exploit the bottleneck capacity, 132 the high BDP may induce an important number of in-flights packets; 134 o Reliability: packet losses detection and correction is slow and 135 the time needed for the end server to react to a congestion event 136 may not be relevant; 138 o Getting up to speed: the exponential increase of the data rate 139 transmission for a channel capacity probing is slowed down when 140 the RTT is high. 142 4. TCP split solution 144 High BDP networks commonly break the TCP end-to-end paradigm to adapt 145 the transport protocol. Splitting TCP allows adaptations to this 146 specific use-case and assessing the issues discussed in section 147 Section 3. PEP [RFC3135] are commonly deployed in SATCOM 148 infrastructure for that purpose and their deployment can result in 149 50% page load time reduction in a SATCOM use-case [ICCRG100]. 151 [NCT13] and [RFC3135] describe the main functionalities of SATCOM TCP 152 split solutions. Shortly, for traffic going from a gateway to an end 153 user behind a terminal, the TCP split intercepts TCP SYN to act as 154 the end user and adapt the data rate transmission to the SATCOM 155 scenario. The TCP split specifically tune the TCP parameters to the 156 context (latency, available capacity) that is measured. 158 One important advantage of a TCP split solution is that it does not 159 require any end-to-end modifications and is independent for both 160 client and server sides. That being said, this comes with a 161 drawback: TCP splitters can hardly embed the most recent end-to-end 162 improvements (e.g. ECN or TCP Fast Open support). 164 5. End-to-end solution 166 This section proposes an improvement of the initialization of 0-RTT 167 connections over satellite communication where the client recalls the 168 BDP previously measured by the server during the 1-RTT handshake. 169 The approach follows the tuning of the initial window described in 170 [I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to 171 improve performance both for high BDP and more common BDP 172 [CONEXT15][ICC16]. 174 5.1. Description of the extension in the NewSessionTicket 176 A new extension named "BDP_data" is defined for NewSessionTicket. It 177 contains the following value: BDP_value, that is the value in bits 178 (same unit as [RFC6349]). The reception of the field BDP_data 179 provides the client with 3 indications: 181 o The path with this server has a large BDP; 183 o The server added the path characteristics in the opaque 'ticket' 184 field; 186 o The server will optimize the reopening of the session upon 187 reception of this opaque ticket. 189 5.2. Usage of the extension in the NewSessionTicket 191 A server measures a connection BDP far larger than usual. It 192 includes the path characteristics in the opaque ticket it sends to 193 the client in a NewSessionTicket message. The message includes an 194 additional 'extensions' field named 'BDP_data'. The client stores 195 the session ticket and the 'BDP_data' field. 197 When the client reconnects to this server in 0-RTT mode, it pushes 198 back this session ticket in the ClientHello and prepares itself to 199 receive data in the context given by the 'BDP_data' field (The client 200 does not send the 'BDP_data' field back to the server). The server 201 receives the session ticket and extracts the BDP context. It uses 202 this information to provide a throughput closer to the capacity of 203 the path. 205 As the validity of the path characteristics may change over the time 206 the server sets the age of the ticket (see section 4.2.11.1 of 207 [RFC8446]) to a short duration or updates the ticket when the path 208 characteristics of the current connection changes. 210 6. Best current practice 212 This section provides examples of data that could be added in the 213 opaque ticket field by the server. The details added by the server 214 in the session ticket do not need to be standardized for 215 interoperability between QUIC clients and servers because it is 216 opaque to the client. The presence of the "BDP_data" extension field 217 in the NewSessionTicket informs the client that the server will 218 actively take action to improve its throughput when the session will 219 restart. 221 Here are examples of information elements set by the server in the 222 session ticket to accompany the signaling of field. These examples 223 are illustrated in Figure 1 and their purpose is detailed in this 224 section. 226 o client aware of the high BDP: The section 7.3.1 of 227 [I-D.ietf-quic-transport] indicates that the "A client that 228 attempts to send 0-RTT data MUST remember the transport parameters 229 used by the server". On top of other transport parameters used by 230 the server, knowing that the BDP is high let the client adapt 231 parameters specifically. As example, the client could adapt the 232 ACK ratio following the discussion in Issue 1978 of the GITHUB 233 repository. 235 o PMTU: The knowledge of the MTU of the previous path improves the 236 time to service because it reduces the duration of the path 237 validation process described in section 8.2 of 238 [I-D.ietf-quic-transport]. 240 o connection RTT: The knowledge of the characteristics of the 241 previous connection RTT improves the throughput because the server 242 can safely improve the slow start: e.g. using pacing models of 243 [I-D.irtf-iccrg-sallantin-initial-spreading] can result in high IW 244 for high RTT paths and a common IW for paths with smaller RTT. 245 The results presented in [ICC16] show that for both files of 15 kB 246 and 750 kB, the proposed solution reduces the time to download by 247 approximatively 2 seconds whether the RTT is 50ms or 500ms. 249 o ticket_lifetime: The server sets a shorter validity duration to 250 avoid receiving obsolete path characteristics later; as an example 251 it reduces the validity to one day. 253 CLIENT SERVER 254 +-----------------------------------+ 255 | 1 RTT connection | 256 +--+------------------------------+-+ 257 | | 258 +<---1-RTT TLS1.3 HANDSHAKE--->+ 259 | | +------------+ 260 +<-----data transmission------>+ |path charact| 261 | | |record | 262 | | +------------+ 263 |<-------------NewSessionTicket+ 264 Client aware | +ticket_lifetime | 265 of high BDP | +'opaque' field | 266 path | + ... | 267 | + PMTU | 268 | + connection RTT | 269 | +'extension' field | 270 | + early_data | 271 | + BDP_data | 272 | | 273 +-----------------------------------+ 274 | 0 RTT connection | 275 +-----------------------------------+ 276 | | 277 +ClientHello------------------>| 278 |+'opaque' field | +-------------------+ 279 | + ... | |param adaptation | 280 | + PMTU | |e.g. | 281 | + connection RTT | |tuned and paced IW | 282 | | +-------------------+ 283 | | 284 +<----+data transmission+----->+ 285 | | 286 + + 288 Figure 1: Example of opaque ticket content 290 7. Discussion 292 The proposal made in this draft follows the approach of the extension 293 field 'early_data' of the NewSessionTicket of TLS1.3. While 294 'early_data' improves the egress traffic of a client, the 'BDP_data' 295 proposal aims at improving its ingress traffic. Improving the 296 ingress traffic of an end user can result in drastic quality-of- 297 experience improvements. As example, this contribution enables the 298 exploitation of the RTT, PMTU and BDP to adapt the initial data 299 transmission of a 0-RTT connection to halve the page load time of a 300 web page download. 302 8. Acknowledgements 304 None. 306 9. Contributors 308 None. 310 10. IANA Considerations 312 TBD: text is required to register the extension BDP_data field. 314 11. Security Considerations 316 The security is provided by the 1-RTT phase. The measure of BDP is 317 made during a previous connection. The exchange and the information 318 are protected both by the TLS encryption and the NewSessionTicket 319 (see section 4.6.1 of [RFC8446]). 321 The BDP information the server will received is protected in the 322 opaque session ticket. The 'BDP_data' field is visible by the client 323 only. An client which does not trust the server transport adaptation 324 ignores any session ticket associated to a 'BDP_data' field. 326 12. References 328 12.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 12.2. Informative References 337 [CONEXT15] 338 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 339 Flows Quickly and Safely", ACM CoNEXT , 2015. 341 [I-D.ietf-quic-recovery] 342 Iyengar, J. and I. Swett, "QUIC Loss Detection and 343 Congestion Control", draft-ietf-quic-recovery-18 (work in 344 progress), January 2019. 346 [I-D.ietf-quic-tls] 347 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 348 draft-ietf-quic-tls-18 (work in progress), January 2019. 350 [I-D.ietf-quic-transport] 351 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 352 and Secure Transport", draft-ietf-quic-transport-18 (work 353 in progress), January 2019. 355 [I-D.ietf-tls-ticketrequests] 356 Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket 357 Requests", draft-ietf-tls-ticketrequests-00 (work in 358 progress), January 2019. 360 [I-D.irtf-iccrg-sallantin-initial-spreading] 361 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 362 E., and A. Beylot, "Safe increase of the TCP's Initial 363 Window Using Initial Spreading", draft-irtf-iccrg- 364 sallantin-initial-spreading-00 (work in progress), January 365 2014. 367 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 368 E., and A-L. Beylot, "Reducing web latency through TCP IW: 369 Be smart", IEEE ICC , 2016. 371 [ICCRG100] 372 Kuhn, N., "MPTCP and BBR performance over Internet 373 satellite paths", IETF ICCRG 100, 2017. 375 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 376 QUIC performance over a public SATCOM access", 377 International Journal of Satellite Communications and 378 Networking , 2019. 380 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 381 performances over geostationary satellite link", Network 382 and Communication Technologies , 2013. 384 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 385 Shelby, "Performance Enhancing Proxies Intended to 386 Mitigate Link-Related Degradations", RFC 3135, 387 DOI 10.17487/RFC3135, June 2001, 388 . 390 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 391 "Framework for TCP Throughput Testing", RFC 6349, 392 DOI 10.17487/RFC6349, August 2011, 393 . 395 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 396 "Increasing TCP's Initial Window", RFC 6928, 397 DOI 10.17487/RFC6928, April 2013, 398 . 400 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 401 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 402 . 404 Authors' Addresses 406 Nicolas Kuhn (editor) 407 CNES 408 18 Avenue Edouard Belin 409 Toulouse 31400 410 France 412 Email: nicolas.kuhn@cnes.fr 414 Emile Stephan (editor) 415 Orange 416 2, avenue Pierre Marzin 417 Lannion 22300 418 France 420 Email: emile.stephan@orange.com