QUICoS

Status

Completed
Status date

2025-07-14
Activity Code

6B.084

Objectives

The goal of the QUICoS project is to study, define, implement, and evaluate, in a satellite-based network testbed, possible enhancements in congestion control, flow control and retransmission mechanisms to be included within the UDP-based QUIC protocol, which is the basement of HTTP/3. These enhancements are driven by the most recent versions of TCP which have demonstrated good performance on satellite networks (TCP Cubic, TCP BBR, TCP Wave). In this way, an innovative and IETF compliant realisation of the QUIC protocol can be defined, able to obtain good performance on both satellite, and terrestrial networks.

Challenges

Future Internet applications will use, more and more, end-to-end encryption and a connection-less UDP transport, which are key elements of the QUIC protocol. For this type of traffic, existing satellite accelerators (PEP) and other components along the data path (i.e., middleboxes, adaptive queues, etc.) cannot work properly. Furthermore, the QUIC IETF standardisation is not explicitly considering possible shortcomings and inefficiencies when satellite-based links are used (especially GEO). Finally, several TCP-based optimisations (available also at the lower level of several operating systems) are lost when using current QUIC implementations and shall be redesigned.

Benefits

A tailored-designed QUIC protocol can enable efficient PEP-less applications over satellite networks, considering different orbits, possible delay and bandwidth variability, losses, handovers, hybrid wired and wireless networks and complex routing/queuing functions. The optimised QUIC end-to-end Congestion Control, outcome of this activity, is specifically designed, validated and tested to offer adequate performance and tackle possible issues and challenges identified, leveraging know-how of TCP and consolidated Internet protocols. In particular, GEO/MEO/LEO satellite environments are considered, without jeopardising the performance of legacy applications and protocols. The reference applications that take advantage from the proposed QUIC protocol stack span from general Web browsing to streaming and long data transfers.

Features

The QUIC protocol defined during this project will be implemented in simulation and real systems, considering common Web browsers and Web servers and different Operating Systems. The key requirements driving its design concern the necessity to operate in very different environments, from narrowband to broadband with variable and potentially high round trip times; suitability to perform efficiently both short, and long data transfers; compensate the incompatibility of PEP by enabling optimisations at the ends; be compatible with adaptive queuing, middleboxes, ECN routers, while respecting the necessary coexistence with previous solutions (friendliness), in particular TCP/HTTP/2.

System Architecture

The resulting design of the QUIC protocol, network nodes and endpoints (clients and servers), are included into a real-time Linux-based network testbed, which will extensively leverage virtualisation, orchestration and monitoring technologies, by a proper integration and adaptation of existing Open-Source multi-platform solutions. A preliminary high-level architecture of the testbed, which represents the main deliverable of the project, is reported in the following figure.

Some of the Virtual Machines deployed within the testbed contain real and emulated clients and servers, deployed in different containers and running in different Operating Systems, on top of which the developed QUIC congestion control can be enabled using real services and Web Browsers (i.e., Chrome). Furthermore, a realistic model of the transport network including complex network elements (e.g., CoDel buffers) and SatCom emulation is considered (e.g. OpenSand), including handovers, between clients and servers. Finally, configuration, execution and tracing of experiments for the testbed, KPI extraction and real-time monitoring capabilities (Management and Orchestration) are performed via OpenBach.

Plan

The project duration is 24 months, and three main milestones are foreseen: