QUIC J. Chen Internet Draft T. Liu Intended status: Standards Track J. Jing Expires: January 2023 Y. Yu Bytedance Inc. July 29, 2022 An Unreliable Extension to QUIC draft-chen-quic-quicu-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 29, 2009. J.Chen, et al. Expires January 29, 2023 [Page 1] Internet-Draft An Unreliable Extension to QUIC July 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 (http://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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Abstract QUIC Unreliable (QUICU) is an extension of the QUIC protocol for unreliable data transmission, mainly through the definition and use of three new types of frames, namely the Expire Offset Frame, Boundary Frame, and Correlation Frame. The main purpose of this extension is to reduce data delivery delay. Through controlling the timing and scope of packet losses, QUICU reduces useless transmission to improve transmission efficiency, reduces head-of-line blocking to improve transmission timeliness, which are beneficial to delay- sensitive applications, especially audio and video applications. This document describes the motivation, the operations, and the wire formats of the three new types of frames. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Motivation.....................................................3 4. Operations.....................................................5 4.1. Transport Negotiation.....................................5 4.2. Data Sending..............................................6 4.3. Data Expiration...........................................6 4.4. Data Receiving............................................6 5. The Wire Format................................................7 J.Chen, et al. Expires January 29, 2023 [Page 2] Internet-Draft An Unreliable Extension to QUIC July 2022 5.1. Expire Offset Frame.......................................7 5.2. Boundary Frame............................................7 5.3. Correlation Frame.........................................8 6. Security Considerations........................................8 7. IANA Considerations............................................8 8. References.....................................................9 8.1. Normative References......................................9 Authors' Addresses...............................................10 1. Introduction QUIC Unreliable (QUICU) is an extension of the QUIC protocol for unreliable data transmission, mainly through the definition and use of three new types of frames, namely the Expire Offset Frame, Boundary Frame, and Correlation Frame. The main purpose of this extension is to reduce data delivery delay. Through controlling the timing and scope of packet losses, QUICU reduces useless transmission to improve transmission efficiency, reduces head-of-line blocking to improve transmission timeliness, which are beneficial to delay- sensitive applications, especially audio and video applications. This document describes the motivation, the operations, and the wire formats of the three new types of frames. 2. Conventions used in this document 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119. 3. Motivation The QUIC protocol has a variety of features, such as 0RTT connection establishment, congestion control, link migration, secure and reliable transmission, and so on. Most UDP applications can be migrated to QUIC. RFC 9221 extends QUIC by adding support for sending and receiving unreliable datagrams over a QUIC connection. In real-time transmission scenarios with high bit rates, such as audio and video transmission, including virtual reality type of applications, packet losses are sometimes unavoidable. On one hand, J.Chen, et al. Expires January 29, 2023 [Page 3] Internet-Draft An Unreliable Extension to QUIC July 2022 after detecting packet losses, QUIC's reliable transmission algorithm will continue to retransmit the lost data until the data is successfully received. Although this ensures the reliability of the data, it will increase the data delivery delay. On the other hand, there will also be issues when not applying any retransmission after packet losses, e.g., by using the new datagram QUIC frame types specified in RFC 9221. Although no retransmission is good for delay, the quality of data delivered to the application layer can become uncontrollable. For example, the audio can then have frequent and sharp bursts, and the video picture may be frequently blurred or even cannot be played. Therefore, it would be desirable to have a mechanism that allows to control the amount and time range of data that is retransmitted, thus allowing optimal tradeoff between delay and media quality. This document proposes such a mechanism. The proposed mechanism involves the definition of three new types of frames, namely the Expire Offset Frame, Boundary Frame, and Correlation Frame. Each of these frames carries a type field indicating the frame type and the stream ID of the target stream for which certain information is provided by these frames. In addition, each of these frames carries a special field, summarized as follows: 1) The Expire Offset Frame (See Section 5.1.1) carries an offset of the target stream, for notifying the receiving end that data before the offset in the target stream will not be retransmitted. Upon reception of this notification, the receiving end shall not wait for the arrival of any data preceding the offset in the target stream. 2) The Boundary Frame (see Section 5.1.2) also carries an offset of the target stream, for indicating the end of an independent block of data in the target stream. All data pieces of an independent block of data should be coupled in transmission, in the sense that a data piece is meaningfully useful only when all of the preceding data pieces of the same independent block have been successfully received. This information can be used to save transmission, retransmission, or request for retransmission of certain data pieces when it is known that some preceding data pieces of the same independent block have been lost and will not be retransmitted. It can also be used to allocate the same priority for all data pieces of an independent block of data. For example, if a coded picture or a part thereof is lost and will not be retransmitted, then all subsequent pictures in the same independent group of pictures would typically be useless even received as they typically depend on the lost (or partially lost) preceding picture for inter prediction reference, therefore in this case transmission, retransmission, or request for retransmission of the data of these pictures can be skipped. J.Chen, et al. Expires January 29, 2023 [Page 4] Internet-Draft An Unreliable Extension to QUIC July 2022 3) The Correlation Frame (see Section 5.1.3) carries the correlation stream ID, which is the stream ID of the stream that contains the request based on which the current stream was created, for associating multiple streams created based on the same request. For backward compatibility reasons, streaming systems may store multiplexed media contents, e.g., in the FLV (Flash Video) format, in the origin and edge servers, while transmitting the media components in separate streams using QUIC to take advantage of different priorities and other properties of the different media components. In such streaming systems, based on one request (either a download request or an upload request), multiple streams can be created. However, without additional information, the entity that receives these multiple streams won't be able to determine which of the received streams were originated from the same request and thus should be presented together. The Correlation Frames in these received streams provide such additional information; those received streams having the same correlation stream ID value were originated from the same request and should be presented together. 4. Operations 4.1. Transport Negotiation Text When establishing a connection, it is necessary to confirm whether the receiver supports QUICU, using a QUIC transport parameter (name=support_quic_unreliable, value=0x21). The support_quic_unreliable transport parameter is an integer value (represented as a variable-length integer), for which the value 0 indicates that QUICU is not supported and the value 1 indicates that QUICU is supported. The default value for this parameter is 0. When the connection is established, a bidirectional stream can be created like normal QUIC. Before receiving the Boundary Frame, the receiver can respond to the data like a normal QUIC stream, while after receiving the Boundary Frame, it starts to enter the QUICU mode. When the peer's support_quic_unreliable transport parameter is not received during the handshake negotiation, the Boundary Frame, Correlation Frame and Expire Offset Frame cannot be sent to the peer. If one side receives a QUICU-specific frame from the peer while it itself does not carry the support_quic_unreliable transport parameter, it should disconnect the connection and return the error code "QUICU mode not supported". Once the QUICU mode is established for a stream, the QUICU mode is used for the entire lifetime of the stream. J.Chen, et al. Expires January 29, 2023 [Page 5] Internet-Draft An Unreliable Extension to QUIC July 2022 The QUICU mode can be unidirectional. Receiving a Boundary Frame indicates that the incoming flow for an entity is in the QUICU mode. However, at the same time, the outgoing flow of this entity can still be in the normal QUIC mode. 4.2. Data Sending When different components of the data do not need to be treated differently in transmission, e.g., with different priorities, they can be transmitted in the same stream, and this transmission mode is referred to as the single-stream mode. In this case, the data is encapsulated in Stream Frames as usual. When different components of the data do need to be treated differently in transmission, e.g., with different priorities, they should be transmitted in different streams, and this transmission mode is referred to as the multi-stream mode. In this case, Correlation Frames need to be sent to associate streams created based on the same request. In both the single-stream and multi-stream modes, and Boundary Frames can be used to indicate the boundaries between independent blocks of data in a stream. 4.3. Data Expiration A piece of sent data of a stream can be considered lost if its reception is not confirmed for a certain period of time; this period of time is referred to as the timeout period. After the timeout period expires, an Expire Offset Frame can be sent to notify the other side that certain data of the stream has been lost and will not be retransmitted. The Expire Offset Frame needs to be sent out as soon as possible after the timeout period expires. Note that this operation is RFC 9221 compliant in the sense that the data transmission is not guaranteed to be reliable. The timeout period can be a fixed value; or configured by users through the application. 4.4. Data Receiving In a stream, if a Boundary Frame is not received, the data of the stream will be delivered to the application same as in the normal QUIC mode; otherwise, the QUICU mode will be in use. In the QUICU mode, the data in independent block is only delivered to the application when the entire independent block of data has been J.Chen, et al. Expires January 29, 2023 [Page 6] Internet-Draft An Unreliable Extension to QUIC July 2022 received and placed in the right order, after the delivery of the previous independent block of data of the same stream. However, when some data of an independent block expires as indicated by an Expire Offset Frame, the content of this independent block is discarded, and the next independent block of data can be delivered to the application when the entire independent block has been received and placed in the right order. 5. The Wire Format Based on the basic standard of QUIC, RFC 9000, three new types of frames are specified, namely, the Boundary Frame, Correlation Frame, and Expire Offset Frame. 5.1. Expire Offset Frame +--------+--------+-- ... --+-------+--------+-- ... --+------------+ |Type(8) | Stream ID (32 bits) | Expire offset (64 bits) | +--------+--------+-- ... --+-------+--------+-- ... --+------------+ Stream ID: Indicates the stream ID of the target stream for which information on which pieces of data will not to be retransmitted is indicated by the Expire Offset field. Expire Offset: Indicating the offset, in units of bytes, of such a position of the target stream, that no data before that position in the target stream will be retransmitted. 5.2. Boundary Frame +--------+--------+-- ... --+-------+--------+-- ... --+----------+ |Type(8) | Stream ID (32 bits) | Boundary Offset (64 bits) | +--------+--------+-- ... --+-------+--------+-- ... --+----------+ Stream ID: Indicates the stream ID of the target stream for which the end position of an independent block of data is indicated by the Boundary Offset field. Boundary Offset: Indicates the end position of an independent block of data in the target stream. Let the value of the Boundary Offset field of the i-th Boundary Frame be bo[i] with bo[0] being the value of the very first Boundary Frame. The first independent block of data in the target stream consists of bytes 0 to bo[0], inclusive. For any value of i greater than 0, the i-th independent block of data in the target stream consists of bytes bo[i-1] + 1 to bo[i], inclusive. The J.Chen, et al. Expires January 29, 2023 [Page 7] Internet-Draft An Unreliable Extension to QUIC July 2022 Boundary Frame of the last independent block of data in the target stream can be but does not have to be sent, as it is known that the end position is the end of the target stream itself. 5.3. Correlation Frame +--------+--------+-- ... --+-------+--------+-- ... --+------------+ |Type(8) | Stream ID (32 bits) |Correlation Stream ID (32 bits)| +--------+--------+-- ... --+-------+--------+-- ... --+------------+ Stream ID: Indicates the stream ID of the target stream that is one of the streams created based on a request contained in a stream identified by the Correlation Stream ID field. Correlation Stream ID: Indicates the stream ID of the stream containing the request based on which the target stream was created. 6. Security Considerations The three new types of frames share the same security properties as the rest of the data transmitted within a QUIC connection, and the security considerations of [RFC9000] apply accordingly. All new frame types, like the Expire Offset Frame, the Boundary Frame and the Boundary Frame, MUST be protected either by 0-RTT or 1-RTT keys. 7. IANA Considerations This document registers a new value in the QUIC Transport Parameter Registry: Value:0x0021 (if this document is approved) Parameter Name: support_quic_unreliable Specification: Section 4.1 of this document. This document also registers three new values in the QUIC Frame Type Registry: J.Chen, et al. Expires January 29, 2023 [Page 8] Internet-Draft An Unreliable Extension to QUIC July 2022 Value:0x32 (if this document is approved) Frame Name: Expire Offset Specification: Section 5.1.1 of this document Value:0x33 (if this document is approved) Frame Name: Boundary Specification: Section 5.1.2 of this document Value:0x34 (if this document is approved) Frame Name: Correlation Specification: Section 5.1.3 of this document 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, . J.Chen, et al. Expires January 29, 2023 [Page 9] Internet-Draft An Unreliable Extension to QUIC July 2022 Authors' Addresses Jianping Chen Bytedance Inc. No. 27, North Third Ring West Road, Haidian District, Beijing China Email: chenjianping.ireader@bytedance.com Tianyi Liu Bytedance Inc. No. 27, North Third Ring West Road, Haidian District, Beijing China Email: liutianyi.lty@bytedance.com Junxian Jing Bytedance Inc. No. 27, North Third Ring West Road, Haidian District, Beijing China Email: jingjunxian@bytedance.com Yongyi Yu Bytedance Inc. No. 27, North Third Ring West Road, Haidian District, Beijing China Email: yuyongyi.yyy@bytedance.com J.Chen, et al. Expires January 29, 2023 [Page 10]