2.8.6 FEC over Transport Framework (fecframe)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


Mark Watson <mark@digitalfountain.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

The object of this group is to develop standards for using forward
error correction (FEC) codes with applications in the Internet to
provide protection against packet loss. The group will develop a
framework for application of FEC codes to arbitrary packet flows over
unreliable transport protocols over both IP multicast and unicast. The
group will build on the work of the RMT working group in the form of
the FEC Building Block developed there to ensure that the framework
developed can support multiple FEC codes and maintain independence
between FEC codes and content delivery protocols. Note: framework
here is a protocol framework, with a design to be determined, but
suitable for interoperable implementations. It is not used in the
sense often used by IETF of a document akin to requirements.

A primary objective of this framework is to support FEC for streaming
media. The group will coordinate closely with AVT and MMUSIC working
groups to ensure that this 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,
considering that transport's role in streaming media.

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 IP
flows over unreliable unicast and multicast transport. The group will
also consider developing its charter to include for proposals for
standardization of specific FEC codes - taking on this work from the
RMT working group - including consideration of their areas of
applicability and generality.

Specification of hybrid schemes involving both retransmission and
forward error correction will be out of scope of the group. However the
group should consider of whether work on such schemes should be
considered in a future phase.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

´╗┐IETF 64 fecframe BOF Minutes

Chair: Mark Watson (mark@digitalfountain.com)

The fecframe BOF was conducted during IETF64 on Wednesday, Nov. 9, from 15:10 to
16:10.  Approximately 60 people attended the BOF (tbc).  The BOF chair, Mark Watson,
reminded the participants of their obligations with respect to IPR, and circulated
blue sheets.  Stephan Wenger volunteered to take this notes.The agenda was accepted
as proposed.

Mark presented a slideset covering his vision of a fecframe WG to be.

Forward Error Correction in this BOF must be seen as a means to recover lost
packets.  It's a forward-only means to combat packet losses (erasures), not a
link-layer mechanism to correct bit errors.  The FEC is calculated on the payloads
and necessary header information of the Transport (e.g. UDP, DCCP).  The main goal
of the WG is not so much to define a specific protocol, but more a "Framework" of
mechanisms (and their interaction) which can be used to define protocols with very
limited effort. 

