idnits 2.17.1 draft-jones-tsvwg-transport-for-satellite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 February 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'O3B' is mentioned on line 325, but not defined == Missing Reference: 'REF' is mentioned on line 763, but not defined == Unused Reference: 'I-D.ietf-quic-recovery' is defined on line 882, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-fairhurst-quic-ack-scaling-03 == Outdated reference: A later version (-11) exists of draft-kuhn-quic-0rtt-bdp-07 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Jones 3 Internet-Draft G. Fairhurst 4 Intended status: Informational University of Aberdeen 5 Expires: 26 August 2021 N. Kuhn 6 CNES 7 J. Border 8 Hughes Network Systems, LLC 9 E. Stephan 10 Orange 11 22 February 2021 13 Enhancing Transport Protocols over Satellite Networks 14 draft-jones-tsvwg-transport-for-satellite-00 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 RFC 2488 and RFC 3135 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 26 August 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Satellite Systems . . . . . . . . . . . . . . . . . . . . . . 5 76 2.1. Geosynchronous Earth Orbit (GEO) . . . . . . . . . . . . 6 77 2.2. Low Earth Orbit (LEO) . . . . . . . . . . . . . . . . . . 7 78 2.3. Medium Earth Orbit (MEO) . . . . . . . . . . . . . . . . 7 79 2.4. Hybrid Network Paths . . . . . . . . . . . . . . . . . . 7 80 2.5. Convergence with Mobile Cellular . . . . . . . . . . . . 8 81 3. Satellite System Characteristics . . . . . . . . . . . . . . 8 82 3.1. Impact of Delay . . . . . . . . . . . . . . . . . . . . . 10 83 3.1.1. Larger Bandwidth Delay Product . . . . . . . . . . . 10 84 3.1.2. Variable Link Delay . . . . . . . . . . . . . . . . . 10 85 3.1.3. Impact of delay on protocol feedback . . . . . . . . 10 86 3.2. Intermittent connectivity . . . . . . . . . . . . . . . . 11 87 4. On-Path Mitigations . . . . . . . . . . . . . . . . . . . . . 11 88 4.1. Link-Level Forward Error Correction and ARQ . . . . . . . 11 89 4.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . . 11 90 4.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . 11 91 4.4. Split-TCP PEP . . . . . . . . . . . . . . . . . . . . . . 11 92 4.5. Application Proxies . . . . . . . . . . . . . . . . . . . 12 93 5. Generic Transport Protocol Mechanisms . . . . . . . . . . . . 13 94 5.1. Getting up to Speed . . . . . . . . . . . . . . . . . . . 14 95 5.2. Sizing of Maxium Congestion Window . . . . . . . . . . . 14 96 5.3. Reliability (Loss Recovery/Repair) . . . . . . . . . . . 14 97 5.3.1. Packet Level Forward Error Correction . . . . . . . . 15 98 5.4. Flow Control . . . . . . . . . . . . . . . . . . . . . . 15 99 5.5. ACK Traffic Reduction . . . . . . . . . . . . . . . . . . 16 100 5.6. 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 and mobile 142 networks, and service provision to moving terminals (maritime, 143 aircraft, etc.). 145 In most scenarios, the satellite IP network segment forms only one 146 part of the end-to-end path used by an Internet transport protocol. 147 This means that user traffic can experience a path that includes a 148 satellite network combined with a wide variety of other network 149 technologies (Ethernet, cable modems, WiFi, cellular, radio links, 150 etc). Although a user can sometimes know the presence of a satellite 151 service, a typical user does not deploy special software or 152 applications when a satellite network is being used. Users can 153 therefore be often unaware of the technologies underpinning the links 154 forming a network path. 156 Satellite path characteristics have an effect on the operation of 157 Internet transport protocols, such as TCP, SCTP or QUIC. Transport 158 Protocol performance can be affected by the magnitude and variability 159 of the network delay. When transport protocols perform poorly the 160 link utilization can be low. Techniques and recommendations have 161 been made that can improve the performance of transport protocols 162 when the path includes as satellite network. 164 The end-to-end performance of an application using an Internet path 165 can be impacted by the path characteristics, such as the Bandwidth- 166 Delay Product (BDP) of the links and network devices forming the 167 path. It can also be impacted by underlying mechanisms used to 168 manage the radio resources. 170 Performance can be impacted at several layers. For instance, the 171 page load time for a complex page can be much larger when a path 172 includes a satellite system. Although mechanisms are designed for 173 use across Internet paths, not all designs are performant when used 174 over the wide diversity of path characteristics that can occur. This 175 document therefore considers the implications of Internet paths that 176 include a satellite system. A significant contribution to the 177 reduced performance can arise from the initialisation and design of 178 transport mechanisms. The analysis and conclusions might also apply 179 to other network systems that also result in characteristics that 180 differ from typical Internet paths. 182 RFC 2488 specifies an Internet Best Current Practices for the 183 Internet Community, relating to use of the standards-track 184 Transmission Control Protocol (TCP) mechanisms over satellite 185 channels [RFC2488]. A separate RFC,[RFC2760], identified research 186 issues and proposed mitigations for satellite paths. 188 Since the publication of these RFCs many TCP mechanisms have become 189 widely used. In particular, this includes a series of mitigation 190 based on Performance Enhancing Proxies (PEPs) [RFC3135] that split 191 the protocol at the transport layer. Although PEPs are now a common 192 component of satellite systems, their use slows the deployment of new 193 transport protocols and mechanisms (each of which demands an update 194 to the PEP functionality). This has made it difficult for new 195 protocol extensions to achieve comparable performance over satellite 196 channels. In addition, protocols with strong requirements on 197 authentication and privacy such as QUIC [I-D.ietf-quic-transport] are 198 not able to be split using a PEP and mitigation, and need to 199 therefore use other methods. 201 XXX Authors Note: This document currently focuses on Geosynchronous 202 Earth Orbit (GEO) satellite systems, the authors solicit feedback and 203 experience from users and operators of satellite systems using other 204 orbits. XXX 206 The remainder of this document is divided as follows: 208 * Section 2 identifies common characteristics of a SATCOM network 209 that can impact the operation of the transport protocols. This 210 complements the description of [RFC2488]. 212 * Section 3 discusses specific characteristics that need to be 213 considered when implementing and deploying transport protocols and 214 highlights key changes since the publication of [RFC2488]. 216 * Section 4 outlines existing deployed mitigations that operate 217 below the transport protocol layer. This offers advice to 218 designers and operators of satellite networks. 220 * Section 5 outlines transport protocol mechanisms defined that may 221 benefit with satellite networks specific tuning and optimization. 222 In particular it discusses on end-to-end considerations, and the 223 mechanisms that impact performance of encrypted transports. 225 * Finally, Section 6 provides a summary of the features recommended 226 for modern transport protocols. 228 2. Satellite Systems 230 This document considers the characteristics of satellite 231 communications systems. Satellite systems are being deployed using 232 many space orbits, including low earth orbit, medium earth orbits, 233 geosynchronous orbits, elliptical orbits and more. 235 * Many communications satellites are located at Geostationary Orbit 236 (GEO) with an altitude of approximately 36,000 km [Sta94]. At 237 this altitude the orbit period is the same as the Earth's rotation 238 period. Therefore, each ground station is always able to "see" 239 the orbiting satellite at the same position in the sky. The 240 propagation time for a radio signal to travel twice that distance 241 (corresponding to a ground station directly below the satellite) 242 is 239.6 milliseconds (ms) [Mar78]. For ground stations at the 243 edge of the coverage of a satellite, the distance traveled is 2 x 244 41,756 km for a total propagation delay of 279.0 ms [Mar78]. 245 These delays are for one ground station-to-satellite-to-ground 246 station route (or "hop"). Therefore, the delay to send a packet 247 and receive the corresponding reply (one round-trip time or RTT) 248 could be at least 558 ms. This RTT is not solely due to satellite 249 signal propagation time and will be increased by other factors, 250 such as the serialisation time, including any FEC encoding/ARQ 251 delay and propagation time of other links along the network path 252 and the queueing delay in network equipment. The delay is also 253 increased when multiple hops are used (i.e. communications is 254 relayed via a gateway) or in systems using inter-satellite links. 255 As satellites become more complex and include on-board processing 256 of signals, additional delay can be added. 258 * Communications satellites can also be built to use a Low Earth 259 Orbit (LEO) [Stu95] [Mon98]. The lower orbits require the use of 260 constellations of satellites for constant coverage. In other 261 words, as one satellite leaves the ground station's sight, another 262 satellite appears on the horizon and the channel is switched to 263 it. The propagation delay to a LEO orbit ranges from several 264 milliseconds when communicating with a satellite directly 265 overhead, to as much as 20 ms when the same satellite is on the 266 horizon. Some LEO systems use inter-satellite links, where the 267 path delay depends on the routing through the network. 269 * Another orbital position use a Medium Earth Orbit (MEO) [Mar78]. 270 These orbits lie between LEO and GEO. 272 2.1. Geosynchronous Earth Orbit (GEO) 274 The characteristics of systems using Geosynchronous Earth Orbit (GEO) 275 satellites differ from paths only using terrestrial links in their 276 path characteristics: 278 * A large propagation delay of at least 250ms one-way delay; 280 * Use of radio resource management (often using techniques similar 281 to cellular mobile or DOCSIS cable networks, but differ to 282 accommodate the satellite propagation delay); 284 * Links can be highly asymmetric in terms of capacity, the one-way 285 delay and their cost of operation. 287 As an example, many GEO systems are build using the DVB-S2 288 specifications [EN 302 307-1], published by the European 289 Telecommunications Standards Institute (ETSI), where the key concept 290 is to ensure both a good usage of the satellite resource and a Quasi- 291 Error-Free (QEF) link. These systems typically monitor the link 292 quality in real-time, and known symbol sequences, included along with 293 regular packets enable an estimation of the current signal-to-noise 294 ratio, that can fed back allowing the transmitting link to adapt its 295 coding rate and modulation to the current transmission conditions. 297 2.2. Low Earth Orbit (LEO) 299 There are many designs of LEO systems. Depending on the locations of 300 the gateways on the ground, routing within the constellation can be 301 necessary to forward packets down to a ground terminal. Capacity can 302 vary significantly between systems. 304 Depending on the routes currently available - especially upon whether 305 Inter-Satellite Links (ISL) are used, additional jitter may occur 306 (from 40ms to 140ms with the Iridium constellation). Some systems 307 can also experience either out-of-order delivery of packets or 308 additional delay due to buffering. Other systems have very different 309 designs. 311 XXX The authors solicit feedback and experience from users and 312 operators of satellite systems in LEO orbits. XXX 314 2.3. Medium Earth Orbit (MEO) 316 MEO systems such as O3B combines advantages and drawbacks from both 317 LEO and GEO systems. 319 MEO systems can have a large coverage and with limited number of 320 satellites required providing a broad service. The usage of powerful 321 satellites enables provision of high data rates. 323 MEO systems have the drawback, from a transport protocol perspective, 324 that the BDP can be very high due to the altitude of such 325 constellations (8 063 km for [O3B]) and there may be delay variations 326 when coverage requires handover to another MEO satellite (e.g. every 327 45 minutes with O3B). This can be mitigated by diversity techniques 328 (e.g. double antennas at terminals). 330 XXX The authors solicit feedback and experience from users and 331 operators of satellite systems in MEO orbits. XXX 333 2.4. Hybrid Network Paths 335 XXX The authors solicit feedback and experience from users and 336 operators of satellite systems in hybrid network scenarios. XXX 338 2.5. Convergence with Mobile Cellular 340 XXX This section should look at IP convergence with 5G systems and 341 emerging specs 3GPP non terrestrial networks (NTN). XXX 343 3. Satellite System Characteristics 345 There is an inherent delay in the delivery of a packet over a 346 satellite system due to the finite speed of light and the altitude of 347 communications satellites. 349 Satellite links are dominated by two fundamental characteristics, as 350 described below: 352 * Packet Loss: The strength of any radio signal falls in proportion 353 to the square of the distance traveled. For a satellite link the 354 square of the distance traveled. Is large and so the signal 355 becomes weak before reaching its destination. This results in a 356 low signal-to-noise ratio. Some frequencies are particularly 357 susceptible to atmospheric effects such as rain attenuation. For 358 applications with moving terminals, satellite channels are 359 especially susceptible to multi-path distortion and shadowing 360 (e.g., blockage by buildings). A typical modern satellite link 361 can have a bit error ratio (BER) of the order of 1 error per 10 362 million bits (1 x 10^-7) or less frequent. Advanced error control 363 coding (e.g., Reed Solomon or LDPC) can be added to existing 364 satellite services and is currently being used by many services. 365 Satellite performance approaching fiber will become more common 366 using advanced error control coding in new systems. However, many 367 legacy satellite systems will continue to exhibit higher physical 368 layer BER than newer satellite systems. TCP uses all packet drops 369 as signals of network congestion and reduces its window size in an 370 attempt to alleviate the congestion. In the absence of knowledge 371 about why a packet was dropped (congestion or corruption), TCP 372 must assume the drop was due to network congestion to avoid 373 congestion collapse [Jac88] [FF98]. Therefore, packets dropped 374 due to corruption cause TCP to reduce the size of its sliding 375 window, even though these packet drops do not signal congestion in 376 the network. 378 * Bandwidth: The radio spectrum is a limited natural resource, there 379 is a restricted amount of bandwidth available to satellite 380 systems, which is regulated by ITU-R and usually controlled by 381 licenses. This scarcity makes it difficult to increase bandwidth 382 to solve other design problems. Satellite-based radio repeaters 383 are known as transponders. Traditional C-band transponder 384 bandwidth is typically 36 MHz to accommodate one color television 385 channel (or 1200 voice channels). Ku-band transponders are 386 typically around 50 MHz. Furthermore, one satellite may carry a 387 few dozen transponders. Not only is bandwidth limited by nature, 388 but the allocations for commercial communications are limited by 389 international agreements so that this scarce resource can be used 390 fairly by many different communications applications. Typical 391 carrier frequencies for current, point- to-point, commercial, 392 satellite services are 6 GHz (uplink) and 4 GHz (downlink), also 393 known as C-band, and 14/12 GHz (Ku band). Services also utilise 394 higher bands, including 30/20 GHz (Ka-band). XXX JB: I think we 395 need add Ka-band details. You cannot get 250 Mbps out of a C-band 396 or Ku-band transponder. Outbound Ka-band transponders range from 397 100 to 500 MHz. Inbound Ka-band transponders range from 50 to 250 398 MHz.XXX 400 * Link Design: It is common to consider a satellite network segment 401 as composed of a forward link and a return link. The two links 402 usually have different capacities and employ different 403 technologies to carry IP packets. On the forward link, a 404 satellite gateway often manages all the available capacity, 405 possibly with several carriers, to communicate with a set of 406 remote terminals. A carrier is a single Time-Division- 407 Multiplexing (TDM) channel that multiplexes packets addressed to 408 specific terminals. There are trade-offs in terms of overall 409 system efficiency and performance observed by a user. Most 410 systems incur additional delay to ensure overall system 411 performance. On the return link, satellite resource is typically 412 dynamically shared among the terminals. 414 * Shared Medium Access: In common with other radio media, satellite 415 capacity can be assigned for use by a link for a period of time, 416 for the duration of communication, for a per-packet or per burst 417 of packets, or accessed using contention mechanisms. Packets sent 418 over a shared radio channels need to be sent in frames that need 419 to be allocated resources (bandwidth, power, time) for their 420 transmission. This results in a range of characteristics that are 421 very different to a permanently assigned medium (such as an 422 Ethernet link using an optical fibre). Two access methods can be 423 distinguished: on-demand access or contention access. In the 424 former, a terminal receives dedicated transmission resources 425 (usually to send to the gateway). In the latter, some resources 426 are reserved for contention access, where a set of terminals are 427 allowed to compete to obtain transmission resource. Dynamic 428 access is more common in currently deployed systems and can be 429 through a Demand Assigned Multiple Access (DAMA) mechanism, while 430 contention access techniques are usually based on Slotted Aloha 431 (SA) and its numerous derivatives. More information on satellite 432 links characteristics can be found in [RFC2488] [IJSCN17]. 434 Satellite systems have several characteristics that differ from most 435 terrestrial channels. These characteristics may degrade the 436 performance of TCP. These characteristics include: 438 3.1. Impact of Delay 440 Even for characteristics shared with terrestrial paths, the impact on 441 a satellite link could be amplified by the path RTT. For example, 442 paths using a satellite system can also exhibit a high loss-rate 443 (e.g., a mobile user or a user behind a Wi-Fi link), where the 444 additional delay can impact transport mechanisms. 446 3.1.1. Larger Bandwidth Delay Product 448 Although capacity is often less than in many terrestrial systems, the 449 bandwidth delay product (BDP) defines the amount of data that a 450 protocol is permitted to have "in flight" (data transmitted, but not 451 yet acknowledged) at any one time to fully utilize the available 452 capacity. 454 The delay used in this equation is the path RTT and the bandwidth is 455 the capacity of the bottleneck link along the network path. Because 456 the delay in some satellite environments is larger, protocols need to 457 keep a larger number of packets "in flight" (that is, sent but not 458 yet acknowledged). 460 This also impacts the size of window/credit needed to avoid flow 461 control mechanisms throttling the sender rate. 463 3.1.2. Variable Link Delay 465 In some satellite environments, such as some Low Earth Orbit (LEO) 466 constellations, the propagation delay to and from the satellite 467 varies over time. 469 Even when the propagation delay varies only very slightly, the 470 effects of medium access methods can result in significant variation 471 in the link delay. Whether or not this will have an impact on 472 performance of a well-designed transport is currently an open 473 question. 475 3.1.3. Impact of delay on protocol feedback 477 The link delay of some satellite systems may require more time for a 478 transport sender to determine whether or not a packet has been 479 successfully received at the final destination. This delay impacts 480 interactive applications as well as loss recovery, congestion 481 control, flow control, and other algorithms (see Section 5). 483 3.2. Intermittent connectivity 485 For systems using non-GEO satellites, from time to time Internet 486 connections need to be transferred from one satellite to another or 487 from one ground station to another. This hand-over can be made 488 without interrupting the service, but in some system designs might 489 cause packet loss or reordering. 491 4. On-Path Mitigations 493 This section describes mitigations that operate on the path, rather 494 than with the transport endpoints. 496 4.1. Link-Level Forward Error Correction and ARQ 498 XXX Common. This includes Adaptive Coding and Modulation (ACM) and 499 sometimes link ARQ - which can reduce the loss at the expense of 500 decreasing the available capacity. XXX 502 4.2. PMTU Discovery 504 XXX Packet size can impact performance and mitigations (such as PEP/ 505 Application Proxy) can interact with end-to-end PMTUD. XXX 507 4.3. Quality of Service (QoS) 509 Links were packets are sent over radio channels exhibit various 510 trade-offs in the way the signal is sent on the communications 511 channel. These trade-offs are not necessarily the same for all 512 packets, and network traffic flows can be optimised by mapping these 513 onto different types of lower layer treatment (packet queues, 514 resource management requests, resource usage, and adaption to the 515 channel using FEC, ARQ, etc). Many systems differentiate classes of 516 traffic to mange these QoS trade-offs. 518 4.4. Split-TCP PEP 520 High BDP networks commonly break the TCP end-to-end paradigm to adapt 521 the transport protocol. Splitting a TCP connection allows adaptation 522 for a specific use-case and to address the issues discussed in 523 Section 2. Satellite communications commonly deploy Performance 524 Enhancing Proxy (PEP) for compression, caching and TCP acceleration 525 services [RFC3135] . Their deployment can result in significant 526 performance improvement (e.g., a 50% page load time reduction in a 527 SATCOM use-case [ICCRG100] . 529 [NCT13] and [RFC3135] describe the main functions of a SATCOM TCP 530 split solution. For traffic originated at a gateway to an endpoint 531 connected via a satellite terminal, the TCP split proxy intercepts 532 TCP SYN packets, acting on behalf of the endpoint and adapts the 533 sending rate to the SATCOM scenario. The split solution can 534 specifically tune TCP parameters to the satellite link (latency, 535 available capacity). 537 When a proxy is used on each side of the satellite link, the 538 transport protocol can be replaced by a protocol other than TCP, 539 optimized for the satellite link. This can be tuned using a priori 540 information about the satellite system and/or by measuring the 541 properties of the network segment that includes the satellite system. 543 Split connections can also recover from packet loss that is local to 544 the part of the connection on which the packet losses occur. This 545 eliminates the need for end-to-end recovery of lost packets. 547 One important advantage of a TCP split solution is that it does not 548 require any end-to-end modification and is independent of both the 549 client and server sides. This also comes with a drawback: split-TCP 550 PEPs can ossify the protocol stack being used because they are often 551 unable to track improvements in end-to-end protocol mechanisms (e.g., 552 RACK, ECN, TCP Fast Open). The set of methods configured in a split 553 proxy usually continue to be used, until the split solution is 554 finally updated. This can delay/negate the benefit of any end-to-end 555 improvements. 557 4.5. Application Proxies 559 Authenticated proxies: 561 * The existence of Application Proxies requires a discovery device, 562 which might vary by user - by service - etc.; 564 * Application Proxies can split key functions, but this requires 565 agreement between endpoints and the proxy on the formats/semantics 566 of the protocol info that is to be changed; 568 * With the common use of security functions (such as TLS), there 569 also needs to be a trust relationship - a proxy needs to be 570 authenticated; 572 * A proxy needs to remain on the path, which can place constraints 573 on the routing infrastructure - handover between proxies is 574 possible, but is generally complex. 576 5. Generic Transport Protocol Mechanisms 578 This section outlines transport protocol mechanisms that may be 579 necessary to tune or optimize in satellite or hybrid satellite/ 580 terrestrial networks to better utilize the available capacity of the 581 link. These mechanisms may also be needed to fully utilize fast 582 terrestrial channels. Furthermore, these mechanisms do not 583 fundamentally hurt performance in a shared terrestrial network. Each 584 of the following sections outlines one mechanism and why that 585 mechanism may be needed. 587 * Transport initialization: the connection handshake (in TCP the 588 3-way exchange) takes a longer time to complete, delaying the time 589 to send data (several transport protocol exchanges may be needed, 590 such as TLS); 592 * Size of congestion window required: to fully exploit the 593 bottleneck capacity, a high BDP requires a larger number of in- 594 flight packets; 596 * Size of receiver (flow control) window required: to fully exploit 597 the bottleneck capacity, a high BDP requires a larger number of 598 in-flight packets; 600 * Reliability: transport layer loss detection and repair can incur a 601 single or multiple RTTs (the performance of end-to-end 602 retransmission is also impacted when using a high RTT path); 604 * Getting up to speed: many congestion control methods employ an 605 exponential increase in the sending rate during slow start (for 606 path capacity probing), a high RTT will increase the time to reach 607 a specific rate; 609 * Asymmetry: when the links are asymmetric the return path may 610 modify the rate and/timing of transport acknowledgment traffic, 611 potentially changing behaviour (e.g., limiting the forward sending 612 rate). 614 5.1. Getting up to Speed 616 Many transport protocols now deploy 0-RTT mechanisms [REF] to reduce 617 the number of RTTs required to establish a connection. QUIC has an 618 advantage that the TLS and TCP negotiations can be completed during 619 the transport connection handshake. This can reduce the time to 620 transmit the first data. Results of [IJSCN19] illustrate that it can 621 still take many RTTs for a CC to increase the sending rate to fill 622 the bottleneck capacity. The delay in getting up to speed can 623 dominate performance for a path with a large RTT, and requires the 624 congestion and flow controls to accommodate the impact of path delay. 626 One relevant solution is tuning of the initial window described in 627 [I-D.irtf-iccrg-sallantin-initial-spreading], which has been shown to 628 improve performance both for high BDP and more common BDP [CONEXT15] 629 [ICC16]. Such a solution requires using sender pacing to avoid 630 generating bursts of packets in a network. 632 5.2. Sizing of Maxium Congestion Window 634 Size of windows required: to fully exploit the bottleneck capacity, a 635 high BDP requires a larger number of in-flight packets. 637 The number of in-flight packets required to fill a bottleneck 638 capacity, is dependent on the BDP. Default values of maximum windows 639 might be unsuitable in a SATCOM context. 641 Such as presented in [PANRG105] , only increasing the initial 642 congestion window is not the only way that can improve QUIC 643 performance in a SATCOM context: increasing maximum congestion 644 windows can also result in much better performance. Other protocol 645 mechanisms also need to be considered, such as flow control at the 646 stream level in QUIC. 648 5.3. Reliability (Loss Recovery/Repair) 650 The time for end systems to perform packet loss detection and 651 recovery/repair is a function of the path RTT. 653 The RTT also determines the time needed by a server to react to a 654 congestion event. Both can impact the user experience. For example, 655 when a user uses a Wi-Fi link to access the Internet via SATCOM 656 terminal. 658 End-to-end packet Forward Error Correction (FEC) offers an 659 alternative to retransmission with different trade offs in terms of 660 utilised capacity and repair capability. 662 Network coding as proposed in [I-D.swett-nwcrg-coding-for-quic] and 663 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] could help QUIC recover from 664 link or congestion loss. Another approach could utilise QUIC tunnels 665 [I-D.schinazi-masque] to apply FEC to all or a part of the end-to-end 666 path. 668 The benefits of introducing FEC need to weighed against the 669 additional capacity introduced by end-to-end FEC and the opportunity 670 to use link-local ARQ and/or link-adaptive FEC. A transport 671 connections can suffer link-related losses from a particular link 672 (e.g., Wi-Fi), but also congestion loss (e.g. router buffer overflow 673 in a satellite operator ground segment or along an Internet path). 674 Mechanisms have been proposed in 675 [I-D.ferrieux-hamchaoui-quic-lossbits] , to identify congestion 676 losses in the ground segment. 678 5.3.1. Packet Level Forward Error Correction 680 XXX Packet level FEC can mitigate loss/re-ordering, with a trade-off 681 in capacity. XXX 683 5.4. Flow Control 685 Flow Control mechanisms allow the receiver to control the amount of 686 data a send can have in flight at any time. Flow Control allows the 687 receiver to allocate the smallest buffer sizes possible improving 688 memory usage on receipt. 690 The sizing of initial receive buffers requires a balance between 691 keeping receive memory allocation small while allowing the send 692 window to grow quickly to help ensure high utilization. The size of 693 receive windows and their growth can govern the performance of the 694 protocol if updates are not timely. 696 Many TCP implementations deploy Auto-scaling mechanisms to increase 697 the size of the largest receive window over time. If these increases 698 are not timely then sender traffic can stall while waiting to be 699 notified of an increase in receive window size. XXX QUIC? XXX 701 Multi-streaming Protocols such as QUIC implement Flow Control using 702 credit-based mechanisms that allow the receiver to prioritise which 703 stream is able to send and when. Credit-based systems, when flow 704 credit allocations are not timely, can stall sending when credit is 705 exhausted. 707 5.5. ACK Traffic Reduction 709 When the links are asymmetric, for various reasons, the return path 710 may modify the rate and/timing of transport acknowledgment traffic, 711 potentially changing behaviour (e.g., limiting the forward sending 712 rate). 714 Asymmetry in capacity (or in the way capacity is granted to a flow) 715 can lead to cases where the transmission in one direction of 716 communication is restricted by the transmission of the acknowledgment 717 traffic flowing in the opposite direction. A network segment could 718 present limitations in the volume of acknowledgment traffic (e.g., 719 limited available return path capacity) or in the number of 720 acknowledgment packets (e.g., when a radio-resource management system 721 has to track channel usage), or both. 723 TCP Performance Implications of Network Path Asymmetry [RFC3449] 724 describes a range of mechanisms that have been used to mitigate the 725 impact of path asymmetry, primarily targeting operation of TCP. 727 Many mitigations have been deployed in satellite systems, often as a 728 mechanism within a PEP. Despite their benefits over paths with high 729 asymmetry, most mechanisms rely on being able to inspect and/or 730 modify the transport layer header information of TCP ACK packets. 731 This is not possible when the transport layer information is 732 encrypted (e.g., using an IP VPN). 734 One simple mitigation is for the remote endpoint to send compound 735 acknowledgments less frequently. A rate of one ACK for every RTT/4 736 can significantly reduce this traffic. The QUIC transport 737 specification may evolve to allow the ACK Ratio to be adjusted. 739 5.6. Multi-Path 741 XXX This includes between different satellite systems and between 742 satellite and terrestrial paths XXX 744 6. Protocol Specific Mechanisms 746 6.1. TCP Protocol Mechanisms 748 6.1.1. Transport Initialization 749 6.1.2. Getting Up To Speed 751 One relevant solution is tuning of the initial window described in 752 [I-D.irtf-iccrg-sallantin-initial-spreading][RFC6928], which has been 753 shown to improve performance both for high BDP and more common BDP 754 [CONEXT15] [ICC16]. This requires sender pacing to avoid generating 755 bursts of packets to the network. 757 6.1.3. Size of Windows 759 6.1.4. Reliability 761 6.1.5. ACK Reduction 763 Mechanisms are being proposed in TCPM for TCP [REF]. 765 6.2. QUIC Protocol Mechanisms 767 6.2.1. Transport initialization 769 QUIC has an advantage that the TLS and TCP negotiations can be 770 completed during the transport connection handshake. This can reduce 771 the time to transmit the first data. Moreover, using 0-RTT may 772 further reduce the connection time for users reconnecting to a 773 server. 775 6.2.2. Getting up to Speed 777 Getting up to speed may be easier with the usage of the 0-RTT-BDP 778 extension proposed in [I-D.kuhn-quic-0rtt-bdp]. 780 6.2.3. Size of Windows 782 6.2.4. Reliability 784 Mechanisms have been proposed in 785 [I-D.ferrieux-hamchaoui-quic-lossbits] , to identify congestion 786 losses in the ground segment. 788 6.2.5. Asymmetry 790 The QUIC transport specification may evolve to allow the ACK Ratio to 791 be adjusted. 793 Default could be adapted following [I-D.fairhurst-quic-ack-scaling] 794 or using extensions to tune acknowledgement strategies 795 [I-D.iyengar-quic-delayed-ack]. 797 6.2.6. Packet Level Forward Error Correction 799 Network coding as proposed in [I-D.swett-nwcrg-coding-for-quic] and 800 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] could help QUIC recover from 801 link or congestion loss. 803 Another approach could utilise QUIC tunnels [I-D.schinazi-masque] to 804 apply packet FEC to all or a part of the end-to-end path or enable 805 local retransmissions. 807 6.2.7. Split Congestion Control 809 Splitting the congestion control requires the deployment of 810 application proxies. 812 7. Discussion 814 Many of the issues identified for high BDP paths already exist when 815 using an encrypted transport service over a path that employs 816 encryption at the IP layer. This includes endpoints that utilise 817 IPsec at the network layer, or use VPN technology over a satellite 818 network segment. Users are unable to benefit from enhancement within 819 the satellite network segment, and often the user is unaware of the 820 presence of the satellite link on their path, except through 821 observing the impact it has on the performance they experience. 823 One solution would be to provide PEP functions at the termination of 824 the security association (e.g., in a VPN client). Another solution 825 could be to fall-back to using TCP (possibly with TLS or similar 826 methods being used on the transport payload). A different solution 827 could be to deploy and maintain a bespoke protocol tailored to high 828 BDP environments. In the future, we anticipate that fall-back to TCP 829 will become less desirable, and methods that rely upon bespoke 830 configurations or protocols will be unattractive. In parallel, new 831 methods such as QUIC will become widely deployed. The opportunity 832 therefore exists to ensure that the new generation of protocols offer 833 acceptable performance over high BDP paths without requiring 834 operating tuning or specific updates by users. 836 7.1. Mitigation Summary 838 XXX A Table will be inserted here XXX 840 8. Acknowledgments 842 The authors would like to thank Mark Allman, Daniel R. Glover and 843 Luis A. Sanchez the authors of RFC2488 from which the format and 844 descriptions of satellite systems in this document have taken 845 inspiration. 847 The authors would like to thank Christian Huitema, Igor Lubashev, 848 Alexandre Ferrieux, Francois Michel, Emmanuel Lochin and the 849 participants of the IETF106 side-meeting on QUIC for high BDP for 850 their useful feedback. 852 9. Security Considerations 854 This document does not propose changes to the security functions 855 provided by the QUIC protocol. QUIC uses TLS encryption to protect 856 the transport header and its payload. Security is considered in the 857 "Security Considerations" of cited IETF documents. 859 10. Informative References 861 [CONEXT15] Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running 862 Short Flows Quickly and Safely", ACM CoNEXT , 2015. 864 [FF98] Floyd, S. and K. Fall, "Promoting the Use of End-to-End 865 Congestion Control in the Internet. IEEE Transactions on 866 Networking". 868 [I-D.fairhurst-quic-ack-scaling] 869 Fairhurst, G., Custura, A., and T. Jones, "Changing the 870 Default QUIC ACK Policy", Work in Progress, Internet- 871 Draft, draft-fairhurst-quic-ack-scaling-03, 14 September 872 2020, . 875 [I-D.ferrieux-hamchaoui-quic-lossbits] 876 Ferrieux, A. and I. Hamchaoui, "The QUIC Loss Bits", Work 877 in Progress, Internet-Draft, draft-ferrieux-hamchaoui- 878 quic-lossbits-00, 9 April 2019, . 882 [I-D.ietf-quic-recovery] 883 Iyengar, J. and I. Swett, "QUIC Loss Detection and 884 Congestion Control", Work in Progress, Internet-Draft, 885 draft-ietf-quic-recovery-34, 14 January 2021, 886 . 889 [I-D.ietf-quic-transport] 890 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 891 and Secure Transport", Work in Progress, Internet-Draft, 892 draft-ietf-quic-transport-34, 14 January 2021, 893 . 896 [I-D.irtf-iccrg-sallantin-initial-spreading] 897 Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, 898 E., and A. Beylot, "Safe increase of the TCP's Initial 899 Window Using Initial Spreading", Work in Progress, 900 Internet-Draft, draft-irtf-iccrg-sallantin-initial- 901 spreading-00, 15 January 2014, . 905 [I-D.iyengar-quic-delayed-ack] 906 Iyengar, J. and I. Swett, "Sender Control of 907 Acknowledgement Delays in QUIC", Work in Progress, 908 Internet-Draft, draft-iyengar-quic-delayed-ack-02, 2 909 November 2020, . 912 [I-D.kuhn-quic-0rtt-bdp] 913 Kuhn, N., Emile, S., Fairhurst, G., and T. Jones, 914 "Transport parameters for 0-RTT connections", Work in 915 Progress, Internet-Draft, draft-kuhn-quic-0rtt-bdp-07, 18 916 May 2020, . 919 [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] 920 Roca, V., Michel, F., Swett, I., and M. Montpetit, 921 "Sliding Window Random Linear Code (RLC) Forward Erasure 922 Correction (FEC) Schemes for QUIC", Work in Progress, 923 Internet-Draft, draft-roca-nwcrg-rlc-fec-scheme-for-quic- 924 03, 9 March 2020, . 927 [I-D.schinazi-masque] 928 Schinazi, D., "The MASQUE Protocol", Work in Progress, 929 Internet-Draft, draft-schinazi-masque-02, 8 January 2020, 930 . 933 [I-D.swett-nwcrg-coding-for-quic] 934 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 935 for QUIC", Work in Progress, Internet-Draft, draft-swett- 936 nwcrg-coding-for-quic-04, 9 March 2020, 937 . 940 [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, 941 E., and A-L. Beylot, "Reducing web latency through TCP IW: 942 Be smart", IEEE ICC , 2016. 944 [ICCRG100] Kuhn, N., "MPTCP and BBR performance over Internet 945 satellite paths", IETF ICCRG 100, 2017. 947 [IJSCN17] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 948 and N. Kuhn, "Software-defined satellite cloud RAN", 949 International Journal of Satellite Communications and 950 Networking , 2017. 952 [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google 953 QUIC performance over a public SATCOM access", 954 International Journal of Satellite Communications and 955 Networking , 2019. 957 [Jac88] Jacobson, V., "Congestion Avoidance and Control. In ACM 958 SIGCOMM, 1988". 960 [Mar78] Martin, J., "Communications Satellite Systems. Prentice 961 Hall, 1978.". 963 [Mon98] Montpetit, M.J., "TELEDESIC: Enabling The Global Community 964 Interaccess. In Proc. of the International Wireless 965 Symposium, May 1998". 967 [NCT13] Pirovano, A. and F. Garcia, "A new survey on improving TCP 968 performances over geostationary satellite link", Network 969 and Communication Technologies , 2013. 971 [PANRG105] Kuhn, N., Stephan, E., Border, J., and G. Fairhurst, "QUIC 972 Over In-sequence Paths with Different Characteristics", 973 IRTF PANRG 105, 2019. 975 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 976 Over Satellite Channels using Standard Mechanisms", 977 BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999, 978 . 980 [RFC2760] Allman, M., Ed., Dawkins, S., Glover, D., Griner, J., 981 Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, 982 H., Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP 983 Research Related to Satellites", RFC 2760, 984 DOI 10.17487/RFC2760, February 2000, 985 . 987 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 988 Shelby, "Performance Enhancing Proxies Intended to 989 Mitigate Link-Related Degradations", RFC 3135, 990 DOI 10.17487/RFC3135, June 2001, 991 . 993 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 994 Sooriyabandara, "TCP Performance Implications of Network 995 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 996 December 2002, . 998 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 999 "Increasing TCP's Initial Window", RFC 6928, 1000 DOI 10.17487/RFC6928, April 2013, 1001 . 1003 [Sta94] Stallings, W., "Data and Computer Communications. 1004 MacMillian, 4th edition, 1994.". 1006 [Stu95] Sturza, M.A., "Architecture of the TELEDESIC Satellite 1007 System. In Proceedings of the International Mobile 1008 Satellite Conference, 1995". 1010 Appendix A. Example Network Profiles 1012 This proposes sampler profiles and a set of regression tests to 1013 evaluate transport protocols over SATCOM links and discusses how to 1014 ensure acceptable protocol performance. 1016 XXX These test profiles currently focus on the measuring performance 1017 and testing for regressions in the QUIC protocol. The authors 1018 solicit input to adapt these tests to apply to more transport 1019 protocols. XXX 1021 A.1. LEO 1023 A.2. MEO 1025 A.3. GEO 1027 This section proposes a set of regression tests for QUIC that 1028 consider high BDP scenarios. We define by: 1030 * Download path: from Internet to the client endpoint; 1031 * Upload path: from the client endpoint to a server (e.g., in the 1032 Internet). 1034 A.3.1. Small public satellite broadband access 1036 The tested scenario has the following path characteristics: 1038 * Satellite downlink path: 10 Mbps 1040 * Satellite uplink path: 2 Mbps 1042 * No emulated packet loss 1044 * RTT: 650 ms 1046 * Buffer size : BDP 1048 During the transmission of 100 MB on both download and upload paths, 1049 the test should report the upload and download time of 2 MB, 10 MB 1050 and 100 MB. 1052 Initial thoughts of the performance objectives for QUIC are the 1053 following: 1055 * 3 s for downloading 2 MB 1057 * 10 s for downloading 10 MB 1059 * 85 s for downloading 100 MB 1061 * 10 s for uploading 2 MB 1063 * 50 s for uploading 10 MB 1065 * 420 s for uploading 100 MB 1067 A.3.2. Medium public satellite broadband access 1069 The tested scenario has the following path characteristics: 1071 * Satellite downlink path: 50 Mbps 1073 * Satellite uplink path: 10 Mbps 1075 * No emulated packet loss 1077 * RTT: 650 ms 1078 * Buffer size : BDP 1080 During the transmission of 100 MB on the download path, the test 1081 should report the download time for 2 MB, 10 MB and 100 MB. Then, to 1082 assess the performance of QUIC with the 0-RTT extension and its 1083 variants, after 10 seconds, repeat the transmission of 100 MB on the 1084 download path where the download time for 2 MB, 10 MB and 100 MB is 1085 recorded. 1087 Initial thoughts of the performance objectives for QUIC are the 1088 following: 1090 * 3 s for the first downloading 2 MB 1092 * 5 s for the first downloading 10 MB 1094 * 20 s for the first downloading 100 MB 1096 * TBD s for the second downloading 2 MB 1098 * TBD s for the second downloading 10 MB 1100 * TBD s for the second downloading 100 MB 1102 A.3.3. Congested medium public satellite broadband access 1104 There are cases where the uplink path is congested or where the 1105 capacity of the uplink path is not guaranteed. 1107 The tested scenario has the following path characteristics: 1109 * Satellite downlink path: 50 Mbps 1111 * Satellite uplink path: 0.5 Mbps 1113 * No emulated packet loss 1115 * RTT: 650 ms 1117 * Buffer size : BDP 1119 During the transmission of 100 MB on the download path, the test 1120 should report the download time for 2 MB, 10 MB and 100 MB. 1122 Initial thoughts of the performance objectives for QUIC are the 1123 following: 1125 * 3 s for downloading 2 MB 1126 * 5 s for downloading 10 MB 1128 * 20 s for downloading 100 MB 1130 A.3.4. Variable medium public satellite broadband access 1132 There are cases where the downlink path is congested or where, due to 1133 link layer adaptations to rain fading, the capacity of the downlink 1134 path is variable. 1136 The tested scenario has the following path characteristics: 1138 * Satellite downlink path: 50 Mbps - wait 5s - 10 Mbps 1140 * Satellite uplink path: 10 Mbps 1142 * No emulated packet loss 1144 * RTT: 650 ms 1146 * 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. 1151 Initial thoughts of the performance objectives for QUIC are the 1152 following: 1154 * TBD s for downloading 2 MB 1156 * TBD s for downloading 10 MB 1158 * TBD s for downloading 100 MB 1160 A.3.5. Loss-free large public satellite broadband access 1162 The tested scenario has the following path characteristics: 1164 * Satellite downlink path: 250 Mbps 1166 * Satellite uplink path: 6 Mbps 1168 * No emulated packet loss 1170 * RTT: 650 ms 1172 * 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. Then, to 1175 assess the performance of QUIC with the 0-RTT extension and its 1176 variants, after 10 seconds, repeat the transmission of 100 MB on the 1177 download path where the download time for 2 MB, 10 MB and 100 MB is 1178 recorded. 1180 Initial thoughts of the performance objectives for QUIC are the 1181 following: 1183 * 3 s for the first downloading 2 MB 1185 * 5 s for the first downloading 10 MB 1187 * 8 s for the first downloading 100 MB 1189 * TBD s for the second downloading 2 MB 1191 * TBD s for the second downloading 10 MB 1193 * TBD s for the second downloading 100 MB 1195 A.3.6. Lossy large public satellite broadband access 1197 The tested scenario has the following path characteristics: 1199 * Satellite downlink path: 250 Mbps 1201 * Satellite uplink path: 6 Mbps 1203 * Emulated packet loss on both downlink and uplink paths: 1205 - Uniform random transmission link losses: 1% 1207 * RTT: 650 ms 1209 * Buffer size : BDP 1211 During the transmission of 100 MB on the download path, the test 1212 should report the download time for 2 MB, 10 MB and 100 MB. 1214 Initial thoughts of the performance objectives for QUIC are the 1215 following: 1217 * 3 s for downloading 2 MB (uniform transmission link losses) 1219 * 6 s for downloading 10 MB (uniform transmission link losses) 1220 * 10 s for downloading 100 MB (uniform transmission link losses) 1222 Appendix B. Revision Notes 1224 Note to RFC-Editor: please remove this entire section prior to 1225 publication. 1227 Individual draft -00: 1229 * Comments and corrections are welcome directly to the authors or 1230 via the https://github.com/uoaerg/draft-jones-transport-for- 1231 satellite github repo in the form of pull requests and issues. 1233 Authors' Addresses 1235 Tom Jones 1236 University of Aberdeen 1238 Email: tom@erg.abdn.ac.uk 1240 Godred Fairhurst 1241 University of Aberdeen 1243 Email: gorry@erg.abdn.ac.uk 1245 Nicolas Kuhn 1246 CNES 1248 Email: nicolas.kuhn@cnes.fr 1250 John Border 1251 Hughes Network Systems, LLC 1253 Email: border@hns.com 1255 Emile Stephan 1256 Orange 1258 Email: emile.stephan@orange.com