Forward Erasure Correction for Short-Message Delay-Sensitive QUIC Connections

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

Table of Contents

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

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

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

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

5. Protocol Extensions

QUIC protocol extensions are specified in this sectioin.¶

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 (..)
}

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

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

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

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

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

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}}|
    +----------+-----------+--------------+

Authors' Addresses