Description
Satellite communication links have specific characteristics that undermine the performance of commonly used Internet protocols, notably TCP, in part because performance over satellite was not a major consideration during the development of those protocols. Specifically, the long propagation delay imposed by GEO satellite links and their asymmetric nature lead to poor TCP performance. Unless addressed, this can result in a poor user experience, and significant under-utilization, contributing additional latency during the time that it takes TCP to ramp up to the available capacity (especially a concern as access speeds increase).Performance Enhancing Proxies (PEPs) are a solution developed to mitigate these performance limitations, utilising a range of quite different technologies. One widely used method splits the TCP protocol connection, allowing the endpoints to increase the sending rate beyond the limits that their own mechanisms would impose. This isolates the satellite service by installing proxies that terminate TCP connections withthe endpoints at one or both sides of the satellite service. Proxies allow an application flow to increase its sending rate, thanksto a reduced Round Trip Time (RTT) between the endpoint and the proxy, and an understanding of the capacity available for the satellite service (either configured or measured). This allows the application to ramp-up faster and take less time to utilise the available capacity of a satellite link. PEPs can also implement higher-level application functions that benefit web traffic and can improve interaction with the radio/resource management functions, e.g. pre-fetch/proxy and Domain Name System (DNS) interception.With a growing desire to preserve the privacy of Internet communications, there has been a notable increase in the proportion of encrypted traffic sent over the Internet, and this will soon become a significant proportion of all web traffic. Initially, there was a major surge in the use of Transport Layer Security (TLS) with https, and whilst this introduced complexity into proxy functions, it does not have a major impact on PEPs that operate at the TCP layer, because there PEPs were still able to modify the TCP protocol headers.While PEP solutions have thus enjoyed success in many deployed systems, the solutions they provide are now being challenged. A newgeneration of secure protocols is now emerging that integrate security into a User Datagram Protocol, UDP, transport layer. The major exponent of such technologies is QUIC, a protocol originally proposed by Google LLC, but that has since become an Internet Engineering Task Force (IETF) work item, expected to result in interoperable specifications. QUIC adoption was originally dominated by Google services, but the publication of an IETF standard specification can be expected to be followed by deployment of more QUIC clients and server platforms - expected to result in a rapid rise of encrypted traffic. QUIC transport fully encrypts all transport protocol headers, rendering these information elements invisible to middleboxes in the network (such as PEPs, traffic classifiers, and other devices used to support network operations). Moreover, QUIC authenticates the endpoints of a connection, making it impossible fora PEP to terminate the PEP connection without explicitly being configured as a proxy for the content origin.The first IETF standard version of QUIC (currently named QUICv1.0) is expected to be finalised early in 2019. To meet this deadline, work for QUICv1.0 has been focussed upon topics such as connection setup, encryption services, and interface to the upper-layer web protocols. However, the QUIC standards process does not conclude in early 2019; rather it will then move to address topics that could not be completed in time for this release date. Specifically, introducing multipath and forward error correction extensions to the QUIC standard is one of the key goals of the IETF working group. Satellite-optimised specifications of such extensions will be crucial to the performance of satellite systems in future integrated terrestrial-satellite 5G architectures. The opportunity to influence the design of the interaction between QUIC and the network path it uses will largely appear in the following 18-24 months as topics are prioritised for QUIC v2.0 and new techniques are proposed, analysed and incorporated into the specification. QUIC has been designed to accelerate transfers across normal Internet paths. Like HTTP2, it promises mechanisms that are also expected to help mitigate the effect a satellite propagation delay - such as reducing the number of RTTs to complete a web transfer, multi-streaming to reduce head of line blocking, more rapid access to new capacity and the ability to compress information (remove redundancy). Indeed, some of the core transport mechanisms being proposed for QUIC are also a central feature in many satellite PEP systems. Because key mechanisms are stillto be standardised in IETF QUIC, the real interactions using a satellite service are, as yet, unknown. There are therefore open questions about the expected performance of QUIC over satellite. The proposed activity therefore comprises three distinct tasks:Task 1: Evaluation of QUICv1.0 performance over satellite linksThe goal of this task is to assess the performance of the QUIC protocol over paths including satellite links via the use of analytical models, simulations and measurements. The assessment will include different scenarios involving a range of technologies (e.g. different types of PEPs, symmetrical and asymmetrical paths) relevant for the analysis. The running Future Preparation work plan activity "Mitigation Techniques for Addressing the Impact of Latency on Services over Satellite Networks" (1B.118) has already selected QUIC as one of the test cases that will be investigated as part of its emulation campaign to be conducted in the first half of 2019. The work of this task will therefore be closely coordinated with this running activity and implemented in the most efficient manner (e.g. possibly via CCN to activity 1B.118 to cover any additional simulations or measurements not currently incorporated, or stand-alone support tasks to cover expertise outside of the current consortia). This work is timed to coincide with the finalisation of the QUICv1.0 specification, and its final publication mid-2019.Task 2: Definition of proposed features for QUICv2 for satelliteUnder this task, based on the analysis performed in Task 1, the contractor willseek to identify and define mechanisms to improve the performance of QUIC when used in paths that include a satellite link. The modifications can include adaptations to the QUIC protocol itself (as proposed features for QUICv2), introduction of multipath operation to exploit both terrestrial and satellite paths, integration of link layer forward error correction and/or network coding to improve link resilience in satellite mobile channels, design recommendations for middleboxes for satellite networks, and the cases where the use of alternative protocols is needed (i.e., fall back to TCP).Task 3: Standardization and RecommendationsThis task will runin parallel with Tasks 1 and 2 and will focus on supporting the standardisation of the identified QUICv2 mechanisms through the IETF, possibly by including features on the roadmap for QUICv2. In addition, the work will include efforts to raise awareness within the satellite community of the potential for QUIC, and the implications for future satellite-based internet traffic.In summary, there is short-term potential to influence the on-going development of standards for QUIC, specifically the features to be added to the QUICv2.0 roadmap. In addition the activity can provide input to the satellite community to help them address the future development of PEP functions in satellite equipment. As a increasing proportion