FECFRAMEv2: Adding Sliding Encoding Window Capabilities to the FEC Framework: Problem Position
draft-roca-nwcrg-fecframev2-problem-position-03

Abstract

The Forward Error Correction (FEC) Framework (or FECFRAME) (RFC 6363) has been defined by the FECFRAME IETF WG to enable the use of FEC Encoding with real-time flows in a flexible manner. The original FECFRAME specification only considers the use of block FEC codes, wherein the input flow(s) is(are) segmented into a sequence of blocks and FEC encoding performed independently on a per-block basis. This document discusses an extension of FECFRAME in order to enable a sliding (potentially elastic) window encoding of the input flow(s), using convolutional FEC codes for the erasure channel, as an alternative to block FEC codes.

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 May 18, 2017.

Copyright Notice

Copyright (c) 2016 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. Notations, Definitions and Abbreviations
• 2.1. Requirements Notation
• 2.2. Definitions
• 3. Key features of FECFRAME
• 3.1. FECFRAME is more a shim layer than a protocol instantiation
• 3.2. FECFRAME is highly flexible
• 3.3. Details are in each FEC Scheme
• 3.4. FECFRAME needs session-level description
• 4. Application of FECFRAME (RFC 6363) to network coding use-cases: a discussion
• 4.1. Block versus convolutional codes
• 4.2. End-to-end versus in-network re-coding
• 4.3. Single versus multi-sources, intra versus inter-flows coding
• 4.4. Single versus multi-paths
• 5. Architectural considerations for FECFRAMEv2
• 5.1. FECFRAMEv2 in sliding encoding window mode
• 5.2. ADU(I) to source symbol mapping
• 5.3. Sliding encoding window management
• 5.4. Encoding Symbol Identifiers (ESI)
• 5.5. Block and convolutional co-existence in a given FECFRAMEv2 session
• 6. Security Considerations
• 7. Privacy Considerations
• 8. IANA Considerations
• 9. Acknowledgments
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Author's Address

1. Introduction

The Forward Error Correction (FEC) Framework (or FECFRAME) [RFC6363], produced by the FECFRAME IETF WG [fecframe-charter], 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. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in [RFC6363]. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol.

However, it is REQUIRED in [RFC6363] that the FEC scheme operate in a block manner, i.e., the input flow(s) MUST be segmented into a sequence of blocks, and FEC encoding (at a sender/coding node) and decoding (at a receiver/decoding node) MUST be performed independently on a per-block basis. This approach has a major impact on coding and decoding delays when used with block FEC codes (e.g., [RFC6681], [RFC6816] or [RFC6865]) since encoding requires that all the source symbols be known at the encoder. In case of continuous input flow(s), even if source symbols can be sent immediately, repair symbols are necessarily delayed by the block creation time, that directly depends on the block size (i.e., the number of source symbols in this block, k). This block creation time is also the minimum decoding latency any receiver will experience in case of erasures, since no repair symbol for the current block can be received before. A good value for the block size is necessarily a good balance between the minimum decoding latency at the receivers (which must be in line with the most stringent real-time requirement of the flow(s)) and the desired robustness in front of long erasure bursts (which depends on the block size).

On the opposite, a convolutional code associated to a sliding encoding window (of fixed size) or a sliding elastic encoding window (of variable size) removes this minimum decoding delay, since repair symbols can be generated and sent on-the-fly, at any time, from the source symbols present in the current encoding window. Using a sliding encoding window mode is therefore highly beneficial to real-time flows, one of the primary targets of FECFRAME.

The present document introduces the FECFRAME framework specificities, its limits, and options to extend it to sliding (optionally elastic) encoding windows and convolutional codes.

2. Notations, Definitions and Abbreviations

2.1. Requirements Notation

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

2.2. Definitions

This document uses the following definitions, that are mostly inspired from [RFC5052], [RFC6363] and [nc-taxonomy-id].

Packet Erasure Channel:

