draft-ietf-tsvwg-fecframe-ext-01.txt   draft-ietf-tsvwg-fecframe-ext-02.txt 
TSVWG V. Roca TSVWG V. Roca
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Standards Track A. Begen Intended status: Standards Track A. Begen
Expires: September 5, 2018 Networked Media Expires: November 2, 2018 Networked Media
March 4, 2018 May 1, 2018
Forward Error Correction (FEC) Framework Extension to Sliding Window Forward Error Correction (FEC) Framework Extension to Sliding Window
Codes Codes
draft-ietf-tsvwg-fecframe-ext-01 draft-ietf-tsvwg-fecframe-ext-02
Abstract Abstract
RFC 6363 describes a framework for using Forward Error Correction RFC 6363 describes a framework for using Forward Error Correction
(FEC) codes with applications in public and private IP networks to (FEC) codes with applications in public and private IP networks to
provide protection against packet loss. The framework supports provide protection against packet loss. The framework supports
applying FEC to arbitrary packet flows over unreliable transport and applying FEC to arbitrary packet flows over unreliable transport and
is primarily intended for real-time, or streaming, media. However is primarily intended for real-time, or streaming, media. However
FECFRAME as per RFC 6363 is restricted to block FEC codes. The FECFRAME as per RFC 6363 is restricted to block FEC codes. The
present document extends FECFRAME to support FEC Codes based on a present document extends FECFRAME to support FEC Codes based on a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 5, 2018. This Internet-Draft will expire on November 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 32 skipping to change at page 3, line 32
intended for real-time or streaming media applications, using intended for real-time or streaming media applications, using
broadcast, multicast, or on-demand delivery. broadcast, multicast, or on-demand delivery.
However [RFC6363] only considers block FEC schemes defined in However [RFC6363] only considers block FEC schemes defined in
accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681],
[RFC6816] or [RFC6865]). These codes require the input flow(s) to be [RFC6816] or [RFC6865]). These codes require the input flow(s) to be
segmented into a sequence of blocks. Then FEC encoding (at a sender segmented into a sequence of blocks. Then FEC encoding (at a sender
or an encoding middlebox) and decoding (at a receiver or a decoding or an encoding middlebox) and decoding (at a receiver or a decoding
middlebox) are both performed on a per-block basis. This approach middlebox) are both performed on a per-block basis. This approach
has major impacts on FEC encoding and decoding delays. The data has major impacts on FEC encoding and decoding delays. The data
packets of continuous media flow(s) can be sent immediately, without packets of continuous media flow(s) may be passed to the transport
delay. But the block creation time, that depends on the number k of layer immediately, without delay. But the block creation time, that
source symbols in this block, impacts the FEC encoding delay since depends on the number k of source symbols in this block, impacts the
encoding requires that all source symbols be known. This block FEC encoding delay since encoding requires that all source symbols be
creation time also impacts the decoding delay a receiver will known. This block creation time also impacts the decoding delay a
experience in case of erasures, since no repair symbol for the receiver will experience in case of erasures, since no repair symbol
current block can be received before. Therefore a good value for the for the current block can be received before. Therefore a good value
block size is necessarily a balance between the maximum decoding for the block size is necessarily a balance between the maximum
latency at the receivers (which must be in line with the most decoding latency at the receivers (which must be in line with the
stringent real-time requirement of the protected flow(s), hence an most stringent real-time requirement of the protected flow(s), hence
incentive to reduce the block size), and the desired robustness an incentive to reduce the block size), and the desired robustness
against long loss bursts (which increases with the block size, hence against long loss bursts (which increases with the block size, hence
an incentive to increase this size). an incentive to increase this size).
This document extends [RFC6363] in order to also support FEC codes This document extends [RFC6363] in order to also support FEC codes
based on a sliding encoding window (A.K.A. convolutional codes). based on a sliding encoding window (A.K.A. convolutional codes).
This encoding window, either of fixed or variable size, slides over This encoding window, either of fixed or variable size, slides over
the set of source symbols. FEC encoding is launched whenever needed, the set of source symbols. FEC encoding is launched whenever needed,
from the set of source symbols present in the sliding encoding window from the set of source symbols present in the sliding encoding window
at that time. This approach significantly reduces FEC-related at that time. This approach significantly reduces FEC-related
latency, since repair symbols can be generated and sent on-the-fly, latency, since repair symbols can be generated and passed to the
at any time, and can be regularly received by receivers to quickly transport layer on-the-fly, at any time, and can be regularly
recover packet losses. Using sliding window FEC codes is therefore received by receivers to quickly recover packet losses. Using
highly beneficial to real-time flows, one of the primary targets of sliding window FEC codes is therefore highly beneficial to real-time
FECFRAME. [RLC-ID] provides an example of such FEC Scheme for flows, one of the primary targets of FECFRAME. [RLC-ID] provides an
FECFRAME, built upon the simple sliding window Random Linear Codes example of such FEC Scheme for FECFRAME, built upon the simple
(RLC). sliding window Random Linear Codes (RLC).
This document is fully backward compatible with [RFC6363] that it This document is fully backward compatible with [RFC6363] that it
extends but does not replace. Indeed: extends but does not replace. Indeed:
o this extension does not prevent nor compromize in any way the o this extension does not prevent nor compromize in any way the
support of block FEC codes. Both types of codes can nicely co- support of block FEC codes. Both types of codes can nicely co-
exist, just like different block FEC schemes can co-exist; exist, just like different block FEC schemes can co-exist;
o any receiver, for instance a legacy receiver that only supports o any receiver, for instance a legacy receiver that only supports
block FEC schemes, can easily identify the FEC Scheme used in a block FEC schemes, can easily identify the FEC Scheme used in a
skipping to change at page 6, line 5 skipping to change at page 6, line 5
FEC Scheme: A specification that defines the additional protocol FEC Scheme: A specification that defines the additional protocol
aspects required to use a particular FEC code with the FEC aspects required to use a particular FEC code with the FEC
Framework. Framework.
FEC Source Packet: At a sender (respectively, at a receiver), a FEC Source Packet: At a sender (respectively, at a receiver), a
payload submitted to (respectively, received from) the transport payload submitted to (respectively, received from) the transport
protocol containing an ADU along with an optional Explicit Source protocol containing an ADU along with an optional Explicit Source
FEC Payload ID. FEC Payload ID.
Protection Amount: The relative increase in data sent due to the use
of FEC.
Repair Flow: The packet flow carrying FEC data. Repair Flow: The packet flow carrying FEC data.
Repair FEC Payload ID: A FEC Payload ID specifically for use with Repair FEC Payload ID: A FEC Payload ID specifically for use with
repair packets. repair packets.
Source Flow: The packet flow to which FEC protection is to be Source Flow: The packet flow to which FEC protection is to be
applied. A source flow consists of ADUs. applied. A source flow consists of ADUs.
Source FEC Payload ID: A FEC Payload ID specifically for use with Source FEC Payload ID: A FEC Payload ID specifically for use with
source packets. source packets.
skipping to change at page 8, line 20 skipping to change at page 8, line 13
an ADU to symbols mapping process that is FEC Scheme specific (see an ADU to symbols mapping process that is FEC Scheme specific (see
below). Once the source block is built, taking into account both the below). Once the source block is built, taking into account both the
FEC Scheme constraints (e.g., in terms of maximum source block size) FEC Scheme constraints (e.g., in terms of maximum source block size)
and the application's flow constraints (e.g., in terms of real-time and the application's flow constraints (e.g., in terms of real-time
constraints), the associated source symbols are handed to the FEC constraints), the associated source symbols are handed to the FEC
Scheme in order to produce an appropriate number of repair symbols. Scheme in order to produce an appropriate number of repair symbols.
FEC Source Packets (containing ADUs) and FEC Repair Packets FEC Source Packets (containing ADUs) and FEC Repair Packets
(containing one or more repair symbols each) are then generated and (containing one or more repair symbols each) are then generated and
sent using UDP (more precisely [RFC6363], Section 7, requires a sent using UDP (more precisely [RFC6363], Section 7, requires a
transport protocol providing an unreliable datagram service, like UDP transport protocol providing an unreliable datagram service, like UDP
or DCCP). In practice FEC Source Packets can be sent as soon as or DCCP). In practice FEC Source Packets may be passed to the
available, without having to wait for FEC encoding to take place. In transport layer as soon as available, without having to wait for FEC
that case a copy of the associated source symbols need to be kept encoding to take place. In that case a copy of the associated source
within FECFRAME for future FEC encoding purposes. symbols needs to be kept within FECFRAME for future FEC encoding
purposes.
At a receiver (not shown), FECFRAME processing operates in a similar At a receiver (not shown), FECFRAME processing operates in a similar
way, taking as input the incoming FEC Source and Repair Packets way, taking as input the incoming FEC Source and Repair Packets
received. In case of FEC Source Packet losses, the FEC decoding of received. In case of FEC Source Packet losses, the FEC decoding of
the associated block may recover all (in case of successful decoding) the associated block may recover all (in case of successful decoding)
or a subset potentially empty (otherwise) of the missing source or a subset potentially empty (otherwise) of the missing source
symbols. After source symbol to ADU mapping, when lost ADUs are symbols. After source symbol to ADU mapping, when lost ADUs are
recovered, they are then assigned to their respective flow (see recovered, they are then assigned to their respective flow (see
below). ADUs are returned to the application(s), either in their below). ADUs are returned to the application(s), either in their
initial transmission order (in that case ADUs received after an initial transmission order (in that case ADUs received after an
 End of changes. 7 change blocks. 
29 lines changed or deleted 27 lines changed or added

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