Re: [Fecframe] Adopt?

Vincent Roca <vincent.roca@inrialpes.fr> Wed, 12 January 2011 07:41 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9BD3A6B08 for <fecframe@core3.amsl.com>; Tue, 11 Jan 2011 23:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level:
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OHSD6rkg81P for <fecframe@core3.amsl.com>; Tue, 11 Jan 2011 23:41:32 -0800 (PST)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 518403A6B02 for <fecframe@ietf.org>; Tue, 11 Jan 2011 23:41:30 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.60,312,1291590000"; d="scan'208,217"; a="84867607"
Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 12 Jan 2011 08:43:47 +0100
Message-ID: <4D2D5BB3.8030507@inrialpes.fr>
Date: Wed, 12 Jan 2011 08:43:47 +0100
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: fecframe@ietf.org
References: <AANLkTimCh3WZWfUQtdknUVZ8mXYnanawgCZv6-FtTD+h@mail.gmail.com> <D77444FFBFFA4C59ACF63ABC119F5ADB@23FX1C1> <4E3DAC27-ED71-4B28-BDEA-4F241242C842@gmail.com> <4D10D064.7090004@inrialpes.fr>
In-Reply-To: <4D10D064.7090004@inrialpes.fr>
Content-Type: multipart/alternative; boundary="------------010801080404060904080601"
Cc: SAVIN Valentin 209363 <valentin.savin@cea.fr>
Subject: Re: [Fecframe] Adopt?
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jan 2011 07:41:39 -0000

Hello Everybody,

Even if the draft-roca-fecframe-ldpc-01 draft has already been accepted, 
please
find below another opinion why these codes make sense in the context of 
FECFRAME.
Thank you, Valentin!

Cheers,

    Vincent


NB: Valentin has many theoretical and practical contributions on FEC codes
in general, and binary or non binary LDPC codes in particular, including 
for the
erasure channel use-cases.


-------- Message original --------
Sujet: 	LDPC-staircase FEC scheme for FECFRAME - review
Date : 	Mon, 10 Jan 2011 15:19:30 +0100
De : 	SAVIN Valentin 209363 <valentin.savin@cea.fr>
Pour : 	Vincent Roca <vincent.roca@inrialpes.fr>



Hello Vincent,

Can you please forward to the FECFRAME list the text below that explains 
why I strongly support the LDPC-Staircase AL-FEC scheme proposal.
Thanks!
----------------------------------------------------------------

/The following review refers to the LDPC-staircase FEC scheme for 
FECFRAME, proposed in the [draft-roca-fecframe-ldpc-01] document/.

In the context of content distribution applications, Low Density Parity 
Check (LDPC) codes constitute a very broad class of FEC codes, 
distinguished by the fact that they are defined by sparse parity-check 
matrices, and can be iteratively decoded in linear time with respect to 
their block-length. Since their invention in early 60's by Gallager, a 
large body of knowledge has been acquired (analysis, optimization, 
construction); LDPC codes are known to be capacity approaching codes for 
a large class of channels, and became synonymous with modern coding.

The LDPC-staircase codes proposed in the abovementioned draft belong to 
the broad class of LDPC codes. They are defined by parity-check matrices 
verifying the two following properties: (1) the columns corresponding to 
source symbols are of constant weight, specified by the parameter N1, 
and (2) the columns corresponding to repair symbols form a "staircase" 
(double-diagonal) matrix. These codes can thereby be fully specified in 
a very simple way and their encoder and decoder allow very simple 
implementations.
Indeed, as for the encoder, each new repair symbol is immediately 
generated as the sum (bitwise xor) of the previous repair symbol and 
some of the source symbols. The decoder can implement either the 
iterative (IT) decoding, which consists of a simple technique of solving 
a linear system by iteratively searching for equations with only one 
single unknown variable left, or the Maximum-Likelihood (ML) decoding, 
which relies on the more complex Gaussian elimination method.

The N1 parameter allows for fine-tuning the FEC scheme with respect to 
the decoding performance, measured in terms of inefficiency or overhead, 
and complexity, measured in terms of throughput. Very high throughputs 
(e.g. several Gbps) can be reached by using the IT decoding, which 
achieves good performance (low overheads) for small values of N1 
(generally 3, 4). To improve the decoding performance, one can trade IT 
for ML decoding. For instance, LDPC-staircase codes with N1 = 5 or 7 
have almost ideal performance under the ML decoding (overhead < 1%), at 
the expense of lower throughput (which however remains above 1 Gbps most 
of the time). Moreover, the performance of the ML decoding can be 
further improved by increasing the N1 parameter above 7 if needed.

The usability, combined with reliable performance, make LDPC-staircase 
highly attractive for practical FEC schemes for the erasure channel. I 
therefore strongly recommend them for adoption by the FECFRAME working 
group.


Dr. Valentin Savin
CEA-LETI, MINATEC
Information Theory Specialist


----------------------------------------------------------------
**/Dr. Valentin Savin/**
//CEA-LETI, MINATEC//
//DSIS/LCS - Communications sans fil et Sécurité//
//17, rue des Martyrs,38054 Grenoble, FRANCE//
//Bât BOC(51C), Pièce C452//
//Tél.  +33.(0)4.38.78.07.11//
//Fax. +33.(0)4.38.78.65.86//
//http://www-leti.cea.fr//, //http://www.minatec.com//