idnits 2.17.1 draft-kuhn-quic-4-sat-02.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 (November 3, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-tls' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-ticketrequests' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC6349' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 460, but no explicit reference was found in the text == 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 (-03) exists of draft-roca-nwcrg-rlc-fec-scheme-for-quic-01 == Outdated reference: A later version (-02) exists of draft-schinazi-masque-01 == Outdated reference: A later version (-04) exists of draft-swett-nwcrg-coding-for-quic-03 Summary: 0 errors (**), 0 flaws (~~), 14 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: May 6, 2020 University of Aberdeen 6 J. Border 7 Hughes Network Systems, LLC 8 E. Stephan 9 Orange 10 November 3, 2019 12 QUIC for SATCOM 13 draft-kuhn-quic-4-sat-02 15 Abstract 17 QUIC has been designed for use across Internet paths. Initial 18 designs of QUIC have focussed on common deployment scenarios for web 19 traffic and have not focussed on the performance when using a path 20 with a large Bandwidth-Delay Product (BDP). A path can combine 21 satellites network segment together with a wide variety of other 22 network technologies (Ethernet, cable modems, WiFi, cellular, radio 23 links, etc): this complicates the characteristics of the end-to-end 24 path. One example of such a scenario occurs when a satellite 25 communication (SATCOM) system is used to provide all or a part of the 26 end-to-end path. If this is not addressed, the end-to-end quality of 27 experience can be degraded. 29 This memo identifies the characteristics of a SATCOM link that impact 30 the operation of the QUIC transport protocol and proposes current 31 practice to ensure acceptable protocol performance. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 6, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Operating over a path with a large BDP . . . . . . . . . . . 3 69 3. TCP Split Solution . . . . . . . . . . . . . . . . . . . . . 5 70 4. Mechanisms that improve the performance of QUIC for SATCOM . 5 71 4.1. Getting up to speed . . . . . . . . . . . . . . . . . . . 5 72 4.2. Maximum window . . . . . . . . . . . . . . . . . . . . . 6 73 4.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.4. ACK ratio . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 77 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 10.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 The end-to-end performance of an application using an Internet path 88 can be impacted by the Bandwidth-Delay Product (BDP) of the links and 89 network devices forming the path. For instance, the page load time 90 for a complex page can be much larger when the path includes a 91 satellite link. A significant contribution to this reduced 92 performance arises from the initialisation and design of transport 93 mechanisms. QUIC's default congestion control is based on TCP 94 NewReno [I-D.ietf-quic-recovery] and the recommended initial window 95 is defined by [RFC6928]. Although QUIC's CC and recovery have been 96 designed for use across Internet Paths, the initial design could not 97 optimise for the wide diversity of path characteristics that can 98 occur. This document therefore considers the specific implications 99 of paths with a significant BDP. 101 Satellite communications (SATCOM) systems have long been used to 102 support point-to-point links and specialised networks. The 103 predominate current use is as a link-layer for Internet Protocols. 104 Typical example applications include: use as an access technology for 105 remote locations, backup and rapid deployment of new services, 106 transit networks and backhaul of various types of IP networks, and 107 provision to mobile (maritime, aircraft, etc.). In most scenarios, 108 the satellite IP network segment usually only forms one part of the 109 end-to-end path. This means user traffic can experience a path that 110 includes satellite link together with a wide variety of other network 111 technologies (Ethernet, cable modems, WiFi, cellular, radio links, 112 etc). Although a user can sometimes know the presence of the 113 satellite service, a typical user does not deploy special software or 114 applications because they expect a satellite network is being used. 115 Often a user is unaware of the technologies underpinning the links 116 forming the network path. 118 This memo identifies the characteristics of a SATCOM link that impact 119 the operation of the QUIC transport protocol and proposes best 120 current practice to ensure acceptable protocol performance. 122 2. Operating over a path with a large BDP 124 The characteristics of systems using Geosynchronous Earth Orbit (GEO) 125 satellites differ from paths only using terrestrial links in their 126 path characteristics: 128 o A large propagation delay of at least 250ms one-way delay; 130 o Employ radio resource management (often using techniques similar 131 to cellular mobile or DOCSIS cable networks, but differing to 132 accommodate the satellite propagation delay); 134 o Links can be highly asymmetric (in terms of capacity and one-way 135 delay). 137 Many systems use the DVB-S2 specifications, where the key concept is 138 to ensure both a good usage of the satellite resource and a Quasi 139 Error Free (QEF) link. It consists in monitoring the link quality in 140 real-time, with the help of known symbols sequences, included along 141 regular packets, on which an estimation of the current signal-to- 142 noise ratio can be done. Then, this estimation is send back to the 143 transmitter that can adapt its coding rate and modulation order to 144 best fit the actual transmission conditions. 146 It is common to consider the satellite network segment composed of a 147 forward link and a return link. The two links can have different 148 capacities and employ different technologies to carry the IP packets. 149 On the forward link, the satellite gateway uses all the available 150 bandwidth, possibly with several carriers, to communicate with the 151 remote terminals. A carrier is a single Time-Division-Multiplexing 152 where packets addressed to terminals are multiplexed. On the return 153 link, the satellite resource is shared among the users. Two access 154 methods can be distinguished: on-demand access or contention access. 155 In the former, a terminal receives dedicated resources on its own to 156 communicate with the gateway. In the latter, some resources are 157 reserved for contention access, where several terminals can compete 158 to obtain the resource. Dedicated access, which is more common in 159 currently deployed systems, can be through a Demand Assigned Multiple 160 Access (DAMA) mechanism, while contention access techniques are 161 usually based on Slotted Aloha (SA) and its numerous derivatives. 162 More information on satellite links characteristics can be found in 163 [RFC2488][IJSCN17]. 165 Beyond that, even for characteristics shared with terrestrial links, 166 the impact on a satellite link could be more and can be amplified by 167 the large RTT. For example, systems can exhibit a high loss-rate 168 (e.g. mobile users or users behind a Wi-Fi link) which would impact 169 loss recovery mechanisms and congestion control reaction to such loss 170 events. The characteristics of a GEO SATCOM system impact the 171 performance of congestion control: 173 o Transport initialization: the 3-way handshake takes a long time to 174 complete, delaying the time at which actual data can be 175 transmitted; 177 o Size of windows required: to fully exploit the bottleneck 178 capacity, a high BDP will increase the number of in-flights 179 packets; 181 o Reliability: packet loss detection and correction is slow (the 182 performance of end-to-end retransmission is also impacted when 183 using a high RTT path); 185 o Getting up to speed: the exponential increase of the data rate 186 during slow start for a channel capacity probing is slowed down 187 when the RTT is high; 189 o Asymetry : when the links are asymmetric, for various reasons, the 190 sizing of the return link may induce modifications of the 191 transport level acknowledgement traffic. 193 3. TCP Split Solution 195 High BDP networks commonly break the TCP end-to-end paradigm to adapt 196 the transport protocol. Splitting TCP allows adaptations to this 197 specific use-case and assessing the issues discussed in section 198 Section 2. Satellite communications commonly deploy Performance 199 Enhancement Proxy (PEP) for compression, caching and TCP acceleration 200 services [RFC3135]. Their deployment can result in 50% page load 201 time reduction in a SATCOM use-case [ICCRG100]. 203 [NCT13] and [RFC3135] describe the main functions of SATCOM TCP split 204 solutions. Shortly, for traffic originated at a gateway to an 205 endpoint connected via a satellite terminal, the TCP split intercepts 206 TCP SYN packets to act on behalf of the endpoint and adapt the data 207 rate transmission to the SATCOM scenario. The split solution 208 specifically tunes the TCP parameters to the context (latency, 209 available capacity) of each link. When a PEP is used on each side of 210 the satellite link, a protocol other than TCP, optimized for the 211 satellite link, may be used. The tuning can be achieved using a 212 priori information about the satellite system and/or by measuring the 213 properties of the network segment that includes the satellite system. 215 One important advantage of a TCP split solution is that it does not 216 require any end-to-end modifications and is independent for both 217 client and server sides. That being said, this comes with a 218 drawback: TCP splitters often are unable to track the most recent 219 end-to-end improvements in protocol mechanisms (e.g., RACK, ECN, TCP 220 Fast Open support) contributing to ossification of the transport 221 system. The methods configured in the split proxy usually continue 222 to be used until a split solution is finally updated. This can 223 delay/negate the benefit of any end-to-end improvements. 225 4. Mechanisms that improve the performance of QUIC for SATCOM 227 4.1. Getting up to speed 229 The advantage of using QUIC is that it includes the TLS and TCP 230 negociations that reduce the time at which the data can be 231 transmitted. That being said, results of [IJSCN19] illustrate that 232 it will take many RTTs for the congestion controller to increase the 233 rate before it fills the bottleneck capacity. This dominates 234 performance when a path has a large RTT (as in GEO SATCOM networks). 235 There is an issue in QUIC getting up to speed in a SATCOM context. 237 The tuning of the initial window described in 238 [I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to 239 improve performance both for high BDP and more common BDP 240 [CONEXT15][ICC16] could be a relevant solution. That being said, 241 such solution requires the usage of pacing to avoid important bursts 242 of packets in the network that does not have a large BDP. 244 4.2. Maximum window 246 A large number of in-flight packets are prewired to fully exploit the 247 bottleneck capacity, when there is a large BDP. Default values of 248 maximum windows may not be suitable for a SATCOM context. 250 Such as presented in [PANRG105], only increasing the initial 251 congestion window is not the only way that can improve QUIC 252 performance in a SATCOM context: increasing maximum congestion 253 windows can also result in much better performance. Other protocol 254 mechanisms also need to be considered, such as flow control at the 255 stream level in QUIC. 257 4.3. Reliability 259 Packet loss detection and loss repair take additional time on paths 260 with a larger RTT. This increases the time that a server needs to 261 react to a congestion event. Both can impact the user experience. 262 This happens when a user uses a Wi-Fi link to access a SATCOM 263 terminal. Although the benefits needed to weighed against the 264 additional capacity in introducing end-to-end FEC and the potential 265 to use link-local ARQ and/or link-adaptive FEC. End-to-end 266 connections may not only suffer from losses in the Wi-Fi segment but 267 also from congestion losses in the satellite operator ground segment. 268 Using the mechanisms proposed in 269 [I-D.ferrieux-hamchaoui-quic-lossbits], congestion losses have been 270 identified on the ground segment. 272 Introducing network coding in QUIC such as proposed in 273 [I-D.swett-nwcrg-coding-for-quic] and 274 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] could help in recovering 275 from the residual Wi-Fi or congestion losses. Another solution would 276 be the usage of QUIC tunnels [I-D.schinazi-masque]. 278 4.4. ACK ratio 280 Asymmetry in capacity (or in the way capacity is granted to a flow) 281 can lead to cases where the throughput in one direction of 282 communication is restricted by the acknowledgement traffic flowing in 283 the opposite direction. The limitations of specific underlying 284 networks could be in terms of the volume of acknowledgement traffic 285 (limited return path capacity) or in the number of acknowledgement 286 packets (e.g., when a radio-resource management system has to track 287 channel usage) or both. 289 TCP Performance Implications of Network Path Asymmetry [RFC3449] 290 describes a range of mechanisms that can mitigate the impact of path 291 asymmetry. One simple method is to tell the remote endpoint to send 292 compound acknowledgments less frequently. A rate of one ACK every 293 RTT/4 can significantly reduce this traffic. 295 Many of these mitigations have been deployed in satellite systems, 296 often as a mechanism within a PEP. Despite their benefits over paths 297 with a high asymmetry of capacity, most mechanisms rely on being able 298 to inspect and/or modify the transport layer header information of 299 TCP ACK packets. This is not possible when the transport layer 300 information is encrypted. The QUIC transport specification may 301 evolve to allow the ACK Ratio to be adjusted. 303 5. Discussion 305 Many of the issues identified already exist for any encrypted 306 transport service that uses a path that employs encryption at the IP 307 layer. This includes endpoints that utilise IPsec at the network 308 layer, or use VPN technology over the satellite network segment. 309 These uses are unable to benefit from enhancement within the 310 satellite network segment, and often the user is unaware of the 311 presence of the satellite link on their path, except through 312 observing the impact it has on the performance they experience. 314 One solution would be to provide PEP functions at the termination of 315 the security association (e.g., in a VPN client). Another solution 316 could be to fall-back to using TCP (possibly with TLS or similar 317 methods being used on the transport payload). A final solution could 318 be to deploy and maintain a bespoke protocol tailored to high BDP 319 environments. In the future, we anticipate that fall-back will 320 become less desirable, and methods that rely upon bespoke 321 configurations or protocols will be unattractive. In parallel, new 322 methods such as QUIC will become widely deployed. The opportunity 323 therefore exists to ensure that the new generation of protocols offer 324 acceptable performance over high BDP paths without requiring 325 operating tuning or specific updates by users. 327 6. Acknowledgements 329 TBD 331 7. Contributors 333 TBD 335 8. IANA Considerations 337 TBD 339 9. Security Considerations 341 This document does not propose changes to the security functions 342 provided by the QUIC protocol. QUIC uses TLS encryption to protect 343 the transport header and its payload. Security is considered in the 344 "Security Considerations" of cited IETF documents. 346 10. References 348 10.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 10.2. Informative References 357 [CONEXT15] 358 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 359 Flows Quickly and Safely", ACM CoNEXT , 2015. 361 [I-D.ferrieux-hamchaoui-quic-lossbits] 362 Ferrieux, A. and I. Hamchaoui, "The QUIC Loss Bits", 363 draft-ferrieux-hamchaoui-quic-lossbits-00 (work in 364 progress), April 2019. 366 [I-D.ietf-quic-recovery] 367 Iyengar, J. and I. Swett, "QUIC Loss Detection and 368 Congestion Control", draft-ietf-quic-recovery-23 (work in 369 progress), September 2019. 371 [I-D.ietf-quic-tls] 372 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 373 draft-ietf-quic-tls-23 (work in progress), September 2019. 375 [I-D.ietf-quic-transport] 376 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 377 and Secure Transport", draft-ietf-quic-transport-23 (work 378 in progress), September 2019. 380 [I-D.ietf-tls-ticketrequests] 381 Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket 382 Requests", draft-ietf-tls-ticketrequests-03 (work in 383 progress), October 2019. 385 [I-D.irtf-iccrg-sallantin-initial-spreading] 386 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 387 E., and A. Beylot, "Safe increase of the TCP's Initial 388 Window Using Initial Spreading", draft-irtf-iccrg- 389 sallantin-initial-spreading-00 (work in progress), January 390 2014. 392 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] 393 Roca, V., Swett, I., and M. Montpetit, "Sliding Window 394 Random Linear Code (RLC) Forward Erasure Correction (FEC) 395 Schemes for QUIC", draft-roca-nwcrg-rlc-fec-scheme-for- 396 quic-01 (work in progress), February 2019. 398 [I-D.schinazi-masque] 399 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 400 masque-01 (work in progress), July 2019. 402 [I-D.swett-nwcrg-coding-for-quic] 403 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 404 for QUIC", draft-swett-nwcrg-coding-for-quic-03 (work in 405 progress), July 2019. 407 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 408 E., and A-L. Beylot, "Reducing web latency through TCP IW: 409 Be smart", IEEE ICC , 2016. 411 [ICCRG100] 412 Kuhn, N., "MPTCP and BBR performance over Internet 413 satellite paths", IETF ICCRG 100, 2017. 415 [IJSCN17] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 416 and N. Kuhn, "Software-defined satellite cloud RAN", 417 International Journal of Satellite Communications and 418 Networking , 2017. 420 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 421 QUIC performance over a public SATCOM access", 422 International Journal of Satellite Communications and 423 Networking , 2019. 425 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 426 performances over geostationary satellite link", Network 427 and Communication Technologies , 2013. 429 [PANRG105] 430 Kuhn, N., Stephan, E., Border, J., and G. Fairhurst, "QUIC 431 Over In-sequence Paths with Different Characteristics", 432 IRTF PANRG 105, 2019. 434 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 435 Over Satellite Channels using Standard Mechanisms", 436 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 437 . 439 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 440 Shelby, "Performance Enhancing Proxies Intended to 441 Mitigate Link-Related Degradations", RFC 3135, 442 DOI 10.17487/RFC3135, June 2001, 443 . 445 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 446 Sooriyabandara, "TCP Performance Implications of Network 447 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 448 December 2002, . 450 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 451 "Framework for TCP Throughput Testing", RFC 6349, 452 DOI 10.17487/RFC6349, August 2011, 453 . 455 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 456 "Increasing TCP's Initial Window", RFC 6928, 457 DOI 10.17487/RFC6928, April 2013, 458 . 460 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 461 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 462 . 464 Authors' Addresses 466 Nicolas Kuhn 467 CNES 469 Email: nicolas.kuhn@cnes.fr 471 Godred Fairhurst 472 University of Aberdeen 474 Email: gorry@erg.abdn.ac.uk 475 John Border 476 Hughes Network Systems, LLC 478 Email: border@hns.com 480 Emile Stephan 481 Orange 483 Email: emile.stephan@orange.com