idnits 2.17.1 draft-jones-tsvwg-transport-for-satellite-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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.) ** The abstract seems to contain references ([RFC3135], [I-D.irtf-panrg-path-properties], [RFC2488]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 907 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF' is mentioned on line 799, but not defined == Unused Reference: 'RFC2760' is defined on line 991, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-irtf-panrg-path-properties-03 == Outdated reference: A later version (-11) exists of draft-kuhn-quic-0rtt-bdp-09 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Jones 3 Internet-Draft G. Fairhurst 4 Intended status: Informational University of Aberdeen 5 Expires: 28 April 2022 N. Kuhn 6 CNES 7 J. Border 8 Hughes Network Systems, LLC 9 E. Stephan 10 Orange 11 25 October 2021 13 Enhancing Transport Protocols over Satellite Networks 14 draft-jones-tsvwg-transport-for-satellite-02 16 Abstract 18 IETF transport protocols such as TCP, SCTP and QUIC are designed to 19 function correctly over any network path. This includes networks 20 paths that utilise a satellite link or network. While transport 21 protocols function, the characteristics of satellite networks can 22 impact performance when using the defaults in standard mechanisms, 23 due to the specific characteristics of these paths. 25 [RFC2488] and [RFC3135] describe mechanisms that enable TCP to more 26 effectively utilize the available capacity of a network path that 27 includes a satellite system. Since publication, both application and 28 transport layers and satellite systems have evolved. Indeed, the 29 development of encrypted protocols such as QUIC challenges currently 30 deployed solutions, for satellite systems the capacity has increased 31 and commercial systems are now available that use a range of 32 satellite orbital positions. 34 This document follows the terminology proposed in 35 [I-D.irtf-panrg-path-properties] to describe the current 36 characterises of common satellite paths. This document also 37 describes considerations when implementing and deploying reliable 38 transport protocols that are intended to work efficiently over paths 39 that include a satellite system. It discusses available network 40 mitigations and offers advice to designers of protocols and operators 41 of satellite networks. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on 28 April 2022. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 67 license-info) in effect on the date of publication of this document. 68 Please review these documents carefully, as they describe your rights 69 and restrictions with respect to this document. Code Components 70 extracted from this document must include Simplified BSD License text 71 as described in Section 4.e of the Trust Legal Provisions and are 72 provided without warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. SATCOM terminology . . . . . . . . . . . . . . . . . . . . . 5 78 3. Satellite Systems . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1. Geosynchronous Earth Orbit (GEO) . . . . . . . . . . . . 7 80 3.2. Low Earth Orbit (LEO) . . . . . . . . . . . . . . . . . . 8 81 3.3. Medium Earth Orbit (MEO) . . . . . . . . . . . . . . . . 8 82 3.4. Hybrid Network Paths . . . . . . . . . . . . . . . . . . 9 83 4. Satellite System Characteristics . . . . . . . . . . . . . . 9 84 4.1. Impact of delay . . . . . . . . . . . . . . . . . . . . . 11 85 4.1.1. Larger Bandwidth Delay Product . . . . . . . . . . . 11 86 4.1.2. Variable Link Delay . . . . . . . . . . . . . . . . . 12 87 4.1.3. Impact of delay on protocol feedback . . . . . . . . 12 88 4.2. Intermittent connectivity . . . . . . . . . . . . . . . . 12 89 5. On-Path Mitigations . . . . . . . . . . . . . . . . . . . . . 12 90 5.1. Link-Level Forward Error Correction and ARQ . . . . . . . 12 91 5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . . 12 92 5.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . 13 93 5.4. Split-TCP PEP . . . . . . . . . . . . . . . . . . . . . . 13 94 5.5. Application Proxies . . . . . . . . . . . . . . . . . . . 14 95 6. Generic Transport Protocol Mechanisms . . . . . . . . . . . . 14 96 6.1. Transport Initialization . . . . . . . . . . . . . . . . 15 97 6.2. Getting up to Speed . . . . . . . . . . . . . . . . . . . 15 98 6.3. Sizing of Maxium Congestion Window . . . . . . . . . . . 15 99 6.4. Reliability (Loss Recovery/Repair) . . . . . . . . . . . 16 100 6.4.1. Packet Level Forward Error Correction . . . . . . . . 16 101 6.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 16 102 6.6. ACK Traffic Reduction . . . . . . . . . . . . . . . . . . 17 103 6.7. Multi-Path . . . . . . . . . . . . . . . . . . . . . . . 17 104 7. Protocol Specific Mechanisms . . . . . . . . . . . . . . . . 18 105 7.1. TCP Protocol Mechanisms . . . . . . . . . . . . . . . . . 18 106 7.1.1. Transport Initialization . . . . . . . . . . . . . . 18 107 7.1.2. Getting Up To Speed . . . . . . . . . . . . . . . . . 18 108 7.1.3. Size of Windows . . . . . . . . . . . . . . . . . . . 18 109 7.1.4. Reliability . . . . . . . . . . . . . . . . . . . . . 18 110 7.1.5. ACK Reduction . . . . . . . . . . . . . . . . . . . . 18 111 7.2. QUIC Protocol Mechanisms . . . . . . . . . . . . . . . . 18 112 7.2.1. Transport initialization . . . . . . . . . . . . . . 18 113 7.2.2. Getting up to Speed . . . . . . . . . . . . . . . . . 18 114 7.2.3. Size of Windows . . . . . . . . . . . . . . . . . . . 18 115 7.2.4. Reliability . . . . . . . . . . . . . . . . . . . . . 18 116 7.2.5. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 18 117 7.2.6. Packet Level Forward Error Correction . . . . . . . . 19 118 7.2.7. Split Congestion Control . . . . . . . . . . . . . . 19 119 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 19 120 8.1. Mitigation Summary . . . . . . . . . . . . . . . . . . . 19 121 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 122 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 123 11. Informative References . . . . . . . . . . . . . . . . . . . 20 124 Appendix A. Example Network Profiles . . . . . . . . . . . . . . 23 125 A.1. LEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 126 A.2. MEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 127 A.3. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 128 A.3.1. Small public satellite broadband access . . . . . . . 24 129 A.3.2. Medium public satellite broadband access . . . . . . 24 130 A.3.3. Congested medium public satellite broadband access . 25 131 A.3.4. Variable medium public satellite broadband access . . 26 132 A.3.5. Loss-free large public satellite broadband access . . 26 133 A.3.6. Lossy large public satellite broadband access . . . . 27 134 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 28 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 137 1. Introduction 139 Satellite communications (SATCOM) systems have long been used to 140 support point-to-point links and specialised networks. The 141 predominate current use today is to support Internet Protocols. 142 Typical example applications include: use as an access technology for 143 remote locations, backup and rapid deployment of new services, 144 transit networks, backhaul of various types of IP networks, and 145 provision to mobile environments (maritime, aircraft, etc.). 147 In most scenarios, the satellite IP network segment forms only one 148 part of the end-to-end path used by an Internet transport protocol. 149 This means that user traffic can experience a path that includes a 150 satellite network combined with a wide variety of other network 151 technologies (Ethernet, cable modems, WiFi, cellular, radio links, 152 etc). Although a user can sometimes know the presence of a satellite 153 service, a typical user does not deploy special software or 154 applications when a satellite network is being used. Users are often 155 unaware of the technologies underpinning the links forming a network 156 path. 158 Satellite path characteristics have an effect on the operation of 159 transport protocols, such as TCP, SCTP or QUIC. Transport Protocol 160 performance can be affected by the magnitude and variability of the 161 network delay. When transport protocols perform poorly the link 162 utilization can be low. Techniques and recommendations have been 163 made that can improve the performance of transport protocols when the 164 path includes as satellite network. 166 The end-to-end performance of an application using an Internet path 167 can be impacted by the path characteristics, such as the Bandwidth- 168 Delay Product (BDP) of the links and network devices forming the 169 path. It can also be impacted by underlying mechanisms used to 170 manage the radio resources. 172 Performance can be impacted at several layers. For instance, the 173 page load time for a complex page can be much larger when a path 174 includes a satellite system. A significant contribution to the 175 reduced performance arises from the initialisation and design of 176 transport mechanisms. 178 Although mechanisms are designed for use across Internet paths, not 179 all designs are performant when used over the wide diversity of path 180 characteristics that can occur. This document therefore considers 181 the implications of Internet paths that include a satellite system. 182 The analysis and conclusions might also apply to other network 183 systems that also result in characteristics that differ from typical 184 Internet paths. 186 RFC2488 specifies an Internet Best Current Practices for the Internet 187 Community, relating to use of the standards-track Transmission 188 Control Protocol (TCP) mechanisms over satellite channels [RFC2488]. 189 A separate RFC,[RFC2760], identified research issues and proposed 190 mitigations for satellite paths. 192 Since the publication of these RFCs many TCP mechanisms have become 193 widely used. In particular, this includes a series of mitigation 194 based on Performance Enhancing Proxies (PEPs) [RFC3135] that split 195 the protocol at the transport layer. Although PEPs are now a common 196 component of satellite systems, their use slows the deployment of new 197 transport protocols and mechanisms (each of which demands an update 198 to the PEP functionality). This has made it difficult for new 199 protocol extensions to achieve comparable performance over satellite 200 channels. In addition, protocols with strong requirements on 201 authentication and privacy such as QUIC [RFC9000] are not able to be 202 split using a PEP and mitigation, and need to therefore use other 203 methods. 205 XXX Note from the current authors: This document currently focuses on 206 Geosynchronous Earth Orbit (GEO) satellite systems, the authors 207 solicit feedback and experience from users and operators of satellite 208 systems using other orbits. XXX 210 2. SATCOM terminology 212 This section follows the terminology proposed in 213 [I-D.irtf-panrg-path-properties] to describe a generic SATCOM system 214 for broadband access. This description is inline with the one 215 proposed in [RFC8975]. 217 A generic SATCOM system could contain the following entities: 219 * A: A Host providing the end service (e.g. web server); 221 * B: A Node being the point-of-presence for the SATCOM system; 223 * C: A Node gathering network functions (e.g. firewall, PEP, caching 224 services, etc.); 226 * D: A Node gathering MAC and PHY functionnalities (a.k.a. the 227 satellite gateway); 229 * E: A Node being one of the satellite (if there are several 230 satellites) (this node could include network layer functions); 232 * F: A Node receiving the signal from the satellite (a.k.a. the 233 satellite terminal); 235 * G: A Host providing the end service (e.g. web browser). 237 These entities would be interconnected with path elements which 238 properties differ from one SATCOM system to another. 239 [I-D.irtf-panrg-path-properties] provides properties that can be 240 discussed to describe the path. These properties are exploited 241 throughout the whole document to describe SATCOM systems. 243 While the paths interconnecting the entities (1) A to B, (2) B to C, 244 (3) C to D and (4) F to G are quite generic for all the systems, and 245 not specific for SATCOM systems, some properties need to be 246 discussed: 248 * Protocol Features available 250 * Transport Protocols available 252 * Transparency 254 The paths (1) D to E and (2) D to F are quite specific to SATCOM 255 systems. In particular, the following elements, provided by 256 [I-D.irtf-panrg-path-properties], are in the scope of this document 257 and deserve some description: 259 * Symmetric Path 261 * Disjointness 263 * Transparency 265 * Link Capacity 267 * Link Usage 269 * One-Way Delay 271 * One-Way Delay Variation 273 * One-Way Packet Loss 275 3. Satellite Systems 277 Satellite communications systems have been deployed using many space 278 orbits, including low earth orbit, medium earth orbits, 279 geosynchronous orbits, elliptical orbits and more. This document 280 considers the characteristics of all satellite networks. 282 * Many communications satellites are located at Geostationary Orbit 283 (GEO) with an altitude of approximately 36,000 km [Sta94]. At 284 this altitude the orbit period is the same as the Earth's rotation 285 period. Therefore, each ground station is always able to "see" 286 the orbiting satellite at the same position in the sky. The 287 propagation time for a radio signal to travel twice that distance 288 (corresponding to a ground station directly below the satellite) 289 is 239.6 milliseconds (ms) [Mar78]. For ground stations at the 290 edge of the view area of the satellite, the distance traveled is 2 291 x 41,756 km for a total propagation delay of 279.0 ms [Mar78]. 292 These delays are for one ground station-to-satellite-to-ground 293 station route (or "hop"). Therefore, the propagation delay for a 294 packet and the corresponding reply (one round-trip time or RTT) 295 could be at least 558 ms. The RTT is not based solely due to 296 satellite propagation time and will be increased by other factors, 297 such as the serialisation time, including any FEC encoding/ARQ 298 delay and propagation time of other links along the network path 299 and the queueing delay in network equipment. The delay is 300 increased when multiple hops are used (i.e. communications is 301 relayed via a gateway) or if inter-satellite links are used. As 302 satellites become more complex and include on-board processing of 303 signals, additional delay can be added. 305 * Communications satellites can also be built to use a Low Earth 306 Orbit (LEO) [Stu95] [Mon98]. The lower orbits require the use of 307 constellations of satellites for constant coverage. In other 308 words, as one satellite leaves the ground station's sight, another 309 satellite appears on the horizon and the channel is switched to 310 it. The propagation delay to a LEO orbit ranges from several 311 milliseconds when communicating with a satellite directly 312 overhead, to as much as 20 ms when the satellite is on the 313 horizon. Some of these systems use inter-satellite links and have 314 variable path delay depending on routing through the network. 316 * Another orbital position use a Medium Earth Orbit (MEO) [Mar78]. 317 These orbits lie between LEO and GEO. 319 3.1. Geosynchronous Earth Orbit (GEO) 321 The characteristics of systems using Geosynchronous Earth Orbit (GEO) 322 satellites differ from paths only using terrestrial links in their 323 path characteristics: 325 * A large propagation delay of at least 250ms one-way delay; 327 * Use of radio resource management (often using techniques similar 328 to cellular mobile or DOCSIS cable networks, but differ to 329 accommodate the satellite propagation delay); 331 * Links can be highly asymmetric (in terms of capacity, one-way 332 delay and in their cost of operation, see Appendix A for example 333 scenarios). 335 As an example. GEO systems use the DVB-S2 specifications [EN 302 336 307-1], published by the European Telecommunications Standards 337 Institute (ETSI), where the key concept is to ensure both a good 338 usage of the satellite resource and a Quasi Error Free (QEF) link. 339 These systems typically monitor the link quality in real-time, with 340 the help of known symbol sequences, included along with regular 341 packets, which enable an estimation of the current signal-to-noise 342 ratio. This estimation is then feedback allowing the transmitting 343 link to adapt its coding rate and modulation to the actual 344 transmission conditions. 346 3.2. Low Earth Orbit (LEO) 348 There is an important variability of LEO systems. Depending on the 349 locations of the gateways on the ground, routing within the 350 constellation may be necessary to bring to packets down to the 351 ground. Depending on the routes currently available for an end user, 352 high levels of jitter may occur (from 40ms to 140ms with the Iridium 353 constellation). This may lead to out-of-order delivery of packets. 355 XXX The authors solicit feedback and experience from users and 356 operators of satellite systems in LEO orbits. XXX 358 3.3. Medium Earth Orbit (MEO) 360 MEO systems such as O3B combines advantages and drawbacks from both 361 LEO and GEO systems. 363 MEO systems can have a large coverage and with limited number of 364 satellites required providing a broad service. The usage of powerful 365 satellites enables provision of high data rates. 367 MEO systems have the drawback, from a transport protocol perspective, 368 that the BDP can be very high due to the altitude of such 369 constellations (8 063 km for O3B) and there may be delay variations 370 when the satellite changes (every 45 minutes with O3B). The latter 371 can be dealt with by means of double antennas terminals. 373 XXX The authors solicit feedback and experience from users and 374 operators of satellite systems in MEO orbits. XXX 376 3.4. Hybrid Network Paths 378 XXX The authors solicit feedback and experience from users and 379 operators of satellite systems in hybrid network scenarios. XXX 381 4. Satellite System Characteristics 383 There is an inherent delay in the delivery of a packet over a 384 satellite system due to the finite speed of light and the altitude of 385 communications satellites. 387 Satellite links are dominated by two fundamental characteristics, as 388 described below: 390 * Packet Loss: The strength of any radio signal falls in proportion 391 to the square of the distance traveled. For a satellite link the 392 square of the distance traveled is large and so the signal becomes 393 weak before reaching its destination. This results in a low 394 signal-to-noise ratio. Some frequencies are particularly 395 susceptible to atmospheric effects such as rain attenuation. For 396 mobile applications, satellite channels are especially susceptible 397 to multi-path distortion and shadowing (e.g., blockage by 398 buildings). Typical bit error ratios (BER) for a satellite link 399 today are on the order of 1 error per 10 million bits (1 x 10^-7) 400 or less frequent. Advanced error control coding (e.g., Reed 401 Solomon or LDPC) can be added to existing satellite services and 402 is currently being used by many services. Satellite performance 403 approaching fiber will become more common using advanced error 404 control coding in new systems. However, many legacy satellite 405 systems will continue to exhibit higher physical layer BER than 406 newer satellite systems. TCP uses all packet drops as signals of 407 network congestion and reduces its window size in an attempt to 408 alleviate the congestion. In the absence of knowledge about why a 409 packet was dropped (congestion or corruption), TCP must assume the 410 drop was due to network congestion to avoid congestion collapse 411 [Jac88] [FF98]. Therefore, packets dropped due to corruption 412 cause TCP to reduce the size of its sliding window, even though 413 these packet drops do not signal congestion in the network. 415 * Bandwidth: The radio spectrum is a limited natural resource, there 416 is a restricted amount of bandwidth available to satellite systems 417 which is typically controlled by licenses. This scarcity makes it 418 difficult to trade bandwidth to solve other design problems. 419 Satellite-based radio repeaters are known as transponders. 420 Traditional C-band transponder bandwidth is typically 36 MHz to 421 accommodate one color television channel (or 1200 voice channels). 422 Ku-band transponders are typically around 50 MHz. Furthermore, 423 one satellite may carry a few dozen transponders. Not only is 424 bandwidth limited by nature, but the allocations for commercial 425 communications are limited by international agreements so that 426 this scarce resource can be used fairly by many different 427 communications applications. Typical carrier frequencies for 428 current, point- to-point, commercial, satellite services are 6 GHz 429 (uplink) and 4 GHz (downlink), also known as C-band, and 14/12 GHz 430 (Ku band). Services also utilise higher bands, including 30/20 431 GHz (Ka-band). XXX JB: I think we need add Ka-band details. You 432 cannot get 250 Mbps out of a C-band or Ku-band transponder. 433 Outbound Ka-band transponders range from 100 to 500 MHz. Inbound 434 Ka-band transponders range from 50 to 250 MHz.XXX 436 * Link Design: It is common to consider the satellite network 437 segment composed of a forward link and a return link. The forward 438 link (also called "downlink") is the link from the ground station 439 of the satellite to the user terminal. The return link (also 440 called "uplink") is the link in the opposite direction. These two 441 links can have different capacities and employ different 442 technologies to carry the IP packets. On the forward link, the 443 satellite gateway often manages all the available capacity, 444 possibly with several carriers, to communicate with a set of 445 remote terminals. A carrier is a single Time-Division- 446 Multiplexing (TDM) channel that multiplexes packets addressed to 447 specific terminals. There are trade-offs in terms of overall 448 system efficiency and performance observed by a user. Most 449 systems incur additional delay to ensure overall system 450 performance. 452 * Shared Medium Access: In common with other radio media, satellite 453 capacity can be assigned for use by a link for a period of time, 454 for the duration of communication, for a per-packet or per burst 455 of packets, or accessed using contention mechanisms. Packets sent 456 over a shared radio channels need to be sent in frames that need 457 to be allocated resources (bandwidth, power, time) for their 458 transmission. This results in a range of characteristics that are 459 very different to a permanently assigned medium (such as an 460 Ethernet link using an optical fibre). On the return link, 461 satellite resource is typically dynamically shared among the 462 terminals. Two access methods can be distinguished: on-demand 463 access or contention access. In the former, a terminal receives 464 dedicated transmission resources (usually to send to the gateway). 465 In the latter, some resources are reserved for contention access, 466 where a set of terminals are allowed to compete to obtain 467 transmission resource. Dedicated access, which is more common in 468 currently deployed systems, can be through a Demand Assigned 469 Multiple Access (DAMA) mechanism, while contention access 470 techniques are usually based on Slotted Aloha (SA) and its 471 numerous derivatives. More information on satellite links 472 characteristics can be found in [RFC2488] [IJSCN17]. 474 Satellite systems have several characteristics that differ from most 475 terrestrial channels. These characteristics may degrade the 476 performance of TCP. These characteristics include: 478 4.1. Impact of delay 480 Even for characteristics shared with terrestrial paths, the impact on 481 a satellite link could be amplified by the path RTT. For example, 482 paths using a satellite system can also exhibit a high loss-rate 483 (e.g., a mobile user or a user behind a Wi-Fi link), where the 484 additional delay can impact transport mechanisms. 486 4.1.1. Larger Bandwidth Delay Product 488 Although capacity is often less than in many terrestrial systems, the 489 bandwidth delay product (BDP) defines the amount of data that a 490 protocol is permitted to have "in flight" at any one time to fully 491 utilize the available capacity. In flight means data that is 492 transmitted, but not yet acknowledged. 494 The delay used in this equation is the path RTT and the bandwidth is 495 the capacity of the bottleneck link along the network path. Because 496 the delay in some satellite environments is higher, protocols need to 497 keep a larger number of packets in flight. 499 This also impacts the size of window/credit needed to avoid flow 500 control mechanisms throttling the sender rate. 502 4.1.2. Variable Link Delay 504 In some satellite environments, such as some Low Earth Orbit (LEO) 505 constellations, the propagation delay to and from the satellite 506 varies over time. 508 Even when the propagation delay varies only very slightly, the 509 effects of medium access methods can result in significant variation 510 in the link delay. Whether or not this will have an impact on 511 performance of a well-designed transport is currently an open 512 question. 514 4.1.3. Impact of delay on protocol feedback 516 The link delay of some satellite systems may require more time for a 517 transport sender to determine whether or not a packet has been 518 successfully received at the final destination. This delay impacts 519 interactive applications as well as loss recovery, congestion 520 control, flow control, and other algorithms (see Section 6). 522 4.2. Intermittent connectivity 524 In some non-GEO satellite orbit configurations, from time to time 525 Internet connections need to be transferred from one satellite to 526 another or from one ground station to another. This hand-off might 527 cause excessive packet loss or reordering if not properly performed. 529 5. On-Path Mitigations 531 This section describes mitigations that operate on the path, rather 532 than with the transport endpoints. 534 5.1. Link-Level Forward Error Correction and ARQ 536 XXX Common, but includes adaptive ModCod and sometimes ARQ - which 537 can reduce the loss at the expense of decreasing the available 538 capacity. XXX 540 5.2. PMTU Discovery 542 XXX Packet Size can impact performance and mitigations (such as PEP/ 543 Application Proxy) can interact with end-to-end PMTUD XXX 545 5.3. Quality of Service (QoS) 547 Links where packets are sent over radio channels exhibit various 548 trade-offs in the way the signal is sent on the communications 549 channel. These trade-offs are not necessarily the same for all 550 packets, and network traffic flows can be optimised by mapping these 551 onto different types of lower layer treatment (packet queues, 552 resource management requests, resource usage, and adaption to the 553 channel using FEC, ARQ, etc). Many systems differentiate classes of 554 traffic to mange these QoS trade-offs. 556 5.4. Split-TCP PEP 558 High BDP networks commonly break the TCP end-to-end paradigm to adapt 559 the transport protocol. Splitting a TCP connection allows adaptation 560 for a specific use-case and to address the issues discussed in 561 Section 2. Satellite communications commonly deploy Performance 562 Enhancing Proxy (PEP) for compression, caching and TCP acceleration 563 services [RFC3135] . Their deployment can result in significant 564 performance improvement (e.g., a 50% page load time reduction in a 565 SATCOM use-case [ICCRG100] . 567 [NCT13] and [RFC3135] describe the main functions of a SATCOM TCP 568 split solution. For traffic originated at a gateway to an endpoint 569 connected via a satellite terminal, the TCP split proxy intercepts 570 TCP SYN packets, acting on behalf of the endpoint and adapts the 571 sending rate to the SATCOM scenario. The split solution can 572 specifically tune TCP parameters to the satellite link (latency, 573 available capacity). 575 When a proxy is used on each side of the satellite link, the 576 transport protocol can be replaced by a protocol other than TCP, 577 optimized for the satellite link. This can be tuned using a priori 578 information about the satellite system and/or by measuring the 579 properties of the network segment that includes the satellite system. 581 Split connections can also recover from packet loss that is local to 582 the part of the connection on which the packet losses occur. This 583 eliminates the need for end-to-end recovery of lost packets. 585 One important advantage of a TCP split solution is that it does not 586 require any end-to-end modification and is independent of both the 587 client and server sides. 589 Split-TCP comes with a significant drawback: TCP splitters are often 590 unable to track end-to-end improvements in protocol mechanisms (e.g., 591 RACK, ECN, TCP Fast Open) or new protocols that share a wire format 592 with TCP (MPTCP [RFC6824]). The set of methods configured in a split 593 proxy usually continue to be used, until the split solution is 594 finally updated. This can delay/negate the benefit of any end-to-end 595 improvements, contributing to ossification of the transport system. 597 5.5. Application Proxies 599 Authenticated proxies: 601 * Split some functions, so the proxy needs to agree on the formats/ 602 semantics of the protocol info that is changed 604 * Need a trust relationship - need to be authenticated, and 605 understand what is modified 607 * Proxy needs to be on-path, which places constraints on the routing 608 via the box 610 * Need to discover the device, which might vary by user - by service 611 - etc. 613 6. Generic Transport Protocol Mechanisms 615 This section outlines transport protocol mechanisms that may be 616 necessary to tune or optimize in satellite or hybrid satellite/ 617 terrestrial networks to better utilize the available capacity of the 618 link. These mechanisms may also be needed to fully utilize fast 619 terrestrial channels. Furthermore, these mechanisms do not 620 fundamentally hurt performance in a shared terrestrial network. Each 621 of the following sections outlines one mechanism and why that 622 mechanism may be needed. 624 * Transport initialization: the connection handshake (in TCP the 625 3-way exchange) takes a longer time to complete, delaying the time 626 to send data (several transport protocol exchanges may be needed, 627 such as TLS); 629 * Size of congestion window required: to fully exploit the 630 bottleneck capacity, a high BDP requires a larger number of in- 631 flight packets; 633 * Size of receiver (flow control) window required: to fully exploit 634 the bottleneck capacity, a high BDP requires a larger number of 635 in-flight packets; 637 * Reliability: transport layer loss detection and repair can incur a 638 single or multiple RTTs (the performance of end-to-end 639 retransmission is also impacted when using a high RTT path); 641 * Getting up to speed: many congestion control methods employ an 642 exponential increase in the sending rate during slow start (for 643 path capacity probing), a high RTT will increase the time to reach 644 the maximum possible rate; 646 * Asymmetry: when the links are asymmetric the return path may 647 modify the rate and/timing of transport acknowledgment traffic, 648 potentially changing behaviour (e.g., limiting the forward sending 649 rate). 651 6.1. Transport Initialization 653 Many transport protocols now deploy 0-RTT mechanisms [REF] to reduce 654 the number of RTTs required to establish a connection. QUIC has an 655 advantage that the TLS and TCP negotiations can be completed during 656 the transport connection handshake. This can reduce the time to 657 transmit the first data. 659 6.2. Getting up to Speed 661 Results of [IJSCN19] illustrate that it can still take many RTTs for 662 a CC to increase the sending rate to fill the bottleneck capacity. 663 The delay in getting up to speed can dominate performance for a path 664 with a large RTT, and requires the congestion and flow controls to 665 accommodate the impact of path delay. 667 One relevant solution is tuning of the initial window described in 668 [I-D.irtf-iccrg-sallantin-initial-spreading] , which has been shown 669 to improve performance both for high BDP and more common BDP 670 [CONEXT15] [ICC16] . Such a solution requires using sender pacing to 671 avoid generating bursts of packets in a network. 673 6.3. Sizing of Maxium Congestion Window 675 Size of windows required: to fully exploit the bottleneck capacity, a 676 high BDP requires a larger number of in-flight packets. 678 The number of in-flight packets required to fill a bottleneck 679 capacity, is dependent on the BDP. Default values of maximum windows 680 may not be suitable for a SATCOM context. 682 Such as presented in [PANRG105] , only increasing the initial 683 congestion window is not the only way that can improve QUIC 684 performance in a SATCOM context: increasing maximum congestion 685 windows can also result in much better performance. Other protocol 686 mechanisms also need to be considered, such as flow control at the 687 stream level in QUIC. 689 6.4. Reliability (Loss Recovery/Repair) 691 The time for end systems to perform packet loss detection and 692 recovery/repair is a function of the path RTT. 694 The RTT also determines the time needed by a server to react to a 695 congestion event. Both can impact the user experience. For example, 696 when a user uses a Wi-Fi link to access the Internet via SATCOM 697 terminal. 699 A solution could be to opportunistically retransmit packets even if 700 they have not been detected as lost but the congestion control allows 701 to transmit more packets. 703 6.4.1. Packet Level Forward Error Correction 705 XXX Packet level FEC can mitigate loss/re-ordering, with a trade-off 706 in capacity. XXX 708 End-to-end packet Forward Error Correction offers an alternative to 709 retransmission with different trade offs in terms of utilised 710 capacity and repair capability. 712 The benefits of introducing FEC need to weighed against the 713 additional overhead introduced by end-to-end FEC and the opportunity 714 to use link-local ARQ and/or link-adaptive FEC. A transport 715 connections can suffer link-related losses from a particular link 716 (e.g., Wi-Fi), but also congestion loss (e.g. router buffer overflow 717 in a satellite operator ground segment or along an Internet path). 719 6.5. Flow Control 721 Flow Control mechanisms allow the receiver to control the amount of 722 data a sender can have in flight at any time. Flow Control allows 723 the receiver to allocate the smallest buffer sizes possible improving 724 memory usage on receipt. 726 The sizing of initial receive buffers requires a balance between 727 keeping receive memory allocation small while allowing the send 728 window to grow quickly to help ensure high utilization. The size of 729 receive windows and their growth can govern the performance of the 730 protocol if updates are not timely. 732 Many TCP implementations deploy Auto-scaling mechanisms to increase 733 the size of the largest receive window over time. If these increases 734 are not timely then sender traffic can stall while waiting to be 735 notified of an increase in receive window size. XXX QUIC? XXX 736 Multi-streaming Protocols such as QUIC implement Flow Control using 737 credit-based mechanisms that allow the receiver to prioritise which 738 stream is able to send and when. Credit-based systems, when flow 739 credit allocations are not timely, can stall sending when credit is 740 exhausted. 742 6.6. ACK Traffic Reduction 744 When the links are asymmetric, for various reasons, the return path 745 may modify the rate and/timing of transport acknowledgment traffic, 746 potentially changing behaviour (e.g., limiting the forward sending 747 rate). 749 Asymmetry in capacity (or in the way capacity is granted to a flow) 750 can lead to cases where the transmission in one direction of 751 communication is restricted by the transmission of the acknowledgment 752 traffic flowing in the opposite direction. A network segment could 753 present limitations in the volume of acknowledgment traffic (e.g., 754 limited available return path capacity) or in the number of 755 acknowledgment packets (e.g., when a radio-resource management system 756 has to track channel usage), or both. 758 TCP Performance Implications of Network Path Asymmetry [RFC3449] 759 describes a range of mechanisms that have been used to mitigate the 760 impact of path asymmetry, primarily targeting operation of TCP. 762 Many mitigations have been deployed in satellite systems, often as a 763 mechanism within a PEP. Despite their benefits over paths with high 764 asymmetry, most mechanisms rely on being able to inspect and/or 765 modify the transport layer header information of TCP ACK packets. 766 This is not possible when the transport layer information is 767 encrypted (e.g., using an IP VPN). 769 One simple mitigation is for the remote endpoint to send compound 770 acknowledgments less frequently. A rate of one ACK for every RTT/4 771 can significantly reduce this traffic. The QUIC transport 772 specification may evolve to allow the ACK Ratio to be adjusted. 774 6.7. Multi-Path 776 XXX This includes between different satellite systems and between 777 satellite and terrestrial paths XXX 779 7. Protocol Specific Mechanisms 781 7.1. TCP Protocol Mechanisms 783 7.1.1. Transport Initialization 785 7.1.2. Getting Up To Speed 787 One relevant solution is tuning of the initial window described in 788 [I-D.irtf-iccrg-sallantin-initial-spreading][RFC6928], which has been 789 shown to improve performance both for high BDP and more common BDP 790 [CONEXT15] [ICC16]. This requires sender pacing to avoid generating 791 bursts of packets to the network. 793 7.1.3. Size of Windows 795 7.1.4. Reliability 797 7.1.5. ACK Reduction 799 Mechanisms are being proposed in TCPM for TCP [REF]. 801 7.2. QUIC Protocol Mechanisms 803 7.2.1. Transport initialization 805 QUIC has an advantage that the TLS and transport protocol 806 negotiations can be completed during the transport connection 807 handshake. This can reduce the time to transmit the first data. 808 Moreover, using 0-RTT may further reduce the connection time for 809 users reconnecting to a server. 811 7.2.2. Getting up to Speed 813 Getting up to speed may be easier with the usage of the 0-RTT-BDP 814 extension proposed in [I-D.kuhn-quic-0rtt-bdp]. 816 7.2.3. Size of Windows 818 7.2.4. Reliability 820 7.2.5. Asymmetry 822 The QUIC transport specification may evolve to allow the ACK Ratio to 823 be adjusted. 825 Default could be adapted following [I-D.fairhurst-quic-ack-scaling] 826 or using extensions to tune acknowledgement strategies 827 [I-D.iyengar-quic-delayed-ack]. 829 7.2.6. Packet Level Forward Error Correction 831 Network coding as proposed in [I-D.swett-nwcrg-coding-for-quic] and 832 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] could help QUIC recover from 833 link or congestion loss. 835 Another approach could utilise QUIC tunnels such as proposed in the 836 MASQUE WG to apply packet FEC to all or a part of the end-to-end path 837 or enable local retransmissions. 839 7.2.7. Split Congestion Control 841 Splitting the congestion control requires the deployment of 842 application proxies. 844 8. Discussion 846 Many of the issues identified for high BDP paths already exist when 847 using an encrypted transport service over a path that employs 848 encryption at the IP layer. This includes endpoints that utilise 849 IPsec at the network layer, or use VPN technology over a satellite 850 network segment. Users are unable to benefit from enhancement within 851 the satellite network segment, and often the user is unaware of the 852 presence of the satellite link on their path, except through 853 observing the impact it has on the performance they experience. 855 One solution would be to provide PEP functions at the termination of 856 the security association (e.g., in a VPN client). Another solution 857 could be to fall-back to using TCP (possibly with TLS or similar 858 methods being used on the transport payload). A different solution 859 could be to deploy and maintain a bespoke protocol tailored to high 860 BDP environments. In the future, we anticipate that fall-back to TCP 861 will become less desirable, and methods that rely upon bespoke 862 configurations or protocols will be unattractive. In parallel, new 863 methods such as QUIC will become widely deployed. The opportunity 864 therefore exists to ensure that the new generation of protocols offer 865 acceptable performance over high BDP paths without requiring 866 operating tuning or specific updates by users. 868 8.1. Mitigation Summary 870 XXX A Table will be inserted here XXX 872 9. Acknowledgments 874 The authors would like to thank Mark Allman, Daniel R. Glover and 875 Luis A. Sanchez the authors of RFC2488 from which the format and 876 descriptions of satellite systems in this document have taken 877 inspiration. 879 The authors would like to thank Christian Huitema, Igor Lubashev, 880 Alexandre Ferrieux, Francois Michel, Emmanuel Lochin, github user 881 sedrubal and the participants of the IETF106 side-meeting on QUIC for 882 high BDP for their useful feedback. 884 10. Security Considerations 886 This document does not propose changes to the security functions 887 provided by the QUIC protocol. QUIC uses TLS encryption to protect 888 the transport header and its payload. Security is considered in the 889 "Security Considerations" of cited IETF documents. 891 11. Informative References 893 [CONEXT15] Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running 894 Short Flows Quickly and Safely", ACM CoNEXT , 2015. 896 [FF98] Floyd, S. and K. Fall, "Promoting the Use of End-to-End 897 Congestion Control in the Internet", IEEE Transactions on 898 Networking 10.1109/90.79302, 1999. 900 [I-D.fairhurst-quic-ack-scaling] 901 Fairhurst, G., Custura, A., and T. Jones, "Changing the 902 Default QUIC ACK Policy", Work in Progress, Internet- 903 Draft, draft-fairhurst-quic-ack-scaling-04, 15 March 2021, 904 . 907 [I-D.irtf-iccrg-sallantin-initial-spreading] 908 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 909 E., and A. Beylot, "Safe increase of the TCP's Initial 910 Window Using Initial Spreading", Work in Progress, 911 Internet-Draft, draft-irtf-iccrg-sallantin-initial- 912 spreading-00, 15 January 2014, 913 . 916 [I-D.irtf-panrg-path-properties] 917 Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path 918 Properties", Work in Progress, Internet-Draft, draft-irtf- 919 panrg-path-properties-03, 9 July 2021, 920 . 923 [I-D.iyengar-quic-delayed-ack] 924 Iyengar, J. and I. Swett, "Sender Control of 925 Acknowledgement Delays in QUIC", Work in Progress, 926 Internet-Draft, draft-iyengar-quic-delayed-ack-02, 2 927 November 2020, . 930 [I-D.kuhn-quic-0rtt-bdp] 931 Kuhn, N., Stephan, E., Fairhurst, G., Jones, T., and C. 932 Huitema, "Transport parameters for 0-RTT connections", 933 Work in Progress, Internet-Draft, draft-kuhn-quic-0rtt- 934 bdp-09, 7 June 2021, . 937 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] 938 Roca, V., Michel, F., Swett, I., and M. Montpetit, 939 "Sliding Window Random Linear Code (RLC) Forward Erasure 940 Correction (FEC) Schemes for QUIC", Work in Progress, 941 Internet-Draft, draft-roca-nwcrg-rlc-fec-scheme-for-quic- 942 03, 9 March 2020, . 945 [I-D.swett-nwcrg-coding-for-quic] 946 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 947 for QUIC", Work in Progress, Internet-Draft, draft-swett- 948 nwcrg-coding-for-quic-04, 9 March 2020, 949 . 952 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 953 E., and A-L. Beylot, "Reducing web latency through TCP IW: 954 Be smart", IEEE ICC , 2016. 956 [ICCRG100] Kuhn, N., "MPTCP and BBR performance over Internet 957 satellite paths", IETF ICCRG 100, 2017. 959 [IJSCN17] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 960 and N. Kuhn, "Software-defined satellite cloud RAN", 961 International Journal of Satellite Communications and 962 Networking , 2017. 964 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 965 QUIC performance over a public SATCOM access", 966 International Journal of Satellite Communications and 967 Networking , 2019. 969 [Jac88] Jacobson, V., "Congestion Avoidance and Control", ACM 970 SIGCOMM 88, 1988. 972 [Mar78] Martin, J., "Communications Satellite Systems", Prentice 973 Hall 78, 1978. 975 [Mon98] Montpetit, M.J., "TELEDESIC: Enabling The Global Community 976 Interaccess", International Wireless Symposium 98, 1998. 978 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 979 performances over geostationary satellite link", Network 980 and Communication Technologies , 2013. 982 [PANRG105] Kuhn, N., Stephan, E., Border, J., and G. Fairhurst, "QUIC 983 Over In-sequence Paths with Different Characteristics", 984 IRTF PANRG 105, 2019. 986 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 987 Over Satellite Channels using Standard Mechanisms", 988 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 989 . 991 [RFC2760] Allman, M., Ed., Dawkins, S., Glover, D., Griner, J., 992 Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, 993 H., Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP 994 Research Related to Satellites", RFC 2760, 995 DOI 10.17487/RFC2760, February 2000, 996 . 998 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 999 Shelby, "Performance Enhancing Proxies Intended to 1000 Mitigate Link-Related Degradations", RFC 3135, 1001 DOI 10.17487/RFC3135, June 2001, 1002 . 1004 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 1005 Sooriyabandara, "TCP Performance Implications of Network 1006 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1007 December 2002, . 1009 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1010 "TCP Extensions for Multipath Operation with Multiple 1011 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1012 . 1014 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1015 "Increasing TCP's Initial Window", RFC 6928, 1016 DOI 10.17487/RFC6928, April 2013, 1017 . 1019 [RFC8975] Kuhn, N., Ed. and E. Lochin, Ed., "Network Coding for 1020 Satellite Systems", RFC 8975, DOI 10.17487/RFC8975, 1021 January 2021, . 1023 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1024 Multiplexed and Secure Transport", RFC 9000, 1025 DOI 10.17487/RFC9000, May 2021, 1026 . 1028 [Sta94] Stallings, W., "Data and Computer Communications", 1029 MacMillian 4th edition, 1994. 1031 [Stu95] Sturza, M.A., "Architecture of the TELEDESIC Satellite 1032 System", International Mobile Satellite Conference 95, 1033 1995. 1035 Appendix A. Example Network Profiles 1037 This proposes sampler profiles and a set of regression tests to 1038 evaluate transport protocols over SATCOM links and discusses how to 1039 ensure acceptable protocol performance. 1041 XXX These test profiles currently focus on the measuring performance 1042 and testing for regressions in the QUIC protocol. The authors 1043 solicit input to adapt these tests to apply to more transport 1044 protocols. XXX 1046 A.1. LEO 1048 A.2. MEO 1050 A.3. GEO 1052 This section proposes a set of regression tests for QUIC that 1053 consider high BDP scenarios. We define by: 1055 * Download path: from Internet to the client endpoint; 1056 * Upload path: from the client endpoint to a server (e.g., in the 1057 Internet). 1059 A.3.1. Small public satellite broadband access 1061 The tested scenario has the following path characteristics: 1063 * Satellite downlink path: 10 Mbps 1065 * Satellite uplink path: 2 Mbps 1067 * No emulated packet loss 1069 * RTT: 650 ms 1071 * Buffer size : BDP 1073 During the transmission of 100 MB on both download and upload paths, 1074 the test should report the upload and download time of 2 MB, 10 MB 1075 and 100 MB. 1077 Initial thoughts of the performance objectives for QUIC are the 1078 following: 1080 * 3 s for downloading 2 MB 1082 * 10 s for downloading 10 MB 1084 * 85 s for downloading 100 MB 1086 * 10 s for uploading 2 MB 1088 * 50 s for uploading 10 MB 1090 * 420 s for uploading 100 MB 1092 A.3.2. Medium public satellite broadband access 1094 The tested scenario has the following path characteristics: 1096 * Satellite downlink path: 50 Mbps 1098 * Satellite uplink path: 10 Mbps 1100 * No emulated packet loss 1102 * RTT: 650 ms 1103 * Buffer size : BDP 1105 During the transmission of 100 MB on the download path, the test 1106 should report the download time for 2 MB, 10 MB and 100 MB. Then, to 1107 assess the performance of QUIC with the 0-RTT extension and its 1108 variants, after 10 seconds, repeat the transmission of 100 MB on the 1109 download path where the download time for 2 MB, 10 MB and 100 MB is 1110 recorded. 1112 Initial thoughts of the performance objectives for QUIC are the 1113 following: 1115 * 3 s for the first downloading 2 MB 1117 * 5 s for the first downloading 10 MB 1119 * 20 s for the first downloading 100 MB 1121 * TBD s for the second downloading 2 MB 1123 * TBD s for the second downloading 10 MB 1125 * TBD s for the second downloading 100 MB 1127 A.3.3. Congested medium public satellite broadband access 1129 There are cases where the uplink path is congested or where the 1130 capacity of the uplink path is not guaranteed. 1132 The tested scenario has the following path characteristics: 1134 * Satellite downlink path: 50 Mbps 1136 * Satellite uplink path: 0.5 Mbps 1138 * No emulated packet loss 1140 * RTT: 650 ms 1142 * Buffer size : BDP 1144 During the transmission of 100 MB on the download path, the test 1145 should report the download time for 2 MB, 10 MB and 100 MB. 1147 Initial thoughts of the performance objectives for QUIC are the 1148 following: 1150 * 3 s for downloading 2 MB 1151 * 5 s for downloading 10 MB 1153 * 20 s for downloading 100 MB 1155 A.3.4. Variable medium public satellite broadband access 1157 There are cases where the downlink path is congested or where, due to 1158 link layer adaptations to rain fading, the capacity of the downlink 1159 path is variable. 1161 The tested scenario has the following path characteristics: 1163 * Satellite downlink path: 50 Mbps - wait 5s - 10 Mbps 1165 * Satellite uplink path: 10 Mbps 1167 * No emulated packet loss 1169 * RTT: 650 ms 1171 * Buffer size : BDP 1173 During the transmission of 100 MB on the download path, the test 1174 should report the download time for 2 MB, 10 MB and 100 MB. 1176 Initial thoughts of the performance objectives for QUIC are the 1177 following: 1179 * TBD s for downloading 2 MB 1181 * TBD s for downloading 10 MB 1183 * TBD s for downloading 100 MB 1185 A.3.5. Loss-free large public satellite broadband access 1187 The tested scenario has the following path characteristics: 1189 * Satellite downlink path: 250 Mbps 1191 * Satellite uplink path: 6 Mbps 1193 * No emulated packet loss 1195 * RTT: 650 ms 1197 * Buffer size : BDP 1198 During the transmission of 100 MB on the download path, the test 1199 should report the download time for 2 MB, 10 MB and 100 MB. Then, to 1200 assess the performance of QUIC with the 0-RTT extension and its 1201 variants, after 10 seconds, repeat the transmission of 100 MB on the 1202 download path where the download time for 2 MB, 10 MB and 100 MB is 1203 recorded. 1205 Initial thoughts of the performance objectives for QUIC are the 1206 following: 1208 * 3 s for the first downloading 2 MB 1210 * 5 s for the first downloading 10 MB 1212 * 8 s for the first downloading 100 MB 1214 * TBD s for the second downloading 2 MB 1216 * TBD s for the second downloading 10 MB 1218 * TBD s for the second downloading 100 MB 1220 A.3.6. Lossy large public satellite broadband access 1222 The tested scenario has the following path characteristics: 1224 * Satellite downlink path: 250 Mbps 1226 * Satellite uplink path: 6 Mbps 1228 * Emulated packet loss on both downlink and uplink paths: 1230 - Uniform random transmission link losses: 1% 1232 * RTT: 650 ms 1234 * Buffer size : BDP 1236 During the transmission of 100 MB on the download path, the test 1237 should report the download time for 2 MB, 10 MB and 100 MB. 1239 Initial thoughts of the performance objectives for QUIC are the 1240 following: 1242 * 3 s for downloading 2 MB (uniform transmission link losses) 1244 * 6 s for downloading 10 MB (uniform transmission link losses) 1245 * 10 s for downloading 100 MB (uniform transmission link losses) 1247 Appendix B. Revision Notes 1249 Note to RFC-Editor: please remove this entire section prior to 1250 publication. 1252 Individual draft -00: 1254 * Comments and corrections are welcome directly to the authors or 1255 via the https://github.com/uoaerg/draft-jones-transport-for- 1256 satellite github repo in the form of pull requests and issues. 1258 Individual draft -01: 1260 * Explained Terms Forward and return link 1262 * Rearranged text to help the document read better 1264 * Fix typos and inaccuracies 1266 * Added a mention of MPTCP 1268 Authors' Addresses 1270 Tom Jones 1271 University of Aberdeen 1273 Email: tom@erg.abdn.ac.uk 1275 Godred Fairhurst 1276 University of Aberdeen 1278 Email: gorry@erg.abdn.ac.uk 1280 Nicolas Kuhn 1281 CNES 1283 Email: nicolas.kuhn@cnes.fr 1285 John Border 1286 Hughes Network Systems, LLC 1288 Email: border@hns.com 1289 Emile Stephan 1290 Orange 1292 Email: emile.stephan@orange.com