Applications Multiplexing a QUIC Session

Introduction

Overview is a UDP-based multiplexed and secure transport protocol. QUIC enables stream multiplexing and stream multiplexing is achieved by interleaving STREAM frames from multiple streams into one or more QUIC packets. In practice, application layer can invoke interfaces to create and close stream as required. But when the QUIC server provides multiple services at the same time, for example, an IT vendor server provides both a video stream service and a web browsing service, different application services use different application layer protocols (for example, HTTP3.0 or RTP/RTCP). In this case, each application layer protocol requires a QUIC session to support its data transmission. This realization will increase system overhead due to maintaining these QUIC sessions. Currently multi-protocol dynamically multiplexing a QUIC sessions is not possible. This document is used to analysis what mechanism is required when multiple application protocols reuse single QUIC session from a deployment perspective. In general, two basic functions are proposed that are ALPN negotiation during the handshake and binding STREAM/DATAGRAM to different applications during the session.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

ALPN negotiation during the handshake As described in QUIC base protocol, endpoints advertise ALPN field in handshake to negotiate the protocol carried in the STREAM frame or DATAGRAM frame when establishing a QUIC session. After receiving the STREAM frame or DATAGRAM frame, the receiver completes the combination for these fragmented STREAM frame and transfers the packet data to the application layer protocol for further parsing. As a result, service packets in a QUIC session can only belong to one application protocol. In the case of mixed application data in one session, ALPN should offer the function for endpoints to advertise multiple application protocols that will be used in this session during connection establishment. In this new mechanism, when an application in QUIC client requests to communicate with its server using QUIC, the initiator will check whether a QUIC session exists. If there is already a QUIC session and this session can support this kind application protocol, the initiator will directly reuse this session and create a new stream in it for exchange of application data.

Binding STREAM to different applications Because multiple applications are using one session simultaneously and create their own streams to transmit data separately, the application layer protocol to which the stream belongs should be indicates to the peer so that the receiver can further parse these packets based on the upper-layer protocol type.

Binding DATAGRAM to different applications If DATAGRAM is used for data transmission for these distinct applications in one QUIC session, the application layer protocol to which the DATAGRAM belongs should be indicated to the peer so that the receiver can further parse these packets based on the upper-layer protocol type.

Other Issue

Dynamically changing application protocol during a QUIC session If upper-layer protocol types supported by a QUIC client or a QUIC server are changed dynamically after a QUIC session is established, protocol negotiation within a QUIC session for these updates should be provide.

IANA Considerations This document includes no request to IANA.

Security Considerations This document provides only requirement analysis. Security problems will be considered in technical solutions.