--- 1/draft-ietf-fecframe-simple-rs-02.txt 2012-03-08 17:13:56.530672540 +0100
+++ 2/draft-ietf-fecframe-simple-rs-03.txt 2012-03-08 17:13:56.574671311 +0100
@@ -1,24 +1,24 @@
FecFrame V. Roca
Internet-Draft INRIA
Intended status: Standards Track M. Cunche
-Expires: June 1, 2012 NICTA
+Expires: September 9, 2012 NICTA
J. Lacan
A. Bouabdallah
ISAE/LAAS-CNRS
K. Matsuzono
Keio University
- November 29, 2011
+ March 8, 2012
Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
- draft-ietf-fecframe-simple-rs-02
+ draft-ietf-fecframe-simple-rs-03
Abstract
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
protect arbitrary media streams along the lines defined by the
FECFRAME framework. Reed-Solomon codes belong to the class of
Maximum Distance Separable (MDS) codes which means they offer optimal
protection against packet erasures. They are also systematic codes,
which means that the source symbols are part of the encoding symbols.
@@ -34,25 +34,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
@@ -98,22 +98,22 @@
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. 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
+ schemes with objects (e.g., files) delivery applications based on the
+ ALC [RFC5775] and NORM [RFC5740] reliable multicast transport
protocols.
More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce
erasure codes based on sparse parity check matrices for object
delivery protocols like ALC and NORM. These codes are efficient in
terms of processing but not optimal in terms of erasure recovery
capabilities when dealing with "small" objects.
The Reed-Solomon FEC codes described in this document belong to the
class of Maximum Distance Separable (MDS) codes that are optimal in
@@ -145,28 +145,27 @@
compatible with the FECFRAME framework [RFC6363]. Therefore this
document specifies only the information specific to the FECFRAME
context and refers to [RFC5510] for the core specifications of the
codes. To that purpose, the present document introduces:
o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that
specifies a simple way of using of Reed-Solomon codes over
GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for
arbitrary packet flows;
For instance, with this scheme, a set of Application Data Units (or
- ADUs) coming from one or several (resp. one) media delivery
- applications (e.g., a set of RTP packets), are grouped in an ADU
- block and FEC encoded as a whole. With Reed-Solomon codes over
- GF(2^^8), there is a strict limit over the number of ADUs that can be
- protected together, since the number of encoded symbols, n, must be
- inferior or equal to 255. This constraint is relaxed when using a
- higher finite field size (m > 8), at the price of an increased
- computational complexity.
+ ADUs) coming from one or several media delivery applications (e.g., a
+ set of RTP packets), are grouped in an ADU block and FEC encoded as a
+ whole. With Reed-Solomon codes over GF(2^^8), there is a strict
+ limit over the number of ADUs that can be protected together, since
+ the number of encoded symbols, n, must be inferior or equal to 255.
+ This constraint is relaxed when using a higher finite field size (m >
+ 8), at the price of an increased computational complexity.
2. Terminology
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 RFC 2119 [RFC2119].
3. Definitions Notations and Abbreviations
3.1. Definitions
@@ -211,22 +210,23 @@
the F[], L[], and Pad[] fields, they form the set of source
symbols over which FEC encoding will be performed.
ADU Information (ADUI): a unit of data constituted by the ADU and
the associated Flow ID, Length and Padding fields (Section 4.3).
This is the unit of data that is used as source symbol.
FEC Framework Configuration Information: Information which controls
the operation of the FEC Framework. The FFCI enables the
synchronization of the FECFRAME sender and receiver instances.
FEC Source Packet: At a sender (respectively, at a receiver) a
payload submitted to (respectively, received from) the transport
- protocol containing an ADU along with an optional Explicit Source
- FEC Payload ID.
+ protocol containing an ADU along with an Explicit Source FEC
+ 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
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
view):
+----------------------+
| Application |
@@ -282,20 +282,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.
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:
@@ -327,28 +328,31 @@
k < n <= 255. Given the target FEC code rate (e.g., provided by the
end-user or upper application when starting the FECFRAME framework,
and taking into account the known or estimated packet loss rate), the
sender calculates:
max_k = floor((2^^m - 1) * CR)
This max_k value leaves enough room for the sender to produce the
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 block.
- 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.