Skip to content

Related Activities

Jump to bottom
黄融 edited this page Jun 2, 2022 · 36 revisions

QUIC-Related IETF Activities and Proposals

This page collects information about the various QUIC-related proposals and activities happening or proposed for the wider IETF space. Please add to this list and update the various items as needed. Feel free to use the given template:

### Short Activity/Proposal Title
A sentence or three on what this is about and how it relates to the chartered QUIC work in the IETF.
* **Main contact:** Names and email addresses of a small number of main contacts.
* **Forum:** Mailing list, Slack channel, etc. for interested parties to learn more and join the effort.
* **Materials:** GitHub repo, I-Ds, papers, etc. Links to relevant material.

Active Proposals

Below is a (not necessarily complete) list of things the chairs are aware of at the moment. Whoever feels in charge for one of the items below should feel free to create an entry (using the template) in this section, and then remove the bullet item from the list:

quic-network-simulator

The QUIC Network Simulator is a ns-3-based network simulator that allows performance measurements of QUIC implementations under various network conditions. The docker-based setup can be used to run different implementations on the client and the server side. An important use case is running QUIC and TCP traffic across the same link.

qlog logging format and associated tooling and visualizations

qlog is a proposal for a flexible, interoperable endpoint logging format/schema spanning multiple modern protocols and networking use cases, as well as its associated tooling. The idea is that all QUIC and HTTP/3 implementations output logs in the same JSON-based format, making it easier to write reusable (browser-based) tools. The format is evolving rapidly and we welcome feedback and implementation experience. Currently supported by over 70% of all QUIC stacks and on track to be adopted by the QUIC wg in 2021.

Loss Bits

Packet loss detection and localization is critical to operating networks. Using two loss bits, preferably in QUIC header, allows passive observers to identify, measure, and localize loss as upstream or downstream of the observer. The proposal is supported by a real world implementation with data derived from actual end-user connections in a number of countries.

0rtt-bdp

This memo discusses a solution where the client is informed about path parameters: both the client and the server can contribute to the reduction of the time-to-service for subsequent connections. The information can not be seen within the network and is only known at the client and server levels.

satellite / etosat

This memo identifies the characteristics of a SATCOM link that impact the operation of the QUIC transport protocol and proposes best current practice to ensure acceptable protocol performance.

Multipath

Multipath is an extension enabling QUIC to make use of several network paths concurrently over a single connection. The two main use-cases are bandwidth aggregation and network resiliency.

Pluginized QUIC

Pluginized QUIC is a framework that enables QUIC clients and servers to dynamically exchange protocol plugins that extend the protocol on a per-connection basis.

Performance Enhancement on Mobile networks

QUIC as a substrate draft (https://datatracker.ietf.org/doc/draft-kuehlewind-quic-substrate/) describes potential use cases where a QUIC proxy is expected in the path between client and server. One of the endpoint (likely the client) is expected to be directly connected to the QUIC proxy. This allows endpoints to make explicit decisions about the services they request from the proxies. For example - the access network ( e.g. mobile networks) have often different characteristics than rest of path on the Internet. In order to use the mobile network capacity efficiently, congestion control would need to be optimized differently. A QUIC proxy solution, similar as also proposed for MASQUE, could either assist the endpoint with additional information about the mobile link or enable different congestion control on an outer QUIC connection between that covers the mobile link only.

Other Proposals

Please create more detailed sections for these above.

  • media
  • auth handshake
  • multicast
  • FEC
  • delay and loss bits (draft-cfb-tsvwg-spinbit-new-measurements)

Historic Proposals

QUIC-LB

This was adopted by the QUIC WG; see https://github.com/quicwg/load-balancers. The following text is left as a historical reference.

Servers generate their Connection IDs, but numerous trusted devices it the path (load balancers, DDOS boxes, crypto offload, local switch disaggregators) need access to some of the encoded data in those CIDs, while that same data is opaque to untrusted observers. QUIC-LB defines multiple encoding strategies to allow this cooperation between servers and trusted intermediaries.

Datagram Frames

This was adopted by the QUIC WG; see https://github.com/quicwg/datagram. The following text is left as a historical reference.

Some applications, particularly those that need to transmit real-time data, prefer to transmit data unreliably. These applications can build directly upon UDP as a transport, and can add security with DTLS. Extending QUIC to support transmitting unreliable application data would provide another option for secure datagrams, with the added benefit of sharing a cryptographic and authentication context used for reliable streams.

This proposal defines DATAGRAM QUIC frame types, which carry application data without requiring retransmissions.

MASQUE

This has progressed as a separate piece of work in the IETF; see https://datatracker.ietf.org/wg/masque/about/. The following text is left as a historical reference.

MASQUE is a mechanism that allows co-locating and obfuscating networking applications behind an HTTPS web server. The currently prevalent use-case is to allow running a proxy or VPN server that is indistinguishable from an HTTPS server to any unauthenticated observer. The proxy will be aware of QUIC and will be able to proxy QUIC by having the client and proxy collaborate.

WebTransport

This has progressed as a separate piece of work in the IETF; see https://datatracker.ietf.org/wg/webtrans/about/. The following text is left as a historical reference.

WebTransport is a framework for bidirectional communications between web applications and servers. It provides, among other things, QuicTransport, an API that allows webapps to create a direct QUIC connection to a valid remote server.

Top pages

Clone this wiki locally