Re: [Fecframe] Last Call: <draft-ietf-fecframe-simple-rs-04.txt> (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard

"Luby, Michael" <luby@qti.qualcomm.com> Tue, 06 November 2012 16:10 UTC

Return-Path: <luby@qti.qualcomm.com>
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 5624721F89F1; Tue, 6 Nov 2012 08:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 XNf+kaJHKAaH; Tue, 6 Nov 2012 08:10:27 -0800 (PST)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF6221F8A32; Tue, 6 Nov 2012 08:10:18 -0800 (PST)
X-IronPort-AV: E=McAfee;i="5400,1158,6887"; a="4501293"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 06 Nov 2012 07:55:44 -0800
X-IronPort-AV: E=Sophos;i="4.80,722,1344236400"; d="scan'208";a="364925826"
Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Nov 2012 08:10:09 -0800
Received: from NASANEXD02C.na.qualcomm.com ([169.254.6.25]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 08:10:08 -0800
From: "Luby, Michael" <luby@qti.qualcomm.com>
To: Vincent Roca <vincent.roca@inria.fr>, "Luby, Michael" <luby@qti.qualcomm.com>
Thread-Topic: [Fecframe] Last Call: <draft-ietf-fecframe-simple-rs-04.txt> (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard
Thread-Index: AQHNvDkwzEWyMByYtk6ne5/OlWimww==
Date: Tue, 06 Nov 2012 16:10:07 +0000
Message-ID: <BAE0CC0CAB9C9C4AAE57C71E55C451D820BE07A1@NASANEXD02C.na.qualcomm.com>
In-Reply-To: <0C779DC7-564A-4EEA-BEAA-AD9168863FF0@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.4.120824
x-originating-ip: [199.106.115.132]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2A90BDEB9954634A89BA38ECC3D02776@qualcomm.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf@ietf.org" <ietf@ietf.org>, "fecframe@ietf.org" <fecframe@ietf.org>
Subject: Re: [Fecframe] Last Call: <draft-ietf-fecframe-simple-rs-04.txt> (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard
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: Tue, 06 Nov 2012 16:10:28 -0000

Vincent, 
Thanks, I think this will help the document.
Mike

On 11/6/12 4:38 PM, "Vincent Roca" <vincent.roca@inria.fr> wrote:

>Mike,
>
>Thanks for your comments. It seems your email didn't show up in the
>fecframe
>list (it's not in the mailing list archive either) which explains why we
>didn't answer
>so far.
>
>
>Concerning (1), you're right and here is the way we address it both in the
>introduction and section 5.3.
>
>** Introduction:
>
>OLD:
>   More specifically, the [RFC5510] document introduced such Reed-
>   Solomon codes and several associated FEC schemes that are compatible
>   with the [RFC5052] framework.  The present document inherits from
>   [RFC5510] the specification of the core Reed-Solomon codes based on
>   Vandermonde matrices, and specifies a simple FEC scheme that is
>   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;
>
>
>NEW:
>   More specifically, the [RFC5510] document introduced such Reed-
>   Solomon codes and several associated FEC schemes that are compatible
>   with the [RFC5052] framework.  The present document inherits from
>   [RFC5510], Section 8 "Reed-Solomon Codes Specification for the
>   Erasure Channel", the specifications of the core Reed-Solomon codes
>   based on Vandermonde matrices, and specifies a simple FEC scheme that
>   is compatible with the FECFRAME framework [RFC6363]:
>
>   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;
>
>   Therefore sections 4, 5, 6 and 7 of [RFC5510], that define [RFC5052]
>   specific Formats and Procedures, are not considered and are replaced
>   by FECFRAME specific Formats and Procedures.
>
>** Section 5.3:
>
>OLD:
>
>   The present document inherits from [RFC5510] the specification of the
>   core Reed-Solomon codes based on Vandermonde matrices for a packet
>   transmission channel.
>
>NEW:
>
>   The present document inherits from [RFC5510], Section 8 "Reed-Solomon
>   Codes Specification for the Erasure Channel", the specifications of
>   the core Reed-Solomon codes based on Vandermonde matrices.
>
>
>As soon as possible, I'll update the LDPC document as well, unlike
>what I said previously, in the same manner. Saying that all the Formats
>and Procedures of RFC5170 are replaced by FECFRAME variants
>can clarify a little bit the document.
>
>
>Concerning (2), same answer than for the LDPC document (it's not
>an exhaustive list).
>
>
>Cheers,
>
>    Vincent, on behalf of the authors
>
>
>---
>	€ From: "Luby, Michael" <luby at qti.qualcomm.com>
>	€ To: "ietf at ietf.org" <ietf at ietf.org>
>	€ Cc: "Luby, Michael" <luby at qti.qualcomm.com>, "fecframe at ietf.org"
><fecframe at ietf.org>
>	€ Date: Thu, 11 Oct 2012 17:30:31 +0000
>	€ In-reply-to: <20121008141129.10923.33854.idtracker at ietfa.amsl.com>
>
>Some quick comments.
>
>(1) This proposal relies upon parts of RFC 5510 for the definition of the
>underlying Reed-Solomon code.  However, it isn't completely explicit in
>this proposal about what exact parts/sections of RFC 5510 are to be used
>in this proposal and how.  It would seem that explicit references to the
>particular sections of RFC 5510 that are being used, and exactly how these
>parts of RFC 5510 are being inherited and used, would be useful (probably
>necessary).
>
>(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 Oct 8, 2012, 16:11, The IESG wrote:
>> 
>> The IESG has received a request from the FEC Framework WG (fecframe) to
>> consider the following document:
>> - 'Simple Reed-Solomon Forward Error Correction (FEC) Scheme for
>> FECFRAME'
>>  <draft-ietf-fecframe-simple-rs-04.txt> as Proposed Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2012-10-22. Exceptionally, comments may
>>be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>> 
>> 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.
>>   The price to pay is a limit on the maximum source block size, on the
>>   maximum number of encoding symbols, and a computational complexity
>>   higher than that of LDPC codes for instance.
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/
>> 
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ballot/
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
>> _______________________________________________
>> Fecframe mailing list
>> Fecframe@ietf.org
>> https://www.ietf.org/mailman/listinfo/fecframe
>