draft-ietf-fecframe-framework-13.txt   draft-ietf-fecframe-framework-14.txt 
FEC Framework M. Watson FEC Framework M. Watson
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Standards Track A. Begen Intended status: Standards Track A. Begen
Expires: August 19, 2011 Cisco Expires: September 5, 2011 Cisco
V. Roca V. Roca
INRIA INRIA
February 15, 2011 March 4, 2011
Forward Error Correction (FEC) Framework Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-13 draft-ietf-fecframe-framework-14
Abstract Abstract
This document describes a framework for using Forward Error This document describes a framework for using Forward Error
Correction (FEC) codes with applications in public and private IP Correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss. The framework networks to provide protection against packet loss. The framework
supports applying FEC to arbitrary packet flows over unreliable supports applying FEC to arbitrary packet flows over unreliable
transport and is primarily intended for real-time, or streaming, transport and is primarily intended for real-time, or streaming,
media. This framework can be used to define Content Delivery media. This framework can be used to define Content Delivery
Protocols that provide FEC for streaming media delivery or other Protocols that provide FEC for streaming media delivery or other
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2011. This Internet-Draft will expire on September 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 41, line 31 skipping to change at page 41, line 31
this can also be achieved by using an RTP framing for FEC repair this can also be achieved by using an RTP framing for FEC repair
packets with a different payload type. Both source and repair packets with a different payload type. Both source and repair
packets can then be sent on the same transport-layer flow. It is packets can then be sent on the same transport-layer flow. It is
the responsibility of the sender to select the appropriate the responsibility of the sender to select the appropriate
mechanism when needed. mechanism when needed.
o Within End-Systems vs. within Middleboxes: When the FEC Framework o Within End-Systems vs. within Middleboxes: When the FEC Framework
is used within middleboxes, it is RECOMMENDED that the paths is used within middleboxes, it is RECOMMENDED that the paths
between the hosts where the sending applications run and the between the hosts where the sending applications run and the
middlebox that performs FEC encoding be as reliable as possible, middlebox that performs FEC encoding be as reliable as possible,
since these paths are not protected against erasures by default. i.e., are not prone to packet loss, packet reordering, or varying
delays in delivering packets.
Similarly, it is RECOMMENDED that the paths between the Similarly, it is RECOMMENDED that the paths between the
middleboxes that perform FEC decoding and the end-systems where middleboxes that perform FEC decoding and the end-systems where
the receiving applications operate, in situations where this is a the receiving applications operate, in situations where this is a
different host, be as reliable as possible since these paths are different host, be as reliable as possible.
not protected against losses by default.
The recommendation for the sending side is particularly important The recommendation for the sending side is particularly important
with FEC schemes that do not modify the ADU for backward with FEC schemes that do not modify the ADU for backward
compatibility purposes (i.e. do not use any Explicit Source FEC compatibility purposes (i.e. do not use any Explicit Source FEC
Payload ID) and rely for instance on the RTP sequence number field Payload ID) and rely for instance on the RTP sequence number field
to identify FEC source packets within their source block. In this to identify FEC source packets within their source block. In this
case, a lost or excessively delayed packet on this path directly case, packet loss or packet reordering leads to a gap in the RTP
leads to a gap in the RTP sequence number space seen by the sequence number space seen by the FECFRAME instance. Similarly,
FECFRAME instance. With FEC schemes that indicate in the Repair varying delay in delivering packets over this path can lead to
FEC Payload ID, for each source block, the base RTP sequence significant timing issues. With FEC schemes that indicate in the
number and number of consecutive RTP packets that belong to this Repair FEC Payload ID, for each source block, the base RTP
source block, a missing ADU could cause the FECFRAME sender to sequence number and number of consecutive RTP packets that belong
switch to a new source block. However, some FEC schemes and/or to this source block, a missing ADU or an ADU delivered out of
receivers may not necessarily handle such varying source block order could cause the FECFRAME sender to switch to a new source
sizes. Thus, all the ADUs SHOULD be fed into the FEC encoder in block. However, some FEC schemes and/or receivers may not
their proper sequence and within a desired certain delay. For necessarily handle such varying source block sizes. In this case,
cases when this cannot be guaranteed, the sender and receiver another solution SHOULD be considered that is use-case specific
implementations need to concider a potential solution and its and whose consequences need to be carefully considered (e.g., by
consequences. duplicating the last ADU received before the loss, or by inserting
a zero'ed ADU, depending on the ADU flow nature).
o Protecting a Single Flow vs. Several Flows Globally: In the o Protecting a Single Flow vs. Several Flows Globally: In the
general case, the various ADU flows that are globally protected general case, the various ADU flows that are globally protected
can have different features, and in particular different real-time can have different features, and in particular different real-time
requirements (in case of real-time flows). The process of requirements (in case of real-time flows). The process of
globally protecting these flows SHOULD take into account the globally protecting these flows SHOULD take into account the
requirements of each individual flow. In particular, it would be requirements of each individual flow. In particular, it would be
counter-productive to add repair traffic to a real-time flow for counter-productive to add repair traffic to a real-time flow for
which the FEC decoding delay at a receiver makes decoded ADUs for which the FEC decoding delay at a receiver makes decoded ADUs for
this flow useless because they do not satisfy the associated real- this flow useless because they do not satisfy the associated real-
 End of changes. 7 change blocks. 
20 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/