QUIC for SATCOM

The end-to-end performance of an application using an Internet path can be impacted by the Bandwidth-Delay Product (BDP) of the links and network devices forming the path. For instance, the page load time for a complex page can be much larger when the path includes a satellite link. A significant contribution to this reduced performance arises from the initialisation and design of transport mechanisms. QUIC's default congestion control is based on TCP NewReno and the recommended initial window is defined by . Although QUIC's Congestion Control (CC) and recovery have been designed for use across Internet Paths, the initial design could not optimise for the wide diversity of path characteristics that can occur. This document therefore considers the specific implications of paths with a significant BDP. Satellite communications (SATCOM) systems have long been used to support point-to-point links and specialised networks. The predominate current use is as a link-layer for Internet Protocols. Typical example applications include: use as an access technology for remote locations, backup and rapid deployment of new services, transit networks and backhaul of various types of IP networks, and provision to mobile (maritime, aircraft, etc.). In most scenarios, the satellite IP network segment usually only forms one part of the end-to-end path. This means user traffic can experience a path that includes satellite link together with a wide variety of other network technologies (Ethernet, cable modems, WiFi, cellular, radio links, etc). Although a user can sometimes know the presence of the satellite service, a typical user does not deploy special software or applications because they expect a satellite network is being used. Often a user is unaware of the technologies underpinning the links forming the network path. This memo identifies the characteristics of a SATCOM link that impact the operation of the QUIC transport protocol. It proposes regression tests to evaluate QUIC over SATCOM links. It discusses how to ensure acceptable protocol performance.

Satellite communications systems have been deployed using many space orbits, including low earth orbit, medium earth orbits, geosynchronous orbits, elliptical orbits and more. This document focuses on Geosynchronous Earth Orbit (GEO) satellite systems. The characteristics of systems using Geosynchronous Earth Orbit (GEO) satellites differ from paths only using terrestrial links in their path characteristics: A large propagation delay of at least 250ms one-way delay; Employ radio resource management (often using techniques similar to cellular mobile or DOCSIS cable networks, but differing to accommodate the satellite propagation delay); Links can be highly asymmetric (in terms of capacity, one-way delay and in their cost of operation). Many systems use the DVB-S2 specifications, published by the European Telecomunications Standards Institute (ETSI), where the key concept is to ensure both a good usage of the satellite resource and a Quasi Error Free (QEF) link. These systems typically monitor the link quality in real-time, with the help of known symbol sequences, included along with regular packets, which enable an estimation of the current signal-to-noise ratio. This estimation is then feedback allowing the transmitting link to adapt its coding rate and modulation to the actual transmission conditions. It is common to consider the satellite network segment composed of a forward link and a return link. The two links can have different capacities and employ different technologies to carry the IP packets. On the forward link, the satellite gateway often uses all the available bandwidth, possibly with several carriers, to communicate with a set of remote terminals. A carrier is a single Time-Division-Multiplexing channel that multiplexes packets addressed to specific terminals. On the return link, satellite resource is shared among the terminals. Two access methods can be distinguished: on-demand access or contention access. In the former, a terminal receives dedicated transmission resources (usually to send to the gateway). In the latter, some resources are reserved for contention access, where a set of terminals are allowed to compete to obtain transmission resource. Dedicated access, which is more common in currently deployed systems, can be through a Demand Assigned Multiple Access (DAMA) mechanism, while contention access techniques are usually based on Slotted Aloha (SA) and its numerous derivatives. More information on satellite links characteristics can be found in . Beyond that, even for characteristics shared with terrestrial links, the impact on a satellite link could be more and can be amplified by the large path RTT. For example, paths using a satellite system can also exhibit a high loss-rate (e.g., a mobile user or a user behind a Wi-Fi link), where additional delay can impact transport mechanisms. Transport initialization: the 3-way handshake takes a longer time to complete, delaying the time to send data (several transport protocol exchanges may be needed, such as TLS); Size of windows required: to fully exploit the bottleneck capacity, a high BDP requires a larger number of in-flight packets; Reliability: packet loss detection and correction is slow (the performance of end-to-end retransmission is also impacted when using a high RTT path); Getting up to speed: many congestion control methods employ an exponential increase in the sending rate during slow start (for path capacity probing), a high RTT will increase the time to reach a specific rate; Asymmetry : when the links are asymmetric, for various reasons, the the return path may modify the rate and/timing of transport acknowledgment traffic, potentially changing behaviour (e.g., limiting the forward sending rate).

