QUIC for SATCOM
draft-kuhn-quic-4-sat-00

Abstract

QUIC's congestion control is not designed for operating over an Internet path with a high BDP. This limits the user experience. Moreover, a path can combine satellites network segment together with a wide variety of other network technologies (Ethernet, cable modems, WiFi, cellular, radio links, etc): this complicates the characteristics of the end-to-end path. If this is not addressed, the end-to-end quality of experience will be degraded.

This memo identifies the characteristics of a SATCOM link that impact the operation of the QUIC transport protocol and proposes best current practice to ensure acceptable protocol performance.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 4, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Operating over a path with a large BDP
• 3. TCP Split Solution
• 4. Mechanisms that improve the performance of QUIC for SATCOM
• 4.1. Getting up to speed
• 4.2. Reliability
• 4.3. Maximum window
• 4.4. ACK ratio
• 5. Discussion
• 6. Acknowledgements
• 7. Contributors
• 8. IANA Considerations
• 9. Security Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

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 congestion control is based on TCP NewReno [I-D.ietf-quic-recovery] and the recommended initial window is defined by [RFC6928].

Moreover, 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.). The satellite IP network segment usually only forms one part of the end-to-end path. This means user traffic can experince 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 and proposes best current practice to ensure acceptable protocol performance.

2. Operating over a path with a large BDP

GEO-satellite based systems characteristics differ from paths only using terrestrial links in their path characteristics:

• A large propagation delay of at least 250ms one-way delay;
• Some systems can exhibit a high loss-rate (e.g. mobile users or users behind a Wi-Fi link);
• 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 and one-way delay).

More information on satellite links characteristics can be found in [RFC2488].

These characteristics have an impact on the performance of end-to-end congestion controls:

• Transport initialization: the 3-way handshake takes a long time to complete, reducing the time at which actual data can be transmitted;
• Size of windows required: to fully exploit the bottleneck capacity, the high BDP may induce an important number of in-flights 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: the exponential increase of the data rate during slow start for a channel capacity probing is slowed down when the RTT is high.

3. TCP Split Solution

High BDP networks commonly break the TCP end-to-end paradigm to adapt the transport protocol. Splitting TCP allows adaptations to this specific use-case and assessing the issues discussed in section Section 2. Satellite communications commonly deploy Performance Enhancement Proxy (PEP) for compression, caching and TCP acceleration services [RFC3135]. Their deployment can result in 50% page load time reduction in a SATCOM use-case [ICCRG100].

[NCT13] and [RFC3135] describe the main functions of SATCOM TCP split solutions. Shortly, for traffic originated at a gateway to an endpoint connected via a satellite terminal, the TCP split intercepts TCP SYN packets to act on behalf of the endpoint and adapt the data rate transmission to the SATCOM scenario. The split solution specifically tunes the TCP parameters to the context (latency, available capacity). The tuning can be achieved using a priori information about the satellite system and/or by measuring the properties of the network segment that includes the satellite system.

One important advantage of a TCP split solution is that it does not require any end-to-end modifications and is independent for both client and server sides. That being said, this comes with a drawback: TCP splitters often are unable to track the most recent end-to-end improvements (e.g. ECN or TCP Fast Open support). The 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.

4. Mechanisms that improve the performance of QUIC for SATCOM

4.1. Getting up to speed

3-way handshake takes a long time reducing the time at which actual data can be transmitted.

The tuning of the initial window described in [I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to improve performance both for high BDP and more common BDP [CONEXT15][ICC16].

4.2. Reliability

Packet losses detection and correction is slow and the time needed for the end server to react to a congestion event may not be relevant. This happens when a user uses a Wi-Fi link to access a SATCOM terminal. Although the benefits needed to weighed against the additional capacity in introducing end-to-end FEC and the potential to use link-local ARQ and/or link-adaptive FEC.

Introducing network coding in QUIC could help in recovering from the residual Wi-Fi losses.

4.3. Maximum window

To fully exploit the bottleneck capacity, the high BDP may induce an important number of in-flights packets.

4.4. ACK ratio

Asymmetry in capacity (or in the way capacity is granted to a flow) can lead to cases where the throughput in one direction of communication is restricted by the acknowledgement traffic flowing in the opposite direction. The limitations of specific underlying networks could be in terms of the volume of acknowledgement traffic (limited return path capacity) or in the number of acknowledgement packets (e.g., when a radio-resource management system has to track channel usage) or both.

TCP Performance Implications of Network Path Asymmetry [RFC3449] describes a range of mechanisms that can mitigate the impact of path asymmetry. One simple method is to tell the remote endpoint to send compound acknowledgments less frequently. A rate of one ACK every RTT/4 can significantly reduce this traffic.

Many of these mitigations have been deployed in satellite systems, often as a mechanism within a PEP. Despite their benefits over paths with a high asymmetry of capacity, 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. The QUIC transport specification may evolve to allow the ACK Ratio to be adjusted.

5. Discussion

Many of the issues identified already exist for any encrypted transport service that uses a path that employs encryption at the IP layer. This includes endpoints that utilise IPsec at the network layer, or use VPN technology over the 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.

6. Acknowledgements

None.

7. Contributors

None.

8. IANA Considerations

TBD: text is required to register the extension BDP_data field.

9. Security Considerations

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.

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses