Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Core QUIC: Enabling Dynamic, Implementation-Agnostic Protocol Extensions

Quentin De Coninck

TL;DR

Core QUIC tackles the inertia of protocol evolution by enabling dynamic, implementation-agnostic extensions to compliant QUIC implementations through a common, bytecode-based plugin framework. It defines a safe, WebAssembly-based runtime and a standardized representation for QUIC structures that allows interoperable extensions without binary changes to host stacks. The authors demonstrate feasibility by making two QUIC implementations (quiche and quinn) Core QUIC-compliant and by developing several use-case plugins (e.g., frame logging, privacy padding, path probing, BDP optimization) that work across both stacks. Micro-benchmarks show modest per-call overhead and startup costs, supporting practical deployment of multiple orthogonal extensions. Overall, the work suggests Core QUIC can significantly accelerate interoperable transport-layer innovation while mitigating deployment barriers.

Abstract

While applications quickly evolve, Internet protocols do not follow the same pace. There are two root causes for this. First, extending protocol with cleartext control plane is usually hindered by various network devices such as middleboxes. Second, such extensions usually require support from all participating entities, but often these run different implementations, leading to the chicken-and-egg deployment issue. The recently standardized QUIC protocol paved the way for dealing with the first concern by embedding encryption by design. However, it attracted so much interest that there is now a large heterogeneity in QUIC implementations, hence amplifying the second problem. To get rid of these deployment issues and to enable inter-operable, implementation-independent innovation at transport layer, we propose a paradigm shift called Core QUIC. While Core QUIC keeps compliant with the standardized QUIC protocol, it enforces implementation architecture such that any Core QUIC-supporting participant can be extended with the same, generic bytecode. To achieve this, Core QUIC defines a standardized representation format of common QUIC structures on which plugins running in a controlled environment can operate to extend the underlying host implementation. We demonstrate the feasibility of our approach by making two implementations Core QUIC-compliant. Then, we show that we can extend both with the same plugin code over several use cases.

Core QUIC: Enabling Dynamic, Implementation-Agnostic Protocol Extensions

TL;DR

Core QUIC tackles the inertia of protocol evolution by enabling dynamic, implementation-agnostic extensions to compliant QUIC implementations through a common, bytecode-based plugin framework. It defines a safe, WebAssembly-based runtime and a standardized representation for QUIC structures that allows interoperable extensions without binary changes to host stacks. The authors demonstrate feasibility by making two QUIC implementations (quiche and quinn) Core QUIC-compliant and by developing several use-case plugins (e.g., frame logging, privacy padding, path probing, BDP optimization) that work across both stacks. Micro-benchmarks show modest per-call overhead and startup costs, supporting practical deployment of multiple orthogonal extensions. Overall, the work suggests Core QUIC can significantly accelerate interoperable transport-layer innovation while mitigating deployment barriers.

Abstract

While applications quickly evolve, Internet protocols do not follow the same pace. There are two root causes for this. First, extending protocol with cleartext control plane is usually hindered by various network devices such as middleboxes. Second, such extensions usually require support from all participating entities, but often these run different implementations, leading to the chicken-and-egg deployment issue. The recently standardized QUIC protocol paved the way for dealing with the first concern by embedding encryption by design. However, it attracted so much interest that there is now a large heterogeneity in QUIC implementations, hence amplifying the second problem. To get rid of these deployment issues and to enable inter-operable, implementation-independent innovation at transport layer, we propose a paradigm shift called Core QUIC. While Core QUIC keeps compliant with the standardized QUIC protocol, it enforces implementation architecture such that any Core QUIC-supporting participant can be extended with the same, generic bytecode. To achieve this, Core QUIC defines a standardized representation format of common QUIC structures on which plugins running in a controlled environment can operate to extend the underlying host implementation. We demonstrate the feasibility of our approach by making two implementations Core QUIC-compliant. Then, we show that we can extend both with the same plugin code over several use cases.
Paper Structure (18 sections, 6 figures, 4 tables, 1 algorithm)

This paper contains 18 sections, 6 figures, 4 tables, 1 algorithm.

Table of Contents

  1. Introduction
  2. Background on QUIC
  3. Designing Core QUIC
  4. Defining Protocol Routines
  5. Specifying a Common Representation
  6. Running Plugins
  7. Making Implementations Core QUIC-Compliant
  8. Implementation
  9. Integration into QUIC Implementations
  10. Micro-benchmarks
  11. Exploring Use Cases
  12. Frame Logging
  13. QUIC-based Privacy Solution
  14. Application-controlled Network Probing
  15. Optimizing QUIC in Large RTT Scenarios
  16. ...and 3 more sections

Figures (6)

  • Figure 1: Architectural view of the different components of pluginop. Plain arrows mean "uses", dashed arrows mean "interacts".
  • Figure 2: The architecture of pluginop. Black arrows mean "contains".
  • Figure 3: Time distribution of client's packets of a 500 KB download.
  • Figure 4: Size distribution of server's packets of a 500 KB download.
  • Figure 5: The BDP frame plugin enables the server to directly operate to a suitable operating state.
  • ...and 1 more figures