--- 1/draft-ietf-tsvwg-fecframe-ext-02.txt 2018-07-25 03:13:29.998426609 -0700 +++ 2/draft-ietf-tsvwg-fecframe-ext-03.txt 2018-07-25 03:13:30.022426923 -0700 @@ -1,52 +1,51 @@ TSVWG V. Roca Internet-Draft INRIA Intended status: Standards Track A. Begen -Expires: November 2, 2018 Networked Media - May 1, 2018 +Expires: January 26, 2019 Networked Media + July 25, 2018 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes - draft-ietf-tsvwg-fecframe-ext-02 + draft-ietf-tsvwg-fecframe-ext-03 Abstract RFC 6363 describes a framework for using Forward Error Correction - (FEC) codes with applications in public and private IP networks 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, in a - backward compatible way. During multicast/broadcast real-time + (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, + 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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 November 2, 2018. + This Internet-Draft will expire on January 26, 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 @@ -145,21 +144,21 @@ 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 compromize 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- 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 @@ -195,29 +194,29 @@ 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) An FEC Code that operates in a block manner, - i.e., for which the input flow MUST be segmented into a sequence - of blocks, FEC encoding and decoding being performed - independently on a per-block basis. + Block FEC Code: (ADDED) An FEC Code that operates on blocks, i.e., + for which the input flow MUST be segmented into a sequence of + blocks, FEC encoding and decoding being performed independently + on a per-block basis. - Sliding Window (or Convolutional) FEC Code: (ADDED) An 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. + Sliding Window FEC Code: (ADDED) An 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 of a packet with respect to the FEC Scheme. @@ -498,21 +497,21 @@ +---------------------+ | | (6) FEC Source Packet | (10) FEC Repair Packets v +----------------------+ | Transport Layer | | (e.g., UDP) | +----------------------+ - Figure 2: Sender Operation with Convolutional FEC Codes + Figure 2: Sender Operation with Sliding Window FEC Codes +----------------------+ | Application | +----------------------+ | | (1) New Application Data Unit (ADU) v +---------------------+ +----------------+ | FEC Framework | | FEC Scheme | | |-------------------------->| | @@ -636,36 +635,37 @@ 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 instead: + specific to block FEC codes. The following item (4) applies in case + of Sliding Window FEC schemes: 4. 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 symbols to be included in the repair packet payload - with the given Repair FEC Payload ID value. + 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; o MUST define the management of the decoding window, consisting of a @@ -733,21 +733,24 @@ 12. IANA Considerations 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 [RFC6363], Section 11, apply and are not repeated here. 13. Acknowledgments - TBD + The authors would like to thank David Black, Gorry Fairhurst, and + Emmanuel Lochin for their valuable feedbacks on this document. This + document being an extension to [RFC6363], the authors would also like + to thank Mark Watson as the main author this RFC. 14. References 14.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, . @@ -782,52 +785,52 @@ (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, . - [RLC-ID] Roca, V., "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), March 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 mapping specific to the FEC Scheme. Source symbols are removed from the sliding encoding window, for instance: o after a certain delay, when an "old" ADU of a real-time flow times out. The source symbol retention delay in the sliding encoding window should therefore be initialized according to the real-time - features of incoming flow(s); + features of incoming flow(s) when applicable; o 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: + encoding window: o at the source flows level: real-time constraints can limit the total time source symbols can remain in the encoding window; o 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; o at the FEC Scheme level: signaling and window management are intrinsically related. For instance, an encoding window composed @@ -837,21 +840,21 @@ maximum encoding window size. On the opposite, an encoding window always composed of a sequential set of source symbols simplifies signaling: providing the identity of the first source symbol plus their number is sufficient, which creates a fixed and relatively small transmission overhead. Authors' Addresses Vincent Roca INRIA - Grenoble + Univ. Grenoble Alpes France EMail: vincent.roca@inria.fr Ali Begen Networked Media Konya Turkey EMail: ali.begen@networked.media