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

From: "Mark Watson" <[email-masked]>
Date: Sun, 7 May 2006 22:24:51 -0400

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