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