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 >
- [Fecframe] Last Call: <draft-ietf-fecframe-simple… The IESG
- Re: [Fecframe] Last Call: <draft-ietf-fecframe-si… Vincent Roca
- Re: [Fecframe] Last Call: <draft-ietf-fecframe-si… Luby, Michael