[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
QUIC                                                        J. Kang, Ed.
Internet-Draft                                                  Q. Liang
Intended status: Informational                                    Huawei
Expires: 6 January 2022                                           P. Liu
                                                            China Mobile
                                                             5 July 2021


                Applications Multiplexing a QUIC Session
             draft-kang-quic-apps-multiplexing-a-session-00

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 6 January 2022.

Copyright Notice

   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.




Kang, et al.             Expires 6 January 2022                 [Page 1]


Internet-Draft              Abbreviated Title                  July 2021


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 6 January 2022                 [Page 2]


Internet-Draft              Abbreviated Title                  July 2021


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 6 January 2022                 [Page 3]


Internet-Draft              Abbreviated Title                  July 2021


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 (editor)
   Huawei
   D2-03,Huawei Industrial Base
   Shenzhen
   China

   Email: kangjiao@huawei.com


   Qiandeng Liang
   Huawei
   No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
   Wuhan
   China

   Email: liangqiandeng@huawei.com










Kang, et al.             Expires 6 January 2022                 [Page 4]


Internet-Draft              Abbreviated Title                  July 2021


   Peng Liu
   China Mobile
   32 Xuanwumen West Street, Xicheng District
   Beijing
   China

   Email: liupengyjy@chinamobile.com












































Kang, et al.             Expires 6 January 2022                 [Page 5]