draft-ietf-fecframe-simple-rs-02.txt   draft-ietf-fecframe-simple-rs-03.txt 
FecFrame V. Roca FecFrame V. Roca
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Standards Track M. Cunche Intended status: Standards Track M. Cunche
Expires: June 1, 2012 NICTA Expires: September 9, 2012 NICTA
J. Lacan J. Lacan
A. Bouabdallah A. Bouabdallah
ISAE/LAAS-CNRS ISAE/LAAS-CNRS
K. Matsuzono K. Matsuzono
Keio University Keio University
November 29, 2011 March 8, 2012
Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
draft-ietf-fecframe-simple-rs-02 draft-ietf-fecframe-simple-rs-03
Abstract Abstract
This document describes a fully-specified simple FEC scheme for Reed- This document describes a fully-specified simple FEC scheme for Reed-
Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to
protect arbitrary media streams along the lines defined by the protect arbitrary media streams along the lines defined by the
FECFRAME framework. Reed-Solomon codes belong to the class of FECFRAME framework. Reed-Solomon codes belong to the class of
Maximum Distance Separable (MDS) codes which means they offer optimal Maximum Distance Separable (MDS) codes which means they offer optimal
protection against packet erasures. They are also systematic codes, protection against packet erasures. They are also systematic codes,
which means that the source symbols are part of the encoding symbols. which means that the source symbols are part of the encoding symbols.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2012. This Internet-Draft will expire on September 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 14 skipping to change at page 4, line 14
1. Introduction 1. Introduction
The use of Forward Error Correction (FEC) codes is a classic solution The use of Forward Error Correction (FEC) codes is a classic solution
to improve the reliability of unicast, multicast and broadcast to improve the reliability of unicast, multicast and broadcast
Content Delivery Protocols (CDP) and applications. The [RFC6363] Content Delivery Protocols (CDP) and applications. The [RFC6363]
document describes a generic framework to use FEC schemes with media document describes a generic framework to use FEC schemes with media
delivery applications, and for instance with real-time streaming delivery applications, and for instance with real-time streaming
media applications based on the RTP real-time protocol. Similarly media applications based on the RTP real-time protocol. Similarly
the [RFC5052] document describes a generic framework to use FEC the [RFC5052] document describes a generic framework to use FEC
schemes with with objects (e.g., files) delivery applications based schemes with objects (e.g., files) delivery applications based on the
on the ALC [RFC5775] and NORM [RFC5740] reliable multicast transport ALC [RFC5775] and NORM [RFC5740] reliable multicast transport
protocols. protocols.
More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce
erasure codes based on sparse parity check matrices for object erasure codes based on sparse parity check matrices for object
delivery protocols like ALC and NORM. These codes are efficient in delivery protocols like ALC and NORM. These codes are efficient in
terms of processing but not optimal in terms of erasure recovery terms of processing but not optimal in terms of erasure recovery
capabilities when dealing with "small" objects. capabilities when dealing with "small" objects.
The Reed-Solomon FEC codes described in this document belong to the The Reed-Solomon FEC codes described in this document belong to the
class of Maximum Distance Separable (MDS) codes that are optimal in class of Maximum Distance Separable (MDS) codes that are optimal in
skipping to change at page 5, line 12 skipping to change at page 5, line 12
compatible with the FECFRAME framework [RFC6363]. Therefore this compatible with the FECFRAME framework [RFC6363]. Therefore this
document specifies only the information specific to the FECFRAME document specifies only the information specific to the FECFRAME
context and refers to [RFC5510] for the core specifications of the context and refers to [RFC5510] for the core specifications of the
codes. To that purpose, the present document introduces: codes. To that purpose, the present document introduces:
o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that
specifies a simple way of using of Reed-Solomon codes over specifies a simple way of using of Reed-Solomon codes over
GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for
arbitrary packet flows; arbitrary packet flows;
For instance, with this scheme, a set of Application Data Units (or For instance, with this scheme, a set of Application Data Units (or
ADUs) coming from one or several (resp. one) media delivery ADUs) coming from one or several media delivery applications (e.g., a
applications (e.g., a set of RTP packets), are grouped in an ADU set of RTP packets), are grouped in an ADU block and FEC encoded as a
block and FEC encoded as a whole. With Reed-Solomon codes over whole. With Reed-Solomon codes over GF(2^^8), there is a strict
GF(2^^8), there is a strict limit over the number of ADUs that can be limit over the number of ADUs that can be protected together, since
protected together, since the number of encoded symbols, n, must be the number of encoded symbols, n, must be inferior or equal to 255.
inferior or equal to 255. This constraint is relaxed when using a This constraint is relaxed when using a higher finite field size (m >
higher finite field size (m > 8), at the price of an increased 8), at the price of an increased computational complexity.
computational complexity.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Definitions Notations and Abbreviations 3. Definitions Notations and Abbreviations
3.1. Definitions 3.1. Definitions
skipping to change at page 6, line 35 skipping to change at page 6, line 35
the F[], L[], and Pad[] fields, they form the set of source the F[], L[], and Pad[] fields, they form the set of source
symbols over which FEC encoding will be performed. symbols over which FEC encoding will be performed.
ADU Information (ADUI): a unit of data constituted by the ADU and ADU Information (ADUI): a unit of data constituted by the ADU and
the associated Flow ID, Length and Padding fields (Section 4.3). the associated Flow ID, Length and Padding fields (Section 4.3).
This is the unit of data that is used as source symbol. This is the unit of data that is used as source symbol.
FEC Framework Configuration Information: Information which controls FEC Framework Configuration Information: Information which controls
the operation of the FEC Framework. The FFCI enables the the operation of the FEC Framework. The FFCI enables the
synchronization of the FECFRAME sender and receiver instances. synchronization of the FECFRAME sender and receiver instances.
FEC Source Packet: At a sender (respectively, at a receiver) a FEC Source Packet: At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the transport payload submitted to (respectively, received from) the transport
protocol containing an ADU along with an optional Explicit Source protocol containing an ADU along with an Explicit Source FEC
FEC Payload ID. Payload ID (that MUST be present in the FEC scheme defined by the
present document, see Section 5.1.2).
FEC Repair Packet: At a sender (respectively, at a receiver) a FEC Repair Packet: At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the transport payload submitted to (respectively, received from) the transport
protocol containing one repair symbol along with a Repair FEC protocol containing one repair symbol along with a Repair FEC
Payload ID and possibly an RTP header. Payload ID and possibly an RTP header.
The above terminology is illustrated in Figure 1 (sender's point of The above terminology is illustrated in Figure 1 (sender's point of
view): view):
+----------------------+ +----------------------+
| Application | | Application |
skipping to change at page 8, line 21 skipping to change at page 8, line 21
3.3. Abbreviations 3.3. Abbreviations
This document uses the following abbreviations: This document uses the following abbreviations:
ADU stands for Application Data Unit. ADU stands for Application Data Unit.
ESI stands for Encoding Symbol ID. ESI stands for Encoding Symbol ID.
FEC stands for Forward Error (or Erasure) Correction code. FEC stands for Forward Error (or Erasure) Correction code.
FFCI stands for FEC Framework Configuration Information. FFCI stands for FEC Framework Configuration Information.
FSSI stands for FEC Scheme Specific Information. FSSI stands for FEC Scheme Specific Information.
MDS stands for Maximum Distance Separable code. MDS stands for Maximum Distance Separable code.
SDP stands for Session Description Protocol.
4. Common Procedures Related to the ADU Block and Source Block Creation 4. Common Procedures Related to the ADU Block and Source Block Creation
This section introduces the procedures that are used during the ADU This section introduces the procedures that are used during the ADU
block and the related source block creation, for the FEC scheme block and the related source block creation, for the FEC scheme
considered. considered.
4.1. Restrictions 4.1. Restrictions
This specification has the following restrictions: This specification has the following restrictions:
skipping to change at page 9, line 18 skipping to change at page 9, line 20
k < n <= 255. Given the target FEC code rate (e.g., provided by the k < n <= 255. Given the target FEC code rate (e.g., provided by the
end-user or upper application when starting the FECFRAME framework, end-user or upper application when starting the FECFRAME framework,
and taking into account the known or estimated packet loss rate), the and taking into account the known or estimated packet loss rate), the
sender calculates: sender calculates:
max_k = floor((2^^m - 1) * CR) max_k = floor((2^^m - 1) * CR)
This max_k value leaves enough room for the sender to produce the This max_k value leaves enough room for the sender to produce the
desired number of repair symbols. Since there is one source symbol desired number of repair symbols. Since there is one source symbol
per ADU, max_k is also an upper bound to the maximum number of ADUs per ADU, max_k is also an upper bound to the maximum number of ADUs
per ADU block. per ADU block.
The source ADU flows MAY have real-time constraints. In that case The source ADU flows MAY have real-time constraints. When there are
the maximum number of ADUs of an ADU block must not exceed a certain multiple flows, with different real-time constraints, let us consider
threshold since it directly impacts the decoding delay. The larger the most stringent constraints (see [RFC6363], section 10.2, item 6
the ADU block size, the longer a decoder may have to wait until it for recommendations when several flows are globally protected). In
has received a sufficient number of encoding symbols for decoding to that case the maximum number of ADUs of an ADU block must not exceed
succeed, and therefore the larger the decoding delay. When the a certain threshold since it directly impacts the decoding delay.
target use-case is known, these real-time constraints result in an The larger the ADU block size, the longer a decoder may have to wait
upper bound to the ADU block size, max_rt. until it has received a sufficient number of encoding symbols for
decoding to succeed, and therefore the larger the decoding delay.
When the target use-case is known, these real-time constraints result
in an upper bound to the ADU block size, max_rt.
For instance, if the use-case specifies a maximum decoding latency, For instance, if the use-case specifies a maximum decoding latency,
l, and if each source ADU covers a duration d of a continuous media l, and if each source ADU covers a duration d of a continuous media
(we assume here the simple case of a constant bit rate ADU flow), (we assume here the simple case of a constant bit rate ADU flow),
then the ADU block size must not exceed: then the ADU block size must not exceed:
max_rt = floor(l / d) max_rt = floor(l / d)
After encoding, this block will produce a set of at most n = max_rt / After encoding, this block will produce a set of at most n = max_rt /
CR encoding symbols. These n encoding symbols will have to be sent CR encoding symbols. These n encoding symbols will have to be sent
at a rate of n / l packets per second. For instance, with d = 10 ms, at a rate of n / l packets per second. For instance, with d = 10 ms,
l = 1 s, max_rt = 100 ADUs. l = 1 s, max_rt = 100 ADUs.
 End of changes. 10 change blocks. 
25 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/