-
Notifications
You must be signed in to change notification settings - Fork 205
Related Activities
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.
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:
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.
-
Main contacts:
- Marten Seemann [email protected]
- Jana Iyengar [email protected]
- Forum: #quic-network-sim in the QUIC slack, Github issues on the repo (see below)
- Materials: https://github.com/marten-seemann/quic-network-simulator/
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.
- Main contact: Robin Marx, [email protected]
- Forum: [email protected], #qlog in the QUIC slack, github issues on the repo (see below)
- Materials:
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.
-
Main contacts:
- Lubashev, Igor [email protected]
- Alexandre Ferrieux [email protected]
- Isabelle Hamchaoui [email protected]
-
Forum:
- github issues on the repo (see below)
- [email protected] (ietf-loss-bits Google Group)
-
Materials:
- GitHub: https://github.com/igorlord/draft-ferrieuxhamchaoui-tsvwg-lossbits
- I-D: https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits
- Slides: TBD (ETA: Friday)
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.
-
Main contact:
- Nicolas Kuhn ([email protected])
- Emile Stephan ([email protected])
- Gorry Fairhurst ([email protected])
- Forum: QUIC mailing list or GitHub issues on the repo
- Materials:
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.
-
Main contact:
- Nicolas Kuhn ([email protected])
- Gorry Fairhurst ([email protected])
- John Border ([email protected])
- Emile Stephan ([email protected])
- Forum: QUIC mailing list or GitHub issues on the repo
- Materials:
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.
-
Main contact:
- Quentin De Coninck [email protected]
- Olivier Bonaventure [email protected]
- Forum: TBD
- Materials:
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.
-
Main contact:
- Quentin De Coninck [email protected]
- François Michel [email protected]
- Maxime Piraux [email protected]
- Olivier Bonaventure [email protected]
- Forum: TBD
- Materials:
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.
-
Main contact:
- Marcus Ihlar [email protected]
- Mirja Kuehlewind [email protected]
- Zaheduzzaman Sarker [email protected]
- Forum: [email protected], or [email protected] for discussion regarding performance enhancements for challenging links
- Materials:
Please create more detailed sections for these above.
- media
- auth handshake
- multicast
- FEC
- delay and loss bits (draft-cfb-tsvwg-spinbit-new-measurements)
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.
-
Main contacts:
- Martin Duke, [email protected]
- Nick Banks, [email protected]
- Forum: There is a Google group. Email Martin to join.
- Materials:
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.
- Main contact: Tommy Pauly, [email protected]
- Forum: #datagram channel in QUIC slack, or QUIC email list.
- Materials:
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.
- Main contact: David Schinazi [email protected]
- Forum: MASQUE IETF mailing list [email protected]
- Materials:
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.
-
Main contact:
- Victor Vasiliev [email protected]
- David Schinazi [email protected]
- Forum: https://www.ietf.org/mailman/listinfo/webtransport
- Materials: