Forward Error Correction (FEC) Framework Extension to Convolutional Codes
draft-roca-tsvwg-fecframev2-03

Abstract

RFC 6363 describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However FECFRAME as per RFC 6363 is restricted to block FEC codes. The present document extends FECFRAME to support convolutional FEC Codes, based on a sliding encoding window, in addition to Block FEC Codes. This is done in a backward compatible way. During multicast/broadcast real-time content delivery, these codes significantly improve robustness in harsh environments, with less repair traffic and lower FEC-related added latency.

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 http://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 August 28, 2017.

Copyright Notice

Copyright (c) 2017 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.

Table of Contents

• 1. Introduction
• 2. Definitions and Abbreviations
• 3. Architecture Overview
• 4. Procedural Overview
• 4.1. General
• 4.2. Sender Operation with Convolutional FEC Codes
• 4.3. Receiver Operation with Convolutional FEC Codes
• 5. Protocol Specification
• 5.1. General
• 5.2. FEC Framework Configuration Information
• 5.3. FEC Scheme Requirements
• 6. Feedback
• 7. Transport Protocols
• 8. Congestion Control
• 9. Implementation Status
• 10. Security Considerations
• 11. Operations and Management Considerations
• 12. IANA Considerations
• 13. Acknowledgments
• 14. References
• 14.1. Normative References
• 14.2. Informative References
• Appendix A. About Sliding Encoding Window Management (non Normative)
• Authors' Addresses

1. Introduction

Many applications need to transport a continuous stream of packetized data from a source (sender) to one or more destinations (receivers) over networks that do not provide guaranteed packet delivery. In particular packets may be lost, which is strictly the focus of this document: we assume that transmitted packets are either received without any corruption or totally lost (e.g., because of a congested router, of a poor signal-to-noise ratio in a wireless network, or because the number of bit errors exceeds the correction capabilities of a low-layer error correcting code).

For these use-cases, Forward Error Correction (FEC) applied within the transport or application layer, is an efficient technique to improve packet transmission robustness in presence of packet losses (or "erasures"), without going through packet retransmissions that create a delay often incompatible with real-time constraints. The FEC Building Block defined in [RFC5052] provides a framework for the definition of Content Delivery Protocols (CDPs) that make use of separately defined FEC schemes. Any CDP defined according to the requirements of the FEC Building Block can then easily be used with any FEC scheme that is also defined according to the requirements of the FEC Building Block.

Then FECFRAME [RFC6363] provides a framework to define Content Delivery Protocols (CDPs) that provide FEC protection for arbitrary packet flows over unreliable transports such as UDP. It is primarily intended for real-time or streaming media applications, using broadcast, multicast, or on-demand delivery.

However [RFC6363] only considers block FEC schemes defined in accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], [RFC6816] or [RFC6865]). These codes require the input flow(s) to be segmented into a sequence of blocks. Then FEC encoding (at a sender or an encoding middlebox) and decoding (at a receiver or a decoding middlebox) are both performed on a per-block basis. This approach has major impacts on FEC encoding and decoding delays. The data packets of continuous media flow(s) can be sent immediately, without delay. But the block creation time, that depends on the number k of source symbols in this block, impacts the FEC encoding delay since encoding requires that all source symbols be known. This block creation time also impacts the decoding delay a receiver will experience in case of erasures, since no repair symbol for the current block can be received before. Therefore a good value for the block size is necessarily a balance between the maximum decoding latency at the receivers (which decreases with the block size and must be in line with the most stringent real-time requirement of the protected flow(s)), and the desired robustness against long loss bursts (which increases with the block size).

This document extends [RFC6363] in order to also support convolutional FEC codes based on a sliding encoding window. This encoding window, either of fixed or variable size, slides over the set of source symbols. FEC encoding is launched whenever needed, from the set of source symbols present in the sliding encoding window at that time. This approach significantly reduces FEC-related latency, since repair symbols can be generated and sent on-the-fly, at any time, and can be regularly received by receivers to quickly recover packet losses. Using convolutional FEC codes is therefore highly beneficial to real-time flows, one of the primary targets of FECFRAME.

[RLC-ID] provides an example of such FEC Scheme for FECFRAME, built from the well-known Random Linear Codes (RLC) convolutional FEC codes.

This document is fully backward compatible with [RFC6363] that it extends but does not replace. Indeed: [RFC6363] and re-uses its structure. It proposes new sections specific to convolutional FEC codes whenever required.

• this extension does not prevent nor compromize in any way the support of block FEC codes. Both types of codes can nicely co-exist, just like different FEC schemes can co-exist;
• any receiver, e.g., a legacy receiver that only supports block FEC schemes, can easily identify the FEC scheme used in a FECFRAME session thanks to the associated SDP file and its FEC Encoding ID information (i.e., the "encoding-id=" parameter of a "fec-repair-flow" attribute, [RFC6364]). This mechanism is not specific to this extension but is the basic approach for a FECFRAME receiver to determine whether or not it supports the FEC scheme used in a given FECFRAME session;