• a communication path where packets are either dropped (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

Systematic Code:

• code in which the Source Symbols are part of the Output Symbols

Input Symbol:

• a unit of data that is provided as an input to the coding process, in a given coding node. It may be a source symbol or an already encoded repair symbol if in-network re-coding is considered

Output Symbol:

• a unit of data that is produced as an output of the coding process, in a given coding node

Application Data Unit (ADU):

• The unit of source data provided as payload to the transport layer. Depending on the use-case, an ADU may use an RTP encapsulation.

ADU Information (ADUI):

• a unit of data constituted by the ADU and the associated Flow ID, Length and Padding fields (Section 5.2).

Source Symbol:

• an original unit of data, before any coding process is applied. Source symbols are the result of the fragmentation of ADUIs.

Repair Symbol:

• an Output Symbol that is not a Source Symbol.

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 Explicit Source FEC Payload ID (if present).

FEC Repair Packet:

• At a sender (respectively, at a receiver) a payload submitted to (respectively, received from) the transport protocol containing a repair symbol (or several repair symbols with certain FEC Schemes) along with a Repair FEC Payload ID (and possibly an RTP header in some cases).

(Source) 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}). Depending on the use-case, several ADU flows may be protected together by the FECFRAME framework.

FEC Source Packet Flow:

• A sequence of FEC Source Packets.

FEC Repair Packet Flow:

• A sequence of FEC Repair Packets.

FEC Framework Configuration Information (FFCI):

• Information which controls the operation of the FEC Framework. The FFCI enables the synchronization of the FECFRAME sender and receiver instances.

3. Key features of FECFRAME

3.1. FECFRAME is more a shim layer than a protocol instantiation

FECFRAME is not a full featured Protocol Instantiation (unlike ALC [RFC5775] and NORM [RFC5740] for instance). It is more a shim layer, or more precisely a framework for using FEC inside existing transport protocols. For instance when FECFRAME is used end-to-end inside a single RTP/UDP stream (the simplest use-case), RTP [RFC3550] and UDP are the transport protocols and FECFRAME is a functional component that performs FEC encoding/decoding and generates RTP compliant repair packets. Even if specific headers are defined for the associated FEC Scheme, FECFRAME is not a full featured transport protocol.

3.2. FECFRAME is highly flexible

FECFRAME is highly flexible in the way it can be used. In particular FECFRAME:

• can protect a single RTP flow [RFC3550], repair packets being themselves RTP packets, possibly multiplexed in the same UDP connection but using a different Payload Type (PT) to distinguish them from source packets. This is particularly useful if backward compatibility is mandatory: non-FECFRAME aware receivers simply drop packets with unknown PT. However this should be regarded as a particular case;
• can protect a single source flow that does NOT use RTP, where repair packets are NOT RTP packets either;
• can protect several source flows, from the same source or from several sources, some of them being RTP flows but not necessarily the other ones;
• can generate a single repair flow or multiple repair flows;
• can be used with any upper protocols (RTP or any other protocol) and transport protocols (e.g., UDP, DCCP) if this latter preserves datagram boundaries;
• can be used with unicast or multicast/broadcast transmissions;

3.3. Details are in each FEC Scheme

In the FECFRAME architecture, most technical details are in the FEC Scheme. In particular a FEC Scheme defines:

• FEC code specifications and associated FEC Encoding ID;
• the way source symbols are created from the data units coming from the application(s), called Application Data Units (ADU);
• signaling for FEC Source Packets (optional), called Source FEC Payload ID;
• signaling for FEC Repair Packets (mandatory), called Repair FEC Payload ID;

3.4. FECFRAME needs session-level description

FECFRAME works in conjunction with SDP (or a similar protocol) to specify high level per FECFRAME Instance (i.e., per-session) signaling [RFC6364]. This information, called FEC Framework Configuration Information [RFC6363], describes:

• the incoming flows (content description and flow identification);
• the outgoing flows, for source and repair packets;
• what FEC Scheme is used, identified via the FEC Encoding ID;
• and the FEC Scheme specific parameters.

In practice, the FEC Scheme is valid for the whole FECFRAME Instance duration, since no update mechanism has been defined to carry a new SDP session description reliably and in real-time to all the potential receivers. This is different from ALC or NORM where the FEC Scheme selection is made on a per-object manner (rather than per-session).

4. Application of FECFRAME (RFC 6363) to network coding use-cases: a discussion

The FECFRAME framework has a certain number of features and restrictions. We discuss each of them below, at the light of the use-cases identified for Network Coding.

4.1. Block versus convolutional codes

FECFRAME, as described in [RFC6363], MUST be associated to block FEC codes. For instance ([RFC6363], section 5.1) says:

• "1. Construction of a source block from ADUs. The FEC code will be applied to this source block to produce the repair payloads."

Therefore the input flow(s) is (resp. are) segmented into a sequence of blocks, FEC encoding being performed independently on a per-block basis.

However this is not a fundamental limitation, in the sense that the same FECFRAME architecture can be used with sliding (potentially elastic) encoding windows, associated with convolutional codes. To that purpose it is sufficient:

• to update [RFC6363] adding the support of sliding (potentially elastic) encoding windows along with the source block approach;
• to specify dedicated FEC Schemes, working with convolutional FEC codes for the erasure channel. All the details of the codes, the required signaling, the management of the sliding encoding window and creation of source symbols will be defined in these FEC Schemes.

4.2. End-to-end versus in-network re-coding

The FECFRAME architecture, as specified in [RFC6363], MUST feature a single encoding node and a single decoding node. These nodes may be the source and destination nodes, or may be middle-boxes, or any combination.

The question of having multiple in-network re-coding operations is not considered in [RFC6363]. The question whether this is feasible and appropriate, given the typical FECFRAME use-cases, is an open question that remains to be discussed.

4.3. Single versus multi-sources, intra versus inter-flows coding

FECFRAME, as specified in [RFC6363], can globally protect several flows that can originate either from a single source or from multiple sources. This also means that FECFRAME can perform both intra-flow coding or inter-flows coding. The only requirement is that those flows be identified and signaled to the FECFRAME encoder and decoder via the FEC Framework Configuration Information (e.g., it can be detailed in the SDP description).

From this point of view, FECFRAME is already in line with advanced network-coding use-cases.

4.4. Single versus multi-paths

FECFRAME, as specified in [RFC6363], does not specify nor restrict how the FEC Source Packet Flow(s) and FEC Repair Packet Flow(s) are to be transmitted: whether they go through the same path (e.g., when they are sent to the same UDP connection) or through multiple paths is irrelevant to FECFRAME since it is an operational and management aspect. However, it is anticipated that when several repair flows are generated, offering different protections levels (e.g., through different code-rates), these repair flows will often use different paths, to better accommodate receiver heterogeneity.

From this point of view, FECFRAME is already in line with advanced network-coding use-cases.

5. Architectural considerations for FECFRAMEv2

Several architectural considerations are now discussed for version 2 of FECFRAME. We assume hereafter that FECFRAMEv2 follows the initial spirit of FECFRAME, i.e., is only applied in end-to-end (see Section 4.2). From what follows we show that adding sliding encoding window support to FECFRAMEv2 is simple and can coexist with legacy FECFRAME flows. Extending FECFRAMEv2 to other situations, e.g., with in-network re-coding, is not considered in this document.

5.1. FECFRAMEv2 in sliding encoding window mode

+----------------------+
|     Application      |
+----------------------+
           |
           | (1) Application Data Units (ADUs)
           v 
+----------------------+                           +----------------+
|   FEC Framework v2   |                           |                |
|                      |-------------------------->|   FEC Scheme   |
|(2) Update of sliding | (3) Source Symbols of     |                |
|    encoding window   |     the sliding window    |                |
|                      |<--------------------------|                |
|                      | (4) Explicit Source       |                |
|(7) Construct FEC     |     FEC Payload ID(s)     |(5) FEC Encoding|
|    source and repair |<--------------------------|    (optional)  |
|    packet(s)         | (6) Repair FEC Payload ID |                |
+----------------------+     + Repair symbol(s)    +----------------+
           |
           | (8) FEC source packets and FEC repair packets
           v 
+----------------------+ 
|   Transport Layer    | 
|     (e.g., UDP)      |
+----------------------+ 

     Symbol Length             Symbol Length
<-----------------------><----------------------->
+----+----+-------------------------+------------+
|F[i]|L[i]|ADU[i]                   | 0 padding  | => symbols j, j+1
+----+----+-------+-----+-----------+------------+
|Fi+1|Li+1|ADUi+1 |  0  |                          => symbol j+2
+----+----+-------+---+-+
|Fi+2|Li+2|ADUi+2     |0|                          => symbols j+3
+----+----+-----------+-+------+-----------------+
|Fi+3|Li+3|ADUi+3              | 0 padding       | => symbols j+4, j+5
+----+----+--------------------+-----------------+