Skip to main content

Forward Erasure Correction for Short-Message Delay-Sensitive QUIC Connections
draft-dmoskvitin-quic-short-message-fec-00

Document Type Active Internet-Draft (individual)
Authors Dmitriy Moskvitin , Evgeny Onegin , Rachel Huang , Hanlin Luo , Qichang Chen
Last updated 2023-10-22
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dmoskvitin-quic-short-message-fec-00
QUIC Working Group                                          D. Moskvitin
Internet-Draft                                                 E. Onegin
Intended status: Standards Track                                R. Huang
Expires: 25 April 2024                                            H. Luo
                                                                 Q. Chen
                                                                  Huawei
                                                         23 October 2023

   Forward Erasure Correction for Short-Message Delay-Sensitive QUIC
                              Connections
               draft-dmoskvitin-quic-short-message-fec-00

Abstract

   This document proposes a FEC scheme for single packet 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 25 April 2024.

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.

Moskvitin, et al.         Expires 25 April 2024                 [Page 1]
Internet-Draft                FEC for QUIC                  October 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Design Overview . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  FEC and Loss Recovery . . . . . . . . . . . . . . . . . . . .   4
   5.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Handshake Negotiation and Transport Parameter . . . . . .   5
     5.2.  Repair Symbol Frame . . . . . . . . . . . . . . . . . . .   5
     5.3.  Acknowledgement of recovered packets  . . . . . . . . . .   6
       5.3.1.  Alternative 1: New FEC ACK Frame  . . . . . . . . . .   6
       5.3.2.  Alternative 2: Extended ACK Frame . . . . . . . . . .   7
   6.  Loss Rate Calculation . . . . . . . . . . . . . . . . . . . .   7
   7.  Adaptive redundancy . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Consideration  . . . . . . . . . . . . . . . . . . .   8
     8.1.  DoS due to difficult symbols recoveries . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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 25 April 2024                 [Page 2]
Internet-Draft                FEC for QUIC                  October 2023

   This document defines extensions to the QUIC protocol to add the
   ability to protect single packets independently and make it able to
   recover from packet losses prior to retransmission using FEC.

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.  Design Overview

   In this document it’s proposed to protect whole QUIC packet,
   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.

Moskvitin, et al.         Expires 25 April 2024                 [Page 3]
Internet-Draft                FEC for QUIC                  October 2023

   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
   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 25 April 2024                 [Page 4]
Internet-Draft                FEC for QUIC                  October 2023

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.  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 3.

   FEC_REPAIR {
      Type (i) = TBD,
      FEC Version (i),
      Packet Number Length (2),
      Protected Packet Number (8..32),
      FEC Meta Data (..),
      Reserved (i) = 0,
      FEC Payload (..)
   }

                     Figure 3: 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.

   Packet Number Length: As defined in [QUICv1]

   Protected Packet Number: The corresponding source packet number that
   the FEC frame protects.  As defined in the packet number definition
   in [QUICv1].

Moskvitin, et al.         Expires 25 April 2024                 [Page 5]
Internet-Draft                FEC for QUIC                  October 2023

   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.

   Reserved: A variable-length integer reserved for future use.  Default
   value is 0.  FEC Payload: The bytes generated by FEC encoder for
   corresponding repair symbol.

5.3.  Acknowledgement of recovered packets

   In order to inform sender about what packets have been recovered,
   acknowledgement of recovered packets MUST be provided.  There are two
   alternatives to be consider:

5.3.1.  Alternative 1: New FEC ACK Frame

   A new frame is proposed.  Receiver SHOULD send FEC_ACK frame either
   after each recovery or with the first ACK frame after recovery.

               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),
                  FEC Restored Packet Number (i) ...
               }

                       Figure 4: 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 25 April 2024                 [Page 6]
Internet-Draft                FEC for QUIC                  October 2023

   This alternative doesn't modify the existing QUIC mechanisms and can
   be easily as a add-on to the current QUIC implementation.

5.3.2.  Alternative 2: Extended ACK Frame

   This alternative is to extend ACK Frame to include optional FEC
   recovery information as defined in Section 5.3.1.

6.  Loss Rate Calculation

   Using FEC recovery acknowledgement mechanism it’s possible to measure
   packet loss rate in network, considering the diagram as follow.

                   +-----------------------+
                   |Sent packets           |
                   | +-----------------+   |
                   | |Acked packets    |   |
                   | | +---------------+-+ |
                   | | | +----------+  | | |
                   | | | | FEC      |  | | |
                   | | | | acked    |  | | |
                   | | | | packets  |  | | |
                   | | | +----------+  | | |
                   | +-+---------------+ | |
                   |   |Protected packets| |
                   |   +-----------------+ |
                   +-----------------------+

    Figure 5: Relationship between acked and FEC acked protected packets

   It is suggested that FEC_ACK is a subset of ACK.  In another words,
   if some PN is FEC acked, then it’s also is acked.

   To avoid the retransmssion of repaired lost packets, the receiver
   SHOULD include the recovered packets as the received packets in the
   ACK frames.  When calculating the loss rate, the recovered packets
   SHOULD be considered as the lost packets as well.

7.  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.

Moskvitin, et al.         Expires 25 April 2024                 [Page 7]
Internet-Draft                FEC for QUIC                  October 2023

       Success ▲
       rate,%  │
            100│_____.....................................
               │     ─────____
               │              ──__
               │                  ──
               │                    ──
               │                      ─_
               │                        _
               │                         _
               │                          ─__
               │                             -___
             ──┼─────────────────────────────────|───────►
              0│                                100%  Packet
                                                      loss
                                                      rate,%

       Figure 6: Example of performance profile of a given FEC scheme

8.  Security Consideration

   The FEC mechanism for QUIC only runs under 0-RTT and 1-RTT encryption
   levels and only operates inside the encrypted payload.

8.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.

9.  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 Repair |{{fecrepair}} |
       +----------+-----------+--------------+
       |TBD       |FEC Ack    |{{alternative1}}|
       +----------+-----------+--------------+

                        Figure 7: List of new frames

Moskvitin, et al.         Expires 25 April 2024                 [Page 8]
Internet-Draft                FEC for QUIC                  October 2023

10.  References

10.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, <https://www.rfc-editor.org/rfc/rfc9002>.

   [QUICv1]   Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [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/rfc/rfc2119>.

   [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/rfc/rfc2119>.

   [rfc8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9265>.

10.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-00, 21 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-michel-quic-
              fec-00>.

Moskvitin, et al.         Expires 25 April 2024                 [Page 9]
Internet-Draft                FEC for QUIC                  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, <https://datatracker.ietf.org/doc/html/
              draft-roca-nwcrg-rlc-fec-scheme-for-quic-03>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-
              coding-for-quic-04>.

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
   Email: luohanlin2@huawei.com

   Qichang Chen
   Huawei
   Email: chenqichang1@huawei.com

Moskvitin, et al.         Expires 25 April 2024                [Page 10]