idnits 2.17.1 draft-kuhn-quic-0rtt-bdp-00.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 (March 5, 2019) is 1879 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-ticketrequests' is defined on line 277, 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 6, 2019 Orange 6 March 5, 2019 8 Transport parameters for 0-RTT connections 9 draft-kuhn-quic-0rtt-bdp-00 11 Abstract 13 0-RTT is designed to accelerate the throughput at the establishment 14 of a connection. There are cases where 0-RTT alone does not improve 15 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 6, 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 . . . . . . . . . . . . . . . . 2 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. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 11.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 0-RTT is designed to accelerate the throughput at the establishment 76 of a connection. There are cases where 0-RTT alone does not improve 77 the time-to-service. 79 As shown in [IJSCN19], the usage of a congestion control and 80 transport initialization not adapted to satellite communication 81 results in higher page loading time for heavy pages in a SATCOM 82 context. QUIC's congestion control is based on TCP NewReno 83 [I-D.ietf-quic-recovery] and the recommended initial window is 84 defined by [RFC6928]. This may not be suitable for good quality of 85 experience for users in high Bandwidth Delay-Product (BDP) networks. 87 This memo discusses a solution where a fundamental characteristic of 88 the path is learned during the 1-RTT phase and shared with the 0-RTT 89 phase to accelerate the initial throughput during subsequent 0-RTT 90 connections. 92 2. QUIC connection establishment 94 This section recalls how 1-RTT and 0-RTT work. 96 QUIC leverages the 2 handshakes of TLS1.3 [I-D.ietf-quic-tls]. The 97 1-RTT handshake initiates a first set of credentials. When a 98 handshake achieves successfully, the server pushes information 99 learned about the session to the client in an opaque session ticket 100 (see section 4.6.1 of [RFC8446]). The pieces of information of the 101 ticket are meaningless to the client. A client willing to establish 102 a fast re-opening of the session pushes back this opaque 'ticket' in 103 a 0-RTT handshake and sends early application data. 105 In practice, the server sends the 'ticket' in a NewSessionTicket 106 record [I-D.ietf-quic-tls]. The structure of the NewSessionTicket 107 includes the opaque 'ticket' and an 'extensions' field. The 108 NewSessionTicket carries an additional field named 'early_data' which 109 indicates to the client the maximal size of application data to 110 insert in the 0-RTT message. 112 3. Large BDP connections 114 GEO-satellite based systems characteristics differ from terrestrial 115 networks with: 117 o A large propagation delay of at least 250ms one-way delay; 119 o A high bit-rate in case of mobile users or when a user connects 120 behind a box using Wi-Fi; 122 o Highl asymmetric links. 124 These characteristics have an impact on end-to-end congestion 125 controls: 127 o Transport initialization: the 3-way handshake takes a long time 128 reducing the time at which actual data can be transmitted; 130 o Maximum windows sizing: to fully exploit the bottleneck capacity, 131 the high BDP may induce an important number of in-flights packets; 133 o Reliability: packet losses detection and correction is slow and 134 the time needed for the end server to react to a congestion event 135 may not be relevant; 137 o Getting up to speed: the exponential increase of the data rate 138 transmission for a channel capacity probing is slowed down when 139 the RTT is high. 141 4. TCP split solution 143 High BDP networks commonly break the TCP end-to-end paradigm to adapt 144 the transport protocol. Splitting TCP allows adaptations to this 145 specific use-case and assessing the issues discussed in section 146 Section 3. PEP [RFC3135] are commonly deployed in SATCOM 147 infrastructure for that purpose and their deployment results in lower 148 page load times [ICCRG100] in a SATCOM use-case. 150 [NCT13] and [RFC3135] describe the main functionalities of SATCOM TCP 151 split solutions. Shortly, for traffic going from a gateway to an end 152 user behind a terminal, the TCP split intercepts TCP SYN to act as 153 the end user and adapt the data rate transmission to the SATCOM 154 scenario. The TCP split specifically tune the TCP parameters to the 155 context (latency, available capacity) that is measured. 157 One important advantage of a TCP split solution is that it does not 158 require any end-to-end modifications and is independent for both 159 client and server sides. That being said, this comes with a 160 drawback: TCP splitters can hardly embed the most recent end-to-end 161 improvements (e.g. ECN or TCP Fast Open support). 163 5. End-to-end solution 165 This section proposes an improvement of the initialization of 0-RTT 166 connections over satellite communication where the client recalls the 167 BDP previously measured by the server during the 1-RTT handshake. 168 The approach follows the tuning of the initial window described in 169 [I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to 170 improve performance both for high BDP and more common BDP 171 [CONEXT15][ICC16]. 173 5.1. Description of the extension in the NewSessionTicket 175 A new extension named "BDP_data" is defined for NewSessionTicket. It 176 contains the following value: BDP_value, that is the value in in bits 177 per second (same unit as [RFC6349]). The reception of the field 178 BDP_data provides the client with 3 indications: 180 o The path with this server has a large BDP; 182 o The server added the path characteristics in the opaque 'ticket' 183 field; 185 o The server will optimize the reopening of the session upon 186 reception of this opaque ticket. 188 5.2. Usage of the extension in the NewSessionTicket 190 A server measures a connection BDP far larger than usual. It 191 includes the path characteristics in the opaque ticket it sends to 192 the client in a NewSessionTicket message. The message includes an 193 additional 'extensions' field named 'BDP_data'. The client stores 194 the session ticket and the 'BDP_data' field. 196 When the client reconnects to this server in 0-RTT mode, it pushes 197 back this session ticket in the ClientHello and prepares itself to 198 receive data in the context given by the 'BDP_data' field (The client 199 does not send the 'BDP_data' field back to the server). The server 200 receives the session ticket and extracts the BDP context. It uses 201 this information to provide a throughput closer to the capacity of 202 the path. 204 As the validity of the path characteristics may change over the time 205 the server sets the age of the ticket (see section 4.2.11.1 of 206 [RFC8446]) to a short duration or updates the ticket when the path 207 characteristics of the current connection changes. 209 6. Discussion 211 The proposal made in this draft follows the approach of the extension 212 field 'early_data' of the NewSessionTicket of TLS1.3. Deeper 213 adaptations of the QUIC congestion control can improve the end-user 214 experience in high BDP contexts but proposing it for other contexts 215 may not be relevant. Indeed, designing either the data-center or the 216 end-user stacks based on large BDP constraints can hardly be done if 217 the deployment is not dedicated to this context (such as it would be 218 the case with specific CDN). Adapting a generic data-center may not 219 be viable since it may result in too aggressive behavior for more 220 common BDP. Moreover, at the end-user side, adapting the stacks or 221 the browser has been proposed in the past but the maintenance is 222 complexed since web browsers' versions often change. 224 7. Acknowledgements 226 None. 228 8. Contributors 230 None. 232 9. IANA Considerations 234 TBD: text is required to register the extension BDP_data field. 236 10. Security Considerations 238 The security is provided by the 1-RTT phase. The measure of BDP is 239 made during a previous connection. The exchange and the information 240 are protected both by the TLS encryption and the NewSessionTicket 241 (see section 4.6.1 of [RFC8446]). 243 The BDP information the server will received is protected in the 244 opaque session ticket. The 'BDP_data' field is visible by the client 245 only. An client which does not trust the server transport adaptation 246 ignores any session ticket associated to a 'BDP_data' field. 248 11. References 250 11.1. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 11.2. Informative References 259 [CONEXT15] 260 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 261 Flows Quickly and Safely", ACM CoNEXT , 2015. 263 [I-D.ietf-quic-recovery] 264 Iyengar, J. and I. Swett, "QUIC Loss Detection and 265 Congestion Control", draft-ietf-quic-recovery-18 (work in 266 progress), January 2019. 268 [I-D.ietf-quic-tls] 269 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 270 draft-ietf-quic-tls-18 (work in progress), January 2019. 272 [I-D.ietf-quic-transport] 273 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 274 and Secure Transport", draft-ietf-quic-transport-18 (work 275 in progress), January 2019. 277 [I-D.ietf-tls-ticketrequests] 278 Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket 279 Requests", draft-ietf-tls-ticketrequests-00 (work in 280 progress), January 2019. 282 [I-D.irtf-iccrg-sallantin-initial-spreading] 283 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 284 E., and A. Beylot, "Safe increase of the TCP's Initial 285 Window Using Initial Spreading", draft-irtf-iccrg- 286 sallantin-initial-spreading-00 (work in progress), January 287 2014. 289 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 290 E., and A-L. Beylot, "Reducing web latency through TCP IW: 291 Be smart", IEEE ICC , 2016. 293 [ICCRG100] 294 Kuhn, N., "MPTCP and BBR performance over Internet 295 satellite paths", IETF ICCRG 100, 2017. 297 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 298 QUIC performance over a public SATCOM access", 299 International Journal of Satellite Communications and 300 Networking , 2019. 302 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 303 performances over geostationary satellite link", Network 304 and Communication Technologies , 2013. 306 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 307 Shelby, "Performance Enhancing Proxies Intended to 308 Mitigate Link-Related Degradations", RFC 3135, 309 DOI 10.17487/RFC3135, June 2001, 310 . 312 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 313 "Framework for TCP Throughput Testing", RFC 6349, 314 DOI 10.17487/RFC6349, August 2011, 315 . 317 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 318 "Increasing TCP's Initial Window", RFC 6928, 319 DOI 10.17487/RFC6928, April 2013, 320 . 322 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 323 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 324 . 326 Authors' Addresses 328 Nicolas Kuhn (editor) 329 CNES 330 18 Avenue Edouard Belin 331 Toulouse 31400 332 France 334 Email: nicolas.kuhn@cnes.fr 336 Emile Stephan (editor) 337 Orange 338 2, avenue Pierre Marzin 339 Lannion 22300 340 France 342 Email: emile.stephan@orange.com