idnits 2.17.00 (12 Aug 2021) /tmp/idnits17093/draft-kang-quic-apps-multiplexing-a-session-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (5 July 2021) is 313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC J. Kang, Ed. 3 Internet-Draft Q. Liang 4 Intended status: Informational Huawei 5 Expires: 6 January 2022 P. Liu 6 China Mobile 7 5 July 2021 9 Applications Multiplexing a QUIC Session 10 draft-kang-quic-apps-multiplexing-a-session-00 12 Abstract 14 This document describes the requirements for extensions on QUIC 15 transport protocol in the use case when multiple application 16 protocols reuse the same QUIC session for data transmission. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 6 January 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. ALPN negotiation during the handshake . . . . . . . . . . . . 3 55 3. Binding STREAM to different applications . . . . . . . . . . 3 56 4. Binding DATAGRAM to different applications . . . . . . . . . 3 57 5. Other Issue . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5.1. Dynamically changing application protocol during a QUIC 59 session . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 1.1. Overview 70 [QUIC] is a UDP-based multiplexed and secure transport protocol. 71 QUIC enables stream multiplexing and stream multiplexing is achieved 72 by interleaving STREAM frames from multiple streams into one or more 73 QUIC packets. In practice, application layer can invoke interfaces 74 to create and close stream as required. 76 But when the QUIC server provides multiple services at the same time, 77 for example, an IT vendor server provides both a video stream service 78 and a web browsing service, different application services use 79 different application layer protocols (for example, HTTP3.0 or RTP/ 80 RTCP). In this case, each application layer protocol requires a QUIC 81 session to support its data transmission. This realization will 82 increase system overhead due to maintaining these QUIC sessions. 83 Currently multi-protocol dynamically multiplexing a QUIC sessions is 84 not possible. 86 This document is used to analysis what mechanism is required when 87 multiple application protocols reuse single QUIC session from a 88 deployment perspective. In general, two basic functions are proposed 89 that are ALPN negotiation during the handshake and binding STREAM/ 90 DATAGRAM to different applications during the session. 92 1.2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. ALPN negotiation during the handshake 100 As described in QUIC base protocol, endpoints advertise ALPN field in 101 handshake to negotiate the protocol carried in the STREAM frame or 102 DATAGRAM frame when establishing a QUIC session. After receiving the 103 STREAM frame or DATAGRAM frame, the receiver completes the 104 combination for these fragmented STREAM frame and transfers the 105 packet data to the application layer protocol for further parsing. 106 As a result, service packets in a QUIC session can only belong to one 107 application protocol. 109 In the case of mixed application data in one session, ALPN should 110 offer the function for endpoints to advertise multiple application 111 protocols that will be used in this session during connection 112 establishment. 114 In this new mechanism, when an application in QUIC client requests to 115 communicate with its server using QUIC, the initiator will check 116 whether a QUIC session exists. If there is already a QUIC session 117 and this session can support this kind application protocol, the 118 initiator will directly reuse this session and create a new stream in 119 it for exchange of application data. 121 3. Binding STREAM to different applications 123 Because multiple applications are using one session simultaneously 124 and create their own streams to transmit data separately, the 125 application layer protocol to which the stream belongs should be 126 indicates to the peer so that the receiver can further parse these 127 packets based on the upper-layer protocol type. 129 4. Binding DATAGRAM to different applications 131 If DATAGRAM is used for data transmission for these distinct 132 applications in one QUIC session, the application layer protocol to 133 which the DATAGRAM belongs should be indicated to the peer so that 134 the receiver can further parse these packets based on the upper-layer 135 protocol type. 137 5. Other Issue 139 5.1. Dynamically changing application protocol during a QUIC session 141 If upper-layer protocol types supported by a QUIC client or a QUIC 142 server are changed dynamically after a QUIC session is established, 143 protocol negotiation within a QUIC session for these updates should 144 be provide. 146 6. IANA Considerations 148 This document includes no request to IANA. 150 7. Security Considerations 152 This document provides only requirement analysis. Security problems 153 will be considered in technical solutions. 155 8. References 157 8.1. Normative References 159 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 160 and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 161 2021, . 164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 165 Requirement Levels", BCP 14, RFC 2119, 166 DOI 10.17487/RFC2119, March 1997, 167 . 169 Authors' Addresses 171 Jiao Kang (editor) 172 Huawei 173 D2-03,Huawei Industrial Base 174 Shenzhen 175 China 177 Email: kangjiao@huawei.com 179 Qiandeng Liang 180 Huawei 181 No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone 182 Wuhan 183 China 185 Email: liangqiandeng@huawei.com 186 Peng Liu 187 China Mobile 188 32 Xuanwumen West Street, Xicheng District 189 Beijing 190 China 192 Email: liupengyjy@chinamobile.com