idnits 2.17.1 draft-ietf-tsvwg-fecframe-ext-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6363, updated by this document, for RFC5378 checks: 2007-02-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 11, 2019) is 1932 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG V. Roca 3 Internet-Draft INRIA 4 Updates: 6363 (if approved) A. Begen 5 Intended status: Standards Track Networked Media 6 Expires: July 15, 2019 January 11, 2019 8 Forward Error Correction (FEC) Framework Extension to Sliding Window 9 Codes 10 draft-ietf-tsvwg-fecframe-ext-08 12 Abstract 14 RFC 6363 describes a framework for using Forward Error Correction 15 (FEC) codes to provide protection against packet loss. The framework 16 supports applying FEC to arbitrary packet flows over unreliable 17 transport and is primarily intended for real-time, or streaming, 18 media. However, FECFRAME as per RFC 6363 is restricted to block FEC 19 codes. This document updates RFC 6363 to support FEC Codes based on 20 a sliding encoding window, in addition to Block FEC Codes, in a 21 backward-compatible way. During multicast/broadcast real-time 22 content delivery, the use of sliding window codes significantly 23 improves robustness in harsh environments, with less repair traffic 24 and lower FEC-related added latency. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 15, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 62 3. Summary of Architecture Overview . . . . . . . . . . . . . . 7 63 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. Sender Operation with Sliding Window FEC Codes . . . . . 10 66 4.3. Receiver Operation with Sliding Window FEC Codes . . . . 13 67 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 15 68 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 5.2. FEC Framework Configuration Information . . . . . . . . . 16 70 5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 16 71 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17 73 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 74 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 11. Operations and Management Considerations . . . . . . . . . . 18 77 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 14.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Appendix A. About Sliding Encoding Window Management 83 (informational) . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 Many applications need to transport a continuous stream of packetized 89 data from a source (sender) to one or more destinations (receivers) 90 over networks that do not provide guaranteed packet delivery. In 91 particular packets may be lost, which is strictly the focus of this 92 document: we assume that transmitted packets are either lost (e.g., 93 because of a congested router, of a poor signal-to-noise ratio in a 94 wireless network, or because the number of bit errors exceeds the 95 correction capabilities of the physical-layer error correcting code) 96 or received by the transport protocol without any corruption (i.e., 97 the bit-errors, if any, have been fixed by the physical-layer error 98 correcting code and therefore are hidden to the upper layers). 100 For these use-cases, Forward Error Correction (FEC) applied within 101 the transport or application layer is an efficient technique to 102 improve packet transmission robustness in presence of packet losses 103 (or "erasures"), without going through packet retransmissions that 104 create a delay often incompatible with real-time constraints. The 105 FEC Building Block defined in [RFC5052] provides a framework for the 106 definition of Content Delivery Protocols (CDPs) that make use of 107 separately-defined FEC schemes. Any CDP defined according to the 108 requirements of the FEC Building Block can then easily be used with 109 any FEC Scheme that is also defined according to the requirements of 110 the FEC Building Block. 112 Then FECFRAME [RFC6363] provides a framework to define Content 113 Delivery Protocols (CDPs) that provide FEC protection for arbitrary 114 packet flows over an unreliable datagram service transport such as 115 UDP. It is primarily intended for real-time or streaming media 116 applications, using broadcast, multicast, or on-demand delivery. 118 However, [RFC6363] only considers block FEC schemes defined in 119 accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], 120 [RFC6816] or [RFC6865]). These codes require the input flow(s) to be 121 segmented into a sequence of blocks. Then FEC encoding (at a sender 122 or an encoding middlebox) and decoding (at a receiver or a decoding 123 middlebox) are both performed on a per-block basis. For instance, if 124 the current block encompasses the 100's to 119's source symbols 125 (i.e., a block of size 20 symbols) of an input flow, encoding (and 126 decoding) will be performed on this block independently of other 127 blocks. This approach has major impacts on FEC encoding and decoding 128 delays. The data packets of continuous media flow(s) may be passed 129 to the transport layer immediately, without delay. But the block 130 creation time, that depends on the number of source symbols in this 131 block, impacts both the FEC encoding delay (since encoding requires 132 that all source symbols be known), and mechanically the packet loss 133 recovery delay at a receiver (since no repair symbol for the current 134 block can be generated and therefore received before that time). 135 Therefore a good value for the block size is necessarily a balance 136 between the maximum FEC decoding latency at the receivers (which must 137 be in line with the most stringent real-time requirement of the 138 protected flow(s), hence an incentive to reduce the block size), and 139 the desired robustness against long loss bursts (which increases with 140 the block size, hence an incentive to increase this size). 142 This document updates [RFC6363] in order to also support FEC codes 143 based on a sliding encoding window (A.K.A. convolutional codes) 145 [RFC8406]. This encoding window, either of fixed or variable size, 146 slides over the set of source symbols. FEC encoding is launched 147 whenever needed, from the set of source symbols present in the 148 sliding encoding window at that time. This approach significantly 149 reduces FEC-related latency, since repair symbols can be generated 150 and passed to the transport layer on-the-fly, at any time, and can be 151 regularly received by receivers to quickly recover packet losses. 152 Using sliding window FEC codes is therefore highly beneficial to 153 real-time flows, one of the primary targets of FECFRAME. [RLC-ID] 154 provides an example of such FEC Scheme for FECFRAME, built upon the 155 simple sliding window Random Linear Codes (RLC). 157 This document is fully backward compatible with [RFC6363]. Indeed: 159 o this FECFRAME update does not prevent nor compromise in any way 160 the support of block FEC codes. Both types of codes can nicely 161 co-exist, just like different block FEC schemes can co-exist; 163 o each sliding window FEC Scheme is associated to a specific FEC 164 Encoding ID subject to IANA registration, just like block FEC 165 Schemes; 167 o any receiver, for instance a legacy receiver that only supports 168 block FEC schemes, can easily identify the FEC Scheme used in a 169 FECFRAME session. Indeed, the FEC Encoding ID that identifies the 170 FEC Scheme is carried in the FEC Framework Configuration 171 Information (see section 5.5 of [RFC6363]). For instance, when 172 the Session Description Protocol (SDP) is used to carry the FEC 173 Framework Configuration Information, the FEC Encoding ID can be 174 communicated in the "encoding-id=" parameter of a "fec-repair- 175 flow" attribute [RFC6364]. This mechanism is the basic approach 176 for a FECFRAME receiver to determine whether or not it supports 177 the FEC Scheme used in a given FECFRAME session; 179 This document leverages on [RFC6363] and re-uses its structure. It 180 proposes new sections specific to sliding window FEC codes whenever 181 required. The only exception is Section 3 that provides a quick 182 summary of FECFRAME in order to facilitate the understanding of this 183 document to readers not familiar with the concepts and terminology. 185 2. Definitions and Abbreviations 187 The following list of definitions and abbreviations is copied from 188 [RFC6363], adding only the Block/sliding window FEC Code and 189 Encoding/Decoding Window definitions (tagged with "ADDED"): 191 Application Data Unit (ADU): The unit of source data provided as 192 payload to the transport layer. For instance, it can be a 193 payload containing the result of the RTP packetization of a 194 compressed video frame. 196 ADU Flow: A sequence of ADUs associated with a transport-layer flow 197 identifier (such as the standard 5-tuple {source IP address, 198 source port, destination IP address, destination port, transport 199 protocol}). 201 AL-FEC: Application-layer Forward Error Correction. 203 Application Protocol: Control protocol used to establish and control 204 the source flow being protected, e.g., the Real-Time Streaming 205 Protocol (RTSP). 207 Content Delivery Protocol (CDP): A complete application protocol 208 specification that, through the use of the framework defined in 209 this document, is able to make use of FEC schemes to provide FEC 210 capabilities. 212 FEC Code: An algorithm for encoding data such that the encoded data 213 flow is resilient to data loss. Note that, in general, FEC codes 214 may also be used to make a data flow resilient to corruption, but 215 that is not considered in this document. 217 Block FEC Code: (ADDED) An FEC Code that operates on blocks, i.e., 218 for which the input flow MUST be segmented into a sequence of 219 blocks, FEC encoding and decoding being performed independently 220 on a per-block basis. 222 Sliding Window FEC Code: (ADDED) An FEC Code that can generate 223 repair symbols on-the-fly, at any time, from the set of source 224 symbols present in the sliding encoding window at that time. 225 These codes are also known as convolutional codes. 227 FEC Framework: A protocol framework for the definition of Content 228 Delivery Protocols using FEC, such as the framework defined in 229 this document. 231 FEC Framework Configuration Information: Information that controls 232 the operation of the FEC Framework. 234 FEC Payload ID: Information that identifies the contents and 235 provides positional information of a packet with respect to the 236 FEC Scheme. 238 FEC Repair Packet: At a sender (respectively, at a receiver), a 239 payload submitted to (respectively, received from) the transport 240 protocol containing one or more repair symbols along with a 241 Repair FEC Payload ID and possibly an RTP header. 243 FEC Scheme: A specification that defines the additional protocol 244 aspects required to use a particular FEC code with the FEC 245 Framework. 247 FEC Source Packet: At a sender (respectively, at a receiver), a 248 payload submitted to (respectively, received from) the transport 249 protocol containing an ADU along with an optional Explicit Source 250 FEC Payload ID. 252 Repair Flow: The packet flow carrying FEC data. 254 Repair FEC Payload ID: A FEC Payload ID specifically for use with 255 repair packets. 257 Source Flow: The packet flow to which FEC protection is to be 258 applied. A source flow consists of ADUs. 260 Source FEC Payload ID: A FEC Payload ID specifically for use with 261 source packets. 263 Source Protocol: A protocol used for the source flow being 264 protected, e.g., RTP. 266 Transport Protocol: The protocol used for the transport of the 267 source and repair flows, using an unreliable datagram service 268 such as UDP. 270 Encoding Window: (ADDED) Set of Source Symbols available at the 271 sender/coding node that are used to generate a repair symbol, 272 with a Sliding Window FEC Code. 274 Decoding Window: (ADDED) Set of received or decoded source and 275 repair symbols available at a receiver that are used to decode 276 erased source symbols, with a Sliding Window FEC Code. 278 Code Rate: The ratio between the number of source symbols and the 279 number of encoding symbols. By definition, the code rate is such 280 that 0 < code rate <= 1. A code rate close to 1 indicates that a 281 small number of repair symbols have been produced during the 282 encoding process. 284 Encoding Symbol: Unit of data generated by the encoding process. 285 With systematic codes, source symbols are part of the encoding 286 symbols. 288 Packet Erasure Channel: A communication path where packets are 289 either lost (e.g., in our case, by a congested router, or because 290 the number of transmission errors exceeds the correction 291 capabilities of the physical-layer code) or received. When a 292 packet is received, it is assumed that this packet is not 293 corrupted (i.e., in our case, the bit-errors, if any, are fixed 294 by the physical-layer code and therefore hidden to the upper 295 layers). 297 Repair Symbol: Encoding symbol that is not a source symbol. 299 Source Block: Group of ADUs that are to be FEC protected as a single 300 block. This notion is restricted to Block FEC Codes. 302 Source Symbol: Unit of data used during the encoding process. 304 Systematic Code: FEC code in which the source symbols are part of 305 the encoding symbols. 307 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 308 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 309 "OPTIONAL" in this document are to be interpreted as described in BCP 310 14 [RFC2119] [RFC8174] when, and only when, they appear in all 311 capitals, as shown here. 313 3. Summary of Architecture Overview 315 The architecture of [RFC6363], Section 3, equally applies to this 316 FECFRAME extension and is not repeated here. However, we provide 317 hereafter a quick summary to facilitate the understanding of this 318 document to readers not familiar with the concepts and terminology. 320 +----------------------+ 321 | Application | 322 +----------------------+ 323 | 324 | (1) Application Data Units (ADUs) 325 | 326 v 327 +----------------------+ +----------------+ 328 | FEC Framework | | | 329 | |-------------------------->| FEC Scheme | 330 |(2) Construct source |(3) Source Block | | 331 | blocks | |(4) FEC Encoding| 332 |(6) Construct FEC |<--------------------------| | 333 | Source and Repair | | | 334 | Packets |(5) Explicit Source FEC | | 335 +----------------------+ Payload IDs +----------------+ 336 | Repair FEC Payload IDs 337 | Repair symbols 338 | 339 |(7) FEC Source and Repair Packets 340 v 341 +----------------------+ 342 | Transport Protocol | 343 +----------------------+ 345 Figure 1: FECFRAME architecture at a sender. 347 The FECFRAME architecture is illustrated in Figure 1 from the 348 sender's point of view, in case of a block FEC Scheme. It shows an 349 application generating an ADU flow (other flows, from other 350 applications, may co-exist). These ADUs, of variable size, must be 351 somehow mapped to source symbols of fixed size (this fixed size is a 352 requirement of all FEC Schemes that comes from the way mathematical 353 operations are applied to symbols content). This is the goal of an 354 ADU-to-symbols mapping process that is FEC-Scheme specific (see 355 below). Once the source block is built, taking into account both the 356 FEC Scheme constraints (e.g., in terms of maximum source block size) 357 and the application's flow constraints (e.g., in terms of real-time 358 constraints), the associated source symbols are handed to the FEC 359 Scheme in order to produce an appropriate number of repair symbols. 360 FEC Source Packets (containing ADUs) and FEC Repair Packets 361 (containing one or more repair symbols each) are then generated and 362 sent using an appropriate transport protocol (more precisely 363 [RFC6363], Section 7, requires a transport protocol providing an 364 unreliable datagram service, such as UDP). In practice FEC Source 365 Packets may be passed to the transport layer as soon as available, 366 without having to wait for FEC encoding to take place. In that case 367 a copy of the associated source symbols needs to be kept within 368 FECFRAME for future FEC encoding purposes. 370 At a receiver (not shown), FECFRAME processing operates in a similar 371 way, taking as input the incoming FEC Source and Repair Packets 372 received. In case of FEC Source Packet losses, the FEC decoding of 373 the associated block may recover all (in case of successful decoding) 374 or a subset potentially empty (otherwise) of the missing source 375 symbols. After source-symbol-to-ADU mapping, when lost ADUs are 376 recovered, they are then assigned to their respective flow (see 377 below). ADUs are returned to the application(s), either in their 378 initial transmission order (in that case ADUs received after an 379 erased one will be delayed until FEC decoding has taken place) or not 380 (in that case each ADU is returned as soon as it is received or 381 recovered), depending on the application requirements. 383 FECFRAME features two subtle mechanisms: 385 o ADUs-to-source-symbols mapping: in order to manage variable size 386 ADUs, FECFRAME and FEC Schemes can use small, fixed size symbols 387 and create a mapping between ADUs and symbols. To each ADU this 388 mechanism prepends a length field (plus a flow identifier, see 389 below) and pads the result to a multiple of the symbol size. A 390 small ADU may be mapped to a single source symbol while a large 391 one may be mapped to multiple symbols. The mapping details are 392 FEC-Scheme-dependent and must be defined in the associated 393 document; 395 o Assignment of decoded ADUs to flows in multi-flow configurations: 396 when multiple flows are multiplexed over the same FECFRAME 397 instance, a problem is to assign a decoded ADU to the right flow 398 (UDP port numbers and IP addresses traditionally used to map 399 incoming ADUs to flows are not recovered during FEC decoding). To 400 make it possible, at the FECFRAME sending instance, each ADU is 401 prepended with a flow identifier (1 byte) during the ADU-to- 402 source-symbols mapping (see above). The flow identifiers are also 403 shared between all FECFRAME instances as part of the FEC Framework 404 Configuration Information. This (flow identifier + length + 405 application payload + padding), called ADUI, is then FEC 406 protected. Therefore a decoded ADUI contains enough information 407 to assign the ADU to the right flow. 409 A few aspects are not covered by FECFRAME, namely: 411 o [RFC6363] section 8 does not detail any congestion control 412 mechanism, but only provides high level normative requirements; 414 o the possibility of having feedbacks from receiver(s) is considered 415 out of scope, although such a mechanism may exist within the 416 application (e.g., through RTCP control messages); 418 o flow adaptation at a FECFRAME sender (e.g., how to set the FEC 419 code rate based on transmission conditions) is not detailed, but 420 it needs to comply with the congestion control normative 421 requirements (see above). 423 4. Procedural Overview 425 4.1. General 427 The general considerations of [RFC6363], Section 4.1, that are 428 specific to block FEC codes are not repeated here. 430 With a Sliding Window FEC Code, the FEC Source Packet MUST contain 431 information to identify the position occupied by the ADU within the 432 source flow, in terms specific to the FEC Scheme. This information 433 is known as the Source FEC Payload ID, and the FEC Scheme is 434 responsible for defining and interpreting it. 436 With a Sliding Window FEC Code, the FEC Repair Packets MUST contain 437 information that identifies the relationship between the contained 438 repair payloads and the original source symbols used during encoding. 439 This information is known as the Repair FEC Payload ID, and the FEC 440 Scheme is responsible for defining and interpreting it. 442 The Sender Operation ([RFC6363], Section 4.2.) and Receiver Operation 443 ([RFC6363], Section 4.3) are both specific to block FEC codes and 444 therefore omitted below. The following two sections detail similar 445 operations for Sliding Window FEC codes. 447 4.2. Sender Operation with Sliding Window FEC Codes 449 With a Sliding Window FEC Scheme, the following operations, 450 illustrated in Figure 2 for the generic case (non-RTP repair flows), 451 and in Figure 3 for the case of RTP repair flows, describe a possible 452 way to generate compliant source and repair flows: 454 1. A new ADU is provided by the application. 456 2. The FEC Framework communicates this ADU to the FEC Scheme. 458 3. The sliding encoding window is updated by the FEC Scheme. The 459 ADU-to-source-symbols mapping as well as the encoding window 460 management details are both the responsibility of the FEC Scheme 461 and MUST be detailed there. Appendix A provides non-normative 462 hints about what FEC Scheme designers need to consider; 464 4. The Source FEC Payload ID information of the source packet is 465 determined by the FEC Scheme. If required by the FEC Scheme, 466 the Source FEC Payload ID is encoded into the Explicit Source 467 FEC Payload ID field and returned to the FEC Framework. 469 5. The FEC Framework constructs the FEC Source Packet according to 470 [RFC6363] Figure 6, using the Explicit Source FEC Payload ID 471 provided by the FEC Scheme if applicable. 473 6. The FEC Source Packet is sent using normal transport-layer 474 procedures. This packet is sent using the same ADU flow 475 identification information as would have been used for the 476 original source packet if the FEC Framework were not present 477 (e.g., the source and destination addresses and UDP port numbers 478 on the IP datagram carrying the source packet will be the same 479 whether or not the FEC Framework is applied). 481 7. When the FEC Framework needs to send one or several FEC Repair 482 Packets (e.g., according to the target Code Rate), it asks the 483 FEC Scheme to create one or several repair packet payloads from 484 the current sliding encoding window along with their Repair FEC 485 Payload ID. 487 8. The Repair FEC Payload IDs and repair packet payloads are 488 provided back by the FEC Scheme to the FEC Framework. 490 9. The FEC Framework constructs FEC Repair Packets according to 491 [RFC6363] Figure 7, using the FEC Payload IDs and repair packet 492 payloads provided by the FEC Scheme. 494 10. The FEC Repair Packets are sent using normal transport-layer 495 procedures. The port(s) and multicast group(s) to be used for 496 FEC Repair Packets are defined in the FEC Framework 497 Configuration Information. 499 +----------------------+ 500 | Application | 501 +----------------------+ 502 | 503 | (1) New Application Data Unit (ADU) 504 v 505 +---------------------+ +----------------+ 506 | FEC Framework | | FEC Scheme | 507 | |-------------------------->| | 508 | | (2) New ADU |(3) Update of | 509 | | | encoding | 510 | |<--------------------------| window | 511 |(5) Construct FEC | (4) Explicit Source | | 512 | Source Packet | FEC Payload ID(s) |(7) FEC | 513 | |<--------------------------| encoding | 514 |(9) Construct FEC | (8) Repair FEC Payload ID | | 515 | Repair Packet(s) | + Repair symbol(s) +----------------+ 516 +---------------------+ 517 | 518 | (6) FEC Source Packet 519 | (10) FEC Repair Packets 520 v 521 +----------------------+ 522 | Transport Protocol | 523 +----------------------+ 525 Figure 2: Sender Operation with Sliding Window FEC Codes 527 +----------------------+ 528 | Application | 529 +----------------------+ 530 | 531 | (1) New Application Data Unit (ADU) 532 v 533 +---------------------+ +----------------+ 534 | FEC Framework | | FEC Scheme | 535 | |-------------------------->| | 536 | | (2) New ADU |(3) Update of | 537 | | | encoding | 538 | |<--------------------------| window | 539 |(5) Construct FEC | (4) Explicit Source | | 540 | Source Packet | FEC Payload ID(s) |(7) FEC | 541 | |<--------------------------| encoding | 542 |(9) Construct FEC | (8) Repair FEC Payload ID | | 543 | Repair Packet(s) | + Repair symbol(s) +----------------+ 544 +---------------------+ 545 | | 546 |(6) Source |(10) Repair payloads 547 | packets | 548 | + -- -- -- -- -+ 549 | | RTP | 550 | +-- -- -- -- --+ 551 v v 552 +----------------------+ 553 | Transport Protocol | 554 +----------------------+ 556 Figure 3: Sender Operation with Sliding Window FEC Codes and RTP 557 Repair Flows 559 4.3. Receiver Operation with Sliding Window FEC Codes 561 With a Sliding Window FEC Scheme, the following operations, 562 illustrated in Figure 4 for the generic case (non-RTP repair flows), 563 and in Figure 5 for the case of RTP repair flows. The only 564 differences with respect to block FEC codes lie in steps (4) and (5). 565 Therefore this section does not repeat the other steps of [RFC6363], 566 Section 4.3, "Receiver Operation". The new steps (4) and (5) are: 568 4. The FEC Scheme uses the received FEC Payload IDs (and derived FEC 569 Source Payload IDs when the Explicit Source FEC Payload ID field 570 is not used) to insert source and repair packets into the 571 decoding window in the right way. If at least one source packet 572 is missing and at least one repair packet has been received, then 573 FEC decoding is attempted to recover missing source payloads. 574 The FEC Scheme determines whether source packets have been lost 575 and whether enough repair packets have been received to decode 576 any or all of the missing source payloads. 578 5. The FEC Scheme returns the received and decoded ADUs to the FEC 579 Framework, along with indications of any ADUs that were missing 580 and could not be decoded. 582 +----------------------+ 583 | Application | 584 +----------------------+ 585 ^ 586 |(6) ADUs 587 | 588 +----------------------+ +----------------+ 589 | FEC Framework | | FEC Scheme | 590 | |<--------------------------| | 591 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding 592 | IDs and pass IDs & |-------------------------->| | 593 | payloads to FEC |(3) Explicit Source FEC +----------------+ 594 | scheme | Payload IDs 595 +----------------------+ Repair FEC Payload IDs 596 ^ Source payloads 597 | Repair payloads 598 |(1) FEC Source 599 | and Repair Packets 600 +----------------------+ 601 | Transport Protocol | 602 +----------------------+ 604 Figure 4: Receiver Operation with Sliding Window FEC Codes 606 +----------------------+ 607 | Application | 608 +----------------------+ 609 ^ 610 |(6) ADUs 611 | 612 +----------------------+ +----------------+ 613 | FEC Framework | | FEC Scheme | 614 | |<--------------------------| | 615 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding| 616 | IDs and pass IDs & |-------------------------->| | 617 | payloads to FEC |(3) Explicit Source FEC +----------------+ 618 | scheme | Payload IDs 619 +----------------------+ Repair FEC Payload IDs 620 ^ ^ Source payloads 621 | | Repair payloads 622 |Source pkts |Repair payloads 623 | | 624 +-- |- -- -- -- -- -- -+ 625 |RTP| | RTP Processing | 626 | | +-- -- -- --|-- -+ 627 | +-- -- -- -- -- |--+ | 628 | | RTP Demux | | 629 +-- -- -- -- -- -- -- -+ 630 ^ 631 |(1) FEC Source and Repair Packets 632 | 633 +----------------------+ 634 | Transport Protocol | 635 +----------------------+ 637 Figure 5: Receiver Operation with Sliding Window FEC Codes and RTP 638 Repair Flows 640 5. Protocol Specification 642 5.1. General 644 This section discusses the protocol elements for the FEC Framework 645 specific to Sliding Window FEC schemes. The global formats of source 646 data packets (i.e., [RFC6363], Figure 6) and repair data packets 647 (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding 648 Window FEC codes. They are not repeated here. 650 5.2. FEC Framework Configuration Information 652 The FEC Framework Configuration Information considerations of 653 [RFC6363], Section 5.5, equally applies to this FECFRAME extension 654 and is not repeated here. 656 5.3. FEC Scheme Requirements 658 The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply 659 to this FECFRAME extension and are not repeated here. An exception 660 though is the "full specification of the FEC code", item (4), that is 661 specific to block FEC codes. The following item (4-bis) applies in 662 case of Sliding Window FEC schemes: 664 4-bis. A full specification of the Sliding Window FEC code 666 This specification MUST precisely define the valid FEC-Scheme- 667 Specific Information values, the valid FEC Payload ID values, and 668 the valid packet payload sizes (where packet payload refers to 669 the space within a packet dedicated to carrying encoding 670 symbols). 672 Furthermore, given valid values of the FEC-Scheme-Specific 673 Information, a valid Repair FEC Payload ID value, a valid packet 674 payload size, and a valid encoding window (i.e., a set of source 675 symbols), the specification MUST uniquely define the values of 676 the encoding symbol (or symbols) to be included in the repair 677 packet payload with the given Repair FEC Payload ID value. 679 Additionally, the FEC Scheme associated to a Sliding Window FEC Code: 681 o MUST define the relationships between ADUs and the associated 682 source symbols (mapping); 684 o MUST define the management of the encoding window that slides over 685 the set of ADUs. Appendix A provides non normative hints about 686 what FEC Scheme designers need to consider; 688 o MUST define the management of the decoding window. This usually 689 consists in managing a system of linear equations (in case of a 690 linear FEC code); 692 6. Feedback 694 The discussion of [RFC6363], Section 6, equally applies to this 695 FECFRAME extension and is not repeated here. 697 7. Transport Protocols 699 The discussion of [RFC6363], Section 7, equally applies to this 700 FECFRAME extension and is not repeated here. 702 8. Congestion Control 704 The discussion of [RFC6363], Section 8, equally applies to this 705 FECFRAME extension and is not repeated here. 707 9. Implementation Status 709 Editor's notes: RFC Editor, please remove this section motivated by 710 RFC 7942 before publishing the RFC. Thanks! 712 An implementation of FECFRAME extended to Sliding Window codes 713 exists: 715 o Organisation: Inria 717 o Description: This is an implementation of FECFRAME extended to 718 Sliding Window codes and supporting the RLC FEC Scheme [RLC-ID]. 719 It is based on: (1) a proprietary implementation of FECFRAME, made 720 by Inria and Expway for which interoperability tests have been 721 conducted; and (2) a proprietary implementation of RLC Sliding 722 Window FEC Codes. 724 o Maturity: the basic FECFRAME maturity is "production", the 725 FECFRAME extension maturity is "under progress". 727 o Coverage: the software implements a subset of [RFC6363], as 728 specialized by the 3GPP eMBMS standard [MBMSTS]. This software 729 also covers the additional features of FECFRAME extended to 730 Sliding Window codes, in particular the RLC FEC Scheme. 732 o Licensing: proprietary. 734 o Implementation experience: maximum. 736 o Information update date: March 2018. 738 o Contact: vincent.roca@inria.fr 740 10. Security Considerations 742 This FECFRAME extension does not add any new security consideration. 743 All the considerations of [RFC6363], Section 9, apply to this 744 document as well. However, for the sake of completeness, the 745 following goal can be added to the list provided in Section 9.1 746 "Problem Statement" of [RFC6363]: 748 o Attacks can try to corrupt source flows in order to modify the 749 receiver application's behavior (as opposed to just denying 750 service). 752 11. Operations and Management Considerations 754 This FECFRAME extension does not add any new Operations and 755 Management Consideration. All the considerations of [RFC6363], 756 Section 10, apply to this document as well. 758 12. IANA Considerations 760 No IANA actions are required for this document. 762 A FEC Scheme for use with this FEC Framework is identified via its 763 FEC Encoding ID. It is subject to IANA registration in the "FEC 764 Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of 765 [RFC6363], Section 11, apply and are not repeated here. 767 13. Acknowledgments 769 The authors would like to thank Christer Holmberg, David Black, Gorry 770 Fairhurst, and Emmanuel Lochin, Spencer Dawkins, Ben Campbell, 771 Benjamin Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their 772 valuable feedback on this document. This document being an extension 773 to [RFC6363], the authors would also like to thank Mark Watson as the 774 main author of that RFC. 776 14. References 778 14.1. Normative References 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, 782 DOI 10.17487/RFC2119, March 1997, 783 . 785 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 786 Correction (FEC) Framework", RFC 6363, 787 DOI 10.17487/RFC6363, October 2011, 788 . 790 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 791 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 792 May 2017, . 794 14.2. Informative References 796 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 797 Protocols and codecs", 3GPP TS 26.346, March 2009, 798 . 800 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 801 Correction (FEC) Building Block", RFC 5052, 802 DOI 10.17487/RFC5052, August 2007, 803 . 805 [RFC6364] Begen, A., "Session Description Protocol Elements for the 806 Forward Error Correction (FEC) Framework", RFC 6364, 807 DOI 10.17487/RFC6364, October 2011, 808 . 810 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 811 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 812 DOI 10.17487/RFC6681, August 2012, 813 . 815 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 816 Parity Check (LDPC) Staircase Forward Error Correction 817 (FEC) Scheme for FECFRAME", RFC 6816, 818 DOI 10.17487/RFC6816, December 2012, 819 . 821 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 822 Matsuzono, "Simple Reed-Solomon Forward Error Correction 823 (FEC) Scheme for FECFRAME", RFC 6865, 824 DOI 10.17487/RFC6865, February 2013, 825 . 827 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 828 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 829 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 830 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 831 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 832 June 2018, . 834 [RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 835 (RLC) Forward Erasure Correction (FEC) Scheme for 836 FECFRAME", Work in Progress, Transport Area Working Group 837 (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in 838 Progress), September 2018, . 841 Appendix A. About Sliding Encoding Window Management (informational) 843 The FEC Framework does not specify the management of the sliding 844 encoding window which is the responsibility of the FEC Scheme. This 845 annex only provides a few informational hints. 847 Source symbols are added to the sliding encoding window each time a 848 new ADU is available at the sender, after the ADU-to-source-symbol 849 mapping specific to the FEC Scheme. 851 Source symbols are removed from the sliding encoding window, for 852 instance: 854 o after a certain delay, when an "old" ADU of a real-time flow times 855 out. The source symbol retention delay in the sliding encoding 856 window should therefore be initialized according to the real-time 857 features of incoming flow(s) when applicable; 859 o once the sliding encoding window has reached its maximum size 860 (there is usually an upper limit to the sliding encoding window 861 size). In that case the oldest symbol is removed each time a new 862 source symbol is added. 864 Several considerations can impact the management of this sliding 865 encoding window: 867 o at the source flows level: real-time constraints can limit the 868 total time source symbols can remain in the encoding window; 870 o at the FEC code level: theoretical or practical limitations (e.g., 871 because of computational complexity) can limit the number of 872 source symbols in the encoding window; 874 o at the FEC Scheme level: signaling and window management are 875 intrinsically related. For instance, an encoding window composed 876 of a non-sequential set of source symbols requires an appropriate 877 signaling to inform a receiver of the composition of the encoding 878 window, and the associated transmission overhead can limit the 879 maximum encoding window size. On the opposite, an encoding window 880 always composed of a sequential set of source symbols simplifies 881 signaling: providing the identity of the first source symbol plus 882 their number is sufficient, which creates a fixed and relatively 883 small transmission overhead. 885 Authors' Addresses 887 Vincent Roca 888 INRIA 889 Univ. Grenoble Alpes 890 France 892 EMail: vincent.roca@inria.fr 894 Ali Begen 895 Networked Media 896 Konya 897 Turkey 899 EMail: ali.begen@networked.media