QUIC J. Kang Internet-Draft Q. Liang Intended status: Informational S. Deng, Ed. Expires: 18 December 2022 Huawei P. Liu China Mobile 16 June 2022 Applications Multiplexing a QUIC Session draft-kang-quic-apps-multiplexing-a-session-01 Abstract 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 https://datatracker.ietf.org/drafts/current/. 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 18 December 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Kang, et al. Expires 18 December 2022 [Page 1] Internet-Draft Abbreviated Title June 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. ALPN negotiation during the handshake . . . . . . . . . . . . 3 3. Binding STREAM to different applications . . . . . . . . . . 3 4. Binding DATAGRAM to different applications . . . . . . . . . 3 5. Other Issue . . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Dynamically changing application protocol during a QUIC session . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 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]. Kang, et al. Expires 18 December 2022 [Page 2] Internet-Draft Abbreviated Title June 2022 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. Kang, et al. Expires 18 December 2022 [Page 3] Internet-Draft Abbreviated Title June 2022 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 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Jiao Kang Huawei Email: jiao_kang2022@163.com Qiandeng Liang Huawei No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone Wuhan China Email: liangqiandeng@huawei.com Shangling Deng (editor) Huawei D2-03,Huawei Industrial Base Shenzhen China Email: dengshangling@huawei.com Kang, et al. Expires 18 December 2022 [Page 4] Internet-Draft Abbreviated Title June 2022 Peng Liu China Mobile 32 Xuanwumen West Street, Xicheng District Beijing China Email: liupengyjy@chinamobile.com Kang, et al. Expires 18 December 2022 [Page 5]