High BDP networks commonly break the TCP end-to-end paradigm to adapt the transport protocol. Splitting a TCP connection allows adaptation for a specific use-case and to address the issues discussed in section . Satellite communications commonly deploy Performance Enhancement Proxy (PEP) for compression, caching and TCP acceleration services . Their deployment can result in significant performance improvement (e.g., a 50% page load time reduction in a SATCOM use-case . and describe the main functions of a SATCOM TCP split solution. For traffic originated at a gateway to an endpoint connected via a satellite terminal, the TCP split proxy intercepts TCP SYN packets, acting on behalf of the endpoint and adapts the sending rate to the SATCOM scenario. The split solution can specifically tune TCP parameters to the satellite link (latency, available capacity). When a proxy is used on each side of the satellite link, the transport protocol can be replace by a protocol other than TCP, optimized for the satellite link. This can be tuned using a priori information about the satellite system and/or by measuring the properties of the network segment that includes the satellite system. Split connections can also recover from packet loss that is local to the part of the connection on which the packet losses occur. This eliminates the need for end-to-end recovery of lost packets. One important advantage of a TCP split solution is that it does not require any end-to-end modification and is independent of both the client and server sides. This comes with a drawback: TCP splitters are often unable to track end-to-end improvements in protocol mechanisms (e.g., RACK, ECN, TCP Fast Open support). Methods configured in the split proxy usually continue to be used until a split solution is finally updated. This can delay/negate the benefit of any end-to-end improvements, contributing to ossification of the transport system.

This section proposes a set of regression tests for QUIC that consider high BDP scenarios. We define by: Download path: from Internet to the client endpoint; Upload path: from the client endpoint to a server (e.g., in the Internet).

The tested scenario has the following path characteristics: Satellite downlink path: 10 Mbps Satellite uplink path: 2 Mbps No emulated packet loss RTT: 650 ms Buffer size : BDP During the transmission of 100 MB on both download and upload paths, the test should report the upload and download time of 2 MB, 10 MB and 100 MB. Initial thoughts of the performance obectives for QUIC are the following: 3 s for downloading 2 MB 10 s for downloading 10 MB 85 s for downloading 100 MB 10 s for uploading 2 MB 50 s for uploading 10 MB 420 s for uploading 100 MB

The tested scenario has the following path characteristics: Satellite downlink path: 50 Mbps Satellite uplink path: 10 Mbps No emulated packet loss RTT: 650 ms Buffer size : BDP During the transmission of 100 MB on the download path, the test should report the download time for 2 MB, 10 MB and 100 MB. Then, to assess the performance of QUIC with the 0-RTT extension and its variants, after 10 seconds, repeat the transmission of 100 MB on the download path where the download time for 2 MB, 10 MB and 100 MB is recorded. Initial thoughts of the performance objectives for QUIC are the following: 3 s for the first downloading 2 MB 5 s for the first downloading 10 MB 20 s for the first downloading 100 MB TBD s for the second downloading 2 MB TBD s for the second downloading 10 MB TBD s for the second downloading 100 MB

There are cases where the uplink path is congested or where the capacity of the uplink path is not guaranteed. The tested scenario has the following path characteristics: Satellite downlink path: 50 Mbps Satellite uplink path: 0.5 Mbps No emulated packet loss RTT: 650 ms Buffer size : BDP During the transmission of 100 MB on the download path, the test should report the download time for 2 MB, 10 MB and 100 MB. Initial thoughts of the performance objectives for QUIC are the following: 3 s for downloading 2 MB 5 s for downloading 10 MB 20 s for downloading 100 MB

There are cases where the downlink path is congested or where, due to link layer adaptations to rain fading, the capacity of the downlink path is variable. The tested scenario has the following path characteristics: Satellite downlink path: 50 Mbps - wait 5s - 10 Mbps Satellite uplink path: 10 Mbps No emulated packet loss RTT: 650 ms Buffer size : BDP During the transmission of 100 MB on the download path, the test should report the download time for 2 MB, 10 MB and 100 MB. Initial thoughts of the performance objectives for QUIC are the following: TBD s for downloading 2 MB TBD s for downloading 10 MB TBD s for downloading 100 MB

The tested scenario has the following path characteristics: Satellite downlink path: 250 Mbps Satellite uplink path: 3 Mbps No emulated packet loss RTT: 650 ms Buffer size : BDP During the transmission of 100 MB on the download path, the test should report the download time for 2 MB, 10 MB and 100 MB. Then, to assess the performance of QUIC with the 0-RTT extension and its variants, after 10 seconds, repeat the transmission of 100 MB on the download path where the download time for 2 MB, 10 MB and 100 MB is recorded. Initial thoughts of the performance objectives for QUIC are the following: 3 s for the first downloading 2 MB 5 s for the first downloading 10 MB 8 s for the first downloading 100 MB TBD s for the second downloading 2 MB TBD s for the second downloading 10 MB TBD s for the second downloading 100 MB

The tested scenario has the following path characteristics: Satellite downlink path: 250 Mbps Satellite uplink path: 3 Mbps Emulated packet loss on both downlink and uplink paths: Uniform random transmission link losses: 1% RTT: 650 ms Buffer size : BDP During the transmission of 100 MB on the download path, the test should report the download time for 2 MB, 10 MB and 100 MB. Initial thoughts of the performance objectives for QUIC are the following: 3 s for downloading 2 MB (uniform transmission link losses) 6 s for downloading 10 MB (uniform transmission link losses) 10 s for downloading 100 MB (uniform transmission link losses)

QUIC has an advantage that the TLS and TCP negotiations can be completed during the transport connection handshake. This can reduce the time to transmit the first data. Results of illustrate that it can still take many RTTs for a CC to increase the sending rate to fill the bottleneck capacity. The delay in getting up to speed can dominate performance for a path with a large RTT, and requires the congestion and flow controls to accommodate the impact of path delay. One relevant solution is tuning of the initial window described in , which has been shown to improve performance both for high BDP and more common BDP . Such a solution requires using sender pacing to avoid generating bursts of packets in a network.

The number of in-flight packets required to fill a bottleneck capacity, is dependent on the BDP. Default values of maximum windows may not be suitable for a SATCOM context. Such as presented in , only increasing the initial congestion window is not the only way that can improve QUIC performance in a SATCOM context: increasing maximum congestion windows can also result in much better performance. Other protocol mechanisms also need to be considered, such as flow control at the stream level in QUIC.

Packet loss detection and loss repair will consume additional time on paths with a larger RTT. The RTT also determines the time needed by a server to react to a congestion event. Both can impact the user experience. For example, when a user uses a Wi-Fi link to access the Internet via SATCOM terminal. End-to-end packet Forward Error Correction offers an alternative to retransmission with different tradeoffs in terms of utilised capacity and repair capability. Network coding as proposed in and could help QUIC recover from link or congestion loss. Another approach could utilise QUIC tunnels to apply FEC to all or a part of the end-to-end path. The benefits of introducing FEC need to weighed against the additional capacity introduced by end-to-end FEC and the opportunity to use link-local ARQ and/or link-adaptive FEC. A transport connections can suffer link-related losses from a particular link (e.g., Wi-Fi), but also congestion loss (e.g. router buffer overflow in a satellite operator ground segment or along an Internet path). Mechanisms have been proposed in , to identify congestion losses in the ground segment.

Asymmetry in capacity (or in the way capacity is granted to a flow) can lead to cases where the transmission in one direction of communication is restricted by the transmission of the acknowledgment traffic flowing in the opposite direction. A network segment could present limitations in the volume of acknowledgment traffic (e.g., limited available return path capacity) or in the number of acknowledgment packets (e.g., when a radio-resource management system has to track channel usage), or both. TCP Performance Implications of Network Path Asymmetry describes a range of mechanisms that have been used to mitigate the impact of path asymmetry, primarily targeting operation of TCP. Many mitigations have been deployed in satellite systems, often as a mechanism within a PEP. Despite their benefits over paths with high asymmetry, most mechanisms rely on being able to inspect and/or modify the transport layer header information of TCP ACK packets. This is not possible when the transport layer information is encrypted (e.g., using an IP VPN). One simple mitigation is for the remote endpoint to send compound acknowledgments less frequently. A rate of one ACK every RTT/4 can significantly reduce this traffic. The QUIC transport specification may evolve to allow the ACK Ratio to be adjusted.

Many of the issues identified for high BDP paths already exist when using an encrypted transport service over a path that employs encryption at the IP layer. This includes endpoints that utilise IPsec at the network layer, or use VPN technology over a satellite network segment. These uses are unable to benefit from enhancement within the satellite network segment, and often the user is unaware of the presence of the satellite link on their path, except through observing the impact it has on the performance they experience. One solution would be to provide PEP functions at the termination of the security association (e.g., in a VPN client). Another solution could be to fall-back to using TCP (possibly with TLS or similar methods being used on the transport payload). A different solution could be to deploy and maintain a bespoke protocol tailored to high BDP environments. In the future, we anticipate that fall-back to TCP will become less desirable, and methods that rely upon bespoke configurations or protocols will be unattractive. In parallel, new methods such as QUIC will become widely deployed. The opportunity therefore exists to ensure that the new generation of protocols offer acceptable performance over high BDP paths without requiring operating tuning or specific updates by users.

The authors would like to thank Christian Huitema, Igor Lubashev, Alexandre Ferrieux, Francois Michel, Emmanuel Lochin and the participants of the IETF106 side-meeting on QUIC for high BDP for their useful feedbacks.

This document does not propose changes to the security functions provided by the QUIC protocol. QUIC uses TLS encryption to protect the transport header and its payload. Security is considered in the "Security Considerations" of cited IETF documents.