draft-ietf-fecframe-ldpc-01.txt   draft-ietf-fecframe-ldpc-02.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
ISAE/LAAS-CNRS ISAE/LAAS-CNRS
November 29, 2011 March 8, 2012
Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME
draft-ietf-fecframe-ldpc-01 draft-ietf-fecframe-ldpc-02
Abstract Abstract
This document describes a fully-specified simple FEC scheme for LDPC- This document describes a fully-specified simple FEC scheme for LDPC-
Staircase codes that can be used to protect media streams along the Staircase codes that can be used to protect media streams along the
lines defined by the FECFRAME framework. These codes have many lines defined by the FECFRAME framework. These codes have many
interesting properties: they are systematic codes, they perform close interesting properties: they are systematic codes, they perform close
to ideal codes in many use-cases and they also feature very high to ideal codes in many use-cases and they also feature very high
encoding and decoding throughputs. LDPC-Staircase codes are encoding and decoding throughputs. LDPC-Staircase codes are
therefore a good solution to protect a single high bitrate source therefore a good solution to protect a single high bitrate source
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 3, line 14 skipping to change at page 3, 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 [RFC3453]. The Content Delivery Protocols (CDP) and applications [RFC3453]. The
[RFC6363] document describes a generic framework to use FEC schemes [RFC6363] document describes a generic framework to use FEC schemes
with media delivery applications, and for instance with real-time with media delivery applications, and for instance with real-time
streaming media applications based on the RTP real-time protocol. streaming media applications based on the RTP real-time protocol.
Similarly the [RFC5052] document describes a generic framework to use Similarly the [RFC5052] document describes a generic framework to use
FEC schemes with with objects (e.g., files) delivery applications FEC schemes with objects (e.g., files) delivery applications based on
based on the ALC [RFC5775] and NORM [RFC5740] reliable multicast the ALC [RFC5775] and NORM [RFC5740] reliable multicast transport
transport protocols. protocols.
More specifically, the [RFC5053] (Raptor) and [RFC5170] (LDPC- More specifically, the [RFC5053] (Raptor) and [RFC5170] (LDPC-
Staircase and LDPC-Triangle) FEC schemes introduce erasure codes Staircase and LDPC-Triangle) FEC schemes introduce erasure codes
based on sparse parity check matrices for object delivery protocols based on sparse parity check matrices for object delivery protocols
like ALC and NORM. Similarly, the [RFC5510] document introduces like ALC and NORM. Similarly, the [RFC5510] document introduces
Reed-Solomon codes based on Vandermonde matrices for the same object Reed-Solomon codes based on Vandermonde matrices for the same object
delivery protocols. All these codes are systematic codes, meaning delivery protocols. All these codes are systematic codes, meaning
that the k source symbols are part of the n encoding symbols. that the k source symbols are part of the n encoding symbols.
Additionally, the Reed-Solomon FEC codes belong to the class of Additionally, the Reed-Solomon FEC codes belong to the class of
Maximum Distance Separable (MDS) codes that are optimal in terms of Maximum Distance Separable (MDS) codes that are optimal in terms of
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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.
LDPC stands for Low Density Parity Check. LDPC stands for Low Density Parity Check.
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 8, line 25 skipping to change at page 8, line 26
source block size, for instance, because of a limited working memory source block size, for instance, because of a limited working memory
size. This decision MUST be clarified at implementation time, when size. This decision MUST be clarified at implementation time, when
the target use-case is known. This results in a max2_k limitation. the target use-case is known. This results in a max2_k limitation.
Then, max_k is given by: Then, max_k is given by:
max_k = min(max1_k, max2_k) max_k = min(max1_k, max2_k)
Note that this calculation is only required at the encoder (sender), Note that this calculation is only required at the encoder (sender),
since the actual k parameter (k <= max_k) is communicated to the since the actual k parameter (k <= max_k) is communicated to the
decoder (receiver) through the Explicit Source/Repair FEC Payload ID. decoder (receiver) through the Explicit Source/Repair FEC Payload ID.
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.
skipping to change at page 19, line 22 skipping to change at page 19, line 22
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
"Reed-Solomon Forward Error Correction (FEC) Schemes", "Reed-Solomon Forward Error Correction (FEC) Schemes",
RFC 5510, April 2009. RFC 5510, April 2009.
[SIMPLE_RS] [SIMPLE_RS]
Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
Matsuzono, "Simple Reed-Solomon Forward Error Correction Matsuzono, "Simple Reed-Solomon Forward Error Correction
(FEC) Scheme for FECFRAME", (FEC) Scheme for FECFRAME",
draft-ietf-fecframe-simple-rs-01 (Work in Progress), draft-ietf-fecframe-simple-rs-02 (Work in Progress),
September 2011. March 2012.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme", RFC 5053, "Raptor Forward Error Correction Scheme", RFC 5053,
June 2007. June 2007.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport "NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009. Protocol", RFC 5740, November 2009.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
 End of changes. 9 change blocks. 
18 lines changed or deleted 22 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/