Internet-Draft Abbreviated Title July 2021
Kang, et al. Expires 6 January 2022 [Page]
Intended Status:
J. Kang, Ed.
Q. Liang
P. Liu
China Mobile

Applications Multiplexing a QUIC Session


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 January 2022.

Table of Contents

1. Introduction

1.1. 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.

1.2. 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 [RFC2119].

2. 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.

3. 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.

4. 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.

5. Other Issue

5.1. 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.

6. IANA Considerations

This document includes no request to IANA.

7. Security Considerations

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

8. References

8.1. Normative References

Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

Authors' Addresses

Jiao Kang (editor)
D2-03,Huawei Industrial Base
Qiandeng Liang
No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
Peng Liu
China Mobile
32 Xuanwumen West Street, Xicheng District