draft-ietf-tsvwg-fecframe-ext-04.txt   draft-ietf-tsvwg-fecframe-ext-05.txt 
TSVWG V. Roca TSVWG V. Roca
Internet-Draft INRIA Internet-Draft INRIA
Updates: 6363 (if approved) A. Begen Updates: 6363 (if approved) A. Begen
Intended status: Standards Track Networked Media Intended status: Standards Track Networked Media
Expires: March 11, 2019 September 7, 2018 Expires: March 23, 2019 September 19, 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-04 draft-ietf-tsvwg-fecframe-ext-05
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 updates 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,
in a backward compatible way. During multicast/broadcast real-time in a backward compatible way. During multicast/broadcast real-time
content delivery, the use of sliding window codes significantly content delivery, the use of sliding window codes significantly
improves robustness in harsh environments, with less repair traffic improves robustness in harsh environments, with less repair traffic
and lower FEC-related added latency. and lower FEC-related added latency.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 11, 2019. This Internet-Draft will expire on March 23, 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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. Summary of Architecture Overview . . . . . . . . . . . . . . 7 3. Summary of Architecture Overview . . . . . . . . . . . . . . 7
4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 9 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 10
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . 13
5. Protocol Specification . . . . . . . . . . . . . . . . . . . 14 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 15
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. FEC Framework Configuration Information . . . . . . . . . 15 5.2. FEC Framework Configuration Information . . . . . . . . . 16
5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 15 5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 16
6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 16 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 16 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Operations and Management Considerations . . . . . . . . . . 17 11. Operations and Management Considerations . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 17 14.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. About Sliding Encoding Window Management (non Appendix A. About Sliding Encoding Window Management (non
Normative) . . . . . . . . . . . . . . . . . . . . . 19 Normative) . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Many applications need to transport a continuous stream of packetized Many applications need to transport a continuous stream of packetized
data from a source (sender) to one or more destinations (receivers) data from a source (sender) to one or more destinations (receivers)
over networks that do not provide guaranteed packet delivery. In over networks that do not provide guaranteed packet delivery. In
particular packets may be lost, which is strictly the focus of this particular packets may be lost, which is strictly the focus of this
document: we assume that transmitted packets are either lost (e.g., document: we assume that transmitted packets are either lost (e.g.,
because of a congested router, of a poor signal-to-noise ratio in a because of a congested router, of a poor signal-to-noise ratio in a
wireless network, or because the number of bit errors exceeds the wireless network, or because the number of bit errors exceeds the
skipping to change at page 3, line 47 skipping to change at page 3, line 47
symbols be known), and mechanically the packet loss recovery delay at symbols be known), and mechanically the packet loss recovery delay at
a receiver (since no repair symbol for the current block can be a receiver (since no repair symbol for the current block can be
generated and therefore received before that time). Therefore a good generated and therefore received before that time). Therefore a good
value for the block size is necessarily a balance between the maximum 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 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 updates [RFC6363] in order to also support FEC codes
based on a sliding encoding window (A.K.A. convolutional codes) based on a sliding encoding window (A.K.A. convolutional codes)
[RFC8406]. This encoding window, either of fixed or variable size, [RFC8406]. This encoding window, either of fixed or variable size,
slides over the set of source symbols. FEC encoding is launched slides over the set of source symbols. FEC encoding is launched
whenever needed, from the set of source symbols present in the whenever needed, from the set of source symbols present in the
sliding encoding window at that time. This approach significantly sliding encoding window at that time. This approach significantly
reduces FEC-related latency, since repair symbols can be generated 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 and passed to the transport layer on-the-fly, at any time, and can be
regularly received by receivers to quickly recover packet losses. regularly received by receivers to quickly recover packet losses.
Using sliding window FEC codes is therefore highly beneficial to Using sliding window FEC codes is therefore highly beneficial to
real-time flows, one of the primary targets of FECFRAME. [RLC-ID] real-time flows, one of the primary targets of FECFRAME. [RLC-ID]
provides an example of such FEC Scheme for FECFRAME, built upon the provides an example of such FEC Scheme for FECFRAME, built upon the
simple 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]. 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. This is made possible with the FEC Encoding ID
Encoding ID information (i.e., the "encoding-id=" parameter of a that identifies the FEC Scheme used and which is carried in the
"fec-repair-flow" attribute, [RFC6364]). This mechanism is not FEC Framework Configuration Information (see section 5.5 of
specific to this extension but is the basic approach for a [RFC6363]). For instance, when the Session Description Protocol
FECFRAME receiver to determine whether or not it supports the FEC (SDP) is used to carry the FEC Framework Configuration
Scheme used in a given FECFRAME session; 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 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 3 that provides a quick required. The only exception is Section 3 that provides a quick
summary of FECFRAME in order to facilitate the understanding of this summary of FECFRAME in order to facilitate the understanding of this
document to readers not familiar with the concepts and terminology. document to readers not familiar with the concepts and terminology.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
The following list of definitions and abbreviations is copied from The following list of definitions and abbreviations is copied from
skipping to change at page 7, line 17 skipping to change at page 7, line 19
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].
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 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 17, line 20 skipping to change at page 18, line 20
12. IANA Considerations 12. IANA Considerations
A FEC Scheme for use with this FEC Framework is identified via its A FEC Scheme for use with this FEC Framework is identified via its
FEC Encoding ID. It is subject to IANA registration in the "FEC FEC Encoding ID. It is subject to IANA registration in the "FEC
Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of
[RFC6363], Section 11, apply and are not repeated here. [RFC6363], Section 11, apply and are not repeated here.
13. Acknowledgments 13. Acknowledgments
The authors would like to thank David Black, Gorry Fairhurst, and The authors would like to thank Christer Holmberg, David Black, Gorry
Emmanuel Lochin for their valuable feedbacks on this document. This Fairhurst, and Emmanuel Lochin for their valuable feedbacks on this
document being an extension to [RFC6363], the authors would also like document. This document being an extension to [RFC6363], the authors
to thank Mark Watson as the main author this RFC. would also like to thank Mark Watson as the main author this RFC.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011, DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>. <https://www.rfc-editor.org/info/rfc6363>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References 14.2. Informative References
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", 3GPP TS 26.346, March 2009, Protocols and codecs", 3GPP TS 26.346, March 2009,
<http://ftp.3gpp.org/specs/html-info/26346.htm>. <http://ftp.3gpp.org/specs/html-info/26346.htm>.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, Correction (FEC) Building Block", RFC 5052,
DOI 10.17487/RFC5052, August 2007, DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>. <https://www.rfc-editor.org/info/rfc5052>.
 End of changes. 13 change blocks. 
37 lines changed or deleted 50 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/