draft-ietf-tsvwg-fecframe-ext-06.txt   draft-ietf-tsvwg-fecframe-ext-07.txt 
TSVWG V. Roca TSVWG V. Roca
Internet-Draft INRIA Internet-Draft INRIA
Updates: 6363 (if approved) A. Begen Updates: 6363 (if approved) A. Begen
Intended status: Standards Track Networked Media Intended status: Standards Track Networked Media
Expires: March 23, 2019 September 19, 2018 Expires: July 8, 2019 January 4, 2019
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-06 draft-ietf-tsvwg-fecframe-ext-07
Abstract Abstract
RFC 6363 describes a framework for using Forward Error Correction RFC 6363 describes a framework for using Forward Error Correction
(FEC) codes to provide protection against packet loss. The framework (FEC) codes 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. However FECFRAME as per RFC 6363 is restricted to block FEC media. However FECFRAME as per RFC 6363 is restricted to block FEC
codes. The present document updates FECFRAME to support FEC Codes codes. This document updates RFC 6363 to support FEC Codes based on
based on a sliding encoding window, in addition to Block FEC Codes, a sliding encoding window, in addition to Block FEC Codes, in a
in a backward compatible way. During multicast/broadcast real-time backward-compatible way. During multicast/broadcast real-time
content delivery, the use of sliding window codes significantly content delivery, the use of sliding window codes significantly
improves robustness in harsh environments, with less repair traffic improves robustness in harsh environments, with less repair traffic
and lower FEC-related added latency. and lower FEC-related added latency.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 23, 2019. This Internet-Draft will expire on July 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Operations and Management Considerations . . . . . . . . . . 18 11. Operations and Management Considerations . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. About Sliding Encoding Window Management (non Appendix A. About Sliding Encoding Window Management (non
Normative) . . . . . . . . . . . . . . . . . . . . . 20 Normative) . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Many applications need to transport a continuous stream of packetized Many applications need to transport a continuous stream of packetized
data from a source (sender) to one or more destinations (receivers) data from a source (sender) to one or more destinations (receivers)
over networks that do not provide guaranteed packet delivery. In over networks that do not provide guaranteed packet delivery. In
particular packets may be lost, which is strictly the focus of this particular packets may be lost, which is strictly the focus of this
document: we assume that transmitted packets are either lost (e.g., document: we assume that transmitted packets are either lost (e.g.,
because of a congested router, of a poor signal-to-noise ratio in a because of a congested router, of a poor signal-to-noise ratio in a
wireless network, or because the number of bit errors exceeds the wireless network, or because the number of bit errors exceeds the
correction capabilities of the physical-layer error correcting code) correction capabilities of the physical-layer error correcting code)
or received by the transport protocol without any corruption (i.e., or received by the transport protocol without any corruption (i.e.,
the bit-errors, if any, have been fixed by the physical-layer error the bit-errors, if any, have been fixed by the physical-layer error
correcting code and therefore are hidden to the upper layers). correcting code and therefore are hidden to the upper layers).
For these use-cases, Forward Error Correction (FEC) applied within For these use-cases, Forward Error Correction (FEC) applied within
the transport or application layer, is an efficient technique to the transport or application layer is an efficient technique to
improve packet transmission robustness in presence of packet losses improve packet transmission robustness in presence of packet losses
(or "erasures"), without going through packet retransmissions that (or "erasures"), without going through packet retransmissions that
create a delay often incompatible with real-time constraints. The create a delay often incompatible with real-time constraints. The
FEC Building Block defined in [RFC5052] provides a framework for the FEC Building Block defined in [RFC5052] provides a framework for the
definition of Content Delivery Protocols (CDPs) that make use of definition of Content Delivery Protocols (CDPs) that make use of
separately defined FEC schemes. Any CDP defined according to the separately-defined FEC schemes. Any CDP defined according to the
requirements of the FEC Building Block can then easily be used with requirements of the FEC Building Block can then easily be used with
any FEC Scheme that is also defined according to the requirements of any FEC Scheme that is also defined according to the requirements of
the FEC Building Block. the FEC Building Block.
Then FECFRAME [RFC6363] provides a framework to define Content Then FECFRAME [RFC6363] provides a framework to define Content
Delivery Protocols (CDPs) that provide FEC protection for arbitrary Delivery Protocols (CDPs) that provide FEC protection for arbitrary
packet flows over an unreliable datagram service transports such as packet flows over an unreliable datagram service transport such as
UDP. It is primarily intended for real-time or streaming media UDP. It is primarily intended for real-time or streaming media
applications, using broadcast, multicast, or on-demand delivery. applications, using 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. For instance if
has major impacts on FEC encoding and decoding delays. The data the current block encompasses the 100's to 119's source symbols
packets of continuous media flow(s) may be passed to the transport (i.e., block of size 20 symbols) of an input flow, encoding (and
layer immediately, without delay. But the block creation time, that decoding) will be performed on this block independantly of other
depends on the number of source symbols in this block, impacts both blocks. This approach has major impacts on FEC encoding and decoding
the FEC encoding delay (since encoding requires that all source delays. The data packets of continuous media flow(s) may be passed
symbols be known), and mechanically the packet loss recovery delay at to the transport layer immediately, without delay. But the block
a receiver (since no repair symbol for the current block can be creation time, that depends on the number of source symbols in this
generated and therefore received before that time). Therefore a good block, impacts both the FEC encoding delay (since encoding requires
value for the block size is necessarily a balance between the maximum that all source symbols be known), and mechanically the packet loss
FEC decoding latency at the receivers (which must be in line with the recovery delay at a receiver (since no repair symbol for the current
most stringent real-time requirement of the protected flow(s), hence block can be generated and therefore received before that time).
an incentive to reduce the block size), and the desired robustness Therefore a good value for the block size is necessarily a balance
against long loss bursts (which increases with the block size, hence between the maximum FEC decoding latency at the receivers (which must
an incentive to increase this size). be in line with the most stringent real-time requirement of the
protected flow(s), hence an incentive to reduce the block size), and
the desired robustness against long loss bursts (which increases with
the block size, hence an incentive to increase this size).
This document updates [RFC6363] in order to also support FEC codes This document updates [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)
[RFC8406]. This encoding window, either of fixed or variable size, [RFC8406]. This encoding window, either of fixed or variable size,
slides over the set of source symbols. FEC encoding is launched slides over the set of source symbols. FEC encoding is launched
whenever needed, from the set of source symbols present in the whenever needed, from the set of source symbols present in the
sliding encoding window at that time. This approach significantly sliding encoding window at that time. This approach significantly
reduces FEC-related latency, since repair symbols can be generated reduces FEC-related latency, since repair symbols can be generated
and passed to the transport layer on-the-fly, at any time, and can be and passed to the transport layer on-the-fly, at any time, and can be
regularly received by receivers to quickly recover packet losses. regularly received by receivers to quickly recover packet losses.
Using sliding window FEC codes is therefore highly beneficial to Using sliding window FEC codes is therefore highly beneficial to
real-time flows, one of the primary targets of FECFRAME. [RLC-ID] real-time flows, one of the primary targets of FECFRAME. [RLC-ID]
provides an example of such FEC Scheme for FECFRAME, built upon the provides an example of such FEC Scheme for FECFRAME, built upon the
skipping to change at page 4, line 15 skipping to change at page 4, line 19
reduces FEC-related latency, since repair symbols can be generated reduces FEC-related latency, since repair symbols can be generated
and passed to the transport layer on-the-fly, at any time, and can be and passed to the transport layer on-the-fly, at any time, and can be
regularly received by receivers to quickly recover packet losses. regularly received by receivers to quickly recover packet losses.
Using sliding window FEC codes is therefore highly beneficial to Using sliding window FEC codes is therefore highly beneficial to
real-time flows, one of the primary targets of FECFRAME. [RLC-ID] real-time flows, one of the primary targets of FECFRAME. [RLC-ID]
provides an example of such FEC Scheme for FECFRAME, built upon the provides an example of such FEC Scheme for FECFRAME, built upon the
simple sliding window Random Linear Codes (RLC). simple sliding window Random Linear Codes (RLC).
This document is fully backward compatible with [RFC6363]. Indeed: This document is fully backward compatible with [RFC6363]. Indeed:
o this extension does not prevent nor compromise in any way the o this FECFRAME update does not prevent nor compromise in any way
support of block FEC codes. Both types of codes can nicely co- the support of block FEC codes. Both types of codes can nicely
exist, just like different block FEC schemes can co-exist; co-exist, just like different block FEC schemes can co-exist;
o each sliding window FEC Scheme is associated to a specific FEC
Encoding ID subject to IANA registration, just like block FEC
Schemes;
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
FECFRAME session. This is made possible with the FEC Encoding ID FECFRAME session. Indeed, the FEC Encoding ID that identifies the
that identifies the FEC Scheme used and which is carried in the FEC Scheme is carried in the FEC Framework Configuration
FEC Framework Configuration Information (see section 5.5 of Information (see section 5.5 of [RFC6363]). For instance, when
[RFC6363]). For instance, when the Session Description Protocol the Session Description Protocol (SDP) is used to carry the FEC
(SDP) is used to carry the FEC Framework Configuration Framework Configuration Information, the FEC Encoding ID can be
Information, the FEC Encoding ID can be communicated in the communicated in the "encoding-id=" parameter of a "fec-repair-
"encoding-id=" parameter of a "fec-repair-flow" attribute flow" attribute [RFC6364]. This mechanism is the basic approach
[RFC6364]. This mechanism is the basic approach for a FECFRAME for a FECFRAME receiver to determine whether or not it supports
receiver to determine whether or not it supports the FEC Scheme the FEC Scheme used in a given FECFRAME session;
used in a given FECFRAME session;
This document leverages on [RFC6363] and re-uses its structure. It This document leverages on [RFC6363] and re-uses its structure. It
proposes new sections specific to sliding window FEC codes whenever proposes new sections specific to sliding window FEC codes whenever
required. The only exception is Section 3 that provides a quick required. The only exception is Section 3 that provides a quick
summary of FECFRAME in order to facilitate the understanding of this summary of FECFRAME in order to facilitate the understanding of this
document to readers not familiar with the concepts and terminology. document to readers not familiar with the concepts and terminology.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
The following list of definitions and abbreviations is copied from The following list of definitions and abbreviations is copied from
[RFC6363], adding only the Block/sliding window FEC Code and [RFC6363], adding only the Block/sliding window FEC Code and
Encoding/Decoding Window definitions (tagged with "ADDED"): Encoding/Decoding Window definitions (tagged with "ADDED"):
Application Data Unit (ADU): The unit of source data provided as Application Data Unit (ADU): The unit of source data provided as
payload to the transport layer. payload to the transport layer. For instance, it can be a
payload containing the result of the RTP packetization of a
compressed video frame.
ADU Flow: A sequence of ADUs associated with a transport-layer flow ADU Flow: A sequence of ADUs associated with a transport-layer flow
identifier (such as the standard 5-tuple {source IP address, identifier (such as the standard 5-tuple {source IP address,
source port, destination IP address, destination port, transport source port, destination IP address, destination port, transport
protocol}). protocol}).
AL-FEC: Application-layer Forward Error Correction. AL-FEC: Application-layer Forward Error Correction.
Application Protocol: Control protocol used to establish and control Application Protocol: Control protocol used to establish and control
the source flow being protected, e.g., the Real-Time Streaming the source flow being protected, e.g., the Real-Time Streaming
skipping to change at page 5, line 38 skipping to change at page 5, line 45
symbols present in the sliding encoding window at that time. symbols present in the sliding encoding window at that time.
These codes are also known as convolutional codes. These codes are also known as convolutional codes.
FEC Framework: A protocol framework for the definition of Content FEC Framework: A protocol framework for the definition of Content
Delivery Protocols using FEC, such as the framework defined in Delivery Protocols using FEC, such as the framework defined in
this document. this document.
FEC Framework Configuration Information: Information that controls FEC Framework Configuration Information: Information that controls
the operation of the FEC Framework. the operation of the FEC Framework.
FEC Payload ID: Information that identifies the contents of a packet FEC Payload ID: Information that identifies the contents and
with respect to the FEC Scheme. provides positional information of a packet with respect to the
FEC Scheme.
FEC Repair Packet: At a sender (respectively, at a receiver), a FEC Repair 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 one or more repair symbols along with a protocol containing one or more repair symbols along with a
Repair FEC Payload ID and possibly an RTP header. Repair FEC Payload ID and possibly an RTP header.
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.
skipping to change at page 7, line 16 skipping to change at page 7, line 25
Source Block: Group of ADUs that are to be FEC protected as a single Source Block: Group of ADUs that are to be FEC protected as a single
block. This notion is restricted to Block FEC Codes. block. This notion is restricted to Block FEC Codes.
Source Symbol: Unit of data used during the encoding process. Source Symbol: Unit of data used during the encoding process.
Systematic Code: FEC code in which the source symbols are part of Systematic Code: FEC code in which the source symbols are part of
the encoding symbols. the encoding symbols.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Summary of Architecture Overview 3. Summary of Architecture Overview
The architecture of [RFC6363], Section 3, equally applies to this The architecture of [RFC6363], Section 3, equally applies to this
FECFRAME extension and is not repeated here. However we provide FECFRAME extension and is not repeated here. However we provide
hereafter a quick summary to facilitate the understanding of this hereafter a quick summary to facilitate the understanding of this
skipping to change at page 8, line 36 skipping to change at page 8, line 36
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
Figure 1: FECFRAME architecture at a sender. Figure 1: FECFRAME architecture at a sender.
The FECFRAME architecture is illustrated in Figure 1 from the The FECFRAME architecture is illustrated in Figure 1 from the
sender's point of view, in case of a block FEC Scheme. It shows an sender's point of view, in case of a block FEC Scheme. It shows an
application generating an ADU flow (other flows, from other application generating an ADU flow (other flows, from other
applications, may co-exist). These ADUs, of variable size, must be applications, may co-exist). These ADUs, of variable size, must be
somehow mapped to source symbols of fixed size. This is the goal of somehow mapped to source symbols of fixed size (this fixed size is a
an ADU to symbols mapping process that is FEC Scheme specific (see requirement of all FEC Schemes that comes from the way mathematical
operations are applied to symbols content). This is the goal of 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 an appropriate transport protocol (more precisely sent using an appropriate transport protocol (more precisely
[RFC6363], Section 7, requires a transport protocol providing an [RFC6363], Section 7, requires a transport protocol providing an
unreliable datagram service, such as UDP). In practice FEC Source unreliable datagram service, such as UDP). In practice FEC Source
Packets may be passed to the transport layer as soon as available, Packets may be passed to the transport layer as soon as available,
without having to wait for FEC encoding to take place. In that case without having to wait for FEC encoding to take place. In that case
a copy of the associated source symbols needs to be kept within a copy of the associated source symbols needs to be kept within
FECFRAME for future FEC encoding purposes. 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
erased one will be delayed until FEC decoding has taken place) or not erased one will be delayed until FEC decoding has taken place) or not
(in that case each ADU is returned as soon as it is received or (in that case each ADU is returned as soon as it is received or
recovered), depending on the application requirements. recovered), depending on the application requirements.
FECFRAME features two subtle mechanisms: FECFRAME features two subtle mechanisms:
o ADUs to source symbols mapping: in order to manage variable size o ADUs-to-source-symbols mapping: in order to manage variable size
ADUs, FECFRAME and FEC Schemes can use small, fixed size symbols ADUs, FECFRAME and FEC Schemes can use small, fixed size symbols
and create a mapping between ADUs and symbols. To each ADU this and create a mapping between ADUs and symbols. To each ADU this
mechanism prepends a length field (plus a flow identifier, see mechanism prepends a length field (plus a flow identifier, see
below) and pads the result to a multiple of the symbol size. A below) and pads the result to a multiple of the symbol size. A
small ADU may be mapped to a single source symbol while a large small ADU may be mapped to a single source symbol while a large
one may be mapped to multiple symbols. The mapping details are one may be mapped to multiple symbols. The mapping details are
FEC Scheme dependant and must be defined in the associated FEC-Scheme-dependent and must be defined in the associated
document; document;
o Assignment of decoded ADUs to flows in multi-flow configurations: o Assignment of decoded ADUs to flows in multi-flow configurations:
when multiple flows are multiplexed over the same FECFRAME when multiple flows are multiplexed over the same FECFRAME
instance, a problem is to assign a decoded ADU to the right flow instance, a problem is to assign a decoded ADU to the right flow
(UDP port numbers and IP addresses traditionally used to map (UDP port numbers and IP addresses traditionally used to map
incoming ADUs to flows are not recovered during FEC decoding). To incoming ADUs to flows are not recovered during FEC decoding). To
make it possible, at the FECFRAME sending instance, each ADU is make it possible, at the FECFRAME sending instance, each ADU is
prepended with a flow identifier (1 byte) during the ADU to source prepended with a flow identifier (1 byte) during the ADU-to-
symbols mapping (see above). The flow identifiers are also shared source-symbols mapping (see above). The flow identifiers are also
between all FECFRAME instances as part of the FEC Framework shared between all FECFRAME instances as part of the FEC Framework
Configuration Information. This (flow identifier + length + Configuration Information. This (flow identifier + length +
application payload + padding), called ADUI, is then FEC application payload + padding), called ADUI, is then FEC
protected. Therefore a decoded ADUI contains enough information protected. Therefore a decoded ADUI contains enough information
to assign the ADU to the right flow. to assign the ADU to the right flow.
A few aspects are not covered by FECFRAME, namely: A few aspects are not covered by FECFRAME, namely:
o [RFC6363] section 8 does not detail any congestion control o [RFC6363] section 8 does not detail any congestion control
mechanism, but only provides high level normative requirements; mechanism, but only provides high level normative requirements;
o the possibility of having feedbacks from receiver(s) is considered o the possibility of having feedbacks from receiver(s) is considered
out of scope, although such a mechanism may exist within the out of scope, although such a mechanism may exist within the
application (e.g., through RCTP control messages); application (e.g., through RTCP control messages);
o flow adaptation at a FECFRAME sender (e.g., how to set the FEC o flow adaptation at a FECFRAME sender (e.g., how to set the FEC
code rate based on transmission conditions) is not detailed, but code rate based on transmission conditions) is not detailed, but
it needs to comply with the congestion control normative it needs to comply with the congestion control normative
requirements (see above). requirements (see above).
4. Procedural Overview 4. Procedural Overview
4.1. General 4.1. General
skipping to change at page 10, line 46 skipping to change at page 10, line 50
With a Sliding Window FEC Scheme, the following operations, With a Sliding Window FEC Scheme, the following operations,
illustrated in Figure 2 for the generic case (non-RTP repair flows), illustrated in Figure 2 for the generic case (non-RTP repair flows),
and in Figure 3 for the case of RTP repair flows, describe a possible and in Figure 3 for the case of RTP repair flows, describe a possible
way to generate compliant source and repair flows: way to generate compliant source and repair flows:
1. A new ADU is provided by the application. 1. A new ADU is provided by the application.
2. The FEC Framework communicates this ADU to the FEC Scheme. 2. The FEC Framework communicates this ADU to the FEC Scheme.
3. The sliding encoding window is updated by the FEC Scheme. The 3. The sliding encoding window is updated by the FEC Scheme. The
ADU to source symbols mapping as well as the encoding window ADU-to-source-symbols mapping as well as the encoding window
management details are both the responsibility of the FEC Scheme management details are both the responsibility of the FEC Scheme
and MUST be detailed there. Appendix A provides non normative and MUST be detailed there. Appendix A provides non-normative
hints about what FEC Scheme designers need to consider; hints about what FEC Scheme designers need to consider;
4. The Source FEC Payload ID information of the source packet is 4. The Source FEC Payload ID information of the source packet is
determined by the FEC Scheme. If required by the FEC Scheme, determined by the FEC Scheme. If required by the FEC Scheme,
the Source FEC Payload ID is encoded into the Explicit Source the Source FEC Payload ID is encoded into the Explicit Source
FEC Payload ID field and returned to the FEC Framework. FEC Payload ID field and returned to the FEC Framework.
5. The FEC Framework constructs the FEC Source Packet according to 5. The FEC Framework constructs the FEC Source Packet according to
[RFC6363] Figure 6, using the Explicit Source FEC Payload ID [RFC6363] Figure 6, using the Explicit Source FEC Payload ID
provided by the FEC Scheme if applicable. provided by the FEC Scheme if applicable.
skipping to change at page 13, line 50 skipping to change at page 13, line 50
illustrated in Figure 4 for the generic case (non-RTP repair flows), illustrated in Figure 4 for the generic case (non-RTP repair flows),
and in Figure 5 for the case of RTP repair flows. The only and in Figure 5 for the case of RTP repair flows. The only
differences with respect to block FEC codes lie in steps (4) and (5). differences with respect to block FEC codes lie in steps (4) and (5).
Therefore this section does not repeat the other steps of [RFC6363], Therefore this section does not repeat the other steps of [RFC6363],
Section 4.3, "Receiver Operation". The new steps (4) and (5) are: Section 4.3, "Receiver Operation". The new steps (4) and (5) are:
4. The FEC Scheme uses the received FEC Payload IDs (and derived FEC 4. The FEC Scheme uses the received FEC Payload IDs (and derived FEC
Source Payload IDs when the Explicit Source FEC Payload ID field Source Payload IDs when the Explicit Source FEC Payload ID field
is not used) to insert source and repair packets into the is not used) to insert source and repair packets into the
decoding window in the right way. If at least one source packet decoding window in the right way. If at least one source packet
is missing and at least one repair packet has been received and is missing and at least one repair packet has been received, then
the rank of the associated linear system permits it, then FEC FEC decoding is attempted to recover missing source payloads.
decoding can be performed in order to recover missing source The FEC Scheme determines whether source packets have been lost
payloads. The FEC Scheme determines whether source packets have and whether enough repair packets have been received to decode
been lost and whether enough repair packets have been received to any or all of the missing source payloads.
decode any or all of the missing source payloads.
5. The FEC Scheme returns the received and decoded ADUs to the FEC 5. The FEC Scheme returns the received and decoded ADUs to the FEC
Framework, along with indications of any ADUs that were missing Framework, along with indications of any ADUs that were missing
and could not be decoded. and could not be decoded.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
|(6) ADUs |(6) ADUs
skipping to change at page 16, line 43 skipping to change at page 16, line 43
Additionally, the FEC Scheme associated to a Sliding Window FEC Code: Additionally, the FEC Scheme associated to a Sliding Window FEC Code:
o MUST define the relationships between ADUs and the associated o MUST define the relationships between ADUs and the associated
source symbols (mapping); source symbols (mapping);
o MUST define the management of the encoding window that slides over o MUST define the management of the encoding window that slides over
the set of ADUs. Appendix A provides non normative hints about the set of ADUs. Appendix A provides non normative hints about
what FEC Scheme designers need to consider; what FEC Scheme designers need to consider;
o MUST define the management of the decoding window, consisting of a o MUST define the management of the decoding window. This usually
system of linear equations (in case of a linear FEC code); consists in managing a system of linear equations (in case of a
linear FEC code);
6. Feedback 6. Feedback
The discussion of [RFC6363], Section 6, equally applies to this The discussion of [RFC6363], Section 6, equally applies to this
FECFRAME extension and is not repeated here. FECFRAME extension and is not repeated here.
7. Transport Protocols 7. Transport Protocols
The discussion of [RFC6363], Section 7, equally applies to this The discussion of [RFC6363], Section 7, equally applies to this
FECFRAME extension and is not repeated here. FECFRAME extension and is not repeated here.
skipping to change at page 17, line 52 skipping to change at page 17, line 52
o Implementation experience: maximum. o Implementation experience: maximum.
o Information update date: March 2018. o Information update date: March 2018.
o Contact: vincent.roca@inria.fr o Contact: vincent.roca@inria.fr
10. Security Considerations 10. Security Considerations
This FECFRAME extension does not add any new security consideration. This FECFRAME extension does not add any new security consideration.
All the considerations of [RFC6363], Section 9, apply to this All the considerations of [RFC6363], Section 9, apply to this
document as well. document as well. However, for the sake of completeness, the
following goal can be added to the list provided in Section 9.1
"Problem Statement" of [RFC6363]:
o Attacks can try to corrupt source flows in order to modify the
receiver application's behavior (as opposed to just denying
service).
11. Operations and Management Considerations 11. Operations and Management Considerations
This FECFRAME extension does not add any new Operations and This FECFRAME extension does not add any new Operations and
Management Consideration. All the considerations of [RFC6363], Management Consideration. All the considerations of [RFC6363],
Section 10, apply to this document as well. Section 10, apply to this document as well.
12. IANA Considerations 12. IANA Considerations
No IANA actions are required for this document. No IANA actions are required for this document.
A FEC Scheme for use with this FEC Framework is identified via its A FEC Scheme for use with this FEC Framework is identified via its
FEC Encoding ID. It is subject to IANA registration in the "FEC FEC Encoding ID. It is subject to IANA registration in the "FEC
Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of
[RFC6363], Section 11, apply and are not repeated here. [RFC6363], Section 11, apply and are not repeated here.
13. Acknowledgments 13. Acknowledgments
The authors would like to thank Christer Holmberg, David Black, Gorry The authors would like to thank Christer Holmberg, David Black, Gorry
Fairhurst, and Emmanuel Lochin for their valuable feedbacks on this Fairhurst, and Emmanuel Lochin, Spencer Dawkins, Ben Campbell,
document. This document being an extension to [RFC6363], the authors Benjamin Kaduk, Eric Rescorla, and Adam Roach for their valuable
would also like to thank Mark Watson as the main author this RFC. feedbacks on this document. This document being an extension to
[RFC6363], the authors would also like to thank Mark Watson as the
main author of that RFC.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 12 skipping to change at page 20, line 12
Progress), September 2018, <https://tools.ietf.org/html/ Progress), September 2018, <https://tools.ietf.org/html/
draft-ietf-tsvwg-rlc-fec-scheme>. draft-ietf-tsvwg-rlc-fec-scheme>.
Appendix A. About Sliding Encoding Window Management (non Normative) Appendix A. About Sliding Encoding Window Management (non Normative)
The FEC Framework does not specify the management of the sliding The FEC Framework does not specify the management of the sliding
encoding window which is the responsibility of the FEC Scheme. This encoding window which is the responsibility of the FEC Scheme. This
annex only provides a few non normative hints. annex only provides a few non normative hints.
Source symbols are added to the sliding encoding window each time a Source symbols are added to the sliding encoding window each time a
new ADU is available at the sender, after the ADU to source symbol new ADU is available at the sender, after the ADU-to-source-symbol
mapping specific to the FEC Scheme. mapping specific to the FEC Scheme.
Source symbols are removed from the sliding encoding window, for Source symbols are removed from the sliding encoding window, for
instance: instance:
o after a certain delay, when an "old" ADU of a real-time flow times o after a certain delay, when an "old" ADU of a real-time flow times
out. The source symbol retention delay in the sliding encoding out. The source symbol retention delay in the sliding encoding
window should therefore be initialized according to the real-time window should therefore be initialized according to the real-time
features of incoming flow(s) when applicable; features of incoming flow(s) when applicable;
 End of changes. 29 change blocks. 
70 lines changed or deleted 86 lines changed or added

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