idnits 2.17.1 draft-kuhn-quic-4-sat-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2020) is 1245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-32 Summary: 1 error (**), 0 flaws (~~), 2 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 3, 2021 University of Aberdeen 6 J. Border 7 Hughes Network Systems, LLC 8 E. Stephan 9 Orange 10 October 30, 2020 12 QUIC for SATCOM 13 draft-kuhn-quic-4-sat-06 15 Abstract 17 QUIC has been designed for use across Internet paths. Initial 18 designs of QUIC focused on common deployment scenarios for web 19 traffic. This document focuses on the performance when using a path 20 with a large Bandwidth-Delay Product (BDP). 22 A large BDP path can result from using a satellite communication 23 (SATCOM) system. The BDP is also high for paths where a satellite 24 network segment is combined with other network technologies 25 (Ethernet, cable modems, WiFi, cellular, radio links, etc), resulting 26 in more complex characteristics. These path characteristics have 27 implications on the efficiency of the network traffic and unless 28 considered in a design can impact the end-to-end quality of 29 experience by the transport service. 31 This memo identifies the characteristics of a SATCOM link that impact 32 the operation of the QUIC transport protocol. It proposes regression 33 tests to evaluate QUIC over SATCOM links. It discusses how to ensure 34 acceptable protocol performance. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 3, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Operating over a path with a large BDP . . . . . . . . . . . 3 72 3. TCP Split Solution . . . . . . . . . . . . . . . . . . . . . 5 73 4. Regression tests . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Small public satellite broadband access . . . . . . . . . 6 75 4.2. Medium public satellite broadband access . . . . . . . . 7 76 4.3. Congested medium public satellite broadband access . . . 7 77 4.4. Variable medium public satellite broadband access . . . . 8 78 4.5. Loss-free large public satellite broadband access . . . . 9 79 4.6. Lossy large public satellite broadband access . . . . . . 9 80 5. Mechanisms that improve the performance of QUIC for SATCOM . 10 81 5.1. Getting up to speed . . . . . . . . . . . . . . . . . . . 10 82 5.2. Maximum window . . . . . . . . . . . . . . . . . . . . . 10 83 5.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.4. ACK ratio . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 9. Informative References . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 The end-to-end performance of an application using an Internet path 94 can be impacted by the Bandwidth-Delay Product (BDP) of the links and 95 network devices forming the path. For instance, the page load time 96 for a complex page can be much larger when the path includes a 97 satellite link. A significant contribution to this reduced 98 performance arises from the initialisation and design of transport 99 mechanisms. QUIC's default congestion control is based on TCP 100 NewReno [I-D.ietf-quic-recovery] and the recommended initial window 101 is defined by [RFC6928]. Although QUIC's Congestion Control (CC) and 102 recovery have been designed for use across Internet Paths, the 103 initial design could not optimise for the wide diversity of path 104 characteristics that can occur. This document therefore considers 105 the specific implications of paths with a significant BDP. 107 Satellite communications (SATCOM) systems have long been used to 108 support point-to-point links and specialised networks. The 109 predominate current use is as a link-layer for Internet Protocols. 110 Typical example applications include: use as an access technology for 111 remote locations, backup and rapid deployment of new services, 112 transit networks and backhaul of various types of IP networks, and 113 provision to mobile (maritime, aircraft, etc.). In most scenarios, 114 the satellite IP network segment usually only forms one part of the 115 end-to-end path. This means user traffic can experience a path that 116 includes satellite link together with a wide variety of other network 117 technologies (Ethernet, cable modems, WiFi, cellular, radio links, 118 etc). Although a user can sometimes know the presence of the 119 satellite service, a typical user does not deploy special software or 120 applications because they expect a satellite network is being used. 121 Often a user is unaware of the technologies underpinning the links 122 forming the network path. 124 This memo identifies the characteristics of a SATCOM link that impact 125 the operation of the QUIC transport protocol. It proposes regression 126 tests to evaluate QUIC over SATCOM links. It discusses how to ensure 127 acceptable protocol performance. 129 2. Operating over a path with a large BDP 131 Satellite communications systems have been deployed using many space 132 orbits, including low earth orbit, medium earth orbits, 133 geosynchronous orbits, elliptical orbits and more. This document 134 focuses on Geosynchronous Earth Orbit (GEO) satellite systems. 136 The characteristics of systems using Geosynchronous Earth Orbit (GEO) 137 satellites differ from paths only using terrestrial links in their 138 path characteristics: 140 o A large propagation delay of at least 250ms one-way delay; 141 o Employ radio resource management (often using techniques similar 142 to cellular mobile or DOCSIS cable networks, but differing to 143 accommodate the satellite propagation delay); 145 o Links can be highly asymmetric (in terms of capacity, one-way 146 delay and in their cost of operation). 148 Many systems use the DVB-S2 specifications, published by the European 149 Telecomunications Standards Institute (ETSI), where the key concept 150 is to ensure both a good usage of the satellite resource and a Quasi 151 Error Free (QEF) link. These systems typically monitor the link 152 quality in real-time, with the help of known symbol sequences, 153 included along with regular packets, which enable an estimation of 154 the current signal-to-noise ratio. This estimation is then feedback 155 allowing the transmitting link to adapt its coding rate and 156 modulation to the actual transmission conditions. 158 It is common to consider the satellite network segment composed of a 159 forward link and a return link. The two links can have different 160 capacities and employ different technologies to carry the IP packets. 162 On the forward link, the satellite gateway often uses all the 163 available bandwidth, possibly with several carriers, to communicate 164 with a set of remote terminals. A carrier is a single Time-Division- 165 Multiplexing channel that multiplexes packets addressed to specific 166 terminals. On the return link, satellite resource is shared among 167 the terminals. Two access methods can be distinguished: on-demand 168 access or contention access. In the former, a terminal receives 169 dedicated transmission resources (usually to send to the gateway). 170 In the latter, some resources are reserved for contention access, 171 where a set of terminals are allowed to compete to obtain 172 transmission resource. Dedicated access, which is more common in 173 currently deployed systems, can be through a Demand Assigned Multiple 174 Access (DAMA) mechanism, while contention access techniques are 175 usually based on Slotted Aloha (SA) and its numerous derivatives. 176 More information on satellite links characteristics can be found in 177 [RFC2488][IJSCN17]. 179 Beyond that, even for characteristics shared with terrestrial links, 180 the impact on a satellite link could be more and can be amplified by 181 the large path RTT. For example, paths using a satellite system can 182 also exhibit a high loss-rate (e.g., a mobile user or a user behind a 183 Wi-Fi link), where additional delay can impact transport mechanisms. 185 o Transport initialization: the 3-way handshake takes a longer time 186 to complete, delaying the time to send data (several transport 187 protocol exchanges may be needed, such as TLS); 189 o Size of windows required: to fully exploit the bottleneck 190 capacity, a high BDP requires a larger number of in-flight 191 packets; 193 o Reliability: packet loss detection and correction is slow (the 194 performance of end-to-end retransmission is also impacted when 195 using a high RTT path); 197 o Getting up to speed: many congestion control methods employ an 198 exponential increase in the sending rate during slow start (for 199 path capacity probing), a high RTT will increase the time to reach 200 a specific rate; 202 o Asymmetry : when the links are asymmetric, for various reasons, 203 the the return path may modify the rate and/timing of transport 204 acknowledgment traffic, potentially changing behaviour (e.g., 205 limiting the forward sending rate). 207 3. TCP Split Solution 209 High BDP networks commonly break the TCP end-to-end paradigm to adapt 210 the transport protocol. Splitting a TCP connection allows adaptation 211 for a specific use-case and to address the issues discussed in 212 section Section 2. Satellite communications commonly deploy 213 Performance Enhancement Proxy (PEP) for compression, caching and TCP 214 acceleration services [RFC3135]. Their deployment can result in 215 significant performance improvement (e.g., a 50% page load time 216 reduction in a SATCOM use-case [ICCRG100]. 218 [NCT13] and [RFC3135] describe the main functions of a SATCOM TCP 219 split solution. For traffic originated at a gateway to an endpoint 220 connected via a satellite terminal, the TCP split proxy intercepts 221 TCP SYN packets, acting on behalf of the endpoint and adapts the 222 sending rate to the SATCOM scenario. The split solution can 223 specifically tune TCP parameters to the satellite link (latency, 224 available capacity). 226 When a proxy is used on each side of the satellite link, the 227 transport protocol can be replace by a protocol other than TCP, 228 optimized for the satellite link. This can be tuned using a priori 229 information about the satellite system and/or by measuring the 230 properties of the network segment that includes the satellite system. 232 Split connections can also recover from packet loss that is local to 233 the part of the connection on which the packet losses occur. This 234 eliminates the need for end-to-end recovery of lost packets. 236 One important advantage of a TCP split solution is that it does not 237 require any end-to-end modification and is independent of both the 238 client and server sides. This comes with a drawback: TCP splitters 239 are often unable to track end-to-end improvements in protocol 240 mechanisms (e.g., RACK, ECN, TCP Fast Open support). Methods 241 configured in the split proxy usually continue to be used until a 242 split solution is finally updated. This can delay/negate the benefit 243 of any end-to-end improvements, contributing to ossification of the 244 transport system. 246 4. Regression tests 248 This section proposes a set of regression tests for QUIC that 249 consider high BDP scenarios. We define by: 251 o Download path: from Internet to the client endpoint; 253 o Upload path: from the client endpoint to a server (e.g., in the 254 Internet). 256 4.1. Small public satellite broadband access 258 The tested scenario has the following path characteristics: 260 o Satellite downlink path: 10 Mbps 262 o Satellite uplink path: 2 Mbps 264 o No emulated packet loss 266 o RTT: 650 ms 268 o Buffer size : BDP 270 During the transmission of 100 MB on both download and upload paths, 271 the test should report the upload and download time of 2 MB, 10 MB 272 and 100 MB. 274 Initial thoughts of the performance obectives for QUIC are the 275 following: 277 o 3 s for downloading 2 MB 279 o 10 s for downloading 10 MB 281 o 85 s for downloading 100 MB 283 o 10 s for uploading 2 MB 284 o 50 s for uploading 10 MB 286 o 420 s for uploading 100 MB 288 4.2. Medium public satellite broadband access 290 The tested scenario has the following path characteristics: 292 o Satellite downlink path: 50 Mbps 294 o Satellite uplink path: 10 Mbps 296 o No emulated packet loss 298 o RTT: 650 ms 300 o Buffer size : BDP 302 During the transmission of 100 MB on the download path, the test 303 should report the download time for 2 MB, 10 MB and 100 MB. Then, to 304 assess the performance of QUIC with the 0-RTT extension and its 305 variants, after 10 seconds, repeat the transmission of 100 MB on the 306 download path where the download time for 2 MB, 10 MB and 100 MB is 307 recorded. 309 Initial thoughts of the performance objectives for QUIC are the 310 following: 312 o 3 s for the first downloading 2 MB 314 o 5 s for the first downloading 10 MB 316 o 20 s for the first downloading 100 MB 318 o TBD s for the second downloading 2 MB 320 o TBD s for the second downloading 10 MB 322 o TBD s for the second downloading 100 MB 324 4.3. Congested medium public satellite broadband access 326 There are cases where the uplink path is congested or where the 327 capacity of the uplink path is not guaranteed. 329 The tested scenario has the following path characteristics: 331 o Satellite downlink path: 50 Mbps 332 o Satellite uplink path: 0.5 Mbps 334 o No emulated packet loss 336 o RTT: 650 ms 338 o Buffer size : BDP 340 During the transmission of 100 MB on the download path, the test 341 should report the download time for 2 MB, 10 MB and 100 MB. 343 Initial thoughts of the performance objectives for QUIC are the 344 following: 346 o 3 s for downloading 2 MB 348 o 5 s for downloading 10 MB 350 o 20 s for downloading 100 MB 352 4.4. Variable medium public satellite broadband access 354 There are cases where the downlink path is congested or where, due to 355 link layer adaptations to rain fading, the capacity of the downlink 356 path is variable. 358 The tested scenario has the following path characteristics: 360 o Satellite downlink path: 50 Mbps - wait 5s - 10 Mbps 362 o Satellite uplink path: 10 Mbps 364 o No emulated packet loss 366 o RTT: 650 ms 368 o Buffer size : BDP 370 During the transmission of 100 MB on the download path, the test 371 should report the download time for 2 MB, 10 MB and 100 MB. 373 Initial thoughts of the performance objectives for QUIC are the 374 following: 376 o TBD s for downloading 2 MB 378 o TBD s for downloading 10 MB 379 o TBD s for downloading 100 MB 381 4.5. Loss-free large public satellite broadband access 383 The tested scenario has the following path characteristics: 385 o Satellite downlink path: 250 Mbps 387 o Satellite uplink path: 3 Mbps 389 o No emulated packet loss 391 o RTT: 650 ms 393 o Buffer size : BDP 395 During the transmission of 100 MB on the download path, the test 396 should report the download time for 2 MB, 10 MB and 100 MB. Then, to 397 assess the performance of QUIC with the 0-RTT extension and its 398 variants, after 10 seconds, repeat the transmission of 100 MB on the 399 download path where the download time for 2 MB, 10 MB and 100 MB is 400 recorded. 402 Initial thoughts of the performance objectives for QUIC are the 403 following: 405 o 3 s for the first downloading 2 MB 407 o 5 s for the first downloading 10 MB 409 o 8 s for the first downloading 100 MB 411 o TBD s for the second downloading 2 MB 413 o TBD s for the second downloading 10 MB 415 o TBD s for the second downloading 100 MB 417 4.6. Lossy large public satellite broadband access 419 The tested scenario has the following path characteristics: 421 o Satellite downlink path: 250 Mbps 423 o Satellite uplink path: 3 Mbps 425 o Emulated packet loss on both downlink and uplink paths: 427 * Uniform random transmission link losses: 1% 429 o RTT: 650 ms 431 o Buffer size : BDP 433 During the transmission of 100 MB on the download path, the test 434 should report the download time for 2 MB, 10 MB and 100 MB. 436 Initial thoughts of the performance objectives for QUIC are the 437 following: 439 o 3 s for downloading 2 MB (uniform transmission link losses) 441 o 6 s for downloading 10 MB (uniform transmission link losses) 443 o 10 s for downloading 100 MB (uniform transmission link losses) 445 5. Mechanisms that improve the performance of QUIC for SATCOM 447 5.1. Getting up to speed 449 QUIC has an advantage that the TLS and TCP negotiations can be 450 completed during the transport connection handshake. This can reduce 451 the time to transmit the first data. Results of [IJSCN19] illustrate 452 that it can still take many RTTs for a CC to increase the sending 453 rate to fill the bottleneck capacity. The delay in getting up to 454 speed can dominate performance for a path with a large RTT, and 455 requires the congestion and flow controls to accommodate the impact 456 of path delay. 458 One relevant solution is tuning of the initial window described in 459 [I-D.irtf-iccrg-sallantin-initial-spreading], which has been shown to 460 improve performance both for high BDP and more common BDP 461 [CONEXT15][ICC16]. Such a solution requires using sender pacing to 462 avoid generating bursts of packets in a network. 464 5.2. Maximum window 466 The number of in-flight packets required to fill a bottleneck 467 capacity, is dependent on the BDP. Default values of maximum windows 468 may not be suitable for a SATCOM context. 470 Such as presented in [PANRG105], only increasing the initial 471 congestion window is not the only way that can improve QUIC 472 performance in a SATCOM context: increasing maximum congestion 473 windows can also result in much better performance. Other protocol 474 mechanisms also need to be considered, such as flow control at the 475 stream level in QUIC. 477 5.3. Reliability 479 Packet loss detection and loss repair will consume additional time on 480 paths with a larger RTT. The RTT also determines the time needed by 481 a server to react to a congestion event. Both can impact the user 482 experience. For example, when a user uses a Wi-Fi link to access the 483 Internet via SATCOM terminal. 485 End-to-end packet Forward Error Correction offers an alternative to 486 retransmission with different tradeoffs in terms of utilised capacity 487 and repair capability. 489 Network coding as proposed in [I-D.swett-nwcrg-coding-for-quic] and 490 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] could help QUIC recover from 491 link or congestion loss. Another approach could utilise QUIC tunnels 492 [I-D.schinazi-masque] to apply FEC to all or a part of the end-to-end 493 path. 495 The benefits of introducing FEC need to weighed against the 496 additional capacity introduced by end-to-end FEC and the opportunity 497 to use link-local ARQ and/or link-adaptive FEC. A transport 498 connections can suffer link-related losses from a particular link 499 (e.g., Wi-Fi), but also congestion loss (e.g. router buffer overflow 500 in a satellite operator ground segment or along an Internet path). 501 Mechanisms have been proposed in 502 [I-D.ferrieux-hamchaoui-quic-lossbits], to identify congestion losses 503 in the ground segment. 505 5.4. ACK ratio 507 Asymmetry in capacity (or in the way capacity is granted to a flow) 508 can lead to cases where the transmission in one direction of 509 communication is restricted by the transmission of the acknowledgment 510 traffic flowing in the opposite direction. A network segment could 511 present limitations in the volume of acknowledgment traffic (e.g., 512 limited available return path capacity) or in the number of 513 acknowledgment packets (e.g., when a radio-resource management system 514 has to track channel usage), or both. 516 TCP Performance Implications of Network Path Asymmetry [RFC3449] 517 describes a range of mechanisms that have been used to mitigate the 518 impact of path asymmetry, primarily targeting operation of TCP. 520 Many mitigations have been deployed in satellite systems, often as a 521 mechanism within a PEP. Despite their benefits over paths with high 522 asymmetry, most mechanisms rely on being able to inspect and/or 523 modify the transport layer header information of TCP ACK packets. 524 This is not possible when the transport layer information is 525 encrypted (e.g., using an IP VPN). 527 One simple mitigation is for the remote endpoint to send compound 528 acknowledgments less frequently. A rate of one ACK every RTT/4 can 529 significantly reduce this traffic. The QUIC transport specification 530 may evolve to allow the ACK Ratio to be adjusted. 532 6. Discussion 534 Many of the issues identified for high BDP paths already exist when 535 using an encrypted transport service over a path that employs 536 encryption at the IP layer. This includes endpoints that utilise 537 IPsec at the network layer, or use VPN technology over a satellite 538 network segment. These uses are unable to benefit from enhancement 539 within the satellite network segment, and often the user is unaware 540 of the presence of the satellite link on their path, except through 541 observing the impact it has on the performance they experience. 543 One solution would be to provide PEP functions at the termination of 544 the security association (e.g., in a VPN client). Another solution 545 could be to fall-back to using TCP (possibly with TLS or similar 546 methods being used on the transport payload). A different solution 547 could be to deploy and maintain a bespoke protocol tailored to high 548 BDP environments. In the future, we anticipate that fall-back to TCP 549 will become less desirable, and methods that rely upon bespoke 550 configurations or protocols will be unattractive. In parallel, new 551 methods such as QUIC will become widely deployed. The opportunity 552 therefore exists to ensure that the new generation of protocols offer 553 acceptable performance over high BDP paths without requiring 554 operating tuning or specific updates by users. 556 7. Acknowledgments 558 The authors would like to thank Christian Huitema, Igor Lubashev, 559 Alexandre Ferrieux, Francois Michel, Emmanuel Lochin and the 560 participants of the IETF106 side-meeting on QUIC for high BDP for 561 their useful feedbacks. 563 8. Security Considerations 565 This document does not propose changes to the security functions 566 provided by the QUIC protocol. QUIC uses TLS encryption to protect 567 the transport header and its payload. Security is considered in the 568 "Security Considerations" of cited IETF documents. 570 9. Informative References 572 [CONEXT15] 573 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 574 Flows Quickly and Safely", ACM CoNEXT , 2015. 576 [I-D.ferrieux-hamchaoui-quic-lossbits] 577 Ferrieux, A. and I. Hamchaoui, "The QUIC Loss Bits", 578 draft-ferrieux-hamchaoui-quic-lossbits-00 (work in 579 progress), April 2019. 581 [I-D.ietf-quic-recovery] 582 Iyengar, J. and I. Swett, "QUIC Loss Detection and 583 Congestion Control", draft-ietf-quic-recovery-32 (work in 584 progress), October 2020. 586 [I-D.irtf-iccrg-sallantin-initial-spreading] 587 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 588 E., and A. Beylot, "Safe increase of the TCP's Initial 589 Window Using Initial Spreading", draft-irtf-iccrg- 590 sallantin-initial-spreading-00 (work in progress), January 591 2014. 593 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] 594 Roca, V., Michel, F., Swett, I., and M. Montpetit, 595 "Sliding Window Random Linear Code (RLC) Forward Erasure 596 Correction (FEC) Schemes for QUIC", draft-roca-nwcrg-rlc- 597 fec-scheme-for-quic-03 (work in progress), March 2020. 599 [I-D.schinazi-masque] 600 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 601 masque-02 (work in progress), January 2020. 603 [I-D.swett-nwcrg-coding-for-quic] 604 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 605 for QUIC", draft-swett-nwcrg-coding-for-quic-04 (work in 606 progress), March 2020. 608 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 609 E., and A-L. Beylot, "Reducing web latency through TCP IW: 610 Be smart", IEEE ICC , 2016. 612 [ICCRG100] 613 Kuhn, N., "MPTCP and BBR performance over Internet 614 satellite paths", IETF ICCRG 100, 2017. 616 [IJSCN17] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 617 and N. Kuhn, "Software-defined satellite cloud RAN", 618 International Journal of Satellite Communications and 619 Networking , 2017. 621 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 622 QUIC performance over a public SATCOM access", 623 International Journal of Satellite Communications and 624 Networking , 2019. 626 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 627 performances over geostationary satellite link", Network 628 and Communication Technologies , 2013. 630 [PANRG105] 631 Kuhn, N., Stephan, E., Border, J., and G. Fairhurst, "QUIC 632 Over In-sequence Paths with Different Characteristics", 633 IRTF PANRG 105, 2019. 635 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 636 Over Satellite Channels using Standard Mechanisms", 637 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 638 . 640 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 641 Shelby, "Performance Enhancing Proxies Intended to 642 Mitigate Link-Related Degradations", RFC 3135, 643 DOI 10.17487/RFC3135, June 2001, 644 . 646 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 647 Sooriyabandara, "TCP Performance Implications of Network 648 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 649 December 2002, . 651 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 652 "Increasing TCP's Initial Window", RFC 6928, 653 DOI 10.17487/RFC6928, April 2013, 654 . 656 Authors' Addresses 658 Nicolas Kuhn 659 CNES 661 Email: nicolas.kuhn@cnes.fr 662 Godred Fairhurst 663 University of Aberdeen 665 Email: gorry@erg.abdn.ac.uk 667 John Border 668 Hughes Network Systems, LLC 670 Email: border@hns.com 672 Emile Stephan 673 Orange 675 Email: emile.stephan@orange.com