Internet DRAFT - draft-kang-quic-apps-multiplexing-a-session
draft-kang-quic-apps-multiplexing-a-session
QUIC J. Kang
Internet-Draft Q. Liang
Intended status: Informational X. Fei, Ed.
Expires: 13 July 2023 Huawei
P. Liu
China Mobile
9 January 2023
Applications Multiplexing a QUIC Session
draft-kang-quic-apps-multiplexing-a-session-02
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 13 July 2023.
Copyright Notice
Copyright (c) 2023 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 13 July 2023 [Page 1]
Internet-Draft Abbreviated Title January 2023
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 13 July 2023 [Page 2]
Internet-Draft Abbreviated Title January 2023
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 13 July 2023 [Page 3]
Internet-Draft Abbreviated Title January 2023
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, <https://xml2rfc.tools.ietf.org/public/rfc/bibxml/
reference.RFC.9000.xml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
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
XinCai Fei (editor)
Huawei
No. 410, Jianghong Road, Binjiang District
Hangzhou
China
Email: feixincai1@huawei.com
Kang, et al. Expires 13 July 2023 [Page 4]
Internet-Draft Abbreviated Title January 2023
Peng Liu
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
China
Email: liupengyjy@chinamobile.com
Kang, et al. Expires 13 July 2023 [Page 5]
