idnits 2.17.1 draft-kuhn-quic-4-sat-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 (July 3, 2019) is 1759 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-tls' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-ticketrequests' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'IJSCN19' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC6349' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 350, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-07) exists of draft-ietf-tls-ticketrequests-01 Summary: 0 errors (**), 0 flaws (~~), 12 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 G. Fairhurst 5 Expires: January 4, 2020 University of Aberdeen 6 J. Border 7 Hughes Network Systems, LLC 8 E. Stephan 9 Orange 10 July 3, 2019 12 QUIC for SATCOM 13 draft-kuhn-quic-4-sat-00 15 Abstract 17 QUIC's congestion control is not designed for operating over an 18 Internet path with a high BDP. This limits the user experience. 19 Moreover, a path can combine satellites network segment together with 20 a wide variety of other network technologies (Ethernet, cable modems, 21 WiFi, cellular, radio links, etc): this complicates the 22 characteristics of the end-to-end path. If this is not addressed, 23 the end-to-end quality of experience will be degraded. 25 This memo identifies the characteristics of a SATCOM link that impact 26 the operation of the QUIC transport protocol and proposes best 27 current practice to ensure acceptable protocol performance. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 4, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Operating over a path with a large BDP . . . . . . . . . . . 3 65 3. TCP Split Solution . . . . . . . . . . . . . . . . . . . . . 4 66 4. Mechanisms that improve the performance of QUIC for SATCOM . 4 67 4.1. Getting up to speed . . . . . . . . . . . . . . . . . . . 4 68 4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.3. Maximum window . . . . . . . . . . . . . . . . . . . . . 5 70 4.4. ACK ratio . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 10.2. Informative References . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 The end-to-end performance of an application using an Internet path 84 can be impacted by the Bandwidth-Delay Product (BDP) of the links and 85 network devices forming the path. For instance, the page load time 86 for a complex page can be much larger when the path includes a 87 satellite link. A significant contribution to this reduced 88 performance arises from the initialisation and design of transport 89 mechanisms. QUIC's congestion control is based on TCP NewReno 90 [I-D.ietf-quic-recovery] and the recommended initial window is 91 defined by [RFC6928]. 93 Moreover, satellite communications (SATCOM) systems have long been 94 used to support point-to-point links and specialised networks. The 95 predominate current use is as a link-layer for Internet Protocols. 96 Typical example applications include: use as an access technology for 97 remote locations, backup and rapid deployment of new services, 98 transit networks and backhaul of various types of IP networks, and 99 provision to mobile (maritime, aircraft, etc.). The satellite IP 100 network segment usually only forms one part of the end-to-end path. 101 This means user traffic can experince a path that includes satellite 102 link together with a wide variety of other network technologies 103 (Ethernet, cable modems, WiFi, cellular, radio links, etc). Although 104 a user can sometimes know the presence of the satellite service, a 105 typical user does not deploy special software or applications because 106 they expect a satellite network is being used. Often a user is 107 unaware of the technologies underpinning the links forming the 108 network path. 110 This memo identifies the characteristics of a SATCOM link that impact 111 the operation of the QUIC transport protocol and proposes best 112 current practice to ensure acceptable protocol performance. 114 2. Operating over a path with a large BDP 116 GEO-satellite based systems characteristics differ from paths only 117 using terrestrial links in their path characteristics: 119 o A large propagation delay of at least 250ms one-way delay; 121 o Some systems can exhibit a high loss-rate (e.g. mobile users or 122 users behind a Wi-Fi link); 124 o Employ radio resource management (often using techniques similar 125 to cellular mobile or DOCSIS cable networks, but differing to 126 accommodate the satellite propagation delay); 128 o Links can be highly asymmetric (in terms of capacity and one-way 129 delay). 131 More information on satellite links characteristics can be found in 132 [RFC2488]. 134 These characteristics have an impact on the performance of end-to-end 135 congestion controls: 137 o Transport initialization: the 3-way handshake takes a long time to 138 complete, reducing the time at which actual data can be 139 transmitted; 141 o Size of windows required: to fully exploit the bottleneck 142 capacity, the high BDP may induce an important number of in- 143 flights packets; 145 o Reliability: packet loss detection and correction is slow (the 146 performance of end-to-end retransmission is also impacted when 147 using a high RTT path); 149 o Getting up to speed: the exponential increase of the data rate 150 during slow start for a channel capacity probing is slowed down 151 when the RTT is high. 153 3. TCP Split Solution 155 High BDP networks commonly break the TCP end-to-end paradigm to adapt 156 the transport protocol. Splitting TCP allows adaptations to this 157 specific use-case and assessing the issues discussed in section 158 Section 2. Satellite communications commonly deploy Performance 159 Enhancement Proxy (PEP) for compression, caching and TCP acceleration 160 services [RFC3135]. Their deployment can result in 50% page load 161 time reduction in a SATCOM use-case [ICCRG100]. 163 [NCT13] and [RFC3135] describe the main functions of SATCOM TCP split 164 solutions. Shortly, for traffic originated at a gateway to an 165 endpoint connected via a satellite terminal, the TCP split intercepts 166 TCP SYN packets to act on behalf of the endpoint and adapt the data 167 rate transmission to the SATCOM scenario. The split solution 168 specifically tunes the TCP parameters to the context (latency, 169 available capacity). The tuning can be achieved using a priori 170 information about the satellite system and/or by measuring the 171 properties of the network segment that includes the satellite system. 173 One important advantage of a TCP split solution is that it does not 174 require any end-to-end modifications and is independent for both 175 client and server sides. That being said, this comes with a 176 drawback: TCP splitters often are unable to track the most recent 177 end-to-end improvements (e.g. ECN or TCP Fast Open support). The 178 methods configured in the split proxy usually continue to be used 179 until a split solution is finally updated. This can delay/negate the 180 benefit of any end-to-end improvements. 182 4. Mechanisms that improve the performance of QUIC for SATCOM 184 4.1. Getting up to speed 186 3-way handshake takes a long time reducing the time at which actual 187 data can be transmitted. 189 The tuning of the initial window described in 190 [I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to 191 improve performance both for high BDP and more common BDP 192 [CONEXT15][ICC16]. 194 4.2. Reliability 196 Packet losses detection and correction is slow and the time needed 197 for the end server to react to a congestion event may not be 198 relevant. This happens when a user uses a Wi-Fi link to access a 199 SATCOM terminal. Although the benefits needed to weighed against the 200 additional capacity in introducing end-to-end FEC and the potential 201 to use link-local ARQ and/or link-adaptive FEC. 203 Introducing network coding in QUIC could help in recovering from the 204 residual Wi-Fi losses. 206 4.3. Maximum window 208 To fully exploit the bottleneck capacity, the high BDP may induce an 209 important number of in-flights packets. 211 4.4. ACK ratio 213 Asymmetry in capacity (or in the way capacity is granted to a flow) 214 can lead to cases where the throughput in one direction of 215 communication is restricted by the acknowledgement traffic flowing in 216 the opposite direction. The limitations of specific underlying 217 networks could be in terms of the volume of acknowledgement traffic 218 (limited return path capacity) or in the number of acknowledgement 219 packets (e.g., when a radio-resource management system has to track 220 channel usage) or both. 222 TCP Performance Implications of Network Path Asymmetry [RFC3449] 223 describes a range of mechanisms that can mitigate the impact of path 224 asymmetry. One simple method is to tell the remote endpoint to send 225 compound acknowledgments less frequently. A rate of one ACK every 226 RTT/4 can significantly reduce this traffic. 228 Many of these mitigations have been deployed in satellite systems, 229 often as a mechanism within a PEP. Despite their benefits over paths 230 with a high asymmetry of capacity, most mechanisms rely on being able 231 to inspect and/or modify the transport layer header information of 232 TCP ACK packets. This is not possible when the transport layer 233 information is encrypted. The QUIC transport specification may 234 evolve to allow the ACK Ratio to be adjusted. 236 5. Discussion 238 Many of the issues identified already exist for any encrypted 239 transport service that uses a path that employs encryption at the IP 240 layer. This includes endpoints that utilise IPsec at the network 241 layer, or use VPN technology over the satellite network segment. 242 These uses are unable to benefit from enhancement within the 243 satellite network segment, and often the user is unaware of the 244 presence of the satellite link on their path, except through 245 observing the impact it has on the performance they experience. 247 6. Acknowledgements 249 None. 251 7. Contributors 253 None. 255 8. IANA Considerations 257 TBD: text is required to register the extension BDP_data field. 259 9. Security Considerations 261 This document does not propose changes to the security functions 262 provided by the QUIC protocol. QUIC uses TLS encryption to protect 263 the transport header and its payload. Security is considered in the 264 "Security Considerations" of cited IETF documents. 266 10. References 268 10.1. Normative References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 10.2. Informative References 277 [CONEXT15] 278 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 279 Flows Quickly and Safely", ACM CoNEXT , 2015. 281 [I-D.ietf-quic-recovery] 282 Iyengar, J. and I. Swett, "QUIC Loss Detection and 283 Congestion Control", draft-ietf-quic-recovery-20 (work in 284 progress), April 2019. 286 [I-D.ietf-quic-tls] 287 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 288 draft-ietf-quic-tls-20 (work in progress), April 2019. 290 [I-D.ietf-quic-transport] 291 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 292 and Secure Transport", draft-ietf-quic-transport-20 (work 293 in progress), April 2019. 295 [I-D.ietf-tls-ticketrequests] 296 Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket 297 Requests", draft-ietf-tls-ticketrequests-01 (work in 298 progress), June 2019. 300 [I-D.irtf-iccrg-sallantin-initial-spreading] 301 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 302 E., and A. Beylot, "Safe increase of the TCP's Initial 303 Window Using Initial Spreading", draft-irtf-iccrg- 304 sallantin-initial-spreading-00 (work in progress), January 305 2014. 307 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 308 E., and A-L. Beylot, "Reducing web latency through TCP IW: 309 Be smart", IEEE ICC , 2016. 311 [ICCRG100] 312 Kuhn, N., "MPTCP and BBR performance over Internet 313 satellite paths", IETF ICCRG 100, 2017. 315 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 316 QUIC performance over a public SATCOM access", 317 International Journal of Satellite Communications and 318 Networking , 2019. 320 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 321 performances over geostationary satellite link", Network 322 and Communication Technologies , 2013. 324 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 325 Over Satellite Channels using Standard Mechanisms", 326 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 327 . 329 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 330 Shelby, "Performance Enhancing Proxies Intended to 331 Mitigate Link-Related Degradations", RFC 3135, 332 DOI 10.17487/RFC3135, June 2001, 333 . 335 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 336 Sooriyabandara, "TCP Performance Implications of Network 337 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 338 December 2002, . 340 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 341 "Framework for TCP Throughput Testing", RFC 6349, 342 DOI 10.17487/RFC6349, August 2011, 343 . 345 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 346 "Increasing TCP's Initial Window", RFC 6928, 347 DOI 10.17487/RFC6928, April 2013, 348 . 350 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 351 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 352 . 354 Authors' Addresses 356 Nicolas Kuhn 357 CNES 359 Email: nicolas.kuhn@cnes.fr 361 Godred Fairhurst 362 University of Aberdeen 364 Email: gorry@erg.abdn.ac.uk 366 John Border 367 Hughes Network Systems, LLC 369 Email: border@hns.com 370 Emile Stephan 371 Orange 373 Email: emile.stephan@orange.com