draft-ietf-fecframe-ldpc-00.txt   draft-ietf-fecframe-ldpc-01.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: March 17, 2012 NICTA Expires: June 1, 2012 NICTA
J. Lacan J. Lacan
ISAE/LAAS-CNRS ISAE/LAAS-CNRS
September 14, 2011 November 29, 2011
Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME
draft-ietf-fecframe-ldpc-00 draft-ietf-fecframe-ldpc-01
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 March 17, 2012. This Internet-Draft will expire on June 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions Notations and Abbreviations . . . . . . . . . . . 4 3. Definitions Notations and Abbreviations . . . . . . . . . . . 4
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
4. Common Procedures Related to the ADU Block and Source 4. Common Procedures Related to the ADU Block and Source
Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 7 Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 7 4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 7
4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 8 4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 9
5. LDPC-Staircase FEC Scheme for Arbitrary ADU Flows . . . . . . 10 5. LDPC-Staircase FEC Scheme for Arbitrary ADU Flows . . . . . . 10
5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 10 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 10
5.1.1. FEC Framework Configuration Information . . . . . . . 10 5.1.1. FEC Framework Configuration Information . . . . . . . 10
5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 12 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 12
5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 13
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 14 5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 14 6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 14
6.1.1. Access to Confidential Content . . . . . . . . . . . . 14 6.1.1. Access to Confidential Content . . . . . . . . . . . . 15
6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 15 6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 15
6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 15 6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 15
6.3. When Several Source Flows are to be Protected Together . . 16 6.3. When Several Source Flows are to be Protected Together . . 16
6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 16 6.4. Baseline Secure FEC Framework Operation . . . . . . . . . 16
7. Operations and Management Considerations . . . . . . . . . . . 16 7. Operations and Management Considerations . . . . . . . . . . . 16
7.1. Operational Recommendations . . . . . . . . . . . . . . . 16 7.1. Operational Recommendations . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
together for the encoding. together for the encoding.
Packet Erasure Channel: a communication path where packets are Packet Erasure Channel: a communication path where packets are
either dropped (e.g., by a congested router, or because the number either dropped (e.g., by a congested router, or because the number
of transmission errors exceeds the correction capabilities of the of transmission errors exceeds the correction capabilities of the
physical layer codes) or received. When a packet is received, it physical layer codes) or received. When a packet is received, it
is assumed that this packet is not corrupted. is assumed that this packet is not corrupted.
Some of them are FECFRAME framework specific and are in line with Some of them are FECFRAME framework specific and are in line with
[RFC6363]: [RFC6363]:
Application Data Unit (ADU): a unit of data coming from (sender) or Application Data Unit (ADU): The unit of source data provided as
given to (receiver) the media delivery application. Depending on payload to the transport layer. Depending on the use-case, an ADU
the use-case, an ADU can use an RTP encapsulation. In this may use an RTP encapsulation.
specification, there is always one source symbol per ADU. (Source) ADU Flow: A sequence of ADUs associated with a transport-
(Source) ADU Flow: a flow of ADUs from a media delivery application layer flow identifier (such as the standard 5-tuple {Source IP
and to which FEC protection is applied. Depending on the use- address, source port, destination IP address, destination port,
case, several ADU flows can be protected together by the FECFRAME transport protocol}). Depending on the use-case, several ADU
framework. flows may be protected together by the FECFRAME framework.
ADU Block: a set of ADUs that are considered together by the ADU Block: a set of ADUs that are considered together by the
FECFRAME instance for the purpose of the FEC scheme. Along with FECFRAME instance for the purpose of the FEC scheme. Along with
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: the FEC scheme specific FEC Framework Configuration Information: Information which controls
information that enables the synchronization of the FECFRAME the operation of the FEC Framework. The FFCI enables the
sender and receiver instances. synchronization of the FECFRAME sender and receiver instances.
FEC Source Packet: a data packet submitted to (sender) or received FEC Source Packet: At a sender (respectively, at a receiver) a
from (receiver) the transport protocol. It contains an ADU along payload submitted to (respectively, received from) the transport
with its optional Explicit Source FEC Payload ID. protocol containing an ADU along with an optional Explicit Source
FEC Repair Packet: a repair packet submitted to (sender) or received FEC Payload ID.
from (receiver) the transport protocol. It contains a repair FEC Repair Packet: At a sender (respectively, at a receiver) a
symbol along with its Repair FEC Payload ID. payload submitted to (respectively, received from) the transport
protocol containing one repair symbol along with a Repair FEC
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 |
+----------------------+ +----------------------+
| |
ADU flow | (1) Application Data Unit (ADU) | (1) Application Data Units (ADUs)
|
v v
+----------------------+ +----------------+ +----------------------+ +----------------+
| FEC Framework | | | | FEC Framework | | |
| |------------------------- >| FEC Scheme | | |-------------------------->| FEC Scheme |
|(2) Construct an ADU | (4) Source Symbols for | | |(2) Construct source |(3) Source Block | |
| block | this Source Block |(5) Perform FEC | | blocks | |(4) FEC Encoding|
|(3) Construct ADU Info| | Encoding | |(6) Construct FEC |<--------------------------| |
|(7) Construct FEC Src |< -------------------------| | | source and repair | | |
| Packets and FEC |(6) Ex src FEC Payload Ids,| | | packets |(5) Explicit Source FEC | |
| Repair Packets | Repair FEC Payload Ids,| | +----------------------+ Payload IDs +----------------+
+----------------------+ Repair Symbols +----------------+ | Repair FEC Payload IDs
| | | Repair symbols
|(8) FEC Src |(8') FEC Repair |
| packets | packets |(7) FEC source and repair packets
v v v
+----------------------+ +----------------------+
| Transport Layer | | Transport Layer |
| (e.g., UDP ) | | (e.g., UDP) |
+----------------------+ +----------------------+
Figure 1: Terminology used in this document (sender). Figure 1: Terminology used in this document (sender).
3.2. Notations 3.2. Notations
This document uses the following notations: Some of them are FEC This document uses the following notations: Some of them are FEC
scheme specific: scheme specific:
k denotes the number of source symbols in a source block. k denotes the number of source symbols in a source block.
max_k denotes the maximum number of source symbols for any source max_k denotes the maximum number of source symbols for any source
skipping to change at page 7, line 38 skipping to change at page 7, line 38
o there MUST be exactly one source symbol per ADUI, and therefore o there MUST be exactly one source symbol per ADUI, and therefore
per ADU; per ADU;
o there MUST be exactly one repair symbol per FEC Repair Packet; o there MUST be exactly one repair symbol per FEC Repair Packet;
o there MUST be exactly one source block per ADU block; o there MUST be exactly one source block per ADU block;
o the use of the LDPC-Staircase scheme is such that there MUST be o the use of the LDPC-Staircase scheme is such that there MUST be
exactly one encoding symbol per group, i.e., G MUST be equal to 1 exactly one encoding symbol per group, i.e., G MUST be equal to 1
[RFC5170]; [RFC5170];
4.2. ADU Block Creation 4.2. ADU Block Creation
Several aspects must be considered, that impact the ADU block Two kinds of limitations MUST be considered, that impact the ADU
creation: block creation:
o the maximum source block size (max_k parameter); o at the FEC Scheme level: the FEC Scheme and the FEC codec have
o the potential real-time constraints, that impact the maximum ADU limitations that define a maximum source block size;
block size, since the larger the block size, the larger the o at the FECFRAME instance level: the target use-case MAY have real-
decoding delay; time constraints that MAY define a maximum ADU block size;
We now detail each of these aspects. Note that terminology "maximum source block size" and "maximum ADU
block size" depends on the point of view that is adopted (FEC Scheme
versus FECFRAME instance). However, in this document, both refer to
the same value since Section 4.1 requires there is exactly one source
symbol per ADU. We now detail each of these aspects.
The maximum source block length in symbols, max_k, depends on several The maximum source block size in symbols, max_k, depends on several
parameters: the code rate (CR), the Encoding Symbol ID (ESI) field parameters: the code rate (CR), the Encoding Symbol ID (ESI) field
length in the Explicit Source/Repair FEC Payload ID (16 bits), as length in the Explicit Source/Repair FEC Payload ID (16 bits), as
well as possible internal codec limitations. More specifically, well as possible internal codec limitations. More specifically,
max_k cannot be larger than the following values, derived from the max_k cannot be larger than the following values, derived from the
ESI field size limitation, for a given code rate: ESI field size limitation, for a given code rate:
max1_k = 2^^(16 - ceil(Log2(1/CR))) max1_k = 2^^(16 - ceil(Log2(1/CR)))
Some common max1_k values are: Some common max1_k values are:
o CR == 1 (no repair symbol): max1_k = 2^^16 = 65536 symbols o CR == 1 (no repair symbol): max1_k = 2^^16 = 65536 symbols
o 1/2 <= CR < 1: max1_k = 2^^15 = 32,768 symbols o 1/2 <= CR < 1: max1_k = 2^^15 = 32,768 symbols
o 1/4 <= CR < 1/2: max1_k = 2^^14 = 16,384 symbols o 1/4 <= CR < 1/2: max1_k = 2^^14 = 16,384 symbols
Additionally, a codec MAY impose other limitations on the maximum Additionally, a codec MAY impose other limitations on the maximum
block size, for instance, because of a limited working memory size. source block size, for instance, because of a limited working memory
This decision MUST be clarified at implementation time, when the size. This decision MUST be clarified at implementation time, when
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 usually have real-time constraints. It means The source ADU flows MAY have real-time constraints. In that case
that the maximum number of ADUs of an ADU block must not exceed a the maximum number of ADUs of an ADU block must not exceed a certain
certain threshold since it directly impacts the decoding delay. It threshold since it directly impacts the decoding delay. The larger
is the role of the developer, who knows the flow real-time features, the ADU block size, the longer a decoder may have to wait until it
to define an appropriate upper bound to the ADU block size, max_rt. 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.
If we take into account these constraints, we find: max_B = For instance, if the use-case specifies a maximum decoding latency,
min(max_k, max_rt). Then max_B gives an upper bound to the number of l, and if each source ADU covers a duration d of a continuous media
ADUs that can constitute an ADU block. (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.
If we take into account all these constraints, we find:
max_B = min(max_k, max_rt)
This max_B parameter is an upper bound to the number of ADUs that can
constitute an ADU block.
4.3. Source Block Creation 4.3. Source Block Creation
In its most general form the FECFRAME framework and the LDPC- In its most general form the FECFRAME framework and the LDPC-
Staircase FEC scheme are meant to protect a set of independent flows. Staircase FEC scheme are meant to protect a set of independent flows.
Since the flows have no relationship to one another, the ADU size of Since the flows have no relationship to one another, the ADU size of
each flow can potentially vary significantly. Even in the special each flow can potentially vary significantly. Even in the special
case of a single flow, the ADU sizes can largely vary (e.g., the case of a single flow, the ADU sizes can largely vary (e.g., the
various frames of a "Group of Pictures (GOP) of an H.264 flow). This various frames of a "Group of Pictures (GOP) of an H.264 flow). This
diversity must be addressed since the LDPC-Staircase FEC scheme diversity must be addressed since the LDPC-Staircase FEC scheme
skipping to change at page 11, line 38 skipping to change at page 11, line 39
otherwise notified by an updated FFCI if this possibility is otherwise notified by an updated FFCI if this possibility is
considered by the use-case or CDP). considered by the use-case or CDP).
N1 minus 3 (n1m3): an integer between 0 (default) and 7, inclusive. N1 minus 3 (n1m3): an integer between 0 (default) and 7, inclusive.
The number of "1s" per column in the left side of the parity check The number of "1s" per column in the left side of the parity check
matrix, N1, is then equal to N1m3 + 3, as specified in [RFC5170]. matrix, N1, is then equal to N1m3 + 3, as specified in [RFC5170].
These elements are required both by the sender (LDPC-Staircase These elements are required both by the sender (LDPC-Staircase
encoder) and the receiver(s) (LDPC-Staircase decoder). encoder) and the receiver(s) (LDPC-Staircase decoder).
When SDP is used to communicate the FFCI, this FEC scheme-specific When SDP is used to communicate the FFCI, this FEC scheme-specific
information is carried in the 'fssi' parameter in textual information is carried in the 'fssi' parameter in textual
representation as specified in [SDP_ELEMENTS]. For instance: representation as specified in [RFC6364]. For instance:
fssi = seed:1234,E:1400,S:0,n1m3:0 fssi=seed:1234,E:1400,S:0,n1m3:0
If another mechanism requires the FSSI to be carried as an opaque If another mechanism requires the FSSI to be carried as an opaque
octet string (for instance after a Base64 encoding), the encoding octet string (for instance after a Base64 encoding), the encoding
format consists of the following 7 octets: format consists of the following 7 octets:
o PRNG seed (seed): 32 bit field. o PRNG seed (seed): 32 bit field.
o Encoding symbol length (E): 16 bit field. o Encoding symbol length (E): 16 bit field.
o Strict (S) flag: 1 bit field. o Strict (S) flag: 1 bit field.
o Reserved: a 4 bit field that MUST be set to zero. o Reserved: a 4 bit field that MUST be set to zero.
o N1m3 parameter (n1m3): 3 bit field. o N1m3 parameter (n1m3): 3 bit field.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed (seed) | | PRNG seed (seed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) |S| resvd | n1m3| | Encoding Symbol Length (E) |S| resvd | n1m3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 34 skipping to change at page 16, line 49
The FEC Framework document [RFC6363] provides a comprehensive The FEC Framework document [RFC6363] provides a comprehensive
analysis of operations and management considerations applicable to analysis of operations and management considerations applicable to
FEC schemes. Therefore the present section only discusses topics FEC schemes. Therefore the present section only discusses topics
that are specific to the use of LDPC-Staircase codes as specified in that are specific to the use of LDPC-Staircase codes as specified in
this document. this document.
7.1. Operational Recommendations 7.1. Operational Recommendations
LDPC-Staircase codes have excellent erasure recovery capabilities LDPC-Staircase codes have excellent erasure recovery capabilities
with large source blocks, close to ideal MDS codes. For instance, with large source blocks, close to ideal MDS codes. For instance,
with a medium source block size k=1024, CR=2/3, N1=5, G=1, with a independently of FECFRAME, with source block size k=1024, CR=2/3,
hybrid ITerative/Maximum Likelihood (IT/ML) decoding approach (see N1=5, G=1, with a hybrid ITerative/Maximum Likelihood (IT/ML)
below) and when all symbols are sent in a random order (see below), decoding approach (see below) and when all symbols are sent in a
the average overhead amounts to 0.64% (corresponding to 6.5 symbols random order (see below), the average overhead amounts to 0.64%
in addition to k) and receiving 1043 symbols (corresponding to a 1.9% (corresponding to 6.5 symbols in addition to k) and receiving 1046
overhead) is sufficient to reduce the decoding failure probability to symbols (corresponding to a 2.1% overhead) is sufficient to reduce
5.1*10^^-5. This is why these codes are a good solution to protect a the decoding failure probability to 5.9*10^^-5. This is why these
single high bitrate source flow as in [Matsuzono10], or to protect codes are a good solution to protect a single high bitrate source
globally several mid-rate source flows within a single FECFRAME flow as in [Matsuzono10], or to protect globally several mid-rate
instance: in both cases the source block size can be assumed to be source flows within a single FECFRAME instance: in both cases the
equal to a few hundreds (or more) source symbols. source block size can be assumed to be equal to a few hundreds (or
more) source symbols.
LDPC-Staircase codes are also a good solution whenever processing LDPC-Staircase codes are also a good solution whenever processing
requirements at a software encoder or decoder must be kept to a requirements at a software encoder or decoder must be kept to a
minimum. This is true when the decoder uses an IT decoding minimum. This is true when the decoder uses an IT decoding
algorithm, or an ML algorithm (we use a Gaussian Elimination as the algorithm, or an ML algorithm (we use a Gaussian Elimination as the
ML algorithm) when this latter is carefully implemented and the ML algorithm) when this latter is carefully implemented and the
source block size kept reasonable, or a mixture of both techniques source block size kept reasonable, or a mixture of both techniques
which is the recommended solution [Cunche08][CunchePHD10]. For which is the recommended solution [Cunche08][CunchePHD10]. For
instance an average decoding speed between 1.3 Gbps (corresponding to instance an average decoding speed between 1.3 Gbps (corresponding to
a very bad channel, close to the theoretical decoding limit and a very bad channel, close to the theoretical decoding limit and
skipping to change at page 17, line 23 skipping to change at page 17, line 38
bits. Additionally, with a hybrid IT/ML approach, a receiver can bits. Additionally, with a hybrid IT/ML approach, a receiver can
decide if and when ML decoding is used, depending on local criteria decide if and when ML decoding is used, depending on local criteria
(e.g., battery or CPU capabilities), independently from other (e.g., battery or CPU capabilities), independently from other
receivers. receivers.
As the source block size decreases, the erasure recovery capabilities As the source block size decreases, the erasure recovery capabilities
of LDPC codes in general also decrease. In the case of LDPC- of LDPC codes in general also decrease. In the case of LDPC-
Staircase codes, in order to compensate this phenomenon, it is Staircase codes, in order to compensate this phenomenon, it is
recommended to increase the N1 parameter (e.g., experiments carried recommended to increase the N1 parameter (e.g., experiments carried
out in [Matsuzono10] use N1=7 if k=170 symbols, and N1=5 otherwise) out in [Matsuzono10] use N1=7 if k=170 symbols, and N1=5 otherwise)
and to use a hybrid IT/ML decoding approach. For instance, with a and to use a hybrid IT/ML decoding approach. For instance,
small source block size k=256 symbols, CR=2/3, N1=7, and G=1, the independently of FECFRAME, with a small source block size k=256
average overhead amounts to 0.67% (corresponding to 1.7 symbols in symbols, CR=2/3, N1=7, and G=1, 8he average overhead amounts to 0.71%
addition to k), and receiving 267 symbols (corresponding to a 4.3% (corresponding to 1.8 symbols in addition to k), and receiving 271
overhead) is sufficient to reduce the decoding failure probability to symbols (corresponding to a 5.9% overhead) is sufficient to reduce
1.4*10^^-5. Using N1=9 further improves these results if need be, the decoding failure probability to 5.9*10^^-5. Using N1=9 or 10
which also enables to use LDPC-Staircase codes with k=100 symbols for further improves these results if need be, which also enables to use
instance. LDPC-Staircase codes with k=100 symbols for instance.
With very small source blocks (e.g., a few tens symbols), using for With very small source blocks (e.g., a few tens symbols), using for
instance Reed-Solomon codes [SIMPLE_RS] or 2D parity check codes MAY instance Reed-Solomon codes [SIMPLE_RS] or 2D parity check codes MAY
be more appropriate. be more appropriate.
The way the FEC Repair Packets are transmitted is of high importance. The way the FEC Repair Packets are transmitted is of high importance.
A good strategy, that works well for any kind of channel loss model, A good strategy, that works well for any kind of channel loss model,
consists in sending FEC Repair Packets in random order (rather than consists in sending FEC Repair Packets in random order (rather than
in sequence) while FEC Source Packets are sent first and in sequence. in sequence) while FEC Source Packets are sent first and in sequence.
Sending all packets in a random order is another possibility, but it Sending all packets in a random order is another possibility, but it
requires that all repair symbols for a source block be produced requires that all repair symbols for a source block be produced
first, which adds some extra delay at a sender. first, which adds some extra delay at a sender.
8. IANA Considerations 8. IANA Considerations
Values of FEC Encoding IDs are subject to IANA registration. Values of FEC Encoding IDs are subject to IANA registration.
skipping to change at page 18, line 30 skipping to change at page 18, line 44
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119.
[RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity
Check (LDPC) Forward Error Correction", RFC 5170, Check (LDPC) Forward Error Correction", RFC 5170,
June 2008. June 2008.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, September 2011. Correction (FEC) Framework", RFC 6363, September 2011.
[SDP_ELEMENTS] [RFC6364] Begen, A., "Session Description Protocol Elements for the
Begen, A., "SDP Elements for FEC Framework", Forward Error Correction (FEC) Framework", RFC 6364,
draft-ietf-fecframe-sdp-elements-10 (Work in Progress), October 2011.
October 2010.
10.2. Informative References 10.2. Informative References
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "The Use of Forward Error Correction M., and J. Crowcroft, "The Use of Forward Error Correction
(FEC) in Reliable Multicast", RFC 3453, December 2002. (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
 End of changes. 27 change blocks. 
85 lines changed or deleted 107 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/