--- 1/draft-ietf-fecframe-ldpc-01.txt 2012-03-08 18:13:56.410671623 +0100
+++ 2/draft-ietf-fecframe-ldpc-02.txt 2012-03-08 18:13:56.446671648 +0100
@@ -1,21 +1,21 @@
FecFrame V. Roca
Internet-Draft INRIA
Intended status: Standards Track M. Cunche
-Expires: June 1, 2012 NICTA
+Expires: September 9, 2012 NICTA
J. Lacan
ISAE/LAAS-CNRS
- November 29, 2011
+ March 8, 2012
Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME
- draft-ietf-fecframe-ldpc-01
+ draft-ietf-fecframe-ldpc-02
Abstract
This document describes a fully-specified simple FEC scheme for LDPC-
Staircase codes that can be used to protect media streams along the
lines defined by the FECFRAME framework. These codes have many
interesting properties: they are systematic codes, they perform close
to ideal codes in many use-cases and they also feature very high
encoding and decoding throughputs. LDPC-Staircase codes are
therefore a good solution to protect a single high bitrate source
@@ -32,25 +32,25 @@
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 June 1, 2012.
+ This Internet-Draft will expire on September 9, 2012.
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.
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
@@ -94,23 +94,23 @@
1. Introduction
The use of Forward Error Correction (FEC) codes is a classic solution
to improve the reliability of unicast, multicast and broadcast
Content Delivery Protocols (CDP) and applications [RFC3453]. The
[RFC6363] document describes a generic framework to use FEC schemes
with media delivery applications, and for instance with real-time
streaming media applications based on the RTP real-time protocol.
Similarly the [RFC5052] document describes a generic framework to use
- FEC schemes with with objects (e.g., files) delivery applications
- based on the ALC [RFC5775] and NORM [RFC5740] reliable multicast
- transport protocols.
+ FEC schemes with objects (e.g., files) delivery applications based on
+ the ALC [RFC5775] and NORM [RFC5740] reliable multicast transport
+ protocols.
More specifically, the [RFC5053] (Raptor) and [RFC5170] (LDPC-
Staircase and LDPC-Triangle) FEC schemes introduce erasure codes
based on sparse parity check matrices for object delivery protocols
like ALC and NORM. Similarly, the [RFC5510] document introduces
Reed-Solomon codes based on Vandermonde matrices for the same object
delivery protocols. All these codes are systematic codes, meaning
that the k source symbols are part of the n encoding symbols.
Additionally, the Reed-Solomon FEC codes belong to the class of
Maximum Distance Separable (MDS) codes that are optimal in terms of
@@ -266,20 +266,21 @@
3.3. Abbreviations
This document uses the following abbreviations:
ADU stands for Application Data Unit.
ESI stands for Encoding Symbol ID.
FEC stands for Forward Error (or Erasure) Correction code.
FFCI stands for FEC Framework Configuration Information.
FSSI stands for FEC Scheme Specific Information.
LDPC stands for Low Density Parity Check.
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
This section introduces the procedures that are used during the ADU
block and the related source block creation, for the FEC scheme
considered.
4.1. Restrictions
This specification has the following restrictions:
@@ -321,28 +322,31 @@
source block size, for instance, because of a limited working memory
size. This decision MUST be clarified at implementation time, when
the target use-case is known. This results in a max2_k limitation.
Then, max_k is given by:
max_k = min(max1_k, max2_k)
Note that this calculation is only required at the encoder (sender),
since the actual k parameter (k <= max_k) is communicated to the
decoder (receiver) through the Explicit Source/Repair FEC Payload ID.
- The source ADU flows MAY have real-time constraints. In that case
- the maximum number of ADUs of an ADU block must not exceed a certain
- threshold since it directly impacts the decoding delay. The larger
- the ADU block size, the longer a decoder may have to wait 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.
+ The source ADU flows MAY have real-time constraints. When there are
+ multiple flows, with different real-time constraints, let us consider
+ the most stringent constraints (see [RFC6363], section 10.2, item 6
+ for recommendations when several flows are globally protected). In
+ that case the maximum number of ADUs of an ADU block must not exceed
+ a certain threshold since it directly impacts the decoding delay.
+ The larger the ADU block size, the longer a decoder may have to wait
+ 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,
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),
then the ADU block size must not exceed:
max_rt = floor(l / d)
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
at a rate of n / l packets per second. For instance, with d = 10 ms,
l = 1 s, max_rt = 100 ADUs.
@@ -818,22 +822,22 @@
Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
"Reed-Solomon Forward Error Correction (FEC) Schemes",
RFC 5510, April 2009.
[SIMPLE_RS]
Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
Matsuzono, "Simple Reed-Solomon Forward Error Correction
(FEC) Scheme for FECFRAME",
- draft-ietf-fecframe-simple-rs-01 (Work in Progress),
- September 2011.
+ draft-ietf-fecframe-simple-rs-02 (Work in Progress),
+ March 2012.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme", RFC 5053,
June 2007.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous