draft-ietf-tsvwg-fecframe-ext-07.txt   draft-ietf-tsvwg-fecframe-ext-08.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: July 8, 2019 January 4, 2019 Expires: July 15, 2019 January 11, 2019
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-07 draft-ietf-tsvwg-fecframe-ext-08
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. This document updates RFC 6363 to support FEC Codes based on codes. This document updates RFC 6363 to support FEC Codes based on
a sliding encoding window, in addition to Block FEC Codes, in a a sliding encoding window, in addition to Block FEC Codes, in a
backward-compatible way. During multicast/broadcast real-time 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
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 July 8, 2019. This Internet-Draft will expire on July 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 39 skipping to change at page 2, line 39
7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Operations and Management Considerations . . . . . . . . . . 18 11. Operations and Management Considerations . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. About Sliding Encoding Window Management (non Appendix A. About Sliding Encoding Window Management
Normative) . . . . . . . . . . . . . . . . . . . . . 20 (informational) . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
requirements of the FEC Building Block can then easily be used with requirements of the FEC Building Block can then easily be used with
any FEC Scheme that is also defined according to the requirements of any FEC Scheme that is also defined according to the requirements of
the FEC Building Block. the FEC Building Block.
Then FECFRAME [RFC6363] provides a framework to define Content Then FECFRAME [RFC6363] provides a framework to define Content
Delivery Protocols (CDPs) that provide FEC protection for arbitrary Delivery Protocols (CDPs) that provide FEC protection for arbitrary
packet flows over an unreliable datagram service transport such as packet flows over an unreliable datagram service transport such as
UDP. It is primarily intended for real-time or streaming media UDP. It is primarily intended for real-time or streaming media
applications, using broadcast, multicast, or on-demand delivery. applications, using broadcast, multicast, or on-demand delivery.
However [RFC6363] only considers block FEC schemes defined in However, [RFC6363] only considers block FEC schemes defined in
accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681],
[RFC6816] or [RFC6865]). These codes require the input flow(s) to be [RFC6816] or [RFC6865]). These codes require the input flow(s) to be
segmented into a sequence of blocks. Then FEC encoding (at a sender segmented into a sequence of blocks. Then FEC encoding (at a sender
or an encoding middlebox) and decoding (at a receiver or a decoding or an encoding middlebox) and decoding (at a receiver or a decoding
middlebox) are both performed on a per-block basis. For instance if middlebox) are both performed on a per-block basis. For instance, if
the current block encompasses the 100's to 119's source symbols the current block encompasses the 100's to 119's source symbols
(i.e., block of size 20 symbols) of an input flow, encoding (and (i.e., a block of size 20 symbols) of an input flow, encoding (and
decoding) will be performed on this block independantly of other decoding) will be performed on this block independently of other
blocks. This approach has major impacts on FEC encoding and decoding blocks. This approach has major impacts on FEC encoding and decoding
delays. The data packets of continuous media flow(s) may be passed delays. The data packets of continuous media flow(s) may be passed
to the transport layer immediately, without delay. But the block to the transport layer immediately, without delay. But the block
creation time, that depends on the number of source symbols in this creation time, that depends on the number of source symbols in this
block, impacts both the FEC encoding delay (since encoding requires block, impacts both the FEC encoding delay (since encoding requires
that all source symbols be known), and mechanically the packet loss that all source symbols be known), and mechanically the packet loss
recovery delay at a receiver (since no repair symbol for the current recovery delay at a receiver (since no repair symbol for the current
block can be generated and therefore received before that time). block can be generated and therefore received before that time).
Therefore a good value for the block size is necessarily a balance Therefore a good value for the block size is necessarily a balance
between the maximum FEC decoding latency at the receivers (which must between the maximum FEC decoding latency at the receivers (which must
skipping to change at page 7, line 33 skipping to change at page 7, line 33
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 |
+----------------------+ +----------------------+
| |
| (1) Application Data Units (ADUs) | (1) Application Data Units (ADUs)
| |
v v
skipping to change at page 17, line 40 skipping to change at page 17, line 40
Window FEC Codes. Window FEC Codes.
o Maturity: the basic FECFRAME maturity is "production", the o Maturity: the basic FECFRAME maturity is "production", the
FECFRAME extension maturity is "under progress". FECFRAME extension maturity is "under progress".
o Coverage: the software implements a subset of [RFC6363], as o Coverage: the software implements a subset of [RFC6363], as
specialized by the 3GPP eMBMS standard [MBMSTS]. This software specialized by the 3GPP eMBMS standard [MBMSTS]. This software
also covers the additional features of FECFRAME extended to also covers the additional features of FECFRAME extended to
Sliding Window codes, in particular the RLC FEC Scheme. Sliding Window codes, in particular the RLC FEC Scheme.
o Lincensing: proprietary. o Licensing: proprietary.
o Implementation experience: maximum. o Implementation experience: maximum.
o Information update date: March 2018. o Information update date: March 2018.
o Contact: vincent.roca@inria.fr o Contact: vincent.roca@inria.fr
10. Security Considerations 10. Security Considerations
This FECFRAME extension does not add any new security consideration. This FECFRAME extension does not add any new security consideration.
skipping to change at page 18, line 30 skipping to change at page 18, line 30
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 Christer Holmberg, David Black, Gorry The authors would like to thank Christer Holmberg, David Black, Gorry
Fairhurst, and Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Fairhurst, and Emmanuel Lochin, Spencer Dawkins, Ben Campbell,
Benjamin Kaduk, Eric Rescorla, and Adam Roach for their valuable Benjamin Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their
feedbacks on this document. This document being an extension to valuable feedback on this document. This document being an extension
[RFC6363], the authors would also like to thank Mark Watson as the to [RFC6363], the authors would also like to thank Mark Watson as the
main author of that RFC. main author of that 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>.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Network Communications", RFC 8406, DOI 10.17487/RFC8406, Network Communications", RFC 8406, DOI 10.17487/RFC8406,
June 2018, <https://www.rfc-editor.org/info/rfc8406>. June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code [RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code
(RLC) Forward Erasure Correction (FEC) Scheme for (RLC) Forward Erasure Correction (FEC) Scheme for
FECFRAME", Work in Progress, Transport Area Working Group FECFRAME", Work in Progress, Transport Area Working Group
(TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in
Progress), September 2018, <https://tools.ietf.org/html/ Progress), September 2018, <https://tools.ietf.org/html/
draft-ietf-tsvwg-rlc-fec-scheme>. draft-ietf-tsvwg-rlc-fec-scheme>.
Appendix A. About Sliding Encoding Window Management (non Normative) Appendix A. About Sliding Encoding Window Management (informational)
The FEC Framework does not specify the management of the sliding The FEC Framework does not specify the management of the sliding
encoding window which is the responsibility of the FEC Scheme. This encoding window which is the responsibility of the FEC Scheme. This
annex only provides a few non normative hints. annex only provides a few informational hints.
Source symbols are added to the sliding encoding window each time a Source symbols are added to the sliding encoding window each time a
new ADU is available at the sender, after the ADU-to-source-symbol new ADU is available at the sender, after the ADU-to-source-symbol
mapping specific to the FEC Scheme. mapping specific to the FEC Scheme.
Source symbols are removed from the sliding encoding window, for Source symbols are removed from the sliding encoding window, for
instance: instance:
o after a certain delay, when an "old" ADU of a real-time flow times 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 out. The source symbol retention delay in the sliding encoding
skipping to change at page 20, line 40 skipping to change at page 20, line 40
o at the source flows level: real-time constraints can limit the o at the source flows level: real-time constraints can limit the
total time source symbols can remain in the encoding window; total time source symbols can remain in the encoding window;
o at the FEC code level: theoretical or practical limitations (e.g., o at the FEC code level: theoretical or practical limitations (e.g.,
because of computational complexity) can limit the number of because of computational complexity) can limit the number of
source symbols in the encoding window; source symbols in the encoding window;
o at the FEC Scheme level: signaling and window management are o at the FEC Scheme level: signaling and window management are
intrinsically related. For instance, an encoding window composed intrinsically related. For instance, an encoding window composed
of a non sequential set of source symbols requires an appropriate of a non-sequential set of source symbols requires an appropriate
signaling to inform a receiver of the composition of the encoding signaling to inform a receiver of the composition of the encoding
window, and the associated transmission overhead can limit the window, and the associated transmission overhead can limit the
maximum encoding window size. On the opposite, an encoding window maximum encoding window size. On the opposite, an encoding window
always composed of a sequential set of source symbols simplifies always composed of a sequential set of source symbols simplifies
signaling: providing the identity of the first source symbol plus signaling: providing the identity of the first source symbol plus
their number is sufficient, which creates a fixed and relatively their number is sufficient, which creates a fixed and relatively
small transmission overhead. small transmission overhead.
Authors' Addresses Authors' Addresses
 End of changes. 14 change blocks. 
18 lines changed or deleted 18 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/