This page is provided to assist in the review and development of Internet Drafts seeking to use QUIC as a transport service for upper layer protocols and applications that do not use HTTP.
Defining application usage of QUIC is potentially challenging and this section captures some resources, recommendations and examples. We expect this to change and evolve.
The QUIC Applicability statement includes some guidance on aspects of QUIC to consider.
Applications needs to consider how to identify applications, this can include both registered port numbers as well as TLS ALPNs.
As QUIC uses TLS for the security handshake any method that is available in TLS for authentication of the peer, either server only or mutual authentication (mTLS) can be used on transport connection level.
QUIC enables 0-RTT data as noted by TLS usage of this data requires considerations as this data cannot be replay protected.
Applications that require long-lived QUIC connections will have to consider how they handle some of the existing limitations of QUIC. QUIC only does ephemeral key exchange at the intitial TLS handshake. This may be unsuitable for application that exchange larger amounts of data or maintain connections longer than an hour. One potential solution to this is to require using TLS extended key update for QUIC for ephemeral key updates, and can consider Exported Authenticators in TLS. The other alternative if the application is capable of supporting this is to ensure that new QUIC connections are established periodically and used to replace those that have been used.
QUIC supports multiple streams (multistreaming) within a connection. Each stream is independent data flow. This avoids head-of-line-blocking between streams. There is no ordering or priority guarantees between data sent using different streams, this is application-specific.
QUIC provides in-order reliable delivery using a Stream. This can be uni- or bi-directional and initiated by either client or server. Closing streams can be done reliably or using a reset, which does not provide delivery guarantees. Reset-at extension provides more control.
Applications need also to consider defining error codes to indicate reasons for closing streams.
The QUIC DATAGRAM frame is a widely-implemented QUIC extension [Datagram Extension] (https://datatracker.ietf.org/doc/rfc9221/). This provides unrelilable datagrams, where the datagram payload must fit within the MTU available to the QUIC session.
Datagrams are congestion-controlled, but not subject to flow control.Because there are no reliability or in-order guarantees applications may need to build on top or require additional information from the QUIC implementation.
<...>
QUIC may be expected to continue to evolve as new versions and options emerge. The design is intentionally flexible. Some QUIC features are defined as extensions or are supported by options. Not all stacks are equal in what they offer, nor in the APIs that they provide.