The target applications comprise audio-visual streaming with high quality and other
stream-based applications (a stream can be seen as a (more or less constant) flow of
packets.  Object protection through FEC stays in RMT.

The justifications for the use of forward protection mechanisms (e.g. FEC) are
manifold, e.g. the unavailability of feedback mechanisms (broadcast, large multicast
groups), but also scaling problems in high-loaded unicast streaming servers, too
long roundtrip times which makes re-transmision inefficient, or cumbersome, and many

(James Polk threw in a remark at this point that the notetaker didn't capture.)

Mark went on suggesting targets for acceptable end-to-end application layer packet
loss rate, e.g. defined in ITU-T Rec. Y.1541.  These numbers were comparatively low,
0.1% and lower.  

A short discussion commenced between Stephan Wenger, Jonathan Rosenberg, and
Yakovlew Stein, on the validity of these values and the best ways to combat the
losses.  Arguments were made in favor and against both source and channel based
coding.  It was clarified that (perhaps outside niche applications), FEC is
primarily useful not for VoIP type low latency, but more for medium latency
application like streaming.  The discussion was getting out of focus for the BOF,
and it was suggested to take it offline.
Mark continued with more properties a FEC framework could help achieving.  For
example, the IETF likes end-to-end solutions, and FEC as proposed (in contrast to
link layer enhancements) is such an end-to-end solution.  

While many see the greatest value of FEC in protecting end-to-end transmissions that
involve at least one highly noisy access link, Mark also clarified that reducing the
packet loss rate in the backbone, e.g. from 10E-5 to 10E-6 or lower, is also very
helpful for the overall performance of the backbone and the Internet.

FEC does not solve the congestion loss problem, congestion control principles need
to be obeyed.  This is done by reducing the rate of both the packet stream and its
protection, by comparable amounts.

Previous work includes RMT's FEC Building block, protocols for object delivery, FEC
schemes, AVT's RTP meta payloads for protection (RFC2733, ULP), 3GPP's MBMS
mechanisms (defined in TS26.346) which protect all UDP traffic, and, the framework
described in draft-watson-tsvwg-fec-sf-00. This draft is one example of a protocol
framework that could result from the WG to be.

The objectives of the WG to be can be taken from the BOF description: sketch up a
requirements draft, develop a framework, develop a "streaming protocol" in
coordination with AVT, MMUSIC, and perhaps other work?

The proposed way forward is to form new working group, as other WGs appear not to be
appropriate. Deliverables for a WG would be: a living "requirements" draft, a
standards track FEC framework, and document on how the FEC framework is used for

With this, Mark opened the floor for an open mike discussion.

Jonathon Rosenberg asked to clarify the relationship between fecframe and AVT work.
 There appears to be overlap, e.g. with respect to ULP, RFC 2733, and perhaps other
drafts. Magnus Westerlund replied that ULP (replacement of RFC 2733) will be
published soon, the Reed-Solomon UXP, is likely to be replaced by this work, however
all of AVT efforts are RTP payload specs and not directly above transport.

Ruscoe: Intention: Tweak existing specifications or develop new ones.

Mark: Intention is to provide new specifications which will draw heavily on the RMT
work and will not overlap.

Lorenzo: Answer is based on the decision what to do with ongoing work in RMT, work
could end up in either fecframe or in RMT

Yacob Stein: It's ok that this work is not in AVT.  However, parallel work in media
standardization groups on error resilient source coding and joint source/channel
optimization is encouraged.

Yacob Stein triggered a short discussion on the subject of IPR, asking if there is
IPR on the subject.  Mark: yes, there is IPR. The FEC schemes (e.g. Raptor) are
RAND, other work so far "free". Lorenzo also commented that in RMT the FEC schemes
has IPR. Vincent commented that he didn't like the IPR situation and the Digital
Fountain IPR reciprocity clause, but would get comments from his company lawyers.
Mark confirmed that there is a reciprocity clause on the statement but otherwise a
free license. Yacob Stein later commented after reviewing the Digital Fountains IPR
statement on draft-watson-tsvwg-fec-sf-00 that it is not a "royalty-free license",
but rather a "will not assert" statement. The FEC schemes are however RAND. Mark
Watson (speaking for DF) responded that his understanding of the company position
was royalty free with reciprocity, and that he would try to address the comments in
short order.

Rob Rein raised some concerns regarding VoIP. VoIP needs very low delay, but has a
fairly high loss tolerance. Mark responded that FEC may not be appropriate for your
conversational application. Magnus Westerlund commented that block lengths needs to
be 200 ms or more to get any decent efficiency, thus very short blocks on the order
of 20 ms is not really usable. Colin Perkins agreed that fecframe is not appropriate
for conversational real-time media, but is useful elsewhere. It should be clarified
which applications that fecframe will apply to. Colin's suggestion was "long lived
flows". Stephan Wenger commented that we shouldn't take to narrow scope either.
There are for example cases of joint source and channel coding for video in which
FEC is appropriate also in low-delay applications. Magnus responded that yes, as the
bit-rate goes up the possibility for low delay applications increases. Yacob Stein
responded that he still don't think fecframe would be useful for VoIP telephony and

At this point, it was suggested to take further technical discussions offline or
later; after all the BOF is there to gauge interest in a subject and not to solve

James Polk asked which timeframe of the work in the WG is planned to have? Mark
Watson responded that he liked to have a very quick, very focused effort. A comment
from the floor was "single digit number of years" which resulted in laughter. Mark
sees as a target to have a good requirements document ready at the next meeting.
Colin Perkins commented that the requirements discussion should reach its
conclusions from appropriate applications. Yacob Stein asked if it rules out usage
of retransmission, which Mark Watson confirmed. Magnus Westerlund commented that the
requirements phase should start with applications and agree on which we would like
to support and from that generate requirements. Jonathan Lennox stated that
requirements should focus on streaming.

James Polk asked if the work perhaps should be happening elsewhere, e.g. in TSVWG,
as the workload is planned to go down there. Allison Mankin responded that although
TSVWG may wind down a bit it is not a good idea to have it in TSVWG. This work would
benefit from the focus of its own WG and therefore Allison supports the formation of
an new WG. 

Someone asked if the meeting should review the charter proposal? Mark responded that
he intended to do details of the charter later. But the base is the charter proposal
in the BOF description. 

Greg Livovitz asked if this is an API problem and not a protocol problem.

Allison Mankin (AD): API could be considered by a WG, assuming that there were a WG.
Discuss charter.

At this point, the BOF description was put on screen and people were given time to
read.  Allison stated that Magnus Westerlund and Stephan Wenger volunteered as WG
chair so to free Mark for an editor position, and suggested a hmm for establishing a
WG. The BOF loudly and clearly hmmd for forming a WG. No one hmmd against forming a

Mark asked for any other business.  No other business where raised, and the meeting
was adjourned.



Agenda, Materials and Background