draft-ietf-tsvwg-fecframe-ext-08.txt   rfc8680.txt 
TSVWG V. Roca Internet Engineering Task Force (IETF) V. Roca
Internet-Draft INRIA Request for Comments: 8680 INRIA
Updates: 6363 (if approved) A. Begen Updates: 6363 A. Begen
Intended status: Standards Track Networked Media Category: Standards Track Networked Media
Expires: July 15, 2019 January 11, 2019 ISSN: 2070-1721 January 2020
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-08
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. This document updates RFC 6363 to support FEC Codes based on codes. This document updates RFC 6363 to support FEC codes based on
a sliding encoding window, in addition to Block FEC Codes, in a a sliding encoding window, in addition to block FEC codes, 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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on July 15, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8680.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology
3. Summary of Architecture Overview . . . . . . . . . . . . . . 7 2.1. Definitions and Abbreviations
4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 10 2.2. Requirements Language
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Summary of Architecture Overview
4.2. Sender Operation with Sliding Window FEC Codes . . . . . 10 4. Procedural Overview
4.3. Receiver Operation with Sliding Window FEC Codes . . . . 13 4.1. General
5. Protocol Specification . . . . . . . . . . . . . . . . . . . 15 4.2. Sender Operation with Sliding Window FEC Codes
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Receiver Operation with Sliding Window FEC Codes
5.2. FEC Framework Configuration Information . . . . . . . . . 16 5. Protocol Specification
5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 16 5.1. General
6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. FEC Framework Configuration Information
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17 5.3. FEC Scheme Requirements
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 6. Feedback
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 7. Transport Protocols
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Congestion Control
11. Operations and Management Considerations . . . . . . . . . . 18 9. Security Considerations
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Operations and Management Considerations
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References
14.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References
Appendix A. About Sliding Encoding Window Management Appendix A. About Sliding Encoding Window Management
(informational) . . . . . . . . . . . . . . . . . . 20 (Informational)
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments
Authors' Addresses
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, 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 were received by the transport protocol without any corruption
the bit-errors, if any, have been fixed by the physical-layer error (i.e., the bit errors, if any, have been fixed by the physical-layer
correcting code and therefore are hidden to the upper layers). error-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 the presence of packet
(or "erasures"), without going through packet retransmissions that losses (or "erasures") without going through packet retransmissions
create a delay often incompatible with real-time constraints. The that create a delay often incompatible with real-time constraints.
FEC Building Block defined in [RFC5052] provides a framework for the The FEC Building Block defined in [RFC5052] provides a framework for
definition of Content Delivery Protocols (CDPs) that make use of the 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 transport 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 that are using broadcast, multicast, or on-demand
delivery. A subset of FECFRAME is currently part of the 3GPP Evolved
Multimedia Broadcast/Multicast Service (eMBMS) standard [MBMSTS].
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
segmented into a sequence of blocks. Then FEC encoding (at a sender be segmented into a sequence of blocks. Then, FEC encoding (at a
or an encoding middlebox) and decoding (at a receiver or a decoding sender or an encoding middlebox) and decoding (at a receiver or a
middlebox) are both performed on a per-block basis. For instance, if decoding middlebox) are both performed on a per-block basis. For
the current block encompasses the 100's to 119's source symbols instance, if the current block encompasses the 100's to 119's source
(i.e., a block of size 20 symbols) of an input flow, encoding (and symbols (i.e., a block of size 20 symbols) of an input flow, encoding
decoding) will be performed on this block independently of other (and decoding) will be performed on this block independently of other
blocks. This approach has major impacts on FEC encoding and decoding blocks. This approach has major impacts on FEC encoding and decoding
delays. The data packets of continuous media flow(s) may be passed delays. The data packets of continuous media flow(s) may be passed
to the transport layer immediately, without delay. But the block to the transport layer immediately, without delay. But the block
creation time, that depends on the number of source symbols in this creation time, which depends on the number of source symbols in this
block, impacts both the FEC encoding delay (since encoding requires block, impacts both the FEC encoding delay (since encoding requires
that all source symbols be known), and mechanically the packet loss that all source symbols be known) and, mechanically, the packet loss
recovery delay at a receiver (since no repair symbol for the current recovery delay at a receiver (since no repair symbol for the current
block can be generated and therefore received before that time). block can be generated and therefore received before that time).
Therefore a good value for the block size is necessarily a balance Therefore, a good value for the block size is necessarily a balance
between the maximum FEC decoding latency at the receivers (which must between the maximum FEC decoding latency at the receivers (which must
be in line with the most stringent real-time requirement of the be in line with the most stringent real-time requirement of the
protected flow(s), hence an incentive to reduce the block size), and protected flow(s), hence an incentive to reduce the block size) and
the desired robustness against long loss bursts (which increases with the desired robustness against long loss bursts (which increases with
the block size, hence an incentive to increase this size). 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 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
sliding encoding window at that time. This approach significantly encoding window at that time. This approach significantly reduces
reduces FEC-related latency, since repair symbols can be generated FEC-related latency, since repair symbols can be generated and passed
and passed to the transport layer on-the-fly, at any time, and can be to the transport layer on the fly at any time and can be regularly
regularly received by receivers to quickly recover packet losses. received by receivers to quickly recover packet losses. Using
Using sliding window FEC codes is therefore highly beneficial to sliding window FEC codes is therefore highly beneficial to real-time
real-time flows, one of the primary targets of FECFRAME. [RLC-ID] flows, one of the primary targets of FECFRAME. [RFC8681] provides an
provides an example of such FEC Scheme for FECFRAME, built upon the example of such a FEC scheme for FECFRAME, which is built upon the
simple sliding window Random Linear Codes (RLC). simple sliding window Random Linear Code (RLC).
This document is fully backward compatible with [RFC6363]. Indeed: This document is fully backward compatible with [RFC6363]. Indeed:
o this FECFRAME update does not prevent nor compromise in any way * This FECFRAME update does not prevent or compromise in any way the
the support of block FEC codes. Both types of codes can nicely support of block FEC codes. Both types of codes can nicely
co-exist, just like different block FEC schemes can co-exist; coexist, just like different block FEC schemes can coexist.
o each sliding window FEC Scheme is associated to a specific FEC * Each sliding window FEC scheme is associated with a specific FEC
Encoding ID subject to IANA registration, just like block FEC Encoding ID subject to IANA registration, just like block FEC
Schemes; schemes.
o any receiver, for instance a legacy receiver that only supports * 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. Indeed, the FEC Encoding ID that identifies the FECFRAME session. Indeed, the FEC Encoding ID that identifies the
FEC Scheme is carried in the FEC Framework Configuration FEC scheme is carried in FEC Framework Configuration Information
Information (see section 5.5 of [RFC6363]). For instance, when (see Section 5.5 of [RFC6363]). For instance, when the Session
the Session Description Protocol (SDP) is used to carry the FEC Description Protocol (SDP) is used to carry the FEC Framework
Framework Configuration Information, the FEC Encoding ID can be Configuration Information, the FEC Encoding ID can be communicated
communicated in the "encoding-id=" parameter of a "fec-repair- in the "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 reuses 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, which 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. Terminology
2.1. 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 FEC Code, Sliding Window FEC Code,
Encoding/Decoding Window definitions (tagged with "ADDED"): and Encoding/Decoding Window definitions (tagged with "ADDED"):
Application Data Unit (ADU): The unit of source data provided as Application Data Unit (ADU):
payload to the transport layer. For instance, it can be a The unit of source data provided as a payload to the transport
payload containing the result of the RTP packetization of a layer. For instance, it can be a payload containing the result of
compressed video frame. the RTP packetization of a compressed video frame.
ADU Flow: A sequence of ADUs associated with a transport-layer flow ADU Flow:
identifier (such as the standard 5-tuple {source IP address, A sequence of ADUs associated with a transport-layer flow
source port, destination IP address, destination port, transport identifier (such as the standard 5-tuple {source IP address,
protocol}). source port, destination IP address, destination port, transport
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:
the source flow being protected, e.g., the Real-Time Streaming Control protocol used to establish and control the source flow
Protocol (RTSP). being protected, e.g., the Real-Time Streaming Protocol (RTSP).
Content Delivery Protocol (CDP): A complete application protocol Content Delivery Protocol (CDP):
specification that, through the use of the framework defined in A complete application protocol specification that, through the
this document, is able to make use of FEC schemes to provide FEC use of the framework defined in this document, is able to make use
capabilities. of FEC schemes to provide FEC capabilities.
FEC Code: An algorithm for encoding data such that the encoded data FEC Code:
flow is resilient to data loss. Note that, in general, FEC codes An algorithm for encoding data such that the encoded data flow is
may also be used to make a data flow resilient to corruption, but resilient to data loss. Note that, in general, FEC codes may also
that is not considered in this document. be used to make a data flow resilient to corruption, but that is
not considered in this document.
Block FEC Code: (ADDED) An FEC Code that operates on blocks, i.e., Block FEC Code: (ADDED)
for which the input flow MUST be segmented into a sequence of A FEC code that operates on blocks, i.e., for which the input flow
blocks, FEC encoding and decoding being performed independently MUST be segmented into a sequence of blocks, with FEC encoding and
on a per-block basis. decoding being performed independently on a per-block basis.
Sliding Window FEC Code: (ADDED) An FEC Code that can generate Sliding Window FEC Code: (ADDED)
repair symbols on-the-fly, at any time, from the set of source A FEC code that can generate repair symbols on the fly, at any
symbols present in the sliding encoding window at that time. time, from the set of source symbols present in the sliding
These codes are also known as convolutional codes. encoding window at that time. These codes are also known as
convolutional codes.
FEC Framework: A protocol framework for the definition of Content FEC Framework:
Delivery Protocols using FEC, such as the framework defined in A protocol framework for the definition of Content Delivery
this document. Protocols using FEC, such as the framework defined in this
document.
FEC Framework Configuration Information: Information that controls FEC Framework Configuration Information:
the operation of the FEC Framework. Information that controls the operation of the FEC Framework.
FEC Payload ID: Information that identifies the contents and FEC Payload ID:
provides positional information of a packet with respect to the Information that identifies the contents and provides positional
FEC Scheme. information of a packet with respect to the FEC scheme.
FEC Repair Packet: At a sender (respectively, at a receiver), a FEC Repair Packet:
payload submitted to (respectively, received from) the transport At a sender (respectively, at a receiver), a payload submitted to
protocol containing one or more repair symbols along with a (respectively, received from) the transport protocol containing
Repair FEC Payload ID and possibly an RTP header. one or more repair symbols along with a Repair FEC Payload ID and
possibly an RTP header.
FEC Scheme: A specification that defines the additional protocol FEC Scheme:
aspects required to use a particular FEC code with the FEC A specification that defines the additional protocol aspects
Framework. required to use a particular FEC code with the FEC Framework.
FEC Source Packet: At a sender (respectively, at a receiver), a FEC Source Packet:
payload submitted to (respectively, received from) the transport At a sender (respectively, at a receiver), a payload submitted to
protocol containing an ADU along with an optional Explicit Source (respectively, received from) the transport protocol containing an
FEC Payload ID. ADU along with an optional Explicit Source FEC Payload ID.
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:
repair packets. A FEC Payload ID specifically for use with repair packets.
Source Flow: The packet flow to which FEC protection is to be Source Flow:
applied. A source flow consists of ADUs. The packet flow to which FEC protection is to be applied. A
source flow consists of ADUs.
Source FEC Payload ID: A FEC Payload ID specifically for use with Source FEC Payload ID:
source packets. A FEC Payload ID specifically for use with source packets.
Source Protocol: A protocol used for the source flow being Source Protocol:
protected, e.g., RTP. A protocol used for the source flow being protected, e.g., RTP.
Transport Protocol: The protocol used for the transport of the Transport Protocol:
source and repair flows, using an unreliable datagram service The protocol used for the transport of the source and repair
such as UDP. flows. This protocol needs to provide an unreliable datagram
service, as UDP does ([RFC6363], Section 7).
Encoding Window: (ADDED) Set of Source Symbols available at the Encoding Window: (ADDED)
sender/coding node that are used to generate a repair symbol, Set of source symbols available at the sender/coding node that are
with a Sliding Window FEC Code. used (with a Sliding Window FEC code) to generate a repair symbol.
Decoding Window: (ADDED) Set of received or decoded source and Decoding Window: (ADDED)
repair symbols available at a receiver that are used to decode Set of received or decoded source and repair symbols available at
erased source symbols, with a Sliding Window FEC Code. a receiver that are used (with a Sliding Window FEC code) to
decode lost source symbols.
Code Rate: The ratio between the number of source symbols and the Code Rate:
number of encoding symbols. By definition, the code rate is such The ratio between the number of source symbols and the number of
that 0 < code rate <= 1. A code rate close to 1 indicates that a encoding symbols. By definition, the code rate is such that 0 <
small number of repair symbols have been produced during the code rate <= 1. A code rate close to 1 indicates that a small
encoding process. number of repair symbols have been produced during the encoding
process.
Encoding Symbol: Unit of data generated by the encoding process. Encoding Symbol:
With systematic codes, source symbols are part of the encoding Unit of data generated by the encoding process. With systematic
symbols. codes, source symbols are part of the encoding symbols.
Packet Erasure Channel: A communication path where packets are Packet Erasure Channel:
either lost (e.g., in our case, by a congested router, or because A communication path where packets are either lost (e.g., in our
the number of transmission errors exceeds the correction case, by a congested router, or because the number of transmission
capabilities of the physical-layer code) or received. When a errors exceeds the correction capabilities of the physical-layer
packet is received, it is assumed that this packet is not code) or received. When a packet is received, it is assumed that
corrupted (i.e., in our case, the bit-errors, if any, are fixed this packet is not corrupted (i.e., in our case, the bit errors,
by the physical-layer code and therefore hidden to the upper if any, are fixed by the physical-layer code and are therefore
layers). hidden to the upper layers).
Repair Symbol: Encoding symbol that is not a source symbol. Repair Symbol:
Encoding symbol that is not a source symbol.
Source Block: Group of ADUs that are to be FEC protected as a single Source Block:
block. This notion is restricted to Block FEC Codes. Group of ADUs that are to be FEC protected as a single 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:
the encoding symbols. FEC code in which the source symbols are part of the encoding
symbols.
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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 Section 3 of [RFC6363] equally applies to this
FECFRAME extension and is not repeated here. However, we provide FECFRAME extension and is not repeated here. However, this section
hereafter a quick summary to facilitate the understanding of this includes a quick summary 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.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) Application Data Units (ADUs) | (1) Application Data Units (ADUs)
| |
v v
+----------------------+ +----------------+ +----------------------+ +----------------+
skipping to change at page 8, line 30 skipping to change at line 362
+----------------------+ Payload IDs +----------------+ +----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs | Repair FEC Payload IDs
| Repair symbols | Repair symbols
| |
|(7) FEC Source and Repair Packets |(7) FEC Source and Repair Packets
v v
+----------------------+ +----------------------+
| 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 for a block FEC
sender's point of view, in case of a block FEC Scheme. It shows an scheme from the sender's point of view. It shows an application
application generating an ADU flow (other flows, from other generating an ADU flow (other flows from other applications may
applications, may co-exist). These ADUs, of variable size, must be coexist). These ADUs of variable size must be somehow mapped to
somehow mapped to source symbols of fixed size (this fixed size is a source symbols of a fixed size (this fixed size is a requirement of
requirement of all FEC Schemes that comes from the way mathematical all FEC schemes, which comes from the way mathematical operations are
operations are applied to symbols content). This is the goal of an applied to the symbols' content). This is the goal of an ADU-to-
ADU-to-symbols mapping process that is FEC-Scheme specific (see symbols mapping process that is FEC scheme specific (see below).
below). Once the source block is built, taking into account both the Once the source block is built, taking into account both the FEC
FEC Scheme constraints (e.g., in terms of maximum source block size) scheme constraints (e.g., in terms of maximum source block size) and
and the application's flow constraints (e.g., in terms of real-time 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 Section 7 of [RFC6363] 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 that is potentially empty (if decoding fails) of the
symbols. After source-symbol-to-ADU mapping, when lost ADUs are missing source symbols. After source-symbol-to-ADU mapping, when
recovered, they are then assigned to their respective flow (see lost ADUs are recovered, they are then assigned to their respective
below). ADUs are returned to the application(s), either in their flow (see below). ADUs are returned to the application(s), either in
initial transmission order (in that case ADUs received after an their initial transmission order (in which case all ADUs received
erased one will be delayed until FEC decoding has taken place) or not after a lost ADU will be delayed until FEC decoding has taken place)
(in that case each ADU is returned as soon as it is received or or not (in which case each ADU is returned as soon as it is received
recovered), depending on the application requirements. or recovered), depending on the application requirements.
FECFRAME features two subtle mechanisms: FECFRAME features two subtle mechanisms whose details are FEC scheme
dependent:
o ADUs-to-source-symbols mapping: in order to manage variable size * 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. The mapping
mechanism prepends a length field (plus a flow identifier, see details are FEC scheme dependent and must be defined in the
below) and pads the result to a multiple of the symbol size. A associated document. For instance, with certain FEC schemes, to
small ADU may be mapped to a single source symbol while a large each ADU, this mechanism prepends a length field (plus a flow
one may be mapped to multiple symbols. The mapping details are identifier; see below) and pads the result to a multiple of the
FEC-Scheme-dependent and must be defined in the associated symbol size. A small ADU may be mapped to a single source symbol,
document; while a large one may be mapped to multiple symbols.
o Assignment of decoded ADUs to flows in multi-flow configurations: * 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).
make it possible, at the FECFRAME sending instance, each ADU is The mapping details are FEC scheme dependent and must be defined
prepended with a flow identifier (1 byte) during the ADU-to- in the associated document. For instance, with certain FEC
source-symbols mapping (see above). The flow identifiers are also schemes, to make it possible, at the FECFRAME sending instance,
shared between all FECFRAME instances as part of the FEC Framework each ADU is prepended with a flow identifier (1 byte) during the
Configuration Information. This (flow identifier + length + ADU-to-source-symbols mapping (see above). The flow identifiers
application payload + padding), called ADUI, is then FEC are also shared between all FECFRAME instances as part of the FEC
protected. Therefore a decoded ADUI contains enough information Framework Configuration Information. The ADU Information (ADUI),
to assign the ADU to the right flow. which includes the flow identifier, length, application payload,
and padding, is then FEC protected. Therefore, a decoded ADUI
contains enough information to assign the ADU to the right flow.
Note that a FEC scheme may also be restricted to the particular
case of a single flow over a FECFRAME instance; that would make
the above mechanism pointless.
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 * Section 8 of [RFC6363] does not detail any congestion control
mechanism, but only provides high level normative requirements; mechanisms and only provides high-level normative requirements.
o the possibility of having feedbacks from receiver(s) is considered * The possibility of having feedback 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 RTCP control messages); application (e.g., through RTP Control Protocol (RTCP) messages).
o flow adaptation at a FECFRAME sender (e.g., how to set the FEC * 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
The general considerations of [RFC6363], Section 4.1, that are The general considerations of Section 4.1 of [RFC6363] that are
specific to block FEC codes are not repeated here. specific to block FEC codes are not repeated here.
With a Sliding Window FEC Code, the FEC Source Packet MUST contain With a Sliding Window FEC code, the FEC Source Packet MUST contain
information to identify the position occupied by the ADU within the information to identify the position occupied by the ADU within the
source flow, in terms specific to the FEC Scheme. This information source flow in terms specific to the FEC scheme. This information is
is known as the Source FEC Payload ID, and the FEC Scheme is known as the Source FEC Payload ID, and the FEC scheme is responsible
responsible for defining and interpreting it. for defining and interpreting it.
With a Sliding Window FEC Code, the FEC Repair Packets MUST contain With a Sliding Window FEC code, the FEC Repair Packets MUST contain
information that identifies the relationship between the contained information that identifies the relationship between the contained
repair payloads and the original source symbols used during encoding. repair payloads and the original source symbols used during encoding.
This information is known as the Repair FEC Payload ID, and the FEC This information is known as the Repair FEC Payload ID, and the FEC
Scheme is responsible for defining and interpreting it. scheme is responsible for defining and interpreting it.
The Sender Operation ([RFC6363], Section 4.2.) and Receiver Operation The sender operation ([RFC6363], Section 4.2) and receiver operation
([RFC6363], Section 4.3) are both specific to block FEC codes and ([RFC6363], Section 4.3) are both specific to block FEC codes and are
therefore omitted below. The following two sections detail similar therefore omitted below. The following two sections detail similar
operations for Sliding Window FEC codes. operations for Sliding Window FEC codes.
4.2. Sender Operation with Sliding Window FEC Codes 4.2. Sender Operation with Sliding Window FEC Codes
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-symbol 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 Figure 6 in [RFC6363], using the Explicit Source FEC Payload ID
provided by the FEC Scheme if applicable. provided by the FEC scheme if applicable.
6. The FEC Source Packet is sent using normal transport-layer 6. The FEC Source Packet is sent using normal transport-layer
procedures. This packet is sent using the same ADU flow procedures. This packet is sent using the same ADU flow
identification information as would have been used for the identification information as would have been used for the
original source packet if the FEC Framework were not present original source packet if the FEC Framework were not present
(e.g., the source and destination addresses and UDP port numbers (e.g., the source and destination addresses and UDP port numbers
on the IP datagram carrying the source packet will be the same on the IP datagram carrying the source packet will be the same
whether or not the FEC Framework is applied). whether or not the FEC Framework is applied).
7. When the FEC Framework needs to send one or several FEC Repair 7. When the FEC Framework needs to send one or several FEC Repair
Packets (e.g., according to the target Code Rate), it asks the Packets (e.g., according to the target code rate), it asks the
FEC Scheme to create one or several repair packet payloads from FEC scheme to create one or several repair packet payloads from
the current sliding encoding window along with their Repair FEC the current sliding encoding window along with their Repair FEC
Payload ID. Payload ID.
8. The Repair FEC Payload IDs and repair packet payloads are 8. The Repair FEC Payload IDs and repair packet payloads are
provided back by the FEC Scheme to the FEC Framework. provided back by the FEC scheme to the FEC Framework.
9. The FEC Framework constructs FEC Repair Packets according to 9. The FEC Framework constructs FEC Repair Packets according to
[RFC6363] Figure 7, using the FEC Payload IDs and repair packet Figure 7 in [RFC6363], using the FEC Payload IDs and repair
payloads provided by the FEC Scheme. packet payloads provided by the FEC scheme.
10. The FEC Repair Packets are sent using normal transport-layer 10. The FEC Repair Packets are sent using normal transport-layer
procedures. The port(s) and multicast group(s) to be used for procedures. The port(s) and multicast group(s) to be used for
FEC Repair Packets are defined in the FEC Framework FEC Repair Packets are defined in the FEC Framework
Configuration Information. Configuration Information.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
skipping to change at page 12, line 31 skipping to change at line 548
| Repair Packet(s) | + Repair symbol(s) +----------------+ | Repair Packet(s) | + Repair symbol(s) +----------------+
+---------------------+ +---------------------+
| |
| (6) FEC Source Packet | (6) FEC Source Packet
| (10) FEC Repair Packets | (10) FEC Repair Packets
v v
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
Figure 2: Sender Operation with Sliding Window FEC Codes Figure 2: Sender Operation with Sliding Window FEC Codes
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
| (1) New Application Data Unit (ADU) | (1) New Application Data Unit (ADU)
v v
+---------------------+ +----------------+ +---------------------+ +----------------+
| FEC Framework | | FEC Scheme | | FEC Framework | | FEC Scheme |
| |-------------------------->| | | |-------------------------->| |
skipping to change at page 13, line 34 skipping to change at line 579
|(6) Source |(10) Repair payloads |(6) Source |(10) Repair payloads
| packets | | packets |
| + -- -- -- -- -+ | + -- -- -- -- -+
| | RTP | | | RTP |
| +-- -- -- -- --+ | +-- -- -- -- --+
v v v v
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
Figure 3: Sender Operation with Sliding Window FEC Codes and RTP Figure 3: Sender Operation with Sliding Window FEC Codes and RTP
Repair Flows Repair Flows
4.3. Receiver Operation with Sliding Window FEC Codes 4.3. Receiver Operation with Sliding Window FEC Codes
With a Sliding Window FEC Scheme, the following operations, With a Sliding Window FEC scheme, the following operations are
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
Section 4.3, "Receiver Operation". The new steps (4) and (5) are: Section 4.3 of [RFC6363] ("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, then is missing and at least one repair packet has been received, then
FEC decoding is attempted to recover missing source payloads. FEC decoding is attempted to recover the missing source payloads.
The FEC Scheme determines whether source packets have been lost The FEC scheme determines whether source packets have been lost
and whether enough repair packets have been received to decode and whether enough repair packets have been received to decode
any or all of the missing source payloads. 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
| |
+----------------------+ +----------------+ +----------------------+ +----------------+
| FEC Framework | | FEC Scheme | | FEC Framework | | FEC Scheme |
| |<--------------------------| | | |<--------------------------| |
|(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding|
| IDs and pass IDs & |-------------------------->| | | IDs and pass IDs & |-------------------------->| |
| payloads to FEC |(3) Explicit Source FEC +----------------+ | payloads to FEC |(3) Explicit Source FEC +----------------+
| scheme | Payload IDs | scheme | Payload IDs
+----------------------+ Repair FEC Payload IDs +----------------------+ Repair FEC Payload IDs
^ Source payloads ^ Source payloads
| Repair payloads | Repair payloads
|(1) FEC Source |(1) FEC Source
| and Repair Packets | and Repair Packets
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
Figure 4: Receiver Operation with Sliding Window FEC Codes Figure 4: Receiver Operation with Sliding Window FEC Codes
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
|(6) ADUs |(6) ADUs
| |
+----------------------+ +----------------+ +----------------------+ +----------------+
| FEC Framework | | FEC Scheme | | FEC Framework | | FEC Scheme |
| |<--------------------------| | | |<--------------------------| |
skipping to change at page 15, line 36 skipping to change at line 661
| +-- -- -- -- -- |--+ | | +-- -- -- -- -- |--+ |
| | RTP Demux | | | | RTP Demux | |
+-- -- -- -- -- -- -- -+ +-- -- -- -- -- -- -- -+
^ ^
|(1) FEC Source and Repair Packets |(1) FEC Source and Repair Packets
| |
+----------------------+ +----------------------+
| Transport Protocol | | Transport Protocol |
+----------------------+ +----------------------+
Figure 5: Receiver Operation with Sliding Window FEC Codes and RTP Figure 5: Receiver Operation with Sliding Window FEC Codes and
Repair Flows RTP Repair Flows
5. Protocol Specification 5. Protocol Specification
5.1. General 5.1. General
This section discusses the protocol elements for the FEC Framework This section discusses the protocol elements for the FEC Framework
specific to Sliding Window FEC schemes. The global formats of source specific to Sliding Window FEC schemes. The global formats of source
data packets (i.e., [RFC6363], Figure 6) and repair data packets data packets (i.e., [RFC6363], Figure 6) and repair data packets
(i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding
Window FEC codes. They are not repeated here. Window FEC codes. They are not repeated here.
5.2. FEC Framework Configuration Information 5.2. FEC Framework Configuration Information
The FEC Framework Configuration Information considerations of The FEC Framework Configuration Information considerations of
[RFC6363], Section 5.5, equally applies to this FECFRAME extension Section 5.5 of [RFC6363] equally apply to this FECFRAME extension and
and is not repeated here. are not repeated here.
5.3. FEC Scheme Requirements 5.3. FEC Scheme Requirements
The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply The FEC scheme requirements of Section 5.6 of [RFC6363] mostly apply
to this FECFRAME extension and are not repeated here. An exception to this FECFRAME extension and are not repeated here. An exception,
though is the "full specification of the FEC code", item (4), that is though, is the "full specification of the FEC code", item (4), which
specific to block FEC codes. The following item (4-bis) applies in is specific to block FEC codes. In case of a Sliding Window FEC
case of Sliding Window FEC schemes: scheme, then the following item (4-bis) applies:
4-bis. A full specification of the Sliding Window FEC code 4-bis.
A full specification of the Sliding Window FEC code.
This specification MUST precisely define the valid FEC-Scheme- This specification MUST precisely define the valid FEC-Scheme-
Specific Information values, the valid FEC Payload ID values, and Specific Information values, the valid FEC Payload ID values, and
the valid packet payload sizes (where packet payload refers to the valid packet payload sizes (where "packet payload" refers to
the space within a packet dedicated to carrying encoding the space within a packet dedicated to carrying encoding
symbols). symbols).
Furthermore, given valid values of the FEC-Scheme-Specific Furthermore, given valid values of the FEC-Scheme-Specific
Information, a valid Repair FEC Payload ID value, a valid packet Information, a valid Repair FEC Payload ID value, a valid packet
payload size, and a valid encoding window (i.e., a set of source payload size, and a valid encoding window (i.e., a set of source
symbols), the specification MUST uniquely define the values of symbols), the specification MUST uniquely define the values of
the encoding symbol (or symbols) to be included in the repair the encoding symbol (or symbols) to be included in the repair
packet payload with the given Repair FEC Payload ID value. packet payload with the given Repair FEC Payload ID value.
Additionally, the FEC Scheme associated to a Sliding Window FEC Code: Additionally, the FEC scheme associated with a Sliding Window FEC
code:
o MUST define the relationships between ADUs and the associated * 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 * 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. This usually * MUST define the management of the decoding window. This usually
consists in managing a system of linear equations (in case of a consists of managing a system of linear equations (for a linear
linear FEC code); FEC code).
6. Feedback 6. Feedback
The discussion of [RFC6363], Section 6, equally applies to this The discussion in Section 6 of [RFC6363] 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 in Section 7 of [RFC6363] equally applies to this
FECFRAME extension and is not repeated here. FECFRAME extension and is not repeated here.
8. Congestion Control 8. Congestion Control
The discussion of [RFC6363], Section 8, equally applies to this The discussion in Section 8 of [RFC6363] equally applies to this
FECFRAME extension and is not repeated here. FECFRAME extension and is not repeated here.
9. Implementation Status 9. Security Considerations
Editor's notes: RFC Editor, please remove this section motivated by
RFC 7942 before publishing the RFC. Thanks!
An implementation of FECFRAME extended to Sliding Window codes
exists:
o Organisation: Inria
o Description: This is an implementation of FECFRAME extended to
Sliding Window codes and supporting the RLC FEC Scheme [RLC-ID].
It is based on: (1) a proprietary implementation of FECFRAME, made
by Inria and Expway for which interoperability tests have been
conducted; and (2) a proprietary implementation of RLC Sliding
Window FEC Codes.
o Maturity: the basic FECFRAME maturity is "production", the
FECFRAME extension maturity is "under progress".
o Coverage: the software implements a subset of [RFC6363], as
specialized by the 3GPP eMBMS standard [MBMSTS]. This software
also covers the additional features of FECFRAME extended to
Sliding Window codes, in particular the RLC FEC Scheme.
o Licensing: proprietary.
o Implementation experience: maximum.
o Information update date: March 2018.
o Contact: vincent.roca@inria.fr
10. Security Considerations
This FECFRAME extension does not add any new security consideration. This FECFRAME extension does not add any new security considerations.
All the considerations of [RFC6363], Section 9, apply to this All the considerations of Section 9 of [RFC6363] apply to this
document as well. However, for the sake of completeness, the document as well. However, for the sake of completeness, the
following goal can be added to the list provided in Section 9.1 following goal can be added to the list provided in Section 9.1 of
"Problem Statement" of [RFC6363]: [RFC6363] ("Problem Statement"):
o Attacks can try to corrupt source flows in order to modify the * Attacks can try to corrupt source flows in order to modify the
receiver application's behavior (as opposed to just denying receiver application's behavior (as opposed to just denying
service). service).
11. Operations and Management Considerations 10. 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 Considerations. All the considerations of Section 10 of
Section 10, apply to this document as well. [RFC6363] apply to this document as well.
12. IANA Considerations 11. IANA Considerations
No IANA actions are required for this document. This document has no IANA actions.
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. Section 11 of [RFC6363] apply and are not repeated here.
13. Acknowledgments
The authors would like to thank Christer Holmberg, David Black, Gorry
Fairhurst, and Emmanuel Lochin, Spencer Dawkins, Ben Campbell,
Benjamin Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their
valuable feedback 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 12. References
14.1. Normative References 12.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>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011, DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>. <https://www.rfc-editor.org/info/rfc6363>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References 12.2. Informative References
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346, March 2009, Protocols and codecs", 3GPP TS 26.346, March 2009,
<http://ftp.3gpp.org/specs/html-info/26346.htm>. <http://ftp.3gpp.org/specs/html-info/26346.htm>.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, Correction (FEC) Building Block", RFC 5052,
DOI 10.17487/RFC5052, August 2007, DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>. <https://www.rfc-editor.org/info/rfc5052>.
skipping to change at page 19, line 45 skipping to change at line 818
DOI 10.17487/RFC6865, February 2013, DOI 10.17487/RFC6865, February 2013,
<https://www.rfc-editor.org/info/rfc6865>. <https://www.rfc-editor.org/info/rfc6865>.
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
S. Sivakumar, "Taxonomy of Coding Techniques for Efficient S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
Network Communications", RFC 8406, DOI 10.17487/RFC8406, Network Communications", RFC 8406, DOI 10.17487/RFC8406,
June 2018, <https://www.rfc-editor.org/info/rfc8406>. June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code [RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code
(RLC) Forward Erasure Correction (FEC) Scheme for (RLC) Forward Erasure Correction (FEC) Schemes for
FECFRAME", Work in Progress, Transport Area Working Group FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020,
(TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in <https://www.rfc-editor.org/info/rfc8681>.
Progress), September 2018, <https://tools.ietf.org/html/
draft-ietf-tsvwg-rlc-fec-scheme>.
Appendix A. About Sliding Encoding Window Management (informational) Appendix A. About Sliding Encoding Window Management (Informational)
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 informational hints. annex only provides a few informational 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 has been done.
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 * 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.
o once the sliding encoding window has reached its maximum size * Once the sliding encoding window has reached its maximum size
(there is usually an upper limit to the sliding encoding window (there is usually an upper limit to the sliding encoding window
size). In that case the oldest symbol is removed each time a new size). In that case, the oldest symbol is removed each time a new
source symbol is added. source symbol is added.
Several considerations can impact the management of this sliding Several considerations can impact the management of this sliding
encoding window: encoding window:
o at the source flows level: real-time constraints can limit the * At the source flows level: real-time constraints can limit the
total time source symbols can remain in the encoding window; total time during which source symbols can remain in the encoding
window.
o at the FEC code level: theoretical or practical limitations (e.g., * At the FEC code level: theoretical or practical limitations (e.g.,
because of computational complexity) can limit the number of because of computational complexity) can limit the number of
source symbols in the encoding window; source symbols in the encoding window.
o at the FEC Scheme level: signaling and window management are * At the FEC scheme level: signaling and window management are
intrinsically related. For instance, an encoding window composed intrinsically related. For instance, an encoding window composed
of a non-sequential set of source symbols requires an appropriate of a nonsequential set of source symbols requires appropriate
signaling to inform a receiver of the composition of the encoding signaling to inform a receiver of the composition of the encoding
window, and the associated transmission overhead can limit the window, and the associated transmission overhead can limit the
maximum encoding window size. On the opposite, an encoding window maximum encoding window size. On the contrary, an encoding window
always composed of a sequential set of source symbols simplifies always composed of a sequential set of source symbols simplifies
signaling: providing the identity of the first source symbol plus signaling: providing the identity of the first source symbol plus
their number is sufficient, which creates a fixed and relatively its number is sufficient, which creates a fixed and relatively
small transmission overhead. small transmission overhead.
Acknowledgments
The authors would like to thank Christer Holmberg, David Black, Gorry
Fairhurst, Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin
Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their valuable
feedback on this document. This document being an extension of
[RFC6363], the authors would also like to thank Mark Watson as the
main author of that RFC.
Authors' Addresses Authors' Addresses
Vincent Roca Vincent Roca
INRIA INRIA
Univ. Grenoble Alpes Univ. Grenoble Alpes
France France
EMail: vincent.roca@inria.fr Email: vincent.roca@inria.fr
Ali Begen Ali Begen
Networked Media Networked Media
Konya Konya/
Turkey Turkey
EMail: ali.begen@networked.media Email: ali.begen@networked.media
 End of changes. 147 change blocks. 
391 lines changed or deleted 383 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/