draft-ietf-tsvwg-fecframe-ext-03.txt   draft-ietf-tsvwg-fecframe-ext-04.txt 
TSVWG V. Roca TSVWG V. Roca
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Standards Track A. Begen Updates: 6363 (if approved) A. Begen
Expires: January 26, 2019 Networked Media Intended status: Standards Track Networked Media
July 25, 2018 Expires: March 11, 2019 September 7, 2018
Forward Error Correction (FEC) Framework Extension to Sliding Window Forward Error Correction (FEC) Framework Extension to Sliding Window
Codes Codes
draft-ietf-tsvwg-fecframe-ext-03 draft-ietf-tsvwg-fecframe-ext-04
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 extends FECFRAME to support FEC Codes codes. The present document extends FECFRAME to support FEC Codes
based on a sliding encoding window, in addition to Block FEC Codes, based on a sliding encoding window, in addition to Block FEC Codes,
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 January 26, 2019. This Internet-Draft will expire on March 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 3. Summary of Architecture Overview . . . . . . . . . . . . . . 7
4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 9 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 9
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Sender Operation with Sliding Window FEC Codes . . . . . 10 4.2. Sender Operation with Sliding Window FEC Codes . . . . . 10
4.3. Receiver Operation with Sliding Window FEC Codes . . . . 12 4.3. Receiver Operation with Sliding Window FEC Codes . . . . 12
5. Protocol Specification . . . . . . . . . . . . . . . . . . . 14 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. FEC Framework Configuration Information . . . . . . . . . 15 5.2. FEC Framework Configuration Information . . . . . . . . . 15
5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 15 5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 15
6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 16 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 2, line 49 skipping to change at page 2, line 49
Appendix A. About Sliding Encoding Window Management (non Appendix A. About Sliding Encoding Window Management (non
Normative) . . . . . . . . . . . . . . . . . . . . . 19 Normative) . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 received document: we assume that transmitted packets are either lost (e.g.,
without any corruption or totally lost (e.g., because of a congested because of a congested router, of a poor signal-to-noise ratio in a
router, of a poor signal-to-noise ratio in a wireless network, or wireless network, or because the number of bit errors exceeds the
because the number of bit errors exceeds the correction capabilities correction capabilities of the physical-layer error correcting code)
of a low-layer error correcting code). or received by the transport protocol without any corruption (i.e.,
the bit-errors, if any, have been fixed by the physical-layer 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 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 unreliable transports such as UDP. It is primarily packet flows over an unreliable datagram service transports such as
intended for real-time or streaming media applications, using UDP. It is primarily intended for real-time or streaming media
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. This approach
has major impacts on FEC encoding and decoding delays. The data has major impacts on FEC encoding and decoding delays. The data
packets of continuous media flow(s) may be passed to the transport packets of continuous media flow(s) may be passed to the transport
layer immediately, without delay. But the block creation time, that layer immediately, without delay. But the block creation time, that
depends on the number k of source symbols in this block, impacts the depends on the number of source symbols in this block, impacts both
FEC encoding delay since encoding requires that all source symbols be the FEC encoding delay (since encoding requires that all source
known. This block creation time also impacts the decoding delay a symbols be known), and mechanically the packet loss recovery delay at
receiver will experience in case of erasures, since no repair symbol a receiver (since no repair symbol for the current block can be
for the current block can be received before. Therefore a good value generated and therefore received before that time). Therefore a good
for the block size is necessarily a balance between the maximum value for the block size is necessarily a balance between the maximum
decoding latency at the receivers (which must be in line with the FEC decoding latency at the receivers (which must be in line with the
most stringent real-time requirement of the protected flow(s), hence most stringent real-time requirement of the protected flow(s), hence
an incentive to reduce the block size), and the desired robustness an incentive to reduce the block size), and the desired robustness
against long loss bursts (which increases with the block size, hence against long loss bursts (which increases with the block size, hence
an incentive to increase this size). an incentive to increase this size).
This document extends [RFC6363] in order to also support FEC codes This document extends [RFC6363] in order to also support FEC codes
based on a sliding encoding window (A.K.A. convolutional codes). based on a sliding encoding window (A.K.A. convolutional codes)
This encoding window, either of fixed or variable size, slides over [RFC8406]. This encoding window, either of fixed or variable size,
the set of source symbols. FEC encoding is launched whenever needed, slides over the set of source symbols. FEC encoding is launched
from the set of source symbols present in the sliding encoding window whenever needed, from the set of source symbols present in the
at that time. This approach significantly reduces FEC-related sliding encoding window at that time. This approach significantly
latency, since repair symbols can be generated and passed to the reduces FEC-related latency, since repair symbols can be generated
transport layer on-the-fly, at any time, and can be regularly and passed to the transport layer on-the-fly, at any time, and can be
received by receivers to quickly recover packet losses. Using regularly received by receivers to quickly recover packet losses.
sliding window FEC codes is therefore highly beneficial to real-time Using sliding window FEC codes is therefore highly beneficial to
flows, one of the primary targets of FECFRAME. [RLC-ID] provides an real-time flows, one of the primary targets of FECFRAME. [RLC-ID]
example of such FEC Scheme for FECFRAME, built upon the simple provides an example of such FEC Scheme for FECFRAME, built upon the
sliding window Random Linear Codes (RLC). simple sliding window Random Linear Codes (RLC).
This document is fully backward compatible with [RFC6363] that it This document is fully backward compatible with [RFC6363] that it
extends but does not replace. Indeed: extends but does not replace. Indeed:
o this extension does not prevent nor compromise in any way the o this extension does not prevent nor compromise in any way the
support of block FEC codes. Both types of codes can nicely co- support of block FEC codes. Both types of codes can nicely co-
exist, just like different block FEC schemes can co-exist; exist, just like different block FEC schemes can co-exist;
o any receiver, for instance a legacy receiver that only supports o any receiver, for instance a legacy receiver that only supports
block FEC schemes, can easily identify the FEC Scheme used in a block FEC schemes, can easily identify the FEC Scheme used in a
FECFRAME session thanks to the associated SDP file and its FEC FECFRAME session thanks to the associated SDP file and its FEC
Encoding ID information (i.e., the "encoding-id=" parameter of a Encoding ID information (i.e., the "encoding-id=" parameter of a
"fec-repair-flow" attribute, [RFC6364]). This mechanism is not "fec-repair-flow" attribute, [RFC6364]). This mechanism is not
specific to this extension but is the basic approach for a specific to this extension but is the basic approach for a
FECFRAME receiver to determine whether or not it supports the FEC FECFRAME receiver to determine whether or not it supports the FEC
Scheme used in a given FECFRAME session; Scheme 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 Section 3 that provides a required. The only exception is Section 3 that provides a quick
quick summary of FECFRAME in order to facilitate the understanding of summary of FECFRAME in order to facilitate the understanding of this
this document to readers not familiar with the concepts and document to readers not familiar with the concepts and terminology.
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.
skipping to change at page 6, line 20 skipping to change at page 6, line 20
Source Flow: The packet flow to which FEC protection is to be Source Flow: The packet flow to which FEC protection is to be
applied. A source flow consists of ADUs. applied. A source flow consists of ADUs.
Source FEC Payload ID: A FEC Payload ID specifically for use with Source FEC Payload ID: A FEC Payload ID specifically for use with
source packets. source packets.
Source Protocol: A protocol used for the source flow being Source Protocol: A protocol used for the source flow being
protected, e.g., RTP. protected, e.g., RTP.
Transport Protocol: The protocol used for the transport of the Transport Protocol: The protocol used for the transport of the
source and repair flows, e.g., UDP and the Datagram Congestion source and repair flows, using an unreliable datagram service
Control Protocol (DCCP). such as UDP.
Encoding Window: (ADDED) Set of Source Symbols available at the Encoding Window: (ADDED) Set of Source Symbols available at the
sender/coding node that are used to generate a repair symbol, sender/coding node that are used to generate a repair symbol,
with a Sliding Window FEC Code. with a Sliding Window FEC Code.
Decoding Window: (ADDED) Set of received or decoded source and Decoding Window: (ADDED) Set of received or decoded source and
repair symbols available at a receiver that are used to decode repair symbols available at a receiver that are used to decode
erased source symbols, with a Sliding Window FEC Code. erased source symbols, with a Sliding Window FEC Code.
Code Rate: The ratio between the number of source symbols and the Code Rate: The ratio between the number of source symbols and the
number of encoding symbols. By definition, the code rate is such number of encoding symbols. By definition, the code rate is such
that 0 < code rate <= 1. A code rate close to 1 indicates that a that 0 < code rate <= 1. A code rate close to 1 indicates that a
small number of repair symbols have been produced during the small number of repair symbols have been produced during the
encoding process. encoding process.
Encoding Symbol: Unit of data generated by the encoding process. Encoding Symbol: Unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding With systematic codes, source symbols are part of the encoding
symbols. symbols.
Packet Erasure Channel: A communication path where packets are Packet Erasure Channel: A communication path where packets are
either lost (e.g., by a congested router, or because the number either lost (e.g., in our case, by a congested router, or because
of transmission errors exceeds the correction capabilities of the the number of transmission errors exceeds the correction
physical-layer codes) or received. When a packet is received, it capabilities of the physical-layer code) or received. When a
is assumed that this packet is not corrupted. packet is received, it is assumed that this packet is not
corrupted (i.e., in our case, the bit-errors, if any, are fixed
by the physical-layer code and therefore 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: 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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. 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
document to readers not familiar with the concepts and terminology. document to readers not familiar with the concepts and terminology.
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
| |
skipping to change at page 7, line 41 skipping to change at page 7, line 46
|(6) Construct FEC |<--------------------------| | |(6) Construct FEC |<--------------------------| |
| Source and Repair | | | | Source and Repair | | |
| Packets |(5) Explicit Source FEC | | | Packets |(5) Explicit Source FEC | |
+----------------------+ 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 Layer | | Transport Protocol |
| (e.g., UDP) |
+----------------------+ +----------------------+
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 is the goal of
an ADU to symbols mapping process that is FEC Scheme specific (see an ADU to symbols mapping process that is FEC Scheme specific (see
below). Once the source block is built, taking into account both the below). Once the source block is built, taking into account both the
FEC Scheme constraints (e.g., in terms of maximum source block size) FEC Scheme constraints (e.g., in terms of maximum source block size)
and the application's flow constraints (e.g., in terms of real-time and the application's flow constraints (e.g., in terms of real-time
constraints), the associated source symbols are handed to the FEC constraints), the associated source symbols are handed to the FEC
Scheme in order to produce an appropriate number of repair symbols. Scheme in order to produce an appropriate number of repair symbols.
FEC Source Packets (containing ADUs) and FEC Repair Packets FEC Source Packets (containing ADUs) and FEC Repair Packets
(containing one or more repair symbols each) are then generated and (containing one or more repair symbols each) are then generated and
sent using UDP (more precisely [RFC6363], Section 7, requires a sent using an appropriate transport protocol (more precisely
transport protocol providing an unreliable datagram service, like UDP [RFC6363], Section 7, requires a transport protocol providing an
or DCCP). In practice FEC Source Packets may be passed to the unreliable datagram service, such as UDP). In practice FEC Source
transport layer as soon as available, without having to wait for FEC Packets may be passed to the transport layer as soon as available,
encoding to take place. In that case a copy of the associated source without having to wait for FEC encoding to take place. In that case
symbols needs to be kept within FECFRAME for future FEC encoding a copy of the associated source symbols needs to be kept within
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
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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
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 case of UDP repair flows, and in illustrated in Figure 2 for the generic case (non-RTP repair flows),
Figure 3 for the case of RTP repair flows, describe a possible way to and in Figure 3 for the case of RTP repair flows, describe a possible
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 some hints on and MUST be detailed there. Appendix A provides non normative
the way it might be performed. 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.
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
(for example, in the UDP case, the UDP source and destination (e.g., the source and destination addresses and UDP port numbers
addresses and ports on the IP datagram carrying the source on the IP datagram carrying the source packet will be the same
packet will be the same whether or not the FEC Framework is whether or not the FEC Framework is applied).
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.
skipping to change at page 11, line 33 skipping to change at page 11, line 33
| Source Packet | FEC Payload ID(s) |(7) FEC | | Source Packet | FEC Payload ID(s) |(7) FEC |
| |<--------------------------| encoding | | |<--------------------------| encoding |
|(9) Construct FEC | (8) Repair FEC Payload ID | | |(9) Construct FEC | (8) Repair FEC Payload ID | |
| 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 Layer | | Transport Protocol |
| (e.g., UDP) |
+----------------------+ +----------------------+
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
skipping to change at page 12, line 31 skipping to change at page 12, line 31
| Repair Packet(s) | + Repair symbol(s) +----------------+ | Repair Packet(s) | + Repair symbol(s) +----------------+
+---------------------+ +---------------------+
| | | |
|(6) Source |(10) Repair payloads |(6) Source |(10) Repair payloads
| packets | | packets |
| + -- -- -- -- -+ | + -- -- -- -- -+
| | RTP | | | RTP |
| +-- -- -- -- --+ | +-- -- -- -- --+
v v v v
+----------------------+ +----------------------+
| Transport Layer | | Transport Protocol |
| (e.g., UDP) |
+----------------------+ +----------------------+
Figure 3: Sender Operation with RTP Repair Flows Figure 3: Sender Operation with Sliding Window FEC Codes and RTP
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,
illustrated in Figure 4 for the case of UDP repair flows, and in illustrated in Figure 4 for the generic case (non-RTP repair flows),
Figure 5 for the case of RTP repair flows. The only differences with and in Figure 5 for the case of RTP repair flows. The only
respect to block FEC codes lie in steps (4) and (5). Therefore this differences with respect to block FEC codes lie in steps (4) and (5).
section does not repeat the other steps of [RFC6363], Section 4.3, Therefore this section does not repeat the other steps of [RFC6363],
"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 and
the rank of the associated linear system permits it, then FEC the rank of the associated linear system permits it, then FEC
decoding can be performed in order to recover missing source decoding can be performed in order to recover missing source
payloads. The FEC Scheme determines whether source packets have payloads. The FEC Scheme determines whether source packets have
been lost and whether enough repair packets have been received to been lost and whether enough repair packets have been received to
skipping to change at page 13, line 31 skipping to change at page 13, line 31
|(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 Layer | | Transport Protocol |
| (e.g., UDP) |
+----------------------+ +----------------------+
Figure 4: Receiver Operation with Sliding Window FEC Codes Figure 4: Receiver Operation with Sliding Window FEC Codes
+----------------------+ +----------------------+
| Application | | Application |
+----------------------+ +----------------------+
^ ^
|(6) ADUs |(6) ADUs
| |
skipping to change at page 14, line 33 skipping to change at page 14, line 33
+-- |- -- -- -- -- -- -+ +-- |- -- -- -- -- -- -+
|RTP| | RTP Processing | |RTP| | RTP Processing |
| | +-- -- -- --|-- -+ | | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ | | +-- -- -- -- -- |--+ |
| | RTP Demux | | | | RTP Demux | |
+-- -- -- -- -- -- -- -+ +-- -- -- -- -- -- -- -+
^ ^
|(1) FEC Source and Repair Packets |(1) FEC Source and Repair Packets
| |
+----------------------+ +----------------------+
| Transport Layer | | Transport Protocol |
| (e.g., UDP) |
+----------------------+ +----------------------+
Figure 5: Receiver Operation with RTP Repair Flows Figure 5: Receiver Operation with Sliding Window FEC Codes and 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.
skipping to change at page 15, line 16 skipping to change at page 15, line 16
The FEC Framework Configuration Information considerations of The FEC Framework Configuration Information considerations of
[RFC6363], Section 5.5, equally applies to this FECFRAME extension [RFC6363], Section 5.5, equally applies to this FECFRAME extension
and is not repeated here. and is 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 [RFC6363], Section 5.6, 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), that is
specific to block FEC codes. The following item (4) applies in case specific to block FEC codes. The following item (4-bis) applies in
of Sliding Window FEC schemes: case of Sliding Window FEC schemes:
4. 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 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 a non normative example; the set of ADUs. Appendix A provides non normative hints about
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, consisting of a
system of linear equations (in case of a linear FEC code); 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
skipping to change at page 18, line 27 skipping to change at page 18, line 27
(FEC) Scheme for FECFRAME", RFC 6816, (FEC) Scheme for FECFRAME", RFC 6816,
DOI 10.17487/RFC6816, December 2012, DOI 10.17487/RFC6816, December 2012,
<https://www.rfc-editor.org/info/rfc6816>. <https://www.rfc-editor.org/info/rfc6816>.
[RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
Matsuzono, "Simple Reed-Solomon Forward Error Correction Matsuzono, "Simple Reed-Solomon Forward Error Correction
(FEC) Scheme for FECFRAME", RFC 6865, (FEC) Scheme for FECFRAME", RFC 6865,
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,
F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
Network Communications", RFC 8406, DOI 10.17487/RFC8406,
June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code [RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code
(RLC) Forward Erasure Correction (FEC) Scheme for (RLC) Forward Erasure Correction (FEC) Scheme for
FECFRAME", Work in Progress, Transport Area Working Group FECFRAME", Work in Progress, Transport Area Working Group
(TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in
Progress), July 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
 End of changes. 29 change blocks. 
82 lines changed or deleted 90 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/