From fecframe-bounces@ietf.org Mon May 01 11:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaaJN-0004Af-O8; Mon, 01 May 2006 11:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaaJM-00046p-Ge for fecframe@ietf.org; Mon, 01 May 2006 11:27:44 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaaJL-000765-AA for fecframe@ietf.org; Mon, 01 May 2006 11:27:44 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4480795 for fecframe@ietf.org; Mon, 01 May 2006 11:27:37 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) References: <4456283A.5030603@isoc.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00A41A57-E275-4760-8E92-ABBA9F028475@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Mon, 1 May 2006 11:27:41 -0400 To: fecframe@ietf.org X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Fecframe] Fwd: IETF Meeting Survey X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org (Acting as if we were a working group... ) If you haven't done so, and you care about the meeting quality, I would urge you to fill out the survey. If you feel that the survey needs more questions / different questions or that there is something else that needs changing, please send that to me or to the IAD directly. Regards Marshall Eubanks Begin forwarded message: > From: Ray Pelletier > Date: May 1, 2006 11:24:42 AM EDT > To: wgchairs@ietf.org > Subject: IETF Meeting Survey > > All; > It has been suggested that if I really wanted to get feedback on > the Meeting Survey (and I do) I should have it forwarded by the WG > Chairs to the working groups - so this is a request that you ask > members of the working groups to complete a short survey that > focuses primarily, but not exclusively, on their meeting experience > in Dallas. > I truly want the info to make the changes members of the community > want, if possible and greatly appreciate your assistance in this > regard. > > Those interested in taking the survey can find it at: > http://www.surveymonkey.com/s.asp?u=649182049947 > > Thanks > Ray Pelletier > IETF Admininstrative Director > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue May 02 18:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3gx-00082f-NJ; Tue, 02 May 2006 18:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3gw-00082R-HU; Tue, 02 May 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3gw-00056B-6U; Tue, 02 May 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k42Mo10e013242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fb3gv-0007z5-8D; Tue, 02 May 2006 18:50:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 02 May 2006 18:50:01 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: fecframe@ietf.org Subject: [Fecframe] WG Action: FEC Framework (fecframe) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. +++ FEC Framework (fecframe) ========================= Current Status: Active Working Group Chairs: Greg Shepherd (gjshep@gmail.com) Marshall Eubanks (tme@multicasttech.com) Transport Area Director(s): Magnus Westerlund (magnus.westerlund@ericsson.com) Lars Eggert (lars.eggert@netlab.nec.de) Transport Area Advisor: Magnus Westerlund (magnus.westerlund@ericsson.com) General Discussion: fecframe@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/fecframe Archive: http://www1.ietf.org/mail-archive/web/fecframe/current/index.html Description: The object of this group is to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The group will develop a protocol framework for application of FEC codes to arbitrary packet flows over unreliable transport protocols over both IP multicast and unicast. The application of the FEC codec on an aggregate of multiple packet flows may be investigated and considered to be included in the solution. The FECFrame working group will use the building block approach (RFC 3269), especially the FEC Building Block (RFC 3452), developed by the RMT working group. The FEC Building Block was developed to ensure that the RMT framework developed can support multiple FEC codes and maintain independence between FEC codes and protocols based on the framework. The FECFrame WG may develop new FEC schemes if necessary to provide substantial performance gains for the intended applications. However the acceptance of any FEC scheme will require multiple, prior, detailed reviews of the FEC code by independent experts from both the IETF and the broader community, since it is likely that the IETF working group will not include a large enough number of suitable experts in its working set. If these reviews are positive, then Working Group acceptance of an FEC scheme work item still needs the approval of the responsible Area Director. A primary objective of this framework is to support FEC for real-time media applications using RTP over UDP, such as on demand streaming and audio/video broadcast. Other potential usages of the framework may be brought to the working group for consideration during the development of the requirements, to enable future support of those usages. The group will coordinate closely with the AVT and MMUSIC working groups to ensure that the streaming use-case is fully specified both in terms of interactions with RTP/RTCP and application layer signalling. The group will also coordinate with the DCCP working group, at least to consider that transport protocol's role in streaming media. The interactions of the framework with existing and used security mechanisms must also be considered. The group will work with the RMT working group to ensure that the FEC Building Block defined in RMT supports both the RMT use-cases (object delivery over multicast) and the more general FEC protection of flow(s) over unreliable unicast and multicast transport. Specification of hybrid schemes involving both retransmission and forward error correction is out of scope of the group. MILESTONES: Nov 06 - Working Group consensus on requirements and their prioritization for the FEC protocol framework Mar 07 - Completed selection of solution to develop and mature Nov 07 - FEC Streaming Framework submitted as Proposed Standard Nov 07 - FEC framework requirements submitted as Informational Mar 08 - Usage of FEC framework with RTP submitted as Proposed Standard Mar 08 - FEC framework signalling specification submitted as Proposed Standard Mar 08 - Discuss re-chartering _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri May 05 10:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1N4-0004oM-K6; Fri, 05 May 2006 10:33:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1N2-0004oH-Uo for fecframe@ietf.org; Fri, 05 May 2006 10:33:28 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1N2-0006T5-Jr for fecframe@ietf.org; Fri, 05 May 2006 10:33:28 -0400 Received: by py-out-1112.google.com with SMTP id m51so1022374pye for ; Fri, 05 May 2006 07:33:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l9NC+HIDROGA7Fi5pQMoW50U3AUjWpb1A9Q+XYH1F8e2PbSxdD4nELM2WSntKTkkvjmhTm5CwJCErplJtCHyhCkeQH7WHSZNFlwl1bUEj6N+OstV379nyVueMGSu6QsXLNs1Kc01YWj8pf8+AWW0GeXK9fhqhx+RXxk8DJ7tOjc= Received: by 10.35.66.12 with SMTP id t12mr766487pyk; Fri, 05 May 2006 07:33:28 -0700 (PDT) Received: by 10.35.110.17 with HTTP; Fri, 5 May 2006 07:33:28 -0700 (PDT) Message-ID: <38c19b540605050733l42664d7fk3ed701f0ee41790@mail.gmail.com> Date: Fri, 5 May 2006 07:33:28 -0700 From: "Greg Shepherd" To: fecframe@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Subject: [Fecframe] Re: WG Action: FEC Framework (fecframe) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Hello, Okay it's official and the clock is now ticking - two clocks actually. One obviously is our own Milestone clock which sets our first goal of having "Working Group consensus on requirements and their prioritization for the FEC protocol framework" by Nov 06. This means we only have the upcoming July meeting before our first Milestone and should have a solid requirements draft by the November meeting. We should certainly have our first real WG meeting in Montreal to get working on the reqs. The 2nd clock gives us one month to prepare for our July meeting agenda. Please let this message serve as a call for agenda items for Montreal in July. I'll follow this up with an agenda outline. Thanks, Greg On 5/2/06, IESG Secretary wrote: > A new IETF working group has been formed in the Transport Area. For > additional information, please contact the Area Directors or the WG Chair= s. > > +++ > > FEC Framework (fecframe) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > Current Status: Active Working Group > > Chairs: > Greg Shepherd (gjshep@gmail.com) > Marshall Eubanks (tme@multicasttech.com) > > Transport Area Director(s): > Magnus Westerlund (magnus.westerlund@ericsson.com) > Lars Eggert (lars.eggert@netlab.nec.de) > > Transport Area Advisor: > Magnus Westerlund (magnus.westerlund@ericsson.com) > > General Discussion: fecframe@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/fecframe > Archive: http://www1.ietf.org/mail-archive/web/fecframe/current/index.htm= l > > Description: > > The object of this group is to develop specifications for using forward > error correction (FEC) codes with applications in the Internet to > provide protection against packet loss. The group will develop a > protocol framework for application of FEC codes to arbitrary packet > flows over unreliable transport protocols over both IP multicast and > unicast. The application of the FEC codec on an aggregate of multiple > packet flows may be investigated and considered to be included in the > solution. > > The FECFrame working group will use the building block approach (RFC > 3269), especially the FEC Building Block (RFC 3452), developed by the > RMT working group. The FEC Building Block was developed to ensure that > the RMT framework developed can support multiple FEC codes and maintain > independence between FEC codes and protocols based on the framework. The > FECFrame WG may develop new FEC schemes if necessary to provide > substantial performance gains for the intended applications. However > the acceptance of any FEC scheme will require multiple, prior, detailed > reviews of the FEC code by independent experts from both the IETF and > the broader community, since it is likely that the IETF working group > will not include a large enough number of suitable experts in its > working set. If these reviews are positive, then Working Group > acceptance of an FEC scheme work item still needs the approval of the > responsible Area > Director. > > A primary objective of this framework is to support FEC for real-time > media applications using RTP over UDP, such as on demand streaming and > audio/video broadcast. Other potential usages of the framework may be > brought to the working group for consideration during the development of > the requirements, to enable future support of those usages. The group > will coordinate closely with the AVT and MMUSIC working groups to ensure > that the streaming use-case is fully specified both in terms of > interactions with RTP/RTCP and application layer signalling. The group > will also coordinate with the DCCP working group, at least to consider > that transport protocol's role in streaming media. The interactions of > the framework with existing and used security mechanisms must also be > considered. > > The group will work with the RMT working group to ensure that the FEC > Building Block defined in RMT supports both the RMT use-cases (object > delivery over multicast) and the more general FEC protection of > flow(s) over unreliable unicast and multicast transport. > > Specification of hybrid schemes involving both retransmission and > forward error correction is out of scope of the group. > > MILESTONES: > > Nov 06 - Working Group consensus on requirements and their > prioritization for the FEC protocol framework > Mar 07 - Completed selection of solution to develop and mature > Nov 07 - FEC Streaming Framework submitted as Proposed Standard > Nov 07 - FEC framework requirements submitted as Informational > Mar 08 - Usage of FEC framework with RTP submitted as Proposed Standard > Mar 08 - FEC framework signalling specification submitted as Proposed > Standard > Mar 08 - Discuss re-chartering > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun May 07 22:25:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvRH-0005ra-DD; Sun, 07 May 2006 22:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvRH-0005rV-00 for fecframe@ietf.org; Sun, 07 May 2006 22:25:35 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcvRE-0002I7-Iu for fecframe@ietf.org; Sun, 07 May 2006 22:25:34 -0400 Received: from [172.23.129.4] (helo=NTXBEUS01.exchange.xchg) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FcvRA3VCS-0001zV; Sun, 07 May 2006 22:25:30 -0400 Received: from NTXBEUS02.exchange.xchg ([172.23.129.5]) by NTXBEUS01.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 May 2006 22:25:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Fecframe] Re: WG Action: FEC Framework (fecframe) Date: Sun, 7 May 2006 22:24:51 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Re: WG Action: FEC Framework (fecframe) Thread-Index: AcZwUOMyoUK0od9QQcmTzFwizUgK/AB9EO8g From: "Mark Watson" To: X-OriginalArrivalTime: 08 May 2006 02:25:29.0016 (UTC) FILETIME=[AC45A380:01C67246] X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Greg, all, Ok, we can get started! The first agenda item I'd suggest is a discussion on requirements for the framework and I'd certainly be happy to provide some input on this in the form of an Internet Draft. To this end, here are some suggestions for requirement items (in outline form - they would each need fleshing out a bit). Please let me know your comments, and then the first draft can include the results of some initial discussion: Terminology ----------- "FEC Framework" - the thing we are designing - a general framework which, when combined with an "FEC scheme" and an application protocol which supports some minimal FEC framework-related requirements (which we shall define) produces a complete protocol for FEC protection of that application. "Media protocol" (good term?) - the protocol used for the data stream being protected - e.g. RTP=20 "Transport protocol" - the protocol used for transport of the data stream being protected - e.g., UDP=20 "Application protocol" - control protocols used to establish & modify the media stream - e.g. RTSP=20 "Source block" - the group of media packets which are to be FEC protected as a single block=20 "Protection amount" - the relative increase in data sent due to the use of FEC "SHALL" requirements: --------------------- =20 Req-01: The FEC Framework shall support of a wide range of FEC codes, using the abstractions of the FEC Building Block defined in RMT (including short and long block FEC codes, systematic and non-systematic codes) Req-02: The FEC Framework shall support variable source block sizes, including real-time variation of source block size between blocks within a stream Req-03: The FEC Framework shall support variable protection amounts, including real-time variation of protection amount between blocks within a stream Req-04: The FEC Framework shall be independent of the media protocols (provided that media protocol uses one of the supported transport protocols) and codecs Req-05: The FEC Framework shall place minimal requirements on the application protocols Req-06: The FEC Framework shall support variable media data rates Req-07: The FEC Framework shall support variable media packet sizes Req-08: The FEC Framework shall provide support of combined protection of multiple packet flows Req-09: The FEC Framework shall provide support of multiple transport protocols for the media protocols (UDP, DCCP, others ?) Req-10: The FEC Framework shall provide support for definition of backwards-compatible FEC protocols (i.e. where the source packets are not modified in any way)=20 Req-11: The FEC Framework shall provide support for different media protocols (RTP, MIKEY, others ?) "SHOULD" requirements: --------------------- Req-12: The FEC Framework should be constructed such that the FEC streaming protocol defined by 3GPP in TS26.346 is a valid instantiation/use-case (term?) of the FEC Framework Regards, Mark Watson -----Original Message----- From: Greg Shepherd [mailto:gjshep@gmail.com]=20 Sent: Friday, May 05, 2006 7:33 AM To: fecframe@ietf.org Subject: [Fecframe] Re: WG Action: FEC Framework (fecframe) Hello, Okay it's official and the clock is now ticking - two clocks actually. One obviously is our own Milestone clock which sets our first goal of having "Working Group consensus on requirements and their prioritization for the FEC protocol framework" by Nov 06. This means we only have the upcoming July meeting before our first Milestone and should have a solid requirements draft by the November meeting. We should certainly have our first real WG meeting in Montreal to get working on the reqs. The 2nd clock gives us one month to prepare for our July meeting agenda. Please let this message serve as a call for agenda items for Montreal in July. I'll follow this up with an agenda outline. Thanks, Greg On 5/2/06, IESG Secretary wrote: > A new IETF working group has been formed in the Transport Area. For > additional information, please contact the Area Directors or the WG Chairs. > > +++ > > FEC Framework (fecframe) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > Current Status: Active Working Group > > Chairs: > Greg Shepherd (gjshep@gmail.com) > Marshall Eubanks (tme@multicasttech.com) > > Transport Area Director(s): > Magnus Westerlund (magnus.westerlund@ericsson.com) > Lars Eggert (lars.eggert@netlab.nec.de) > > Transport Area Advisor: > Magnus Westerlund (magnus.westerlund@ericsson.com) > > General Discussion: fecframe@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/fecframe > Archive: http://www1.ietf.org/mail-archive/web/fecframe/current/index.html > > Description: > > The object of this group is to develop specifications for using forward > error correction (FEC) codes with applications in the Internet to > provide protection against packet loss. The group will develop a > protocol framework for application of FEC codes to arbitrary packet > flows over unreliable transport protocols over both IP multicast and > unicast. The application of the FEC codec on an aggregate of multiple > packet flows may be investigated and considered to be included in the > solution. > > The FECFrame working group will use the building block approach (RFC > 3269), especially the FEC Building Block (RFC 3452), developed by the > RMT working group. The FEC Building Block was developed to ensure that > the RMT framework developed can support multiple FEC codes and maintain > independence between FEC codes and protocols based on the framework. The > FECFrame WG may develop new FEC schemes if necessary to provide > substantial performance gains for the intended applications. However > the acceptance of any FEC scheme will require multiple, prior, detailed > reviews of the FEC code by independent experts from both the IETF and > the broader community, since it is likely that the IETF working group > will not include a large enough number of suitable experts in its > working set. If these reviews are positive, then Working Group > acceptance of an FEC scheme work item still needs the approval of the > responsible Area > Director. > > A primary objective of this framework is to support FEC for real-time > media applications using RTP over UDP, such as on demand streaming and > audio/video broadcast. Other potential usages of the framework may be > brought to the working group for consideration during the development of > the requirements, to enable future support of those usages. The group > will coordinate closely with the AVT and MMUSIC working groups to ensure > that the streaming use-case is fully specified both in terms of > interactions with RTP/RTCP and application layer signalling. The group > will also coordinate with the DCCP working group, at least to consider > that transport protocol's role in streaming media. The interactions of > the framework with existing and used security mechanisms must also be > considered. > > The group will work with the RMT working group to ensure that the FEC > Building Block defined in RMT supports both the RMT use-cases (object > delivery over multicast) and the more general FEC protection of > flow(s) over unreliable unicast and multicast transport. > > Specification of hybrid schemes involving both retransmission and > forward error correction is out of scope of the group. > > MILESTONES: > > Nov 06 - Working Group consensus on requirements and their > prioritization for the FEC protocol framework > Mar 07 - Completed selection of solution to develop and mature > Nov 07 - FEC Streaming Framework submitted as Proposed Standard > Nov 07 - FEC framework requirements submitted as Informational > Mar 08 - Usage of FEC framework with RTP submitted as Proposed Standard > Mar 08 - FEC framework signalling specification submitted as Proposed > Standard > Mar 08 - Discuss re-chartering > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue May 16 15:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4tz-00045C-TR; Tue, 16 May 2006 15:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4ty-00044j-TH for fecframe@ietf.org; Tue, 16 May 2006 15:08:14 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4ty-0007sC-6C for fecframe@ietf.org; Tue, 16 May 2006 15:08:14 -0400 Received: by nf-out-0910.google.com with SMTP id x30so32289nfb for ; Tue, 16 May 2006 12:08:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=oul2eYdo1pGw0sitQ+DL3/IBXGiGxpkNIGYMhHTDOPn0SuG4uCqsuULHknJX6fiadkbnvjDH08EWL4ooZ6XTKIyk5FQNL7nxRlzQGPQtxE0jS3R3aO4lbQNcltcheZonUWbRcG/ixVRsitl8WEYP9BJ2yGAUbkpxZ9HMxzyZFy8= Received: by 10.49.5.3 with SMTP id h3mr76428nfi; Tue, 16 May 2006 12:08:13 -0700 (PDT) Received: by 10.49.2.15 with HTTP; Tue, 16 May 2006 12:08:13 -0700 (PDT) Message-ID: <38c19b540605161208u724f5b94qf19442e5bda8b5ef@mail.gmail.com> Date: Tue, 16 May 2006 12:08:13 -0700 From: "Greg Shepherd" To: tsvwg@ietf.org, rmt@ietf.org, dccp@ietf.org, avt@ietf.org, mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: fecframe@ietf.org Subject: [Fecframe] FEC Framework (fecframe) WG Invitation X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Hello, The FECFrame WG has been approved by the IESG and will be holding the first WG meeting in Montreal. We are still assembling the agenda for the meeting, but from the charter you can see our top priority is to establish the requirements which will be presented and discussed at that time. Please accept this as an invitation to participate and help make the FECFrame effort a success. http://www.ietf.org/html.charters/fecframe-charter.html Thanks, Greg ---------- Forwarded message ---------- From: IESG Secretary Date: May 2, 2006 3:50 PM Subject: WG Action: FEC Framework (fecframe) To: ietf-announce@ietf.org Cc: fecframe@ietf.org, gjshep@gmail.com, tme@multicasttech.com A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. +++ FEC Framework (fecframe) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current Status: Active Working Group Chairs: Greg Shepherd (gjshep@gmail.com) Marshall Eubanks (tme@multicasttech.com) Transport Area Director(s): Magnus Westerlund (magnus.westerlund@ericsson.com) Lars Eggert (lars.eggert@netlab.nec.de) Transport Area Advisor: Magnus Westerlund (magnus.westerlund@ericsson.com) General Discussion: fecframe@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/fecframe Archive: http://www1.ietf.org/mail-archive/web/fecframe/current/index.html Description: The object of this group is to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The group will develop a protocol framework for application of FEC codes to arbitrary packet flows over unreliable transport protocols over both IP multicast and unicast. The application of the FEC codec on an aggregate of multiple packet flows may be investigated and considered to be included in the solution. The FECFrame working group will use the building block approach (RFC 3269), especially the FEC Building Block (RFC 3452), developed by the RMT working group. The FEC Building Block was developed to ensure that the RMT framework developed can support multiple FEC codes and maintain independence between FEC codes and protocols based on the framework. The FECFrame WG may develop new FEC schemes if necessary to provide substantial performance gains for the intended applications. However the acceptance of any FEC scheme will require multiple, prior, detailed reviews of the FEC code by independent experts from both the IETF and the broader community, since it is likely that the IETF working group will not include a large enough number of suitable experts in its working set. If these reviews are positive, then Working Group acceptance of an FEC scheme work item still needs the approval of the responsible Area Director. A primary objective of this framework is to support FEC for real-time media applications using RTP over UDP, such as on demand streaming and audio/video broadcast. Other potential usages of the framework may be brought to the working group for consideration during the development of the requirements, to enable future support of those usages. The group will coordinate closely with the AVT and MMUSIC working groups to ensure that the streaming use-case is fully specified both in terms of interactions with RTP/RTCP and application layer signalling. The group will also coordinate with the DCCP working group, at least to consider that transport protocol's role in streaming media. The interactions of the framework with existing and used security mechanisms must also be considered. The group will work with the RMT working group to ensure that the FEC Building Block defined in RMT supports both the RMT use-cases (object delivery over multicast) and the more general FEC protection of flow(s) over unreliable unicast and multicast transport. Specification of hybrid schemes involving both retransmission and forward error correction is out of scope of the group. MILESTONES: Nov 06 - Working Group consensus on requirements and their prioritization for the FEC protocol framework Mar 07 - Completed selection of solution to develop and mature Nov 07 - FEC Streaming Framework submitted as Proposed Standard Nov 07 - FEC framework requirements submitted as Informational Mar 08 - Usage of FEC framework with RTP submitted as Proposed Standard Mar 08 - FEC framework signalling specification submitted as Proposed Standard Mar 08 - Discuss re-chartering _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri May 19 07:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3EB-0005u3-4N; Fri, 19 May 2006 07:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3EA-0005ty-8j for fecframe@ietf.org; Fri, 19 May 2006 07:33:06 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh3E7-0000Th-T9 for fecframe@ietf.org; Fri, 19 May 2006 07:33:06 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4554760 for fecframe@ietf.org; Fri, 19 May 2006 07:32:35 -0400 Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22AE78EE-1ABB-4367-8501-24C7616A085E@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Fri, 19 May 2006 07:32:59 -0400 To: fecframe@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Fecframe] Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: May 19, 2006 12:00:01 AM EDT > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF > Meeting in Montreal, Quebec, Canada > > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 66th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe