IRTF Network Coding Research Group (NWCRG) V. Roca
Internet-Draft INRIA
Intended status: Informational May 20, 2016
Expires: November 21, 2016

FECFRAMEv2: Adding Sliding Encoding Window Capabilities to the FEC Framework: Problem Position


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

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 November 21, 2016.

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

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:

Systematic Code:

Input Symbol:

Output Symbol:

Application Data Unit (ADU):

ADU Information (ADUI):

Source Symbol:

Repair Symbol:

FEC Source Packet:

FEC Repair Packet:

(Source) ADU Flow:

FEC Source Packet Flow:

FEC Repair Packet Flow:

FEC Framework Configuration Information (FFCI):

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:

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:

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:

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:

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:

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)
+----------------------+                           +----------------+
|   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
|   Transport Layer    | 
|     (e.g., UDP)      |

Figure 1: Architecture of FECFRAMEv2 in sliding encoding window mode, at a sender/coding node.

Figure 1 (adapted from [RFC6865]) illustrates the general architecture of FECFRAMEv2 when working in sliding encoding window mode. The difference with respect to the [RFC6363] architecture lies in steps 2 to 6. Instead of creating a source block, composed of a certain number of ADUs plus their associated flow/length/padding information (see for instance [RFC6865]), FECFRAMEv2 in sliding encoding window mode continuously updates this window (step 2) and communicates the set of symbols to the FEC Scheme (step 3). This latter then returns the Explicit Source FEC Payload ID(s) (step 4) so that the new symbol(s) can be sent immediately. When FECFRAMEv2 needs to send one or several FEC repair packets (this is determined by the desired target code rate), it asks the FEC Scheme to create one or several repair symbols (step 5) along with their Repair FEC Payload ID (step 6). The associated FEC Repair Packets are then sent (steps 7 and 8).

When FECFRAMEv2 works with a block FEC Scheme, Figure 2 and Figure 3 of [RFC6363] remain valid, without any change.

5.2. ADU(I) to source symbol mapping

Let us now detail the ADU to source symbol mapping. As in FECFRAME, each ADU is first prepended with its {flow ID, length} information (respectively the F and L fields of Figure 2) and potentially zero padded to align to a multiple of the target symbol length ("0 padding" field of Figure 2). This augmented ADU is called ADUI.

ADUIs are then mapped to source symbols. Since incoming ADUs can have largely varying sizes, it makes sense to use a symbol size significantly lower than the PMTU (as in [MBMS], section which means that large ADUIs will be segmented into several source symbols while small ADUIs may fit into a single or low number of symbols. This has the advantage of limiting transmission overhead if at the same time the FEC Scheme enables the transmission of several repair symbols in the same FEC Repair Packet. However one may also choose to associate a symbol size equal to the maximum ADUI size of the current block, in case of a block FEC Scheme, as in [RFC6816] or [RFC6865], in order to always have a one-to-one mapping between ADUIs and source symbols.

The block versus sliding window mode does have an impact on the strategy chosen. More precisely:

In any case it is recommended that the symbol size be small enough with respect to the PMTU.

FEC code related considerations can impact the choice of a symbol size (assuming they are of fixed size). This is out of the scope of this document.

Figure 2 illustrates the creation of the ADUIs from incoming ADUs and the mapping to source symbols in case of small, fixed size symbols.

     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

Figure 2: ADUI and source symbols, case of small symbol sizes, for either FECFRAME or FECFRAMEv2.

5.3. Sliding encoding window management

Let us now detail the sliding window update process at a sender. Two kinds of limitations exist that impact the sliding window management:

  • at the FEC Scheme level: this latter can have internal or practical limitations (e.g., for complexity reasons) that limit the number of source symbols in the encoding window;
  • at the FECFRAMEv2 instance level: the source flows can have real-time constraints that limit the number of source symbols in the encoding window;

The most stringent limitation defines the maximum window size in terms of either number of source symbols or number of ADUs (depending on the relationship between them, see Section 5.2, they can be equal or not).

Source symbols are added to the sliding encoding window as ADUs arrive.

Source symbols (and the corresponding ADUs) are removed from the sliding encoding window:

  • after a certain delay, for situations where the sliding encoding window is managed on a time basis. The motivation is that an old ADU of a real-time flow becomes useless after a certain delay. The ADU retention delay in the sliding encoding window is therefore initialized according to the real-time features of incoming flow(s);
  • once the sliding encoding window has reached its maximum size, when there is an upper limit to the sliding encoding window size;
  • when the sliding encoding window is of fixed size, the oldest symbol is removed each time a new symbol is added;
  • if the sender knows that a particular ADU has been correctly received by the receiver(s), the corresponding source symbol(s) is(are) removed. Of course this mechanism requires that an acknowledgement mechanism be setup to inform the FECFRAMEv2 sender of good ADU reception, which is out of the scope of FECFRAMEv2.

5.4. Encoding Symbol Identifiers (ESI)

Any **source** symbol of a flow MUST be uniquely identified during the full duration where this symbol is useful.

Depending on the FEC Scheme being used, a **repair** symbol of a flow may or not need to be uniquely identified during the full duration where this symbol is useful. For instance, being able to identify a repair symbol is OPTIONAL with Random Linear Codes (RLC) since the coding window content and associated coding vector are communicated in the Repair FEC Payload ID and nothing else is needed to process this repair symbol. But being able to identify a repair symbol is REQUIRED with FEC Schemes that use this symbol identifier during the encoding and decoding processes (this is the case for instance with any block FEC code and some of the convolutional FEC codes).

In block mode, the encoding symbols are uniquely identified both by their Source Block Number (SBN) and Encoding Symbol ID (ESI), the first k ESI values identifying source symbols and the remaining n-k ESI values the repair symbols [RFC5052]. In sliding encoding window mode, the situation is totally different:

  • since there is no block, there is no SBN;
  • since there is no block, the ESI space that identifies source symbols is linear, each source symbol having an ESI that is 1 greater than the previous source symbol, except when a wrap-around to zero occurs after reaching the maximum ESI value permitted by the ESI field size (see below);
  • an ESI space dedicated to repair symbols is used when the FEC Scheme requires repair symbols to be identified. This ESI space is logically different from the ESI space used for source symbols. Therefore the same ESI value identifies different symbols depending on whether we are considering a FEC source packet or FEC repair packet. This is the context (e.g., the transport identifiers like the destination UDP port number) that enables a FECFRAME receiver to distinguish between source and repair symbols, not the ESI value;

Since the ESI space is limited by the header/trailer ESI field size to b bits (as specified by the FEC Scheme), wrap-around to zero is unavoidable with long FECFRAMEv2 sessions. This has two consequences:

  • the maximum sliding encoding window size MUST be smaller than 2^^b, and in practice be significantly smaller;
  • if the network may significantly delay packets, there is a risk of confusion if an ESI wrap-around takes place in the meantime, since the delayed symbol may be misinterpreted as a fresh symbol. A security margin is therefore needed that consists in having a "b" value sufficiently large to avoid such confusions. What security margin to consider is a deployment decision that also depends on the various flow transmission bitrates. Note that a timestamp information carried in FEC Source Packets may help identifying delayed packets. However this is not a generic mechanism since ADU flows are not required to use RTP framing.

5.5. Block and convolutional co-existence in a given FECFRAMEv2 session

When two (or more) FEC Repair Packet Flows are used in a given FECFRAME session, it is possible to have both a block FEC Scheme on one flow and a convolutional FEC Scheme on the other flow, both of them protecting the same ADU flow(s). This can be useful in order to preserve backward compatibility, legacy receivers joining the FEC Repair Packet Flow corresponding to the block FEC Scheme and ignoring the other flow.

The SDP description associated to this FECFRAMEv2 session indicates if a FEC Repair Packet flow works in block mode or sliding encoding window mode. This is done through the FEC Encoding ID communicated via the "a=fec-repair-flow: encoding-id=0; ..." attribute [RFC6364] (or "a=FEC-declaration:VALUE encoding-id=VALUE" attribute in case of [MBMS]). Then, from this FEC Encoding ID, the FECFRAME receiver can easily deduce if the FEC Scheme corresponds to a block or a convolutional FEC code.

6. Security Considerations

Adding the new sliding window mode to FECFRAMEv2 (what this document is about) in addition to the block mode of FECFRAME, while keeping the end-to-end approach of FECFRAME, does not fundamentally change the situation from a security point of view. Therefore all the security considerations detailed in [RFC6363] also apply to FECFRAMEv2. More precisely:

  • the problem statement, section 9.1 of [RFC6363];
  • the attacks against the data flows, section 9.2 of [RFC6363];
  • the attacks against the FEC parameters, section 9.3 of [RFC6363];
  • the discussion related to the FEC protection of several source flows, section 9.4 of [RFC6363];
  • and the baseline secure FEC Framework operation, section 9.5 of [RFC6363];

all apply to FECFRAMEv2, regardless of whether it follows a block or sliding window mode. Security considerations specific to a FEC Scheme, if any, will have to be discussed in the associated FEC Scheme document.

7. Privacy Considerations

Adding the new sliding window mode to FECFRAMEv2 (what this document is about), in addition to the block mode of FECFRAME, does not change the situation from a privacy point of view. Those considerations will be discussed in an update of [RFC6363].

8. IANA Considerations


9. Acknowledgments

The author wants to thank Morten V. Pedersen for his comments to this document.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003.
[RFC5052] Watson, M., Luby, M. and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007.
[RFC6363] Watson, M., Begen, A. and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011.
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, DOI 10.17487/RFC6364, October 2011.

10.2. Informative References

[fecframe-charter] FECFRAME WG, IETF., "FEC Framework (fecframe) charter", URL:, March 2013.
[MBMS] 3rd Generation Partnership Project (3GPP) SA4 Working Group, , "Multimedia Broadcast/Multicast Service (MBMS): Protocols and codecs", 3GPP TS 26.346, March 2016.
[nc-taxonomy-id] Firoiu, V., Adamson, B., Roca, V., Adjih, C., Bilbao, J., Fitzek, F., Masucci, A. and M. Montpetit, "Network Coding Taxonomy", Internet-Draft draft-irtf-nwcrg-network-coding-taxonomy-00, November 2014.
[RFC5740] Adamson, B., Bormann, C., Handley, M. and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009.
[RFC5775] Luby, M., Watson, M. and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010.
[RFC6681] Watson, M., Stockhammer, T. and M. Luby, "Raptor Forward Error Correction (FEC) Schemes for FECFRAME", RFC 6681, DOI 10.17487/RFC6681, August 2012.
[RFC6816] Roca, V., Cunche, M. and J. Lacan, "Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6816, DOI 10.17487/RFC6816, December 2012.
[RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A. and K. Matsuzono, "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6865, DOI 10.17487/RFC6865, February 2013.

Author's Address

Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex, 38334 France EMail: URI: