QUIC Working Group D. Moskvitin Internet-Draft E. Onegin Intended status: Standards Track R. Huang Expires: 7 November 2024 H. Luo Q. Chen Huawei 6 May 2024 Adaptive Forward Erasure Correction for Delay-Sensitive QUIC Connections draft-dmoskvitin-quic-adaptive-fec-00 Abstract This document proposes a FEC supporting mechanism of QUIC protocol for both short flows and long flows protection in accordance to the sender observed packet loss rate. 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 7 November 2024. Copyright Notice Copyright (c) 2024 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. Moskvitin, et al. Expires 7 November 2024 [Page 1] Internet-Draft FEC for QUIC May 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Short Message FEC Design Overview . . . . . . . . . . . . . . 3 4. FEC and Loss Recovery . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 5.1. Handshake Negotiation and Transport Parameter . . . . . . 5 5.2. FEC Tag Frame . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Repair Symbol Frame . . . . . . . . . . . . . . . . . . . 6 5.4. Usage of FEC Tag in QUIC Packets . . . . . . . . . . . . 6 5.4.1. Short Flow Usage . . . . . . . . . . . . . . . . . . 7 5.4.2. Long Flow Usage . . . . . . . . . . . . . . . . . . . 7 6. Impact of Loss Recovery . . . . . . . . . . . . . . . . . . . 7 7. Loss Rate Calculation . . . . . . . . . . . . . . . . . . . . 7 8. Adaptive redundancy . . . . . . . . . . . . . . . . . . . . . 9 9. Security Consideration . . . . . . . . . . . . . . . . . . . 9 9.1. DoS due to difficult symbols recoveries . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The QUIC protocol [QUICv1] is general purpose transport protocol, which supports both reliable and unreliable data transmission. Depending on application-specific use cases, one can choose either to rely on QUIC built-in loss recovery mechanism [QUIC-RECOVERY] or to use application layer retransmission mechanism. In both cases it takes more than one round-trip time to retransmit lost data, which may be crucial in delay-sensitive applications (e.g. RTC) if RTT is high enough. Forward erasure coding allows to avoid or minimize extra delay incurred by the retransmission of lost data, while redundancy adaptation minimizes data overhead generated by FEC.. There are several works considering the use of Forward Erasure Correction (FEC) in QUIC protocol: [I-D.roca-nwcrg-rlc-fec-scheme-for-quic], [I-D.swett-nwcrg-coding-for-quic] and [I-D.michel-quic-fec]. These works share the common idea of protecting a sequence of packets each containing protected data. But there is a broad area of applications there it’s only needed to send short messages of data (one or couple QUIC packets) in timely manner with relatively high time gap in- between, for example instant messaging, control channels, notifications, etc. In this case it’s more beneficial to protect every message independently of each over. Moskvitin, et al. Expires 7 November 2024 [Page 2] Internet-Draft FEC for QUIC May 2024 This document defines extensions to the QUIC protocol which has the ability to cover both use cases, i.e., either a FEC packet protecting a sequence of packets or several FEC packets protecting single packet independently, and adaptively adjust the FEC redundancy according to packet loss rate. It is useful in random loss scenarios for delay sensitive services. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Short Message FEC Design Overview FEC mechanisms used for streaming scenario which is one FEC pacekts protecting a seqence of packets is well known. In this section, how to protect whole QUIC packet is introduced, motivated by the applications described in introduction. Therefore, each protected packet corresponds to several repair symbols, and each repair symbol correspond to one protected packet. Prior to encryption, serialized QUIC packet is divided into several parts, called shards, each shard acts as source symbol and sequence of shards corresponding to single QUIC packet act as message (see Figure 1). +---------------+ - - - - - - +---------------+ | QUIC header | | | +---------------+ | Shard 1 | | | | | | | - - - - - - +---------------+ | Payload | | | | | | Shard 2 | | | | | +---------------+ - - - - - - +---------------+ Figure 1: Example of packet division into two shards Number of shards depend on encoding algorithm and parameters used for protection. If the size of protected packet is either too small or can’t be evenly divided, then the protected packet may be padded with PADDING frame during serialization to achieve desirable size. It is noted that this method only protect the application data space. After sending protected packet, sender SHOULD encode corresponding shards into repair symbols and send them afterwards. Several repair symbols MAY be sent in one QUIC packet, but it’s RECOMMENDED to send Moskvitin, et al. Expires 7 November 2024 [Page 3] Internet-Draft FEC for QUIC May 2024 repair symbols in separate packets. In general, distribution of repair symbols between packets depends on properties of concrete erasure code used. Each repair symbol MUST contain information about corresponding protected packet number. It allows to avoid marking protected packets with some FEC-specific id. Receiver MAY ignore repair symbols, particularly in the cases when corresponding protected packet is either already received or recovered. Repair symbols are accumulated on receiver either until recovery or the moment when recovery of corresponding lost packet is not possible anymore. Network Receiver side Sender QUIC Packet Decoder | Processing | | | | Protected | | Packet 1 - - - - X Loss | | | | | Repair | | Symbol 1 - - - - - - - - > | - - - - - - - - - > | | | | Repair | | Symbol 2 - - - - - - - - > | - - - - - - - - - > | | | Protected Packet 1 | | < - - - - - - - Recovered Figure 2: Example of protected packet recovery after two corresponding repair symbols received 4. FEC and Loss Recovery The FEC extension described in this document SHOULD work as an addition to built-in QUIC loss recovery mechanism and intended only for faster recovery of data lost during transmission through network. Modules of QUIC, which rely on precise loss rate measurements (e.g. congestion control) during transmission, should be provided with actual packet loss rate from wire, rather than loss rate measured after recovery. Depending on repair symbol scheduling, packet recovery may be observed as packet reordering in wire, therefore should be properly accounted. Finally, FEC adaptive redundancy mechanism should consider possible losses incurred by congestion control overshooting and avoid positive feedback loop: recursively increase redundancy as a reaction to increased packet loss rate. Moskvitin, et al. Expires 7 November 2024 [Page 4] Internet-Draft FEC for QUIC May 2024 5. Protocol Extensions QUIC protocol extensions are specified in this sectioin. 5.1. Handshake Negotiation and Transport Parameter This extension defines a new transport parameter, used to negotiate the use of FEC extensions during the connection handshake, as specified in [QUICv1]. The new transport parameter is defined as follows: enable_FEC: The enable_FEC transport parameter is included if the endpoint supports FEC mechanism and FEC extensions as defined in this draft. This parameter specify the the support FEC algorithm. How the FEC algorithm is encoded will be added in future versions. 5.2. FEC Tag Frame FEC_Tag Frame are used to indicate the relationship between FEC source symbol and repair symbol, as well as adaptive FEC information. FEC_Tag frames are formattes as follow Figure 3 FEC_Tag { Type (i), Tag Type (1), Sequence (5), Tag ID Length (2), Tag ID (8..32), [Redundancy Ratio (8)], } Figure 3: FEC_TAG frame format This FEC Tag frame can be used either in source symbol or in repair symbol. It contains the following fields: Tag type: It indicates the usage of this FEC tag. 0 indicates it is using short message FEC mechanism, in which case only repair symbol MUST include this frame; 1 indicates it's for long flow usage in which case both source symbol and repair symbos must include this frame. Sequence: The sequence number in FEC block. When the frame is used in source symbol, it indicates sequence number of this proctected QUIC packet appeared in the current FEC block. When the frame is used in repair symbol, it indicates the sequence number of this repair packet in the current FEC block produced by the FEC mechanism. Moskvitin, et al. Expires 7 November 2024 [Page 5] Internet-Draft FEC for QUIC May 2024 Tag ID Length: It is encoded as an unsigned two-bit integer that is one less than the length of the Tag ID field in bytes Tag ID: It is the information of current FEC block. In the case of tag type is 0, i.e., one QUIC packet is protected by several FEC repair packets, it is equal to the corresponding source packet number that the FEC frame protects, As defined in the packet number definition in [QUICv1]. In the case of tag type is 1, i.e., multiple QUIC packets are protected by one or multiple FEC repair packets, it is encoded as the FEC block ID. Redundancy Ratio: The ration of FEC repair packets in one FEC block. It is equivalent to taking the interger part after multiplying the redundancy ratio by 256. The redundacy ratio is defined to be the number of FEC repair packets divided by the total number of packets sent in the same FEC block. When this field is 0, it means that adaptive FEC is not used. 5.3. Repair Symbol Frame FEC-REPAIR Frame are used by a sender to contain the FEC symbol which will be used by the receiver to recover a lost packet. FEC_REPAIR frames are formatted as follow Figure 4. FEC_REPAIR { Type (i) = TBD, FEC Version (i), FEC Meta Data (..), Reserved (i) = 0, FEC Payload (..) } Figure 4: FEC_REPAIR frame format It contains the following fields: FEC Version: A variable-length integer which specifies the encoding algorithm used and the structure of the following FEC Meta Data field. FEC Meta Data: A structure, which is intended for additional information about repair symbol, such as identificator of repair symbol in the coding block, encoding parameters, FEC Payload size, etc. Contents of this structure depend on concrete implementation and encoding algorithm used. 5.4. Usage of FEC Tag in QUIC Packets Moskvitin, et al. Expires 7 November 2024 [Page 6] Internet-Draft FEC for QUIC May 2024 5.4.1. Short Flow Usage In this case, the souce symbol quic packets are untouched. The repair symbol quic packets will look like as follow: Repir_Symbol_QUIC_Packet { QUIC header, FEC_Tag, FEC_REPAIR } 5.4.2. Long Flow Usage In this case, both the souce symbol quic packets and the repair symbol quic packets MUST contain FEC_Tag frame. Souce_Symbol_QUIC_Packet { QUIC header, FEC_Tag, Original payload } Repir_Symbol_QUIC_Packet { QUIC header, FEC_Tag, FEC_REPAIR } 6. Impact of Loss Recovery In the case of lost source symbol packets have been successfully recovered by FEC mechnisim, it should avoid the retransmssion of those packets at the sender. Thus, the receiver MUST treat those recovered packets as the received packets, in stead of lost packets, in the ACK frames. In the case of lost pacekts are FEC repair symbol, retransmission of these packet at the sender is meaningless. Therefore, the sender SHOULD ignore them when detecting such losses from the ACK frames. 7. Loss Rate Calculation Loss rate calculation is based on the received ACK frame by the sender. With the introduction of FEC, loss rate calculation will includes repair packets, which is not accurately represent the source symbol packet loss rate. When using adaptive FEC, a more precise calculation of the original packet loss rate would be benefitial to determine the appropriate level of FEC redundancy to be injected. Considering the diagram as follow. Moskvitin, et al. Expires 7 November 2024 [Page 7] Internet-Draft FEC for QUIC May 2024 +-----------------------+ |Sent packets | | +-----------------+ | | |Acked packets | | | | +---------------+-+ | | | | +----------+ | | | | | | | FEC | | | | | | | | acked | | | | | | | | packets | | | | | | | +----------+ | | | | +-+---------------+ | | | |Protected packets| | | +-----------------+ | +-----------------------+ Figure 5: Relationship between acked and FEC acked protected packets To address this issue, a new frame is introduced to inform the sender what packets have been recovered. It is formatted as follow Figure 6. FEC_ACK { Type (i) = TBD, FEC Latest Restored Packet Number (i), FEC Restored Bytes (i), FEC Restored Packets (i), FEC Restored Packet List Size (i), Figure 6: FEC_ACK frame format FEC Latest Restored Packet Number: A variable-length integer which contains latest restored packet number. FEC Restored Bytes: A variable-length integer which contains number of bytes restored on receiver side. This field is intended for statistics collection and analysis on sender. FEC Restored Packets: A variable-length integer which contains number of packets restored on receiver side. This field is intended for statistics collection and analysis on sender. FEC Restored Packet List Size: A variable-length integer which contains amount of packet numbers following after in that frame. FEC Restored Packet Number: A list of recovered packet numbers listed in restoring order (newer first). Moskvitin, et al. Expires 7 November 2024 [Page 8] Internet-Draft FEC for QUIC May 2024 This frame is optional. It can be used to calculate the loss rate more accurately when used for adaptive FEC. 8. Adaptive redundancy In order to achieve maximum efficiency, sender should change encoding algorithm parameters to match network conditions. To be precise, from a set of algorithm parameters, which provide a certain protection level at current network packet loss rate ( we provide example of relation between loss rate in BEC and performance of FEC scheme with fixed parameters as follow), choose one that have maximum coding rate. This way it will tend to reduce redundancy while providing certain level of protection. Success ▲ rate,% │ 100│_____..................................... │ ─────____ │ ──__ │ ── │ ── │ ─_ │ _ │ _ │ ─__ │ -___ ──┼─────────────────────────────────|───────► 0│ 100% Packet loss rate,% Figure 7: Example of performance profile of a given FEC scheme 9. Security Consideration The FEC mechanism for QUIC only runs under 0-RTT and 1-RTT encryption levels and only operates inside the encrypted payload. 9.1. DoS due to difficult symbols recoveries An attacker could try to cause a DoS of a receiver by selectively sending repair symbols to trigger intensive erasure correction operations on the receiver. A QUIC receiver is never forced to perform any erasure correction and may ignore any received repair symbol if it has doubts in its capabilities to decode it in a reasonable amount of time. Moskvitin, et al. Expires 7 November 2024 [Page 9] Internet-Draft FEC for QUIC May 2024 10. IANA Considerations This document defines a new transport parameter for supporting FEC mechanisms, and possibly 2 new frame types. +==========+===========+==============+ |Frame ID |Frame name |Specification | +==========+===========+==============+ |TBD |FEC Tag |{{fectag}} | +----------+-----------+--------------+ |TBD |FEC Repair |{{fecrepair}} | +----------+-----------+--------------+ |TBD |FEC Ack |{{fecack}} | +----------+-----------+--------------+ Figure 8: List of new frames 11. References 11.1. Normative References [QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . [QUICv1] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Moskvitin, et al. Expires 7 November 2024 [Page 10] Internet-Draft FEC for QUIC May 2024 [rfc9265] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward Erasure Correction (FEC) Coding and Congestion Control in Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022, . 11.2. Informative References [I-D.michel-quic-fec] Michel, F. and O. Bonaventure, "Forward Erasure Correction for QUIC loss recovery", Work in Progress, Internet-Draft, draft-michel-quic-fec-01, 23 October 2023, . [I-D.roca-nwcrg-rlc-fec-scheme-for-quic] Roca, V., Michel, F., Swett, I., and M. Montpetit, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for QUIC", Work in Progress, Internet-Draft, draft-roca-nwcrg-rlc-fec-scheme-for-quic- 03, 9 March 2020, . [I-D.swett-nwcrg-coding-for-quic] Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding for QUIC", Work in Progress, Internet-Draft, draft-swett- nwcrg-coding-for-quic-04, 9 March 2020, . Authors' Addresses Dmitry Moskvitin Huawei Email: dmitry.moskvitin@huawei.com Evgeny Onegin Huawei Email: onegin.evgeny@huawei.com Rachel Huang Huawei Email: rachel.huang@huawei.com Hanlin Luo Huawei Moskvitin, et al. Expires 7 November 2024 [Page 11] Internet-Draft FEC for QUIC May 2024 Email: luohanlin2@huawei.com Qichang Chen Huawei Email: chenqichang1@huawei.com Moskvitin, et al. Expires 7 November 2024 [Page 12]