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

Vincent Roca <vincent.roca@inria.fr> Wed, 17 October 2012 11:59 UTC

Return-Path: <vincent.roca@inria.fr>
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 2222521F8789 for <fecframe@ietfa.amsl.com>; Wed, 17 Oct 2012 04:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.405
X-Spam-Level:
X-Spam-Status: No, score=-110.405 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 scF+W+3U8cQt for <fecframe@ietfa.amsl.com>; Wed, 17 Oct 2012 04:59:35 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAA121F8786 for <fecframe@ietf.org>; Wed, 17 Oct 2012 04:59:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,600,1344204000"; d="scan'208";a="177612031"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 17 Oct 2012 13:59:33 +0200
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <507E76D3.9060001@neclab.eu>
Date: Wed, 17 Oct 2012 13:59:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D353D8B7-6F27-447F-8EB4-3890A2ECC8AE@inria.fr>
References: <BAE0CC0CAB9C9C4AAE57C71E55C451D820BC0506@NASANEXD02C.na.qualcomm.com> <507E76D3.9060001@neclab.eu>
To: "Luby, Michael" <luby@qti.qualcomm.com>
X-Mailer: Apple Mail (2.1085)
Cc: Mathieu Cunche <mathieu.cunche@inria.fr>, Jérôme Lacan <jerome.lacan@isae.fr>, fecframe@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 11:59:36 -0000

Mike,

Thanks for your feedback.

>> (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.

I have no doubt that an implementer will find its way in RFC5170 and identify
what needs to be used. With the further restriction of having G=1, the
specifications of RFC5170 become fairly small (~14 technical pages, pseudo-code
included) and easy to understand IMHO.

We are not planning to change anything here unless the IESG asks us to do so.


>> (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.

This list is not intended to be exhaustive. No other FEC scheme tries to provide
an exhaustive list: RFC5053 (Raptor) does not reference any other FEC scheme,
and RFC6330 (RaptorQ) / RFC6681 (Raptor(Q) for FECFRAME) only reference
Raptor.


More importantly. Since:

1- you noticed we impose restrictions on the way LDPC-Staircase codes are
  being used in section 4.1;

2- you certainly remember the discussion we had in 2009 concerning 10 out
  of the 13 patents mentioned in the RFC5170 IPR disclosure, whose conclusion
  is here:
	http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html

3- the present I-D only considers LDPC-Staircase codes whereas RFC5170
   defines two FEC schemes;

you will probably conclude like us that QC's IPR disclosure for RFC5170 does
not necessarily apply to this I-D. Hence our question: does QC intend to do
a new IPR disclosure? When?


Regards,


    Vincent, on behalf of the authors


NB: I'm adding Stephen Farrell who first identified the IPR disclosure question
during IESG review.