Third party funded individual grant
Start date : 01.12.2022
End date : 01.12.2024
The TCP performance over satellite
communications has become a well-known problem, following significant
experimentation with Internet services over satellite since the '90s.
Several tailored TCP optimisations have been introduced (mainly
implementing changes at the sender side, but also at the receiver side
in some proposals). In parallel, given the challenge of installing
tailored TCP versions directly in the end user system, a set of
architectural extensions have been introduced culminating in the concept
of a Performance Enhancing Proxy (PEP, RFC 3135), whereby a native
end-to-end TCP connection is now commonly split into a series of
multiple connection (a split TCP concept). This allows a tailored TCP to
be deployed on the satellite link (i.e., between the satellite
terminals and gateways to be optimised). Though largely used since the
early 2000's, PEPs have always been unable to enhance non-TCP protocols
or VPN connections traversing the satellite network segment.
Application-layer compression and acceleration was also provided in some
PEPs.
Since 2000, there has been a continued effort to evolve
the protocol stack for Internet web services, with several updates to
the protocols for HTTP-based services. A design of HTTP by Google, known
as SDPY, was standardised as HTTP/2. This provided significant
improvements in download speed of satellite, but at the same time
deployed application-layer encryption and compression – making
application-layer acceleration dependent on using an authenticated proxy
and impossible within a PEP.
A more recent Google proposal
(known as gQUIC) sought a transport other than TCP that uses a UDP
substrate with transport encryption. This effort evolved in
standardisation by the Internet Engineering Task Force (IETF) and was
finally published as IETF QUIC (RFC 9000) in 2021. QUIC is specified for
use with HTTP/3, a replacement for HTTP2/TCP. The main leap from
classical HTTP services over TCP is in that QUIC uses encrypted datagram
connections, with congestion control, flow control, NAT-rebinding and
migration algorithms directly implemented within the QUIC protocol.
Following standardisation, QUIC and HTTP/3 have been implemented and
have been rapidly deployed to the Internet.
Hence, the design
rationale of QUIC intrinsically prevents using a classical PEP solution
for the optimisation of performance over a satellite system. Whilst the
application-layer performance of HTTP/3 resembles or improves on that
of HTTP/2, and the transport design has been shown to operate correctly
over satellite with respect to initialisation, protocol timers, and
other core functions, experiments have shown that performance of QUIC
operated end-to-end over paths comprising a satellite network segment
can be lower than offered by TCP using a PEP. This has motivated the
scientific community and the satellite industry to think of alternative
solutions for QUIC congestion control (CC) to accelerate with the QUIC
performance degradation, which is still now at the early stages. QUIC
has also been suggested for other applications.
The German
Aerospace Center (Deutsches Zentrum für Luft- und Raumfahrt), University
of Aberdeen, and Friedrich-Alexander-Universität Erlangen-Nürnberg have
built a consortium that is committed to thoroughly analyse the existing
approaches and options to improve the performance of TCP over satellite
network segment and apply the most appropriate concepts to QUIC
congestion control mechanisms as well as understanding the implications
of deploying the new approaches as a part of a secure end-to-end
architecture. As a result, a novel algorithm will be defined and then
verified against the relevant technical requirements. Finally, the
resulting new QUIC specifications will be validated using real satellite
trials in exemplar scenarios.