FEC Extension for QUIC

Introduction This document specifies an extension to QUIC version 1 to supports Forward Error Correction (FEC). FEC is a method of erasure control in data transmission by simultaneously sending redundant data (see ). This redundancy allows the receiver to detect and recover limited lost data without waiting for retransmission, which can be beneficial in latency-sensitive scenarios. For instance, real-time communication frameworks like WebRTC, which is widely applied in scenarios such as video conferenceing and voice call. FEC plays an important role by recovering lost packets under unreliable network, thereby optimizing user experience. QUIC-FEC might become a crucial foundation for MoQ (Media over QUIC), which is primarily used for video stream transmission, which can migrate the impact of packet loss on media transmission. This document defines how FEC framework take effects in QUIC transport process. Since FEC extension introduce new QUIC frames and parameters, it requires negotiation between two endpoints. This document does not define how the flows to be protected are determined, nor does it defines how the redundant data are calculated via FEC schemes. This document also defines an optional Repair ACK frame (see ) through which the receiver can notify the sender of source packets successfully recovered via FEC decoding. This allows the sender to suppress unnecessary retransmissions, thereby avoiding bandwidth waste, while ensuring that the notification does not interfere with congestion control or RTT estimation.

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 when, and only when, they appear in all capitals, as shown here. We assume that the reader is familiar with the terminology used in . In addition, we introduce the following FEC-related terms:

Source symbol: piece of information exchanged by two endpoints. This document considers QUIC packets payloads as source symbols.
Repair symbol: redundant information constructed from the combination of several source symbols.
Erasure: loss of one or more symbols
Erasure correction code: algorithm generating repair symbols and reconstructing missing source symbols from a set of source and repair symbols.
Forward Erasure Correction: process of recovering erased symbols before the detection of their erasure.
FEC scheme: the conjunction of an erasure correction code and the specific protocol elements required to use it with the design described in this document.
Encoder: entity producing repair symbols using an erasure correction code. The encoder can be a library used by the protocol implementation or a program running in a separate process or machine.
Decoder: entity reconstructing missing source symbols using an erasure correction code. The decoder can be a library used by the protocol implementation or a program running in a separate process or machine.
Coding window: window of source symbols that are required to decode a repair symbol.

Architecture Overview FEC Framework is designed as a module within QUIC-Transport layer. The primary target of current draft is to establish common mechanism for integrating FEC logic into the QUIC protocol, thus ensuring interoperability across different QUIC instances. Endpoints use transport parameters in to negotiate whether to enable the FEC mechanism. The FEC Framework specifies necessary configuration information that needs to be exchanged between QUIC endpoints using transport parameters during the QUIC handshake process. The FEC Framework operates within the QUIC-Transport layer. It facilitates the transmission of FEC information and redundant data using QUIC frames. The FEC framework calls upon the FEC scheme to manage the detailed processes of FEC encoding and decoding. The FEC scheme defines detailed algorithm process, and the procedures used to identidy packet payload data in the context of FEC scheme. This draft will describe the interface specification between FEC Framework and FEC scheme. FEC Framework MUST ensure compatibility with existing modules within the QUIC protocol. Special attention is given to ensuring interoperability with the congestion control and the ACK handling and retransmission decisions (see and ).

Handshake Negotiation and Transport Parameter

Transport Parameter This extension defines several new transport parameters used to negotiate the use of the FEC extension and specific FEC schemes during the connection handshake (see ). The new transport parameters are defined as follows:

fec_encode_schemes (current version uses 0xfece01): A list of variable-length integers specifying the FEC schemes supported by endpoints for encoding. The presence of this transport parameter indicates whether FEC functionality is enabled for encoding.
fec_decode_schemes (current version uses 0xfecd02): A list of variable-length integers defining the FEC schemes supported by endpoints for decoding. The content of this transport parameter determines which FEC scheme is used for decoding.

introduce the transport parameter format of fec_encode_schemes and fec_decode_schemes:

Transport Parameter for FEC

fec_max_symbol_num (current version uses 0xfecb02): A variable-length integer indicating the block size (i.e., the number of symbols in each encoding group) used in block encoding. This is an optional transport parameter and SHOULD be sent only when an endpoint uses block code schemes for encoding. For coding methods such as convolutional codes that do not require a fixed block size, this parameter SHOULD NOT be included.

For a single endpoint, FEC encoding and decoding are independent processes. By negotiating these separately, the framework can support distinct FEC schemes for encoding and decoding, or enable unidirectional encoding/decoding only. This flexibility allows FEC operations to adapt to diverse requirements and configurations. To ensure interoperability of FEC negotiation across QUIC protocol stacks, FEC schemes MUST use standardized identifiers registered with IANA (Internet Assigned Numbers Authority). This standardization guarantees seamless communication and compatibility between implementations. During negotiation, if a receiver's encoder scheme matches any of the sender's encoder schemes, the negotiation for that direction is considered successful.