This document leverages on

2. Definitions and Abbreviations

The following list of definitions and abbreviations is copied from [RFC6363], adding only the Block/Convolutional FEC Code and Encoding/Decoding Window definitions:

Application Data Unit (ADU):

The unit of source data provided as payload to the transport layer.

ADU Flow:

A sequence of ADUs associated with a transport-layer flow identifier (such as the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}).

AL-FEC:

Application-layer Forward Error Correction.

Application Protocol:

Control protocol used to establish and control the source flow being protected, e.g., the Real-Time Streaming Protocol (RTSP).

Content Delivery Protocol (CDP):

A complete application protocol specification that, through the use of the framework defined in this document, is able to make use of FEC schemes to provide FEC capabilities.

FEC Code:

An algorithm for encoding data such that the encoded data flow is resilient to data loss. Note that, in general, FEC codes may also be used to make a data flow resilient to corruption, but that is not considered in this document.

Block FEC Code:

FEC Code that operate in a block manner, i.e., for which the input flow MUST be segmented into a sequence of blocks, FEC encoding and decoding being performed independently on a per-block basis.

Convolutional FEC Code:

FEC Code that can generate repair symbols on-the-fly, at any time, from the set of source symbols present in the sliding encoding window at that time.

FEC Framework:

A protocol framework for the definition of Content Delivery Protocols using FEC, such as the framework defined in this document.

FEC Framework Configuration Information:

Information that controls the operation of the FEC Framework.

FEC Payload ID:

Information that identifies the contents of a packet with respect to the FEC scheme.

FEC Repair Packet:

At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing one or more repair symbols along with a Repair FEC Payload ID and possibly an RTP header.

FEC Scheme:

A specification that defines the additional protocol aspects required to use a particular FEC code with the FEC Framework.

FEC Source Packet:

At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an optional Explicit Source FEC Payload ID.

Protection Amount:

The relative increase in data sent due to the use of FEC.

Repair Flow:

The packet flow carrying FEC data.

Repair FEC Payload ID:

A FEC Payload ID specifically for use with repair packets.

Source Flow:

The packet flow to which FEC protection is to be applied. A source flow consists of ADUs.

Source FEC Payload ID:

A FEC Payload ID specifically for use with source packets.

Source Protocol:

A protocol used for the source flow being protected, e.g., RTP.

Transport Protocol:

The protocol used for the transport of the source and repair flows, e.g., UDP and the Datagram Congestion Control Protocol (DCCP).

Encoding Window:

Set of Source Symbols available at the sender/coding node that are used to generate a repair symbol, with a Convolutional FEC Code.

Decoding Window:

Set of received or decoded source and repair symbols available at a receiver that are used to decode erased source symbols, with a Convolutional FEC Code.

Code Rate:

The ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that 0 < code rate <= 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process.

Encoding Symbol:

Unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols.

Packet Erasure Channel:

A communication path where packets are either lost (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical-layer codes) or received. When a packet is received, it is assumed that this packet is not corrupted.

Repair Symbol:

Encoding symbol that is not a source symbol.

Source Block:

Group of ADUs that are to be FEC protected as a single block. This notion is restricted to Block FEC Codes.

Source Symbol:

Unit of data used during the encoding process.

Systematic Code:

FEC code in which the source symbols are part of the encoding symbols.

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 [RFC2119].

3. Architecture Overview

The architecture of [RFC6363], Section 3, equally applies to this FECFRAME extension and is not repeated here.

4. Procedural Overview

4.1. General

The general considerations of [RFC6363], Section 4.1, that are specific to block FEC codes are not repeated here.

With a Convolutional FEC Code, the FEC source packet MUST contain information to identify the position occupied by the ADU within the source flow, in terms specific to the FEC scheme. This information is known as the Source FEC Payload ID, and the FEC scheme is responsible for defining and interpreting it.

With a Convolutional FEC Code, the FEC repair packets MUST contain information that identifies the relationship between the contained repair payloads and the original source symbols used during encoding. This information is known as the Repair FEC Payload ID, and the FEC scheme is responsible for defining and interpreting it.

To the Sender Operation ([RFC6363], Section 4.2.) and Receiver Operation ([RFC6363], Section 4.3), both specific to block FEC codes and therefore omitted below, the following two sections detail similar operations for convolutional FEC codes.

4.2. Sender Operation with Convolutional FEC Codes

With a convolutional FEC scheme, the following operations, illustrated in Figure 1 for the case of UDP repair flows, and in Figure 2 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:

