Subject: Re: [Fecframe] Re: WG Action: FEC Framework (fecframe)

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 6 Jun 2006 10:19:56 -0700

Mark,

How is this effort progressing? Will you have this submitted for Montreal?

Thanks,
Greg

On 5/7/06, Mark Watson <[email-masked]> wrote:
> 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
>
> "Transport protocol" - the protocol used for transport of the data
> stream being protected - e.g., UDP
>
> "Application protocol" - control protocols used to establish & modify
> the media stream - e.g. RTSP
>
> "Source block" - the group of media packets which are to be FEC
> protected as a single block
>
> "Protection amount" - the relative increase in data sent due to the use
> of FEC
>
> "SHALL" requirements:
> ---------------------
>
> 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)
>
> 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:[email-masked]]
> Sent: Friday, May 05, 2006 7:33 AM
> To: [email-masked]
> 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 <[email-masked]> 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)
> > =========================
> >
> > Current Status: Active Working Group
> >
> > Chairs:
> > Greg Shepherd ([email-masked])
> > Marshall Eubanks ([email-masked])
> >
> > Transport Area Director(s):
> > Magnus Westerlund ([email-masked])
> > Lars Eggert ([email-masked])
> >
> > Transport Area Advisor:
> > Magnus Westerlund ([email-masked])
> >
> > General Discussion: [email-masked]
> > 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/fecframe
>

_______________________________________________
Fecframe mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe