idnits 2.17.1 draft-kuhn-quic-4-sat-05.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 (May 29, 2020) is 1422 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-27 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: November 30, 2020 University of Aberdeen 6 J. Border 7 Hughes Network Systems, LLC 8 E. Stephan 9 Orange 10 May 29, 2020 12 QUIC for SATCOM 13 draft-kuhn-quic-4-sat-05 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 November 30, 2020. 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. Medium public satellite broadband access . . . . . . . . 6 75 4.2. Congested medium public satellite broadband access . . . 7 76 4.3. Variable medium public satellite broadband access . . . . 7 77 4.4. Loss-free large public satellite broadband access . . . . 8 78 4.5. Lossy large public satellite broadband access . . . . . . 9 79 5. Mechanisms that improve the performance of QUIC for SATCOM . 9 80 5.1. Getting up to speed . . . . . . . . . . . . . . . . . . . 9 81 5.2. Maximum window . . . . . . . . . . . . . . . . . . . . . 10 82 5.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.4. ACK ratio . . . . . . . . . . . . . . . . . . . . . . . . 10 84 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 9. Informative References . . . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 The end-to-end performance of an application using an Internet path 93 can be impacted by the Bandwidth-Delay Product (BDP) of the links and 94 network devices forming the path. For instance, the page load time 95 for a complex page can be much larger when the path includes a 96 satellite link. A significant contribution to this reduced 97 performance arises from the initialisation and design of transport 98 mechanisms. QUIC's default congestion control is based on TCP 99 NewReno [I-D.ietf-quic-recovery] and the recommended initial window 100 is defined by [RFC6928]. Although QUIC's Congestion Control (CC) and 101 recovery have been designed for use across Internet Paths, the 102 initial design could not optimise for the wide diversity of path 103 characteristics that can occur. This document therefore considers 104 the specific implications of paths with a significant BDP. 106 Satellite communications (SATCOM) systems have long been used to 107 support point-to-point links and specialised networks. The 108 predominate current use is as a link-layer for Internet Protocols. 109 Typical example applications include: use as an access technology for 110 remote locations, backup and rapid deployment of new services, 111 transit networks and backhaul of various types of IP networks, and 112 provision to mobile (maritime, aircraft, etc.). In most scenarios, 113 the satellite IP network segment usually only forms one part of the 114 end-to-end path. This means user traffic can experience a path that 115 includes satellite link together with a wide variety of other network 116 technologies (Ethernet, cable modems, WiFi, cellular, radio links, 117 etc). Although a user can sometimes know the presence of the 118 satellite service, a typical user does not deploy special software or 119 applications because they expect a satellite network is being used. 120 Often a user is unaware of the technologies underpinning the links 121 forming the network path. 123 This memo identifies the characteristics of a SATCOM link that impact 124 the operation of the QUIC transport protocol. It proposes regression 125 tests to evaluate QUIC over SATCOM links. It discusses how to ensure 126 acceptable protocol performance. 128 2. Operating over a path with a large BDP 130 Satellite communications systems have been deployed using many space 131 orbits, including low earth orbit, medium earth orbits, 132 geosynchronous orbits, elliptical orbits and more. This document 133 focuses on Geosynchronous Earth Orbit (GEO) satellite systems. 135 The characteristics of systems using Geosynchronous Earth Orbit (GEO) 136 satellites differ from paths only using terrestrial links in their 137 path characteristics: 139 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. Medium public satellite broadband access 258 The tested scenario has the following path characteristics: 260 o Satellite downlink path: 50 Mbps 262 o Satellite uplink path: 10 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 the download time for 2 MB, 10 272 MB and 100 MB. 274 Initial thoughts of the performance objectives for QUIC are the 275 following: 277 o 3 s for downloading 2 MB 279 o 5 s for downloading 10 MB 281 o 20 s for downloading 100 MB 283 o TBD s for uploading 2 MB 285 o TBD s for uploading 10 MB 287 o TBD s for uploading 100 MB 289 4.2. Congested medium public satellite broadband access 291 There are cases where the uplink path is congested or where the 292 capacity of the uplink path is not guaranteed. 294 The tested scenario has the following path characteristics: 296 o Satellite downlink path: 50 Mbps 298 o Satellite uplink path: 0.5 Mbps 300 o No emulated packet loss 302 o RTT: 650 ms 304 o Buffer size : BDP 306 During the transmission of 100 MB on the download path, the test 307 should report the download time for 2 MB, 10 MB and 100 MB. 309 Initial thoughts of the performance objectives for QUIC are the 310 following: 312 o TBD s for downloading 2 MB 314 o TBD s for downloading 10 MB 316 o TBD s for downloading 100 MB 318 4.3. Variable medium public satellite broadband access 320 There are cases where the downlink path is congested or where, due to 321 link layer adaptations to rain fading, the capacity of the downlink 322 path is variable. 324 The tested scenario has the following path characteristics: 326 o Satellite downlink path: 50 Mbps - wait 5s - 10 Mbps 328 o Satellite uplink path: 10 Mbps 330 o No emulated packet loss 332 o RTT: 650 ms 334 o Buffer size : BDP 335 During the transmission of 100 MB on the download path, the test 336 should report the download time for 2 MB, 10 MB and 100 MB. 338 Initial thoughts of the performance objectives for QUIC are the 339 following: 341 o TBD s for downloading 2 MB 343 o TBD s for downloading 10 MB 345 o TBD s for downloading 100 MB 347 4.4. Loss-free large public satellite broadband access 349 The tested scenario has the following path characteristics: 351 o Satellite downlink path: 250 Mbps 353 o Satellite uplink path: 3 Mbps 355 o No emulated packet loss 357 o RTT: 650 ms 359 o Buffer size : BDP 361 During the transmission of 100 MB on the download path, the test 362 should report the download time for 2 MB, 10 MB and 100 MB. Then, 363 after 10 seconds, repeat the transmission of 100 MB on the download 364 path where the download time for 2 MB, 10 MB and 100 MB is recorded. 366 Initial thoughts of the performance objectives for QUIC are the 367 following: 369 o 3 s for the first downloading 2 MB 371 o 5 s for the first downloading 10 MB 373 o 8 s for the first downloading 100 MB 375 o TBD s for the second downloading 2 MB 377 o TBD s for the second downloading 10 MB 379 o TBD s for the second downloading 100 MB 381 4.5. Lossy 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 Emulated packet loss on both downlink and uplink paths: 391 * Uniform random transmission link losses: 1% 393 o RTT: 650 ms 395 o Buffer size : BDP 397 During the transmission of 100 MB on the download path, the test 398 should report the download time for 2 MB, 10 MB and 100 MB. 400 Initial thoughts of the performance objectives for QUIC are the 401 following: 403 o 3 s for downloading 2 MB (uniform transmission link losses) 405 o 6 s for downloading 10 MB (uniform transmission link losses) 407 o 10 s for downloading 100 MB (uniform transmission link losses) 409 5. Mechanisms that improve the performance of QUIC for SATCOM 411 5.1. Getting up to speed 413 QUIC has an advantage that the TLS and TCP negotiations can be 414 completed during the transport connection handshake. This can reduce 415 the time to transmit the first data. Results of [IJSCN19] illustrate 416 that it can still take many RTTs for a CC to increase the sending 417 rate to fill the bottleneck capacity. The delay in getting up to 418 speed can dominate performance for a path with a large RTT, and 419 requires the congestion and flow controls to accommodate the impact 420 of path delay. 422 One relevant solution is tuning of the initial window described in 423 [I-D.irtf-iccrg-sallantin-initial-spreading], which has been shown to 424 improve performance both for high BDP and more common BDP 425 [CONEXT15][ICC16]. Such a solution requires using sender pacing to 426 avoid generating bursts of packets in a network. 428 5.2. Maximum window 430 The number of in-flight packets required to fill a bottleneck 431 capacity, is dependent on the BDP. Default values of maximum windows 432 may not be suitable for a SATCOM context. 434 Such as presented in [PANRG105], only increasing the initial 435 congestion window is not the only way that can improve QUIC 436 performance in a SATCOM context: increasing maximum congestion 437 windows can also result in much better performance. Other protocol 438 mechanisms also need to be considered, such as flow control at the 439 stream level in QUIC. 441 5.3. Reliability 443 Packet loss detection and loss repair will consume additional time on 444 paths with a larger RTT. The RTT also determines the time needed by 445 a server to react to a congestion event. Both can impact the user 446 experience. For example, when a user uses a Wi-Fi link to access the 447 Internet via SATCOM terminal. 449 End-to-end packet Forward Error Correction offers an alternative to 450 retransmission with different tradeoffs in terms of utilised capacity 451 and repair capability. 453 Network coding as proposed in [I-D.swett-nwcrg-coding-for-quic] and 454 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] could help QUIC recover from 455 link or congestion loss. Another approach could utilise QUIC tunnels 456 [I-D.schinazi-masque] to apply FEC to all or a part of the end-to-end 457 path. 459 The benefits of introducing FEC need to weighed against the 460 additional capacity introduced by end-to-end FEC and the opportunity 461 to use link-local ARQ and/or link-adaptive FEC. A transport 462 connections can suffer link-related losses from a particular link 463 (e.g., Wi-Fi), but also congestion loss (e.g. router buffer overflow 464 in a satellite operator ground segment or along an Internet path). 465 Mechanisms have been proposed in 466 [I-D.ferrieux-hamchaoui-quic-lossbits], to identify congestion losses 467 in the ground segment. 469 5.4. ACK ratio 471 Asymmetry in capacity (or in the way capacity is granted to a flow) 472 can lead to cases where the transmission in one direction of 473 communication is restricted by the transmission of the acknowledgment 474 traffic flowing in the opposite direction. A network segment could 475 present limitations in the volume of acknowledgment traffic (e.g., 476 limited available return path capacity) or in the number of 477 acknowledgment packets (e.g., when a radio-resource management system 478 has to track channel usage), or both. 480 TCP Performance Implications of Network Path Asymmetry [RFC3449] 481 describes a range of mechanisms that have been used to mitigate the 482 impact of path asymmetry, primarily targeting operation of TCP. 484 Many mitigations have been deployed in satellite systems, often as a 485 mechanism within a PEP. Despite their benefits over paths with high 486 asymmetry, most mechanisms rely on being able to inspect and/or 487 modify the transport layer header information of TCP ACK packets. 488 This is not possible when the transport layer information is 489 encrypted (e.g., using an IP VPN). 491 One simple mitigation is for the remote endpoint to send compound 492 acknowledgments less frequently. A rate of one ACK every RTT/4 can 493 significantly reduce this traffic. The QUIC transport specification 494 may evolve to allow the ACK Ratio to be adjusted. 496 6. Discussion 498 Many of the issues identified for high BDP paths already exist when 499 using an encrypted transport service over a path that employs 500 encryption at the IP layer. This includes endpoints that utilise 501 IPsec at the network layer, or use VPN technology over a satellite 502 network segment. These uses are unable to benefit from enhancement 503 within the satellite network segment, and often the user is unaware 504 of the presence of the satellite link on their path, except through 505 observing the impact it has on the performance they experience. 507 One solution would be to provide PEP functions at the termination of 508 the security association (e.g., in a VPN client). Another solution 509 could be to fall-back to using TCP (possibly with TLS or similar 510 methods being used on the transport payload). A different solution 511 could be to deploy and maintain a bespoke protocol tailored to high 512 BDP environments. In the future, we anticipate that fall-back to TCP 513 will become less desirable, and methods that rely upon bespoke 514 configurations or protocols will be unattractive. In parallel, new 515 methods such as QUIC will become widely deployed. The opportunity 516 therefore exists to ensure that the new generation of protocols offer 517 acceptable performance over high BDP paths without requiring 518 operating tuning or specific updates by users. 520 7. Acknowledgments 522 The authors would like to thank Christian Huitema, Igor Lubashev, 523 Alexandre Ferrieux, Francois Michel, Emmanuel Lochin and the 524 participants of the IETF106 side-meeting on QUIC for high BDP for 525 their useful feedbacks. 527 8. Security Considerations 529 This document does not propose changes to the security functions 530 provided by the QUIC protocol. QUIC uses TLS encryption to protect 531 the transport header and its payload. Security is considered in the 532 "Security Considerations" of cited IETF documents. 534 9. Informative References 536 [CONEXT15] 537 Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short 538 Flows Quickly and Safely", ACM CoNEXT , 2015. 540 [I-D.ferrieux-hamchaoui-quic-lossbits] 541 Ferrieux, A. and I. Hamchaoui, "The QUIC Loss Bits", 542 draft-ferrieux-hamchaoui-quic-lossbits-00 (work in 543 progress), April 2019. 545 [I-D.ietf-quic-recovery] 546 Iyengar, J. and I. Swett, "QUIC Loss Detection and 547 Congestion Control", draft-ietf-quic-recovery-27 (work in 548 progress), March 2020. 550 [I-D.irtf-iccrg-sallantin-initial-spreading] 551 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 552 E., and A. Beylot, "Safe increase of the TCP's Initial 553 Window Using Initial Spreading", draft-irtf-iccrg- 554 sallantin-initial-spreading-00 (work in progress), January 555 2014. 557 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] 558 Roca, V., Michel, F., Swett, I., and M. Montpetit, 559 "Sliding Window Random Linear Code (RLC) Forward Erasure 560 Correction (FEC) Schemes for QUIC", draft-roca-nwcrg-rlc- 561 fec-scheme-for-quic-03 (work in progress), March 2020. 563 [I-D.schinazi-masque] 564 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 565 masque-02 (work in progress), January 2020. 567 [I-D.swett-nwcrg-coding-for-quic] 568 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 569 for QUIC", draft-swett-nwcrg-coding-for-quic-04 (work in 570 progress), March 2020. 572 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 573 E., and A-L. Beylot, "Reducing web latency through TCP IW: 574 Be smart", IEEE ICC , 2016. 576 [ICCRG100] 577 Kuhn, N., "MPTCP and BBR performance over Internet 578 satellite paths", IETF ICCRG 100, 2017. 580 [IJSCN17] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 581 and N. Kuhn, "Software-defined satellite cloud RAN", 582 International Journal of Satellite Communications and 583 Networking , 2017. 585 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 586 QUIC performance over a public SATCOM access", 587 International Journal of Satellite Communications and 588 Networking , 2019. 590 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 591 performances over geostationary satellite link", Network 592 and Communication Technologies , 2013. 594 [PANRG105] 595 Kuhn, N., Stephan, E., Border, J., and G. Fairhurst, "QUIC 596 Over In-sequence Paths with Different Characteristics", 597 IRTF PANRG 105, 2019. 599 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 600 Over Satellite Channels using Standard Mechanisms", 601 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 602 . 604 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 605 Shelby, "Performance Enhancing Proxies Intended to 606 Mitigate Link-Related Degradations", RFC 3135, 607 DOI 10.17487/RFC3135, June 2001, 608 . 610 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 611 Sooriyabandara, "TCP Performance Implications of Network 612 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 613 December 2002, . 615 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 616 "Increasing TCP's Initial Window", RFC 6928, 617 DOI 10.17487/RFC6928, April 2013, 618 . 620 Authors' Addresses 622 Nicolas Kuhn 623 CNES 625 Email: nicolas.kuhn@cnes.fr 627 Godred Fairhurst 628 University of Aberdeen 630 Email: gorry@erg.abdn.ac.uk 632 John Border 633 Hughes Network Systems, LLC 635 Email: border@hns.com 637 Emile Stephan 638 Orange 640 Email: emile.stephan@orange.com