Matthias Hofstätter

Es wurden leider keine Publikationen gefunden.

• QUICOPTSAT

  (Drittmittelfinanzierte Einzelförderung)

  Laufzeit: 2022-12-01 - 2024-12-01
  Mittelgeber: andere Förderorganisation
  Abstract

  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.

  →Mehr Informationen