PEP and SATCOM - Impact of QUIC on solutions with TCP PEP

The protocols deployed in endpoints such as TCP can hardly be relevant to every link available in the Internet, their diversity ranging from "very high speed low latency" for datacenters to "high speed high latency" for satellite systems. As a result, many access systems deploy Performance Enhancing Proxies (PEPs) that isolate different sub-segments of the end-to-end path in order to adapt protocols to the specificities of the links operated. These solutions can be applied at different levels of the protocol stack, and are generally applied at the transport layer in SATellite COMmunication (SATCOM), in particular by adapting the Transmission Control Protocol (TCP).

With a TCP PEP, packet losses are distributed over three sub-segments, and congestion control can be adapted on the satellite link. This can cut web page loading times in half. Deploying QUIC end-to-end calls these adaptations into question. Indeed, with QUIC, functionalities previously divided between Hypertext Transfer Protocol (HTTP) 1/1.1/2, Transport Layer Security (TLS) and TCP evolve towards HTTP3, QUIC and UDP. As UDP is not a connected-mode protocol, it is not possible to slice and dice the end-to-end communication as with TCP.

This article reviews the main characteristics of systems using satellites in geostationary orbit. The implications of these specific features for congestion control are presented, and the main solutions proposed in TCP proxies are described. The challenges that applications using QUIC will face in a satellite communications context are presented. An analysis of the strengths and weaknesses of the QUIC protocol in a satellite communications context is proposed, and avenues for adaptation are discussed. Although applied to systems operating on satellites in geostationary orbit, the analyses presented in this article can be considered for any other application where the deployment of PEP is relevant.