--- 1/draft-ietf-tsvwg-fecframe-ext-03.txt 2018-09-07 07:13:52.759281918 -0700 +++ 2/draft-ietf-tsvwg-fecframe-ext-04.txt 2018-09-07 07:13:52.807283063 -0700 @@ -1,20 +1,20 @@ TSVWG V. Roca Internet-Draft INRIA -Intended status: Standards Track A. Begen -Expires: January 26, 2019 Networked Media - July 25, 2018 +Updates: 6363 (if approved) A. Begen +Intended status: Standards Track Networked Media +Expires: March 11, 2019 September 7, 2018 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes - draft-ietf-tsvwg-fecframe-ext-03 + draft-ietf-tsvwg-fecframe-ext-04 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. The present document extends FECFRAME to support FEC Codes based on a sliding encoding window, in addition to Block FEC Codes, @@ -31,42 +31,42 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 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 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 - 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 + 3. Summary of Architecture Overview . . . . . . . . . . . . . . 7 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Sender Operation with Sliding Window FEC Codes . . . . . 10 4.3. Receiver Operation with Sliding Window FEC Codes . . . . 12 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 14 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. FEC Framework Configuration Information . . . . . . . . . 15 5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 15 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 16 @@ -82,101 +82,102 @@ Appendix A. About Sliding Encoding Window Management (non Normative) . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 received - without any corruption or totally lost (e.g., because of a congested - router, of a poor signal-to-noise ratio in a wireless network, or - because the number of bit errors exceeds the correction capabilities - of a low-layer error correcting code). + 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 + wireless network, or because the number of bit errors exceeds the + correction capabilities of the physical-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 the transport or application layer, is an efficient technique to improve packet transmission robustness in 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 unreliable transports such as UDP. It is primarily - intended for real-time or streaming media applications, using - broadcast, multicast, or on-demand delivery. + packet flows over an unreliable datagram service transports such as + UDP. It is primarily intended for real-time or streaming media + applications, using broadcast, multicast, or on-demand delivery. 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. 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, that - depends on the number k of source symbols in this block, impacts the - FEC encoding delay since encoding requires that all source symbols be - known. This block creation time also impacts the decoding delay a - receiver will experience in case of erasures, since no repair symbol - for the current block can be received before. Therefore a good value - for the block size is necessarily a balance between the maximum - decoding latency at the receivers (which must be in line with the + 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 extends [RFC6363] in order to also support FEC codes - based on a sliding encoding window (A.K.A. convolutional codes). - This encoding window, either of 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. [RLC-ID] provides an - example of such FEC Scheme for FECFRAME, built upon the simple - sliding window Random Linear Codes (RLC). + based on a sliding encoding window (A.K.A. convolutional codes) + [RFC8406]. This encoding window, either of 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. [RLC-ID] + provides an example of such FEC Scheme for FECFRAME, built upon the + simple sliding window Random Linear Codes (RLC). This document is fully backward compatible with [RFC6363] that it extends but does not replace. Indeed: o this extension does not prevent nor compromise in any way the support of block FEC codes. Both types of codes can nicely co- exist, just like different block FEC schemes can co-exist; o any receiver, for instance a legacy receiver that only supports block FEC schemes, can easily identify the FEC Scheme used in a FECFRAME session thanks to the associated SDP file and its FEC Encoding ID information (i.e., the "encoding-id=" parameter of a "fec-repair-flow" attribute, [RFC6364]). This mechanism is not specific to this extension but 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 re-uses its structure. It proposes new sections specific to sliding window FEC codes whenever - required. The only exception is Section Section 3 that provides a - quick summary of FECFRAME in order to facilitate the understanding of - this document to readers not familiar with the concepts and - terminology. + required. The only exception is Section 3 that 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. Definitions and Abbreviations The following list of definitions and abbreviations is copied from [RFC6363], adding only the Block/sliding window FEC Code and Encoding/Decoding Window definitions (tagged with "ADDED"): Application Data Unit (ADU): The unit of source data provided as payload to the transport layer. @@ -243,62 +244,65 @@ 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, e.g., UDP and the Datagram Congestion - Control Protocol (DCCP). + source and repair flows, using an unreliable datagram service + such as UDP. Encoding Window: (ADDED) Set of Source Symbols available at the sender/coding node that are used to generate a repair symbol, with a Sliding Window FEC Code. Decoding Window: (ADDED) Set of received or decoded source and repair symbols available at a receiver that are used to decode erased source symbols, with a Sliding Window FEC Code. 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., by a congested router, or because the number - of transmission errors exceeds the correction capabilities of the - physical-layer codes) or received. When a packet is received, it - is assumed that this packet is not corrupted. + 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 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. -3. Architecture Overview +3. Summary of Architecture Overview The architecture of [RFC6363], Section 3, equally applies to this FECFRAME extension and is not repeated here. However we provide hereafter a quick summary to facilitate the understanding of this document to readers not familiar with the concepts and terminology. +----------------------+ | Application | +----------------------+ | @@ -313,46 +317,45 @@ |(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 Layer | - | (e.g., UDP) | + | Transport Protocol | +----------------------+ Figure 1: FECFRAME architecture at a sender. 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 application generating an ADU flow (other flows, from other applications, may co-exist). These ADUs, of variable size, must be 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 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 UDP (more precisely [RFC6363], Section 7, requires a - transport protocol providing an unreliable datagram service, like UDP - or DCCP). 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. + sent using an appropriate transport protocol (more precisely + [RFC6363], Section 7, 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 potentially empty (otherwise) 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 that case ADUs received after an @@ -420,51 +423,50 @@ 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 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 case of UDP repair flows, and in - Figure 3 for the case of RTP repair flows, describe a possible way to - generate compliant source and 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 + 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 symbols 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 some hints on - the way it might be performed. + 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 [RFC6363] Figure 6, 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 - (for example, in the UDP case, the UDP source and destination - addresses and ports on the IP datagram carrying the source - packet will be the same whether or not the FEC Framework is - applied). + (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. @@ -493,22 +495,21 @@ | 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 Layer | - | (e.g., UDP) | + | Transport Protocol | +----------------------+ Figure 2: Sender Operation with Sliding Window FEC Codes +----------------------+ | Application | +----------------------+ | | (1) New Application Data Unit (ADU) v @@ -525,34 +526,34 @@ | Repair Packet(s) | + Repair symbol(s) +----------------+ +---------------------+ | | |(6) Source |(10) Repair payloads | packets | | + -- -- -- -- -+ | | RTP | | +-- -- -- -- --+ v v +----------------------+ - | Transport Layer | - | (e.g., UDP) | + | Transport Protocol | +----------------------+ - 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 With a Sliding Window FEC Scheme, the following operations, - illustrated in Figure 4 for the case of UDP 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 [RFC6363], Section 4.3, - "Receiver Operation". The new steps (4) and (5) 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 [RFC6363], + 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 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 and the rank of the associated linear system permits it, then FEC decoding can be performed in order to recover missing source payloads. The FEC Scheme determines whether source packets have been lost and whether enough repair packets have been received to @@ -574,22 +575,21 @@ |(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 Layer | - | (e.g., UDP) | + | Transport Protocol | +----------------------+ Figure 4: Receiver Operation with Sliding Window FEC Codes +----------------------+ | Application | +----------------------+ ^ |(6) ADUs | @@ -608,25 +608,25 @@ +-- |- -- -- -- -- -- -+ |RTP| | RTP Processing | | | +-- -- -- --|-- -+ | +-- -- -- -- -- |--+ | | | RTP Demux | | +-- -- -- -- -- -- -- -+ ^ |(1) FEC Source and Repair Packets | +----------------------+ - | Transport Layer | - | (e.g., UDP) | + | Transport Protocol | +----------------------+ - 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.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. @@ -635,45 +635,46 @@ The FEC Framework Configuration Information considerations of [RFC6363], Section 5.5, equally applies to this FECFRAME extension and is not repeated here. 5.3. FEC Scheme Requirements The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply to this FECFRAME extension and are not repeated here. An exception 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 - of Sliding Window FEC schemes: + specific to block FEC codes. The following item (4-bis) applies in + 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- 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 to a Sliding Window FEC Code: o MUST define the relationships between ADUs and the associated source symbols (mapping); 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 system of linear equations (in case of a linear FEC code); 6. Feedback The discussion of [RFC6363], Section 6, equally applies to this FECFRAME extension and is not repeated here. 7. Transport Protocols @@ -785,25 +786,32 @@ (FEC) Scheme for FECFRAME", RFC 6816, DOI 10.17487/RFC6816, December 2012, . [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, . + [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, . + [RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME", Work in Progress, Transport Area Working Group (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in - Progress), July 2018, . Appendix A. About Sliding Encoding Window Management (non Normative) 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 non normative 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