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

Martin Stiemerling <martin.stiemerling@neclab.eu> Wed, 17 October 2012 09:14 UTC

Return-Path: <Martin.Stiemerling@neclab.eu>
X-Original-To: fecframe@ietfa.amsl.com
Delivered-To: fecframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A2C21F8622 for <fecframe@ietfa.amsl.com>; Wed, 17 Oct 2012 02:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.016
X-Spam-Level:
X-Spam-Status: No, score=-103.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROfni8Opt-fE for <fecframe@ietfa.amsl.com>; Wed, 17 Oct 2012 02:14:06 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3521F861F for <fecframe@ietf.org>; Wed, 17 Oct 2012 02:14:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 70835102200; Wed, 17 Oct 2012 11:14:05 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBlU7tV4cGO5; Wed, 17 Oct 2012 11:14:05 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 56E631021DB; Wed, 17 Oct 2012 11:13:55 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 11:13:55 +0200
Message-ID: <507E76D3.9060001@neclab.eu>
Date: Wed, 17 Oct 2012 11:13:55 +0200
From: Martin Stiemerling <martin.stiemerling@neclab.eu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Luby, Michael" <luby@qti.qualcomm.com>, "fecframe@ietf.org" <fecframe@ietf.org>
References: <BAE0CC0CAB9C9C4AAE57C71E55C451D820BC0506@NASANEXD02C.na.qualcomm.com>
In-Reply-To: <BAE0CC0CAB9C9C4AAE57C71E55C451D820BC0506@NASANEXD02C.na.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Oct 2012 09:14:07 -0000

Hi Michael, all,

Thanks for your comments, but I would have wished to see them either 
during the WG Last Call or latest during IETF LC.

Anyhow, apart from the timing, the questions are probably good to be 
discussed. Especially, as there are IPR declarations for RFC 5170.

Any feedback from the WG?

Thanks,

   Martin

-- 
IETF Transport Area Director

martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283


On 10/11/2012 08:23 PM, Luby, Michael wrote:
> 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
> used
> and how is important.  An example of how this is not at all precisely
> defined:
>
> 	Because of the requirement to have exactly one encoding symbol per
> 	group, i.e., because G MUST be equal to 1 (Section 4.1
> <http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04#section-4.1>),
> several
> 	parts of [RFC5170 <http://tools.ietf.org/html/rfc5170>] are useless.  In
> particular, this is the case of
> 	Section 5.6
> <http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04#section-5.6>.
> "Identifying the G Symbols of an Encoding Symbol
> 	Group".
>
> 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
> so.
>
> Thanks, Mike
>
>
>
> On 10/9/12 6:22 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> 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
>>
>> 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
>>    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:
>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-fecframe-ldpc-04
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> Fecframe mailing list
>> Fecframe@ietf.org
>> https://www.ietf.org/mailman/listinfo/fecframe
>
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe
>