| Internet-Draft | Abbreviated Title | July 2021 |
| Kang, et al. | Expires 6 January 2022 | [Page] |
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.¶
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 6 January 2022.¶
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
[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.¶
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].¶
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.¶
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.¶
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.¶
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.¶
This document includes no request to IANA.¶
This document provides only requirement analysis. Security problems will be considered in technical solutions.¶