Handshake Negotiation Endpoints negotiate the transport parameters for FEC during the connection handshake, as outlined in Section 3.1. illustrates an example of the negotiation process:

Handshake negotiation for FEC fec_encode_schemes={REED_SOLOMON,XOR} fec_decode_schemes={XOR} fec_max_symbol_num=10 <------------------------------------ fec_encode_schemes={XOR} fec_decode_schemes={REED_SOLOMON} fec_max_symbol_num=5 ]]> Please note that in the actual process, the Client first declare the list of encoder/decoder algorithms it can handle. When the server receive the fec_encode_schemes and fec_decode_schemes, it chooses one proper scheme for each direction, and set fec_decode_schemes and fec_encode_schemes params as corresponding scheme for decoding and encoding. Note that if the client wants to specify the FEC algorithm, it can provide only one FEC algorithm for fec negotiation process, the server could choose to support or not; otherwise, the algorithm selection SHOULD be based on the server's priority. For example, if the client's FEC schemes parameter is set as follows:

fec_encode_schemes {Algorithm1, Algorithm2, Algorithm3, ...}
fec_decode_schemes {Algorithm1, Algorithm2, Algorithm3, ...}

The encoder/decoder algorithm used in practice is chosen and returned by the Server:

supported_fec_encode_schemes {Algorithm1}
supported_fec_decode_schemes {Algorithm3}

Note that the encoding/decoding option and the selected algorithm may differ after negotiation.

Transport mechanism The FEC module directly participates in and influences the sending and receiving stages of packet transmission: As the sender, the FEC Framework takes the original data frame as source symbols and provides the required source symbols to the FEC scheme module. The FEC scheme can encode the data grouped by streams, or mixed data from different streams. FEC Framework retrieves the following information from the FEC scheme:

Source Symbol ID (SID) frame: SID frame is viewed as an unique identification for source symbol, which is composed of block ID and symbol index typically.
Repair packets: When the incoming source symbols meets the encoding conditions, the FEC scheme could generate original source symbol with repair packets. Repair packet contains FEC Payload ID, repair symbol, and optional repair key.

At the sender, FEC Framework is required to acquire and insert the SID frame into the packet that includes the source symbols. Subsequently, FEC Framework SHOULD generate and transmit repair packets to the receiver after processing a sufficient number of source symbols. Generally, the repair packets SHOULD be sent immediately following the source packets from the same block. As the receiver, the source packets can be normally parsed by ignoring SID frame, but it might be necessary to store source symbols and identifications to perform FEC decoding after receiving repair packets from the same block.

Work Flow for FEC

Sender Operation ### Define FEC-protected QUIC payload Endpoints can decide which types of data require FEC protection. As applying equal protection to all data types may result in inefficient bandwidth utilization, it is RECOMMENDED that protocol implementations selectively prioritize protection for critical data, such as restricting FEC to stream frames and datagram frames. For retransmitted frames or non-time-sensitive data, FEC SHOULD NOT be applied.

Identify source symbols using SID frame In the context of packets that require protection through FEC (Forward Error Correction), it is necessary to define a SID (Source Identifier) frame that conveys the identity information of the data. This is intended to help the receiver clarify the following information during the decoding process:

Which part of data insides the packet will be taken part in the FEC decode process.
Which block and the index inside the block the source symbol belongs to.

Therefore, it's recommended to append the SID frame after the fec-protected QUIC packet data to indicate that the data preceding this frame is identified by the current SID frame and is involved in the decoding process at the receiver. Based on the above reason, generating and inserting the SID frame SHOULD occur before the encryption process of packets. As the FEC module requires an additional data frame to be appended after the protected packet, developers MUST consider reserving space for the FEC data frames within the packet. This ensures that the length of the packet does not exceed the MTU (Maximum Transmission Unit) limit. Additionally, the SID MUST include Explicit Source Payload ID information to facilitate the resolution of the current data's identity, as shown in Figure 6.

Generate and send repair symbols The encoding content of the Repair package originates from the original data identified by the SID frame. It requires encoding the identity information of the FEC for the receiver to recognize the protection object of the current Repair package, as shown in Figure 6. The specific encoding process is carried out by the FEC scheme module, which typically requires the sender to pre-set the following parameters:

Block size: How many original packets are involved in the calculation for a computing unit, which directly affects the frequency of Repair symbol generation.
Redundancy level of FEC: How many redundant packets can be generated from the block.
Repair key (optional): The encoding key required by the FEC scheme module, which usually needs to be included in the Repair package for the receiver to use for decoding.