1. A new ADU is provided by the application.
2. The FEC Framework communicates this ADU to the FEC scheme.
3. The sliding encoding window is updated by the FEC scheme. The ADU to source symbols mapping as well as the encoding window management details are both the responsibility of the FEC scheme. However Appendix A provide some hints on the way it might be performed.
4. The Source FEC Payload ID information of the source packet is determined by the FEC scheme. If required by the FEC scheme, the Source FEC Payload ID is encoded into the Explicit Source FEC Payload ID field and returned to the FEC Framework.
5. The FEC Framework constructs the FEC source packet according to [RFC6363] Figure 6, using the Explicit Source FEC Payload ID provided by the FEC scheme if applicable.
6. The FEC source packet is sent using normal transport-layer procedures. This packet is sent using the same ADU flow identification information as would have been used for the original source packet if the FEC Framework were not present (for example, in the UDP case, the UDP source and destination addresses and ports on the IP datagram carrying the source packet will be the same whether or not the FEC Framework is applied).
7. When the FEC Framework needs to send one or several FEC repair packets (e.g., according to the target Code Rate), it asks the FEC scheme to create one or several repair packet payloads from the current sliding encoding window along with their Repair FEC Payload ID.
8. The Repair FEC Payload IDs and repair packet payloads are provided back by the FEC scheme to the FEC Framework.
9. The FEC Framework constructs FEC repair packets according to [RFC6363] Figure 7, using the FEC Payload IDs and repair packet payloads provided by the FEC scheme.
10. The FEC repair packets are sent using normal transport-layer procedures. The port(s) and multicast group(s) to be used for FEC repair packets are defined in the FEC Framework Configuration Information.

+----------------------+
|     Application      |
+----------------------+
           |
           | (1) New Application Data Unit (ADU)
           v 
+---------------------+                           +----------------+
|    FEC Framework    |                           |   FEC Scheme   |
|                     |-------------------------->|                |
|                     | (2) New ADU               |(3) Update of   |
|                     |                           |    encoding    |
|                     |<--------------------------|    window      |
|(5) Construct FEC    | (4) Explicit Source       |                |
|    source packet    |     FEC Payload ID(s)     |(7) FEC         |
|                     |<--------------------------|    encoding    |
|(9) Construct FEC    | (8) Repair FEC Payload ID |                |
|    repair packet(s) |     + Repair symbol(s)    +----------------+
+---------------------+ 
           | 
           | (6)  FEC source packet 
           | (10) FEC repair packets
           v 
+----------------------+ 
|   Transport Layer    | 
|     (e.g., UDP)      |
+----------------------+ 

+----------------------+
|     Application      |
+----------------------+
           |
           | (1) New Application Data Unit (ADU)
           v 
+---------------------+                           +----------------+
|    FEC Framework    |                           |   FEC Scheme   |
|                     |-------------------------->|                |
|                     | (2) New ADU               |(3) Update of   |
|                     |                           |    encoding    |
|                     |<--------------------------|    window      |
|(5) Construct FEC    | (4) Explicit Source       |                |
|    source packet    |     FEC Payload ID(s)     |(7) FEC         |
|                     |<--------------------------|    encoding    |
|(9) Construct FEC    | (8) Repair FEC Payload ID |                |
|    repair packet(s) |     + Repair symbol(s)    +----------------+
+---------------------+
    |             |
    |(6) Source   |(10) Repair payloads
    |    packets  |
    |      + -- -- -- -- -+
    |      |     RTP      |
    |      +-- -- -- -- --+
    v             v                 
+----------------------+ 
|   Transport Layer    | 
|     (e.g., UDP)      |
+----------------------+ 

+----------------------+
|     Application      |
+----------------------+
           ^
           |(6) ADUs
           |
+----------------------+                           +----------------+
|    FEC Framework     |                           |   FEC Scheme   |
|                      |<--------------------------|                |
|(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding
|   IDs and pass IDs & |-------------------------->|                |
|   payloads to FEC    |(3) Explicit Source FEC    +----------------+
|   scheme             |            Payload IDs
+----------------------+    Repair FEC Payload IDs
           ^                Source payloads       
           |                Repair payloads
           |(1) FEC source
           |    and repair packets
+----------------------+ 
|   Transport Layer    | 
|     (e.g., UDP)      |
+----------------------+

+----------------------+
|     Application      |
+----------------------+
           ^
           |(6) ADUs
           |
+----------------------+                           +----------------+
|    FEC Framework     |                           |   FEC Scheme   |
|                      |<--------------------------|                |
|(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding|
|   IDs and pass IDs & |-------------------------->|                |
|   payloads to FEC    |(3) Explicit Source FEC    +----------------+
|   scheme             |            Payload IDs
+----------------------+    Repair FEC Payload IDs
    ^             ^         Source payloads
    |             |         Repair payloads
    |Source pkts  |Repair payloads
    |             |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing | 
|   | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux        | |
+-- -- -- -- -- -- -- -+ 
           ^
           |(1) FEC source and repair packets
           |         
+----------------------+ 
|   Transport Layer    | 
|     (e.g., UDP)      |
+----------------------+