-
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:
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 contact: Martin Duke, [email protected]
- Forum: There is a google group. Email Martin to join.
- Materials: https://github.com/martinduke/draft-duke-quic-load-balancers, https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/
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: https://github.com/tfpauly/draft-pauly-quic-datagram
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 would 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 (partially) by quicker, lsquic, mvfst, quant and aioquic.
- Main contact: Robin Marx, [email protected]
- Forum: [email protected], #qlog in the QUIC slack, github issues on the repo (see below)
- Materials: https://github.com/quiclog, https://tools.ietf.org/html/draft-marx-qlog-main-schema-00, https://tools.ietf.org/html/draft-marx-qlog-event-definitions-quic-h3-00, https://quic.edm.uhasselt.be, https://quic.edm.uhasselt.be/qtr-to-qlog/
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); TBD for mailing list (ETA: Wednesday)
-
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.
- 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]) and Emile Stephan ([email protected])
- Forum: QUIC mailing list or GitHub issues on the repo
- Materials:
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:
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:
- media
- auth handshake
- multicast
- satellite / etosat
- FEC
- quic-network-sim