Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt

"Luby, Michael" <> Thu, 11 October 2012 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0191F21F85AE; Thu, 11 Oct 2012 11:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.554
X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mN7eBX3rGU0Q; Thu, 11 Oct 2012 11:24:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C6DC021F854C; Thu, 11 Oct 2012 11:23:59 -0700 (PDT)
X-IronPort-AV: E=McAfee;i="5400,1158,6862"; a="246552256"
Received: from ([]) by with ESMTP; 11 Oct 2012 11:23:36 -0700
X-IronPort-AV: E=Sophos;i="4.80,573,1344236400"; d="scan'208";a="124881201"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 11 Oct 2012 11:23:36 -0700
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 11:23:34 -0700
From: "Luby, Michael" <>
To: "" <>, "" <>
Thread-Topic: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt
Thread-Index: AQHNpiEgQHxRRh+VfUSBSAt8xaBu5Je0bsiA
Date: Thu, 11 Oct 2012 18:23:34 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Oct 2012 18:24:02 -0000

Some quick comments.

(1) This proposal relies upon parts of RFC 5170 for the definition of the
underlying LDPC staircase code.  However, it isn't completely explicit in
this proposal about what exact parts/sections of RFC 5170 are to be used
in this proposal and how.  It would seem that explicit references to the
particular sections of RFC 5170 that are being used, and exactly how these
parts of RFC 5170 are being inherited and used, would be useful (probably
necessary).  Note that there are several codes with different FEC encoding
IDs defined in RFC 5170, so making exact references to which parts are
and how is important.  An example of how this is not at all precisely

	Because of the requirement to have exactly one encoding symbol per
	group, i.e., because G MUST be equal to 1 (Section 4.1
	parts of [RFC5170 <>] are useless.  In
particular, this is the case of
	Section 5.6 
"Identifying the G Symbols of an Encoding Symbol

This snippet above that says several parts of RFC 5170 are useless (very
vague), and it seems instead it should explicitly state what
parts are to be used and exactly how.  It provides one example of
something that is not is to be used from RFC 5170, but it seems that
it should be the other way around, stating explicitly what should be used
and how.

(2) This proposal references RFC 5170 and RFC 5053, and makes some
comparisons.  However, there is also RFC 6330 that is relevant and is not
mentioned or referenced in this proposal.  It would seem appropriate to do

Thanks, Mike

On 10/9/12 6:22 AM, ""; <>;

>A New Internet-Draft is available from the on-line Internet-Drafts
> This draft is a work item of the FEC Framework Working Group of the IETF.
>	Title           : Simple LDPC-Staircase Forward Error Correction (FEC)
>Scheme for FECFRAME
>	Author(s)       : Vincent Roca
>                          Mathieu Cunche
>                          Jerome Lacan
>	Filename        : draft-ietf-fecframe-ldpc-04.txt
>	Pages           : 22
>	Date            : 2012-10-09
>   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
>   flow, or to protect globally several mid-rate flows within a single
>   FECFRAME instance.  They are also a good solution whenever the
>   processing load of a software encoder or decoder must be kept to a
>   minimum.
>The IETF datatracker status page for this draft is:
>There's also a htmlized version available at:
>A diff from the previous version is available at:
>Internet-Drafts are also available by anonymous FTP at:
>Fecframe mailing list