doc: Add RFC documents

1 files changed, 896 insertions, 0 deletions

diff --git a/doc/rfc/rfc8680.txt b/doc/rfc/rfc8680.txt
new file mode 100644
index 0000000..ee049c2
--- /dev/null
+++ b/doc/rfc/rfc8680.txt
@@ -0,0 +1,896 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           V. Roca
+Request for Comments: 8680                                         INRIA
+Updates: 6363                                                   A. Begen
+Category: Standards Track                                Networked Media
+ISSN: 2070-1721                                             January 2020
+
+
+  Forward Error Correction (FEC) Framework Extension to Sliding Window
+                                 Codes
+
+Abstract
+
+   RFC 6363 describes a framework for using Forward Error Correction
+   (FEC) codes to provide protection against packet loss.  The framework
+   supports applying FEC to arbitrary packet flows over unreliable
+   transport and is primarily intended for real-time, or streaming,
+   media.  However, FECFRAME as per RFC 6363 is restricted to block FEC
+   codes.  This document updates RFC 6363 to support FEC codes based on
+   a sliding encoding window, in addition to block FEC codes, in a
+   backward-compatible way.  During multicast/broadcast real-time
+   content delivery, the use of sliding window codes significantly
+   improves robustness in harsh environments, with less repair traffic
+   and lower FEC-related added latency.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   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 (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+     2.1.  Definitions and Abbreviations
+     2.2.  Requirements Language
+   3.  Summary of Architecture Overview
+   4.  Procedural Overview
+     4.1.  General
+     4.2.  Sender Operation with Sliding Window FEC Codes
+     4.3.  Receiver Operation with Sliding Window FEC Codes
+   5.  Protocol Specification
+     5.1.  General
+     5.2.  FEC Framework Configuration Information
+     5.3.  FEC Scheme Requirements
+   6.  Feedback
+   7.  Transport Protocols
+   8.  Congestion Control
+   9.  Security Considerations
+   10. Operations and Management Considerations
+   11. IANA Considerations
+   12. References
+     12.1.  Normative References
+     12.2.  Informative References
+   Appendix A.  About Sliding Encoding Window Management
+           (Informational)
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   Many applications need to transport a continuous stream of packetized
+   data from a source (sender) to one or more destinations (receivers)
+   over networks that do not provide guaranteed packet delivery.  In
+   particular, packets may be lost, which is strictly the focus of this
+   document: we assume that transmitted packets are either lost (e.g.,
+   because of a congested router, a poor signal-to-noise ratio in a
+   wireless network, or because the number of bit errors exceeds the
+   correction capabilities of the physical-layer error-correcting code)
+   or were 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
+   the transport or application layer is an efficient technique to
+   improve packet transmission robustness in the presence of packet
+   losses (or "erasures") without going through packet retransmissions
+   that create a delay often incompatible with real-time constraints.
+   The FEC Building Block defined in [RFC5052] provides a framework for
+   the definition of Content Delivery Protocols (CDPs) that make use of
+   separately defined FEC schemes.  Any CDP defined according to the
+   requirements of the FEC Building Block can then easily be used with
+   any FEC scheme that is also defined according to the requirements of
+   the FEC Building Block.
+
+   Then, FECFRAME [RFC6363] provides a framework to define Content
+   Delivery Protocols (CDPs) that provide FEC protection for arbitrary
+   packet flows over an unreliable datagram service transport, such as
+   UDP.  It is primarily intended for real-time or streaming media
+   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
+   accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681],
+   [RFC6816], or [RFC6865]).  These codes require the input flow(s) to
+   be segmented into a sequence of blocks.  Then, FEC encoding (at a
+   sender or an encoding middlebox) and decoding (at a receiver or a
+   decoding middlebox) are both performed on a per-block basis.  For
+   instance, if the current block encompasses the 100's to 119's source
+   symbols (i.e., a block of size 20 symbols) of an input flow, encoding
+   (and decoding) will be performed on this block independently of other
+   blocks.  This approach has major impacts on FEC encoding and decoding
+   delays.  The data packets of continuous media flow(s) may be passed
+   to the transport layer immediately, without delay.  But the block
+   creation time, which depends on the number of source symbols in this
+   block, impacts both the FEC encoding delay (since encoding requires
+   that all source symbols be known) and, mechanically, the packet loss
+   recovery delay at a receiver (since no repair symbol for the current
+   block can be generated and therefore received before that time).
+   Therefore, a good value for the block size is necessarily a balance
+   between the maximum FEC decoding latency at the receivers (which must
+   be in line with the most stringent real-time requirement of the
+   protected flow(s), hence an incentive to reduce the block size) and
+   the desired robustness against long loss bursts (which increases with
+   the block size, hence an incentive to increase this size).
+
+   This document updates [RFC6363] in order to also support FEC codes
+   based on a sliding encoding window (a.k.a., convolutional codes)
+   [RFC8406].  This encoding window, either fixed or variable size,
+   slides over the set of source symbols.  FEC encoding is launched
+   whenever needed from the set of source symbols present in the sliding
+   encoding window at that time.  This approach significantly reduces
+   FEC-related latency, since repair symbols can be generated and passed
+   to the transport layer on the fly at any time and can be regularly
+   received by receivers to quickly recover packet losses.  Using
+   sliding window FEC codes is therefore highly beneficial to real-time
+   flows, one of the primary targets of FECFRAME.  [RFC8681] provides an
+   example of such a FEC scheme for FECFRAME, which is built upon the
+   simple sliding window Random Linear Code (RLC).
+
+   This document is fully backward compatible with [RFC6363].  Indeed:
+
+   *  This FECFRAME update does not prevent or compromise in any way the
+      support of block FEC codes.  Both types of codes can nicely
+      coexist, just like different block FEC schemes can coexist.
+
+   *  Each sliding window FEC scheme is associated with a specific FEC
+      Encoding ID subject to IANA registration, just like block FEC
+      schemes.
+
+   *  Any receiver -- for instance, a legacy receiver that only supports
+      block FEC schemes -- can easily identify the FEC scheme used in a
+      FECFRAME session.  Indeed, the FEC Encoding ID that identifies the
+      FEC scheme is carried in FEC Framework Configuration Information
+      (see Section 5.5 of [RFC6363]).  For instance, when the Session
+      Description Protocol (SDP) is used to carry the FEC Framework
+      Configuration Information, the FEC Encoding ID can be communicated
+      in the "encoding-id=" parameter of a "fec-repair-flow" attribute
+      [RFC6364].  This mechanism is the basic approach for a FECFRAME
+      receiver to determine whether or not it supports the FEC scheme
+      used in a given FECFRAME session.
+
+   This document leverages on [RFC6363] and reuses its structure.  It
+   proposes new sections specific to sliding window FEC codes whenever
+   required.  The only exception is Section 3, which provides a quick
+   summary of FECFRAME in order to facilitate the understanding of this
+   document to readers not familiar with the concepts and terminology.
+
+2.  Terminology
+
+2.1.  Definitions and Abbreviations
+
+   The following list of definitions and abbreviations is copied from
+   [RFC6363], adding only the Block FEC Code, Sliding Window FEC Code,
+   and Encoding/Decoding Window definitions (tagged with "ADDED"):
+
+   Application Data Unit (ADU):
+      The unit of source data provided as a payload to the transport
+      layer.  For instance, it can be a payload containing the result of
+      the RTP packetization of a compressed video frame.
+
+   ADU Flow:
+      A sequence of ADUs associated with a transport-layer flow
+      identifier (such as the standard 5-tuple {source IP address,
+      source port, destination IP address, destination port, transport
+      protocol}).
+
+   AL-FEC:
+      Application-Layer Forward Error Correction.
+
+   Application Protocol:
+      Control protocol used to establish and control the source flow
+      being protected, e.g., the Real-Time Streaming Protocol (RTSP).
+
+   Content Delivery Protocol (CDP):
+      A complete application protocol specification that, through the
+      use of the framework defined in this document, is able to make use
+      of FEC schemes to provide FEC capabilities.
+
+   FEC Code:
+      An algorithm for encoding data such that the encoded data flow is
+      resilient to data loss.  Note that, in general, FEC codes may also
+      be used to make a data flow resilient to corruption, but that is
+      not considered in this document.
+
+   Block FEC Code: (ADDED)
+      A FEC code that operates on blocks, i.e., for which the input flow
+      MUST be segmented into a sequence of blocks, with FEC encoding and
+      decoding being performed independently on a per-block basis.
+
+   Sliding Window FEC Code: (ADDED)
+      A FEC code that can generate repair symbols on the fly, at any
+      time, from the set of source symbols present in the sliding
+      encoding window at that time.  These codes are also known as
+      convolutional codes.
+
+   FEC Framework:
+      A protocol framework for the definition of Content Delivery
+      Protocols using FEC, such as the framework defined in this
+      document.
+
+   FEC Framework Configuration Information:
+      Information that controls the operation of the FEC Framework.
+
+   FEC Payload ID:
+      Information that identifies the contents and provides positional
+      information of a packet with respect to the FEC scheme.
+
+   FEC Repair Packet:
+      At a sender (respectively, at a receiver), a payload submitted to
+      (respectively, received from) the transport protocol containing
+      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 aspects
+      required to use a particular FEC code with the FEC Framework.
+
+   FEC Source Packet:
+      At a sender (respectively, at a receiver), a payload submitted to
+      (respectively, received from) the transport protocol containing an
+      ADU along with an optional Explicit Source FEC Payload ID.
+
+   Repair Flow:
+      The packet flow carrying FEC data.
+
+   Repair FEC Payload ID:
+      A FEC Payload ID specifically for use with repair packets.
+
+   Source Flow:
+      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 packets.
+
+   Source Protocol:
+      A protocol used for the source flow being protected, e.g., RTP.
+
+   Transport Protocol:
+      The protocol used for the transport of the source and repair
+      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 sender/coding node that are
+      used (with a Sliding Window FEC code) to generate a repair symbol.
+
+   Decoding Window: (ADDED)
+      Set of received or decoded source and repair symbols available at
+      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 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 small
+      number of repair symbols have been produced during the encoding
+      process.
+
+   Encoding Symbol:
+      Unit of data generated by the encoding process.  With systematic
+      codes, source symbols are part of the encoding symbols.
+
+   Packet Erasure Channel:
+      A communication path where packets are either lost (e.g., in our
+      case, by a congested router, or because the number of transmission
+      errors exceeds the correction capabilities of the physical-layer
+      code) or received.  When a 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 are therefore
+      hidden to the upper layers).
+
+   Repair Symbol:
+      Encoding symbol that is not a source symbol.
+
+   Source Block:
+      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.
+
+   Systematic Code:
+      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",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Summary of Architecture Overview
+
+   The architecture of Section 3 of [RFC6363] equally applies to this
+   FECFRAME extension and is not repeated here.  However, this section
+   includes a quick summary to facilitate the understanding of this
+   document to readers not familiar with the concepts and terminology.
+
+   +----------------------+
+   |     Application      |
+   +----------------------+
+              |
+              | (1) Application Data Units (ADUs)
+              |
+              v
+   +----------------------+                           +----------------+
+   |    FEC Framework     |                           |                |
+   |                      |-------------------------->|   FEC Scheme   |
+   |(2) Construct source  |(3) Source Block           |                |
+   |    blocks            |                           |(4) FEC Encoding|
+   |(6) Construct FEC     |<--------------------------|                |
+   |    Source and Repair |                           |                |
+   |    Packets           |(5) Explicit Source FEC    |                |
+   +----------------------+    Payload IDs            +----------------+
+              |                Repair FEC Payload IDs
+              |                Repair symbols
+              |
+              |(7) FEC Source and Repair Packets
+              v
+   +----------------------+
+   |  Transport Protocol  |
+   +----------------------+
+
+                Figure 1: FECFRAME Architecture at a Sender
+
+   The FECFRAME architecture is illustrated in Figure 1 for a block FEC
+   scheme from the sender's point of view.  It shows an application
+   generating an ADU flow (other flows from other applications may
+   coexist).  These ADUs of variable size must be somehow mapped to
+   source symbols of a fixed size (this fixed size is a requirement of
+   all FEC schemes, which comes from the way mathematical operations are
+   applied to the symbols' content).  This is the goal of an ADU-to-
+   symbols mapping process that is FEC scheme specific (see below).
+   Once the source block is built, taking into account both the 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
+   constraints), the associated source symbols are handed to the FEC
+   scheme in order to produce an appropriate number of repair symbols.
+   FEC Source Packets (containing ADUs) and FEC Repair Packets
+   (containing one or more repair symbols each) are then generated and
+   sent using an appropriate transport protocol (more precisely,
+   Section 7 of [RFC6363] requires a transport protocol providing an
+   unreliable datagram service, such as UDP).  In practice, FEC Source
+   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,
+   a copy of the associated source symbols needs to be kept within
+   FECFRAME for future FEC encoding purposes.
+
+   At a receiver (not shown), FECFRAME processing operates in a similar
+   way, taking as input the incoming FEC Source and Repair Packets
+   received.  In case of FEC Source Packet losses, the FEC decoding of
+   the associated block may recover all (in case of successful decoding)
+   or a subset that is potentially empty (if decoding fails) of the
+   missing source symbols.  After source-symbol-to-ADU mapping, when
+   lost ADUs are recovered, they are then assigned to their respective
+   flow (see below).  ADUs are returned to the application(s), either in
+   their initial transmission order (in which case all ADUs received
+   after a lost ADU will be delayed until FEC decoding has taken place)
+   or not (in which case each ADU is returned as soon as it is received
+   or recovered), depending on the application requirements.
+
+   FECFRAME features two subtle mechanisms whose details are FEC scheme
+   dependent:
+
+   *  ADUs-to-source-symbols mapping: in order to manage variable size
+      ADUs, FECFRAME and FEC schemes can use small, fixed-size symbols
+      and create a mapping between ADUs and symbols.  The mapping
+      details are FEC scheme dependent and must be defined in the
+      associated document.  For instance, with certain FEC schemes, to
+      each ADU, this mechanism prepends a length field (plus a flow
+      identifier; see below) and pads the result to a multiple of the
+      symbol size.  A small ADU may be mapped to a single source symbol,
+      while a large one may be mapped to multiple symbols.
+
+   *  Assignment of decoded ADUs to flows in multi-flow configurations:
+      when multiple flows are multiplexed over the same FECFRAME
+      instance, a problem is to assign a decoded ADU to the right flow
+      (UDP port numbers and IP addresses traditionally used to map
+      incoming ADUs to flows are not recovered during FEC decoding).
+      The mapping details are FEC scheme dependent and must be defined
+      in the associated document.  For instance, with certain FEC
+      schemes, to make it possible, at the FECFRAME sending instance,
+      each ADU is prepended with a flow identifier (1 byte) during the
+      ADU-to-source-symbols mapping (see above).  The flow identifiers
+      are also shared between all FECFRAME instances as part of the FEC
+      Framework Configuration Information.  The ADU Information (ADUI),
+      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:
+
+   *  Section 8 of [RFC6363] does not detail any congestion control
+      mechanisms and only provides high-level normative requirements.
+
+   *  The possibility of having feedback from receiver(s) is considered
+      out of scope, although such a mechanism may exist within the
+      application (e.g., through RTP Control Protocol (RTCP) messages).
+
+   *  Flow adaptation at a FECFRAME sender (e.g., how to set the FEC
+      code rate based on transmission conditions) is not detailed, but
+      it needs to comply with the congestion control normative
+      requirements (see above).
+
+4.  Procedural Overview
+
+4.1.  General
+
+   The general considerations of Section 4.1 of [RFC6363] that are
+   specific to block FEC codes are not repeated here.
+
+   With a Sliding Window FEC code, the FEC Source Packet MUST contain
+   information to identify the position occupied by the ADU within the
+   source flow in terms specific to the FEC scheme.  This information is
+   known as the Source FEC Payload ID, and the FEC scheme is responsible
+   for defining and interpreting it.
+
+   With a Sliding Window FEC code, the FEC Repair Packets MUST contain
+   information that identifies the relationship between the contained
+   repair payloads and the original source symbols used during encoding.
+   This information is known as the Repair FEC Payload ID, and the FEC
+   scheme is responsible for defining and interpreting it.
+
+   The sender operation ([RFC6363], Section 4.2) and receiver operation
+   ([RFC6363], Section 4.3) are both specific to block FEC codes and are
+   therefore omitted below.  The following two sections detail similar
+   operations for Sliding Window FEC codes.
+
+4.2.  Sender Operation with Sliding Window FEC Codes
+
+   With a Sliding Window FEC scheme, the following operations,
+   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
+   way to generate compliant source and repair flows:
+
+   1.   A new ADU is provided by the application.
+
+   2.   The FEC Framework communicates this ADU to the FEC scheme.
+
+   3.   The sliding encoding window is updated by the FEC scheme.  The
+        ADU-to-source-symbol mapping as well as the encoding window
+        management details are both the responsibility of the FEC scheme
+        and MUST be detailed there.  Appendix A provides non-normative
+        hints about what FEC scheme designers need to consider.
+
+   4.   The Source FEC Payload ID information of the source packet is
+        determined by the FEC scheme.  If required by the FEC scheme,
+        the Source FEC Payload ID is encoded into the Explicit Source
+        FEC Payload ID field and returned to the FEC Framework.
+
+   5.   The FEC Framework constructs the FEC Source Packet according to
+        Figure 6 in [RFC6363], using the Explicit Source FEC Payload ID
+        provided by the FEC scheme if applicable.
+
+   6.   The FEC Source Packet is sent using normal transport-layer
+        procedures.  This packet is sent using the same ADU flow
+        identification information as would have been used for the
+        original source packet if the FEC Framework were not present
+        (e.g., the source and destination addresses and UDP port numbers
+        on the IP datagram carrying the source packet will be the same
+        whether or not the FEC Framework is applied).
+
+   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
+        FEC scheme to create one or several repair packet payloads from
+        the current sliding encoding window along with their Repair FEC
+        Payload ID.
+
+   8.   The Repair FEC Payload IDs and repair packet payloads are
+        provided back by the FEC scheme to the FEC Framework.
+
+   9.   The FEC Framework constructs FEC Repair Packets according to
+        Figure 7 in [RFC6363], using the FEC Payload IDs and repair
+        packet payloads provided by the FEC scheme.
+
+   10.  The FEC Repair Packets are sent using normal transport-layer
+        procedures.  The port(s) and multicast group(s) to be used for
+        FEC Repair Packets are defined in the FEC Framework
+        Configuration Information.
+
+   +----------------------+
+   |     Application      |
+   +----------------------+
+              |
+              | (1) New Application Data Unit (ADU)
+              v
+   +---------------------+                           +----------------+
+   |    FEC Framework    |                           |   FEC Scheme   |
+   |                     |-------------------------->|                |
+   |                     | (2) New ADU               |(3) Update of   |
+   |                     |                           |    encoding    |
+   |                     |<--------------------------|    window      |
+   |(5) Construct FEC    | (4) Explicit Source       |                |
+   |    Source Packet    |     FEC Payload ID(s)     |(7) FEC         |
+   |                     |<--------------------------|    encoding    |
+   |(9) Construct FEC    | (8) Repair FEC Payload ID |                |
+   |    Repair Packet(s) |     + Repair symbol(s)    +----------------+
+   +---------------------+
+              |
+              | (6)  FEC Source Packet
+              | (10) FEC Repair Packets
+              v
+   +----------------------+
+   |  Transport Protocol  |
+   +----------------------+
+
+          Figure 2: Sender Operation with Sliding Window FEC Codes
+
+   +----------------------+
+   |     Application      |
+   +----------------------+
+              |
+              | (1) New Application Data Unit (ADU)
+              v
+   +---------------------+                           +----------------+
+   |    FEC Framework    |                           |   FEC Scheme   |
+   |                     |-------------------------->|                |
+   |                     | (2) New ADU               |(3) Update of   |
+   |                     |                           |    encoding    |
+   |                     |<--------------------------|    window      |
+   |(5) Construct FEC    | (4) Explicit Source       |                |
+   |    Source Packet    |     FEC Payload ID(s)     |(7) FEC         |
+   |                     |<--------------------------|    encoding    |
+   |(9) Construct FEC    | (8) Repair FEC Payload ID |                |
+   |    Repair Packet(s) |     + Repair symbol(s)    +----------------+
+   +---------------------+
+       |             |
+       |(6) Source   |(10) Repair payloads
+       |    packets  |
+       |      + -- -- -- -- -+
+       |      |     RTP      |
+       |      +-- -- -- -- --+
+       v             v
+   +----------------------+
+   |  Transport Protocol  |
+   +----------------------+
+
+      Figure 3: Sender Operation with Sliding Window FEC Codes and RTP
+                                Repair Flows
+
+4.3.  Receiver Operation with Sliding Window FEC Codes
+
+   With a Sliding Window FEC scheme, the following operations are
+   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
+   differences with respect to block FEC codes lie in steps (4) and (5).
+   Therefore, this section does not repeat the other steps of
+   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
+       Source Payload IDs when the Explicit Source FEC Payload ID field
+       is not used) to insert source and repair packets into the
+       decoding window in the right way.  If at least one source packet
+       is missing and at least one repair packet has been received, then
+       FEC decoding is attempted to recover the missing source payloads.
+       The FEC scheme determines whether source packets have been lost
+       and whether enough repair packets have been received to decode
+       any or all of the missing source payloads.
+
+   5.  The FEC scheme returns the received and decoded ADUs to the FEC
+       Framework, along with indications of any ADUs that were missing
+       and could not be decoded.
+
+   +----------------------+
+   |     Application      |
+   +----------------------+
+              ^
+              |(6) ADUs
+              |
+   +----------------------+                           +----------------+
+   |    FEC Framework     |                           |   FEC Scheme   |
+   |                      |<--------------------------|                |
+   |(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding|
+   |   IDs and pass IDs & |-------------------------->|                |
+   |   payloads to FEC    |(3) Explicit Source FEC    +----------------+
+   |   scheme             |            Payload IDs
+   +----------------------+    Repair FEC Payload IDs
+              ^                Source payloads
+              |                Repair payloads
+              |(1) FEC Source
+              |    and Repair Packets
+   +----------------------+
+   |  Transport Protocol  |
+   +----------------------+
+
+         Figure 4: Receiver Operation with Sliding Window FEC Codes
+
+   +----------------------+
+   |     Application      |
+   +----------------------+
+              ^
+              |(6) ADUs
+              |
+   +----------------------+                           +----------------+
+   |    FEC Framework     |                           |   FEC Scheme   |
+   |                      |<--------------------------|                |
+   |(2)Extract FEC Payload|(5) ADUs                   |(4) FEC Decoding|
+   |   IDs and pass IDs & |-------------------------->|                |
+   |   payloads to FEC    |(3) Explicit Source FEC    +----------------+
+   |   scheme             |            Payload IDs
+   +----------------------+    Repair FEC Payload IDs
+       ^             ^         Source payloads
+       |             |         Repair payloads
+       |Source pkts  |Repair payloads
+       |             |
+   +-- |- -- -- -- -- -- -+
+   |RTP| | RTP Processing |
+   |   | +-- -- -- --|-- -+
+   | +-- -- -- -- -- |--+ |
+   | | RTP Demux        | |
+   +-- -- -- -- -- -- -- -+
+              ^
+              |(1) FEC Source and Repair Packets
+              |
+   +----------------------+
+   |  Transport Protocol  |
+   +----------------------+
+
+       Figure 5: Receiver Operation with Sliding Window FEC Codes and
+                              RTP Repair Flows
+
+5.  Protocol Specification
+
+5.1.  General
+
+   This section discusses the protocol elements for the FEC Framework
+   specific to Sliding Window FEC schemes.  The global formats of source
+   data packets (i.e., [RFC6363], Figure 6) and repair data packets
+   (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding
+   Window FEC codes.  They are not repeated here.
+
+5.2.  FEC Framework Configuration Information
+
+   The FEC Framework Configuration Information considerations of
+   Section 5.5 of [RFC6363] equally apply to this FECFRAME extension and
+   are not repeated here.
+
+5.3.  FEC Scheme Requirements
+
+   The FEC scheme requirements of Section 5.6 of [RFC6363] mostly apply
+   to this FECFRAME extension and are not repeated here.  An exception,
+   though, is the "full specification of the FEC code", item (4), which
+   is specific to block FEC codes.  In case of a Sliding Window FEC
+   scheme, then the following item (4-bis) applies:
+
+   4-bis.
+       A full specification of the Sliding Window FEC code.
+
+       This specification MUST precisely define the valid FEC-Scheme-
+       Specific Information values, the valid FEC Payload ID values, and
+       the valid packet payload sizes (where "packet payload" refers to
+       the space within a packet dedicated to carrying encoding
+       symbols).
+
+       Furthermore, given valid values of the FEC-Scheme-Specific
+       Information, a valid Repair FEC Payload ID value, a valid packet
+       payload size, and a valid encoding window (i.e., a set of source
+       symbols), the specification MUST uniquely define the values of
+       the encoding symbol (or symbols) to be included in the repair
+       packet payload with the given Repair FEC Payload ID value.
+
+   Additionally, the FEC scheme associated with a Sliding Window FEC
+   code:
+
+   *  MUST define the relationships between ADUs and the associated
+      source symbols (mapping).
+
+   *  MUST define the management of the encoding window that slides over
+      the set of ADUs.  Appendix A provides non-normative hints about
+      what FEC scheme designers need to consider.
+
+   *  MUST define the management of the decoding window.  This usually
+      consists of managing a system of linear equations (for a linear
+      FEC code).
+
+6.  Feedback
+
+   The discussion in Section 6 of [RFC6363] equally applies to this
+   FECFRAME extension and is not repeated here.
+
+7.  Transport Protocols
+
+   The discussion in Section 7 of [RFC6363] equally applies to this
+   FECFRAME extension and is not repeated here.
+
+8.  Congestion Control
+
+   The discussion in Section 8 of [RFC6363] equally applies to this
+   FECFRAME extension and is not repeated here.
+
+9.  Security Considerations
+
+   This FECFRAME extension does not add any new security considerations.
+   All the considerations of Section 9 of [RFC6363] apply to this
+   document as well.  However, for the sake of completeness, the
+   following goal can be added to the list provided in Section 9.1 of
+   [RFC6363] ("Problem Statement"):
+
+   *  Attacks can try to corrupt source flows in order to modify the
+      receiver application's behavior (as opposed to just denying
+      service).
+
+10.  Operations and Management Considerations
+
+   This FECFRAME extension does not add any new Operations and
+   Management Considerations.  All the considerations of Section 10 of
+   [RFC6363] apply to this document as well.
+
+11.  IANA Considerations
+
+   This document has no IANA actions.
+
+   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
+   Framework (FECFRAME) FEC Encoding IDs" registry.  All the rules of
+   Section 11 of [RFC6363] apply and are not repeated here.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
+              Correction (FEC) Framework", RFC 6363,
+              DOI 10.17487/RFC6363, October 2011,
+              <https://www.rfc-editor.org/info/rfc6363>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+12.2.  Informative References
+
+   [MBMSTS]   3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
+              Protocols and codecs", 3GPP TS 26.346, March 2009,
+              <http://ftp.3gpp.org/specs/html-info/26346.htm>.
+
+   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
+              Correction (FEC) Building Block", RFC 5052,
+              DOI 10.17487/RFC5052, August 2007,
+              <https://www.rfc-editor.org/info/rfc5052>.
+
+   [RFC6364]  Begen, A., "Session Description Protocol Elements for the
+              Forward Error Correction (FEC) Framework", RFC 6364,
+              DOI 10.17487/RFC6364, October 2011,
+              <https://www.rfc-editor.org/info/rfc6364>.
+
+   [RFC6681]  Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward
+              Error Correction (FEC) Schemes for FECFRAME", RFC 6681,
+              DOI 10.17487/RFC6681, August 2012,
+              <https://www.rfc-editor.org/info/rfc6681>.
+
+   [RFC6816]  Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density
+              Parity Check (LDPC) Staircase Forward Error Correction
+              (FEC) Scheme for FECFRAME", RFC 6816,
+              DOI 10.17487/RFC6816, December 2012,
+              <https://www.rfc-editor.org/info/rfc6816>.
+
+   [RFC6865]  Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
+              Matsuzono, "Simple Reed-Solomon Forward Error Correction
+              (FEC) Scheme for FECFRAME", RFC 6865,
+              DOI 10.17487/RFC6865, February 2013,
+              <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>.
+
+   [RFC8681]  Roca, V. and B. Teibi, "Sliding Window Random Linear Code
+              (RLC) Forward Erasure Correction (FEC) Schemes for
+              FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020,
+              <https://www.rfc-editor.org/info/rfc8681>.
+
+Appendix A.  About Sliding Encoding Window Management (Informational)
+
+   The FEC Framework does not specify the management of the sliding
+   encoding window, which is the responsibility of the FEC scheme.  This
+   annex only provides a few informational hints.
+
+   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
+   mapping specific to the FEC scheme has been done.
+
+   Source symbols are removed from the sliding encoding window.  For
+   instance:
+
+   *  After a certain delay, when an "old" ADU of a real-time flow times
+      out.  The source symbol retention delay in the sliding encoding
+      window should therefore be initialized according to the real-time
+      features of incoming flow(s) when applicable.
+
+   *  Once the sliding encoding window has reached its maximum size
+      (there is usually an upper limit to the sliding encoding window
+      size).  In that case, the oldest symbol is removed each time a new
+      source symbol is added.
+
+   Several considerations can impact the management of this sliding
+   encoding window:
+
+   *  At the source flows level: real-time constraints can limit the
+      total time during which source symbols can remain in the encoding
+      window.
+
+   *  At the FEC code level: theoretical or practical limitations (e.g.,
+      because of computational complexity) can limit the number of
+      source symbols in the encoding window.
+
+   *  At the FEC scheme level: signaling and window management are
+      intrinsically related.  For instance, an encoding window composed
+      of a nonsequential set of source symbols requires appropriate
+      signaling to inform a receiver of the composition of the encoding
+      window, and the associated transmission overhead can limit the
+      maximum encoding window size.  On the contrary, an encoding window
+      always composed of a sequential set of source symbols simplifies
+      signaling: providing the identity of the first source symbol plus
+      its number is sufficient, which creates a fixed and relatively
+      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
+
+   Vincent Roca
+   INRIA
+   Univ. Grenoble Alpes
+   France
+
+   Email: vincent.roca@inria.fr
+
+
+   Ali Begen
+   Networked Media
+   Konya/
+   Turkey
+
+   Email: ali.begen@networked.media