Receiver Operation

Process recovered symbols In the FEC module, the block triggering the decoding module generally needs to satisfy the following conditions:

The block receives a sufficient number of source symbols;
The block receive at least one repair symbol.

However, the specific required amounts of source symbols and repair symbols SHOULD be determined by the FEC schemes module.

FEC Frame Types FEC will introduce three new frames into QUIC protocol: the Source Symbol ID (SID) frame, which SHOULD be attached to the original packet; the Repair Symbol frame, which contains repair data and SHOULD be encapsulated and transmitted independently; and the optional Repair ACK frame, which allows the receiver to notify the sender of source packets that have been successfully recovered via FEC decoding.

Source Symbol ID Frame FEC SID FRAME contains the identification of the current source packet, which declares the encoding flow and the block current symbol is involved. SID Frame SHOULD be inserted after the fec-protected QUIC frame to indicate the range of FEC protected data. Since the maximum length of the repair symbol is equal to that of the source symbol, it is necessary to restrict the content length of the source packet to prevent the content length of the repair packet from exceeding the MTU limit. SRC_SYMBOL_ID Frame Structure:

SRC_SYMBOL_ID Frame

Flow ID (i): A variable-length integer that identifies which data stream the symbol belongs to.
Explicit Source Payload ID (SID): A variable-length integer that serves as a unique identifier for the source symbol. It MUST includes the block id and the symbol index of current source symbol. This can be formatted as follows.

Explicit Source Payload ID

Repair Symbol Frame In contrast to the SID Frame mentioned above, the Repair Frame SHOULD include not only the identification but also the encoded content of the source symbols. Repair symbol frame SHOULD incorporate the following informations:

REPAIR_SYMBOL Frame

Repair ID(i): - Flow ID(i): A variable-length integer that identifies which data stream the symbol belongs to; - Explicit Repair Payload ID (4 bytes): A variable-length integer that serves as a unique identifier for the repair symbol. It MUST includes the block id and the symbol index of current repair symbol.
Repair Key (4 bytes): An optional key generated by fec scheme, and is used for FEC decoding.
Repair Symbol Payload: The content of repair symbol, whose length is typically aligns with the block's longest symbol. This can be formatted as Figure above.

Repair ACK Frame The Repair ACK frame is an OPTIONAL mechanism that allows the receiver to notify the sender which QUIC packets have been successfully received through FEC recovery. Its semantics mirror those of the standard QUIC ACK frame (see Section 19.3): the receiver acknowledges packet numbers using the same packet number space, but the acknowledgment is triggered by FEC decoding rather than direct network reception. When the sender receives a Repair ACK, it can determine that the data carried in those packets has been successfully delivered to the remote endpoint via FEC recovery, and therefore SHOULD suppress any pending retransmissions for those packets, avoiding bandwidth waste. Support for sending and processing Repair ACK frames is OPTIONAL. An endpoint that does not implement Repair ACK MUST silently ignore received Repair ACK frames.

Distinction from Standard ACK Although the Repair ACK frame conveys the same packet number information as a standard ACK frame, it MUST be treated differently by the sender:

An endpoint MUST NOT use a Repair ACK frame to update RTT estimates or to trigger loss detection. RTT estimation and loss recovery MUST rely solely on standard QUIC ACK frames as specified in .
An endpoint MUST NOT update its congestion window or pacing rate upon receiving a Repair ACK frame. A recovered packet was never successfully received by the network in the normal sense, so its timing carries no meaningful congestion signal.
The sender MUST NOT remove packets from its loss detection state solely based on a Repair ACK. Instead, it SHOULD only cancel scheduled retransmissions for those packets.

The separate frame type (0xfec7) ensures that existing QUIC implementations and congestion control modules can unambiguously distinguish Repair ACK from standard ACK.

Repair ACK Frame Structure The Repair ACK frame follows the same range-encoding structure as the standard QUIC ACK frame, but omits the ACK Delay field (which is used for RTT calculation and is not applicable here) and the ECN Counts field.

REPAIR_ACK Frame

Largest Acknowledged (i): A variable-length integer representing the largest packet number among the packets recovered via FEC and being acknowledged in this frame. The semantics are identical to the Largest Acknowledged field in a standard ACK frame.
ACK Range Count (i): A variable-length integer specifying the number of ACK Range fields that follow.
First ACK Range (i): A variable-length integer indicating the number of contiguous packets recovered, counting down from Largest Acknowledged (inclusive). A value of zero means only the packet with number Largest Acknowledged was recovered.
ACK Range: Each entry describes a contiguous range of recovered packet numbers preceded by a gap of unacknowledged packet numbers:
- Gap (i): The number of unacknowledged packets between the end of the previous acknowledged range and the start of this one, minus one.
- ACK Range Length (i): The number of contiguous packets recovered in this range, minus one.

Sender Behavior upon Receiving Repair ACK Upon receiving a Repair ACK frame, the sender SHOULD:

Identify the QUIC packets whose packet numbers are covered by the acknowledged ranges.
Cancel any pending retransmission scheduled for those packets.
Not alter the congestion control state, RTT estimates, or loss detection timers as a result of processing the Repair ACK.

If a packet number acknowledged by a Repair ACK has already been acknowledged by a standard QUIC ACK frame, the Repair ACK SHOULD be silently ignored for that packet number.

Operation & Management Consideration The QUIC-FEC protocol are expected to be a universal solution against packet loss. When implemented, the QUIC packets will be finally divided into different FEC blocks according to the stream size or fixed size. Since that, the FEC Framework only needs to focus on whether the symbols within the block satisfy the encoding/decoding conditions, regardless of the upper layer protocols. It's important for FEC Framework to determine how to group QUIC packets into blocks, which needs to consider the optimisation effects at the application layer and the FEC scheme support. For example, dividing data into fixed-size blocks is a more convenient approach and allows better control over the packet repair rate. However, this may result in some repair packets arriving too late for the source packets to be protected, just as for source packet 4 belows, repair packet of packet 4 will not be send until stream 2 finish the sending:

FIXED BLOCK Implementation Steps | FEC <--------> FEC | | Framework | | Scheme | +-----|-----+ +-----------+ | v +----------+ +----------+ +----------+ +----------+ Block 1 | Source | | Source | | Source | | Repair | | packet 1 | | packet 2 | | packet 3 | | packet 1 | +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ Block 2 | Source | | Source | | Source | | Repair | | packet 4 | | packet 1 | | packet 2 | | packet 2 | +----------+ +----------+ +----------+ +----------+ ]]> Dividing the block according to the QUIC Stream can avoid the problem of long time difference between the generation of repair packets and the arrival of protected packets. But not all the fec schemes supports variable-length block codecs. It requires the fec scheme to carry the block size information with the FEC frame. For instance, certain algorithms employ a repair key field to specify the number of packets and their indices within a block, enabling the receiver to determine when decoding is possible. Without this information, the receiver cannot support encoding schemes with flexible block sizes.

FLEXIBLE BLOCK Implementation Steps | FEC <--------> FEC | | Framework | | Scheme | +-----|-----+ +-----------+ | v +----------+ +----------+ +----------+ +----------+ +----------+ Block 1 | Source | | Source | | Source | | Source | | Repair | | packet 1 | | packet 2 | | packet 3 | | packet 4 | | packet 1 | +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ Block 2 | Source | | Source | | Repair | | packet 1 | | packet 2 | | packet 2 | +----------+ +----------+ +----------+ ]]> In short, the FEC scheme determines which block partitioning method can be chosen, and the application layer optimization effect determines which partitioning method should be chosen. And the specific codec flow and repair key design should be decided by the fec scheme. The both steps can be applied to most application layer requests based on the QUIC protocol, and it's been proven to work with the HTTP/3 and MoQ protocols as the above steps. However, FEC should not protect all application layer data without discrimination in the QUIC connection. In order to reduce the bandwidth overhead, the FEC module should provide the upper layers with an interface to switch off the FEC module at the Stream level. It did make differences on when and how to switch off FEC among different application layer. We offers an abstract steps as an example here:

CLOSE FEC Implementation Steps QUIC_Packet { | ...Frames, | CLOSE_FEC_FRAME{stream_id} | } | parse close_fec_frame from packet | v stream_state.enable_fec = false ]]>

Security Consideration TBD

IANA Considerations This document defines three new transport parameters for the negotiation of enable fec for QUIC, and three new frame types.

New transport parameters The following entry in should be added to the "QUIC Transport Parameters" registry under the "QUIC Protocol" heading. Addition to QUIC Transport Parameters Entries

Parameter ID	Parameter name	Specification
0xfece01	fec_encode_schemes
0xfecd02	fec_decode_schemes
0xfecb02	fec_max_symbol_num

New frames The following frame types defined in should be added to the "QUIC Frame Types" registry under the "QUIC Protocol" heading. Addition to QUIC Frame Types Entries

Frame ID	Frame name	Specification
0xfec5	SID Frame
0xfec6	Repair Frame
0xfec7	Repair ACK Frame

Acknowledgments The specification has been materially improved through technical discussions with Ian Swett. Thanks to his recommendations with the draft and FEC mechanism.