From vincent.roca@inria.fr Tue Nov 6 07:39:03 2012 Return-Path: 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 8323821F870D; Tue, 6 Nov 2012 07:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 aFXf1pjor8Qa; Tue, 6 Nov 2012 07:39:02 -0800 (PST) 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 0FFBF21F86A6; Tue, 6 Nov 2012 07:39:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,722,1344204000"; d="scan'208";a="180385135" Received: from ral126r.vpn.inria.fr ([128.93.178.126]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 06 Nov 2012 16:38:59 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Vincent Roca In-Reply-To: <20121008141129.10923.33854.idtracker@ietfa.amsl.com> Date: Tue, 6 Nov 2012 16:38:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C779DC7-564A-4EEA-BEAA-AD9168863FF0@inria.fr> References: <20121008141129.10923.33854.idtracker@ietfa.amsl.com> To: Michael Luby X-Mailer: Apple Mail (2.1085) Cc: ietf@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 15:39:03 -0000 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 <=3D m <=3D 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 <=3D m <=3D 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 --- =95 From: "Luby, Michael" =95 To: "ietf at ietf.org" =95 Cc: "Luby, Michael" , "fecframe at = ietf.org" =95 Date: Thu, 11 Oct 2012 17:30:31 +0000 =95 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: >=20 > 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' > as Proposed Standard >=20 > 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. >=20 > Abstract >=20 >=20 > This document describes a fully-specified simple FEC scheme for = Reed- > Solomon codes over GF(2^^m), with 2 <=3D m <=3D 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. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From internet-drafts@ietf.org Tue Nov 6 07:42:07 2012 Return-Path: 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 13B8521F89F8; Tue, 6 Nov 2012 07:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 IcNO-DN-69AD; Tue, 6 Nov 2012 07:42:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2FE21F8965; Tue, 6 Nov 2012 07:42:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106154206.25382.98199.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 07:42:06 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-simple-rs-05.txt X-BeenThere: fecframe@ietf.org 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: Tue, 06 Nov 2012 15:42:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Simple Reed-Solomon Forward Error Correction (FEC) Schem= e for FECFRAME Author(s) : Vincent Roca Mathieu Cunche Jerome Lacan Amine Bouabdallah Kazuhisa Matsuzono Filename : draft-ietf-fecframe-simple-rs-05.txt Pages : 22 Date : 2012-11-06 Abstract: This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 <=3D m <=3D 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-fecframe-simple-rs-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-fecframe-simple-rs-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From luby@qti.qualcomm.com Tue Nov 6 08:10:28 2012 Return-Path: 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" To: Vincent Roca , "Luby, Michael" Thread-Topic: [Fecframe] Last Call: (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard Thread-Index: AQHNvDkwzEWyMByYtk6ne5/OlWimww== Date: Tue, 6 Nov 2012 16:10:07 +0000 Message-ID: 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" , "fecframe@ietf.org" Subject: Re: [Fecframe] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:10:28 -0000 Vincent,=20 Thanks, I think this will help the document. Mike On 11/6/12 4:38 PM, "Vincent Roca" 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 <=3D m <=3D 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 <=3D m <=3D 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 > > >--- > =80 From: "Luby, Michael" > =80 To: "ietf at ietf.org" > =80 Cc: "Luby, Michael" , "fecframe at ietf.org= " > > =80 Date: Thu, 11 Oct 2012 17:30:31 +0000 > =80 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: >>=20 >> 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' >> as Proposed Standard >>=20 >> 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. >>=20 >> Abstract >>=20 >>=20 >> This document describes a fully-specified simple FEC scheme for Reed- >> Solomon codes over GF(2^^m), with 2 <=3D m <=3D 16, that can be used t= o >> 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. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > From wwwrun@rfc-editor.org Fri Nov 30 15:09:50 2012 Return-Path: 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 B4E7A21F89DC; Fri, 30 Nov 2012 15:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 LhuQoH5lBpMv; Fri, 30 Nov 2012 15:09:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 30A9821F8708; Fri, 30 Nov 2012 15:09:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E3372B1E002; Fri, 30 Nov 2012 15:01:48 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121130230148.E3372B1E002@rfc-editor.org> Date: Fri, 30 Nov 2012 15:01:48 -0800 (PST) Cc: fecframe@ietf.org, rfc-editor@rfc-editor.org Subject: [Fecframe] RFC 6801 on Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework X-BeenThere: fecframe@ietf.org 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: Fri, 30 Nov 2012 23:09:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6801 Title: Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework Author: U. Kozat, A. Begen Status: Informational Stream: IETF Date: November 2012 Mailbox: kozat@docomolabs-usa.com, abegen@cisco.com Pages: 11 Characters: 24923 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fecframe-pseudo-cdp-05.txt URL: http://www.rfc-editor.org/rfc/rfc6801.txt This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the FEC Framework Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC