Applications Multiplexing a QUIC Session
Internet-Draft draft-kang-quic-apps-multiplexing-a-session-01
Jiao Kang
Huawei
jiao_kang2022@163.com
Qiandeng Liang
Huawei
No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
Wuhan
China
liangqiandeng@huawei.com
Shangling Deng, Ed.
Huawei
D2-03,Huawei Industrial Base
Shenzhen
China
dengshangling@huawei.com
Peng Liu
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
China
liupengyjy@chinamobile.com
2022
Transport Area
QUIC
quic
This document describes the requirements for extensions on QUIC transport protocol in the use case when multiple application protocols reuse the same QUIC session for data transmission.
Introduction
Overview
[QUIC] 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.
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
DOI 10.17487/RFC2119
RFC 2119
BCP 14
S. Bradner
March 1997
[QUIC]

QUIC: A UDP-Based Multiplexed and Secure Transport
Jana Iyengar
Martin Thomson
May 2021
RFC 9000
DOI 10.17487/RFC9000