idnits 2.17.1 draft-ietf-tsvwg-fecframe-ext-00.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 -- The document date (July 17, 2017) is 2469 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG V. Roca 3 Internet-Draft INRIA 4 Intended status: Standards Track A. Begen 5 Expires: January 18, 2018 Networked Media 6 July 17, 2017 8 Forward Error Correction (FEC) Framework Extension to Sliding Window 9 Codes 10 draft-ietf-tsvwg-fecframe-ext-00 12 Abstract 14 RFC 6363 describes a framework for using Forward Error Correction 15 (FEC) codes with applications in public and private IP networks to 16 provide protection against packet loss. The framework supports 17 applying FEC to arbitrary packet flows over unreliable transport and 18 is primarily intended for real-time, or streaming, media. However 19 FECFRAME as per RFC 6363 is restricted to block FEC codes. The 20 present document extends FECFRAME to support FEC Codes based on a 21 sliding encoding window, in addition to Block FEC Codes, in a 22 backward compatible way. During multicast/broadcast real-time 23 content delivery, the use of sliding window codes significantly 24 improves robustness in harsh environments, with less repair traffic 25 and lower FEC-related added latency. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 18, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 63 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 64 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2. Sender Operation with Sliding Window FEC Codes . . . . . 10 67 4.3. Receiver Operation with Sliding Window FEC Codes . . . . 12 68 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 14 69 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 5.2. FEC Framework Configuration Information . . . . . . . . . 15 71 5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 15 72 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 16 74 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 16 75 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 11. Operations and Management Considerations . . . . . . . . . . 17 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 14.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Appendix A. About Sliding Encoding Window Management (non 84 Normative) . . . . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 Many applications need to transport a continuous stream of packetized 90 data from a source (sender) to one or more destinations (receivers) 91 over networks that do not provide guaranteed packet delivery. In 92 particular packets may be lost, which is strictly the focus of this 93 document: we assume that transmitted packets are either received 94 without any corruption or totally lost (e.g., because of a congested 95 router, of a poor signal-to-noise ratio in a wireless network, or 96 because the number of bit errors exceeds the correction capabilities 97 of a low-layer error correcting code). 99 For these use-cases, Forward Error Correction (FEC) applied within 100 the transport or application layer, is an efficient technique to 101 improve packet transmission robustness in presence of packet losses 102 (or "erasures"), without going through packet retransmissions that 103 create a delay often incompatible with real-time constraints. The 104 FEC Building Block defined in [RFC5052] provides a framework for the 105 definition of Content Delivery Protocols (CDPs) that make use of 106 separately defined FEC schemes. Any CDP defined according to the 107 requirements of the FEC Building Block can then easily be used with 108 any FEC scheme that is also defined according to the requirements of 109 the FEC Building Block. 111 Then FECFRAME [RFC6363] provides a framework to define Content 112 Delivery Protocols (CDPs) that provide FEC protection for arbitrary 113 packet flows over unreliable transports such as UDP. It is primarily 114 intended for real-time or streaming media applications, using 115 broadcast, multicast, or on-demand delivery. 117 However [RFC6363] only considers block FEC schemes defined in 118 accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], 119 [RFC6816] or [RFC6865]). These codes require the input flow(s) to be 120 segmented into a sequence of blocks. Then FEC encoding (at a sender 121 or an encoding middlebox) and decoding (at a receiver or a decoding 122 middlebox) are both performed on a per-block basis. This approach 123 has major impacts on FEC encoding and decoding delays. The data 124 packets of continuous media flow(s) can be sent immediately, without 125 delay. But the block creation time, that depends on the number k of 126 source symbols in this block, impacts the FEC encoding delay since 127 encoding requires that all source symbols be known. This block 128 creation time also impacts the decoding delay a receiver will 129 experience in case of erasures, since no repair symbol for the 130 current block can be received before. Therefore a good value for the 131 block size is necessarily a balance between the maximum decoding 132 latency at the receivers (which must be in line with the most 133 stringent real-time requirement of the protected flow(s), hence an 134 incentive to reduce the block size), and the desired robustness 135 against long loss bursts (which increases with the block size, hence 136 an incentive to increase this size). 138 This document extends [RFC6363] in order to also support FEC codes 139 based on a sliding encoding window (A.K.A. convolutional codes). 140 This encoding window, either of fixed or variable size, slides over 141 the set of source symbols. FEC encoding is launched whenever needed, 142 from the set of source symbols present in the sliding encoding window 143 at that time. This approach significantly reduces FEC-related 144 latency, since repair symbols can be generated and sent on-the-fly, 145 at any time, and can be regularly received by receivers to quickly 146 recover packet losses. Using sliding window FEC codes is therefore 147 highly beneficial to real-time flows, one of the primary targets of 148 FECFRAME. [RLC-ID] provides an example of such FEC Scheme for 149 FECFRAME, built upon the simple sliding window Random Linear Codes 150 (RLC). 152 This document is fully backward compatible with [RFC6363] that it 153 extends but does not replace. Indeed: 155 o this extension does not prevent nor compromize in any way the 156 support of block FEC codes. Both types of codes can nicely co- 157 exist, just like different block FEC schemes can co-exist; 159 o any receiver, for instance a legacy receiver that only supports 160 block FEC schemes, can easily identify the FEC scheme used in a 161 FECFRAME session thanks to the associated SDP file and its FEC 162 Encoding ID information (i.e., the "encoding-id=" parameter of a 163 "fec-repair-flow" attribute, [RFC6364]). This mechanism is not 164 specific to this extension but is the basic approach for a 165 FECFRAME receiver to determine whether or not it supports the FEC 166 scheme used in a given FECFRAME session; 168 This document leverages on [RFC6363] and re-uses its structure. It 169 proposes new sections specific to sliding window FEC codes whenever 170 required. The only exception is Section Section 3 that provides a 171 quick summary of FECFRAME in order to facilitate the understanding of 172 this document to readers not familiar with the concepts and 173 terminology. 175 2. Definitions and Abbreviations 177 The following list of definitions and abbreviations is copied from 178 [RFC6363], adding only the Block/sliding window FEC Code and 179 Encoding/Decoding Window definitions: 181 Application Data Unit (ADU): The unit of source data provided as 182 payload to the transport layer. 184 ADU Flow: A sequence of ADUs associated with a transport-layer flow 185 identifier (such as the standard 5-tuple {source IP address, 186 source port, destination IP address, destination port, transport 187 protocol}). 189 AL-FEC: Application-layer Forward Error Correction. 191 Application Protocol: Control protocol used to establish and control 192 the source flow being protected, e.g., the Real-Time Streaming 193 Protocol (RTSP). 195 Content Delivery Protocol (CDP): A complete application protocol 196 specification that, through the use of the framework defined in 197 this document, is able to make use of FEC schemes to provide FEC 198 capabilities. 200 FEC Code: An algorithm for encoding data such that the encoded data 201 flow is resilient to data loss. Note that, in general, FEC codes 202 may also be used to make a data flow resilient to corruption, but 203 that is not considered in this document. 205 Block FEC Code: An FEC Code that operates in a block manner, i.e., 206 for which the input flow MUST be segmented into a sequence of 207 blocks, FEC encoding and decoding being performed independently 208 on a per-block basis. 210 Sliding Window (or Convolutional) FEC Code: An FEC Code that can 211 generate repair symbols on-the-fly, at any time, from the set of 212 source symbols present in the sliding encoding window at that 213 time. 215 FEC Framework: A protocol framework for the definition of Content 216 Delivery Protocols using FEC, such as the framework defined in 217 this document. 219 FEC Framework Configuration Information: Information that controls 220 the operation of the FEC Framework. 222 FEC Payload ID: Information that identifies the contents of a packet 223 with respect to the FEC scheme. 225 FEC Repair Packet: At a sender (respectively, at a receiver), a 226 payload submitted to (respectively, received from) the transport 227 protocol containing one or more repair symbols along with a 228 Repair FEC Payload ID and possibly an RTP header. 230 FEC Scheme: A specification that defines the additional protocol 231 aspects required to use a particular FEC code with the FEC 232 Framework. 234 FEC Source Packet: At a sender (respectively, at a receiver), a 235 payload submitted to (respectively, received from) the transport 236 protocol containing an ADU along with an optional Explicit Source 237 FEC Payload ID. 239 Protection Amount: The relative increase in data sent due to the use 240 of FEC. 242 Repair Flow: The packet flow carrying FEC data. 244 Repair FEC Payload ID: A FEC Payload ID specifically for use with 245 repair packets. 247 Source Flow: The packet flow to which FEC protection is to be 248 applied. A source flow consists of ADUs. 250 Source FEC Payload ID: A FEC Payload ID specifically for use with 251 source packets. 253 Source Protocol: A protocol used for the source flow being 254 protected, e.g., RTP. 256 Transport Protocol: The protocol used for the transport of the 257 source and repair flows, e.g., UDP and the Datagram Congestion 258 Control Protocol (DCCP). 260 Encoding Window: Set of Source Symbols available at the sender/ 261 coding node that are used to generate a repair symbol, with a 262 Sliding Window FEC Code. 264 Decoding Window: Set of received or decoded source and repair 265 symbols available at a receiver that are used to decode erased 266 source symbols, with a Sliding Window FEC Code. 268 Code Rate: The ratio between the number of source symbols and the 269 number of encoding symbols. By definition, the code rate is such 270 that 0 < code rate <= 1. A code rate close to 1 indicates that a 271 small number of repair symbols have been produced during the 272 encoding process. 274 Encoding Symbol: Unit of data generated by the encoding process. 275 With systematic codes, source symbols are part of the encoding 276 symbols. 278 Packet Erasure Channel: A communication path where packets are 279 either lost (e.g., by a congested router, or because the number 280 of transmission errors exceeds the correction capabilities of the 281 physical-layer codes) or received. When a packet is received, it 282 is assumed that this packet is not corrupted. 284 Repair Symbol: Encoding symbol that is not a source symbol. 286 Source Block: Group of ADUs that are to be FEC protected as a single 287 block. This notion is restricted to Block FEC Codes. 289 Source Symbol: Unit of data used during the encoding process. 291 Systematic Code: FEC code in which the source symbols are part of 292 the encoding symbols. 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 296 document are to be interpreted as described in [RFC2119]. 298 3. Architecture Overview 300 The architecture of [RFC6363], Section 3, equally applies to this 301 FECFRAME extension and is not repeated here. However we provide 302 hereafter a quick summary to facilitate the understanding of this 303 document to readers not familiar with the concepts and terminology. 305 +----------------------+ 306 | Application | 307 +----------------------+ 308 | 309 | (1) Application Data Units (ADUs) 310 | 311 v 312 +----------------------+ +----------------+ 313 | FEC Framework | | | 314 | |-------------------------->| FEC Scheme | 315 |(2) Construct source |(3) Source Block | | 316 | blocks | |(4) FEC Encoding| 317 |(6) Construct FEC |<--------------------------| | 318 | source and repair | | | 319 | packets |(5) Explicit Source FEC | | 320 +----------------------+ Payload IDs +----------------+ 321 | Repair FEC Payload IDs 322 | Repair symbols 323 | 324 |(7) FEC source and repair packets 325 v 326 +----------------------+ 327 | Transport Layer | 328 | (e.g., UDP) | 329 +----------------------+ 331 Figure 1: FECFRAME architecture at a sender. 333 The FECFRAME architecture is illustrated in Figure 1 from the 334 sender's point of view, in case of a block FEC Scheme. It shows an 335 application generating an ADU flow (other flows, from other 336 applications, may co-exist). These ADUs, of variable size, must be 337 somehow mapped to source symbols of fixed size. This is the goal of 338 an ADU to symbols mapping process that is FEC Scheme specific (see 339 below). Once the source block is built, taking into account both the 340 FEC Scheme constraints (e.g., in terms of maximum source block size) 341 and the application's flow constraints (e.g., in terms of real-time 342 constraints), the associated source symbols are handed to the FEC 343 Scheme in order to produce an appropriate number of repair symbols. 344 FEC Source Packets (containing ADUs) and FEC Repair Packets 345 (containing one or more repair symbols each) are then generated and 346 sent using UDP (more precisely [RFC6363], Section 7, requires a 347 transport protocol providing an unreliable datagram service, like UDP 348 or DCCP). In practice FEC Source Packets can be sent as soon as 349 available, without having to wait for FEC encoding to take place. In 350 that case a copy of the associated source symbols need to be kept 351 within FECFRAME for future FEC encoding purposes. 353 At a receiver (not shown), FECFRAME processing operates in a similar 354 way, taking as input the incoming FEC source and repair packets 355 received. In case of FEC source packet losses, the FEC decoding of 356 the associated block may recover all (in case of successful decoding) 357 or a subset potentially empty (otherwise) of the missing source 358 symbols. After source symbol to ADU mapping, when lost ADUs are 359 recovered, they are then assigned to their respective flow (see 360 below). ADUs are returned to the application(s), either in their 361 initial transmission order (in that case ADUs received after an 362 erased one will be delayed until FEC decoding has taken place) or not 363 (in that case each ADU is returned as soon as it is received or 364 recovered), depending on the application requirements. 366 FECFRAME features two subtle mechanisms: 368 o ADUs to source symbols mapping: in order to manage variable size 369 ADUs, FECFRAME and FEC Schemes can use small, fixed size symbols 370 and create a mapping between ADUs and symbols. To each ADU this 371 mechanism prepends a length field (plus a flow identifier, see 372 below) and pads the result to a multiple of the symbol size. A 373 small ADU may be mapped to a single source symbol while a large 374 one may be mapped to multiple symbols. The mapping details are 375 FEC Scheme dependant and must be defined in the associated 376 document; 378 o Assignment of decoded ADUs to flows in multi-flow configurations: 379 when multiple flows are multiplexed over the same FECFRAME 380 instance, a problem is to assign a decoded ADU to the right flow 381 (UDP port numbers and IP addresses traditionally used to map 382 incoming ADUs to flows are not recovered during FEC decoding). To 383 make it possible, at the FECFRAME sending instance, each ADU is 384 prepended with a flow identifier (1 byte) during the mapping to 385 source symbols (see above). The flow identifiers are also shared 386 between all FECFRAME instances as part of the FEC Framework 387 Configuration Information. This (flow identifier + length + 388 application payload + padding), called ADUI, is then FEC 389 protected. Therefore a decoded ADUI contains enough information 390 to assign the ADU to the right flow. 392 A few aspects are not covered by FECFRAME, namely: 394 o [RFC6363] section 8 does not detail any congestion control 395 mechanism, but only provides high level normative requirements; 397 o the possibility of having feedbacks from receiver(s) is considered 398 out of scope, although such a mechanism may exist within the 399 application (e.g., through RCTP control messages); 401 o flow adaptation at a FECFRAME sender (e.g., how to set the FEC 402 code rate based on transmission conditions) is not detailed, but 403 it needs to comply with the congestion control normative 404 requirements (see above). 406 4. Procedural Overview 408 4.1. General 410 The general considerations of [RFC6363], Section 4.1, that are 411 specific to block FEC codes are not repeated here. 413 With a Sliding Window FEC Code, the FEC source packet MUST contain 414 information to identify the position occupied by the ADU within the 415 source flow, in terms specific to the FEC scheme. This information 416 is known as the Source FEC Payload ID, and the FEC scheme is 417 responsible for defining and interpreting it. 419 With a Sliding Window FEC Code, the FEC repair packets MUST contain 420 information that identifies the relationship between the contained 421 repair payloads and the original source symbols used during encoding. 422 This information is known as the Repair FEC Payload ID, and the FEC 423 scheme is responsible for defining and interpreting it. 425 The Sender Operation ([RFC6363], Section 4.2.) and Receiver Operation 426 ([RFC6363], Section 4.3) are both specific to block FEC codes and 427 therefore omitted below. The following two sections detail similar 428 operations for Sliding Window FEC codes. 430 4.2. Sender Operation with Sliding Window FEC Codes 432 With a Sliding Window FEC scheme, the following operations, 433 illustrated in Figure 2 for the case of UDP repair flows, and in 434 Figure 3 for the case of RTP repair flows, describe a possible way to 435 generate compliant source and repair flows: 437 1. A new ADU is provided by the application. 439 2. The FEC Framework communicates this ADU to the FEC scheme. 441 3. The sliding encoding window is updated by the FEC scheme. The 442 ADU to source symbols mapping as well as the encoding window 443 management details are both the responsibility of the FEC scheme 444 and MUST be detailed there. Appendix A provides some hints on 445 the way it might be performed. 447 4. The Source FEC Payload ID information of the source packet is 448 determined by the FEC scheme. If required by the FEC scheme, 449 the Source FEC Payload ID is encoded into the Explicit Source 450 FEC Payload ID field and returned to the FEC Framework. 452 5. The FEC Framework constructs the FEC source packet according to 453 [RFC6363] Figure 6, using the Explicit Source FEC Payload ID 454 provided by the FEC scheme if applicable. 456 6. The FEC source packet is sent using normal transport-layer 457 procedures. This packet is sent using the same ADU flow 458 identification information as would have been used for the 459 original source packet if the FEC Framework were not present 460 (for example, in the UDP case, the UDP source and destination 461 addresses and ports on the IP datagram carrying the source 462 packet will be the same whether or not the FEC Framework is 463 applied). 465 7. When the FEC Framework needs to send one or several FEC repair 466 packets (e.g., according to the target Code Rate), it asks the 467 FEC scheme to create one or several repair packet payloads from 468 the current sliding encoding window along with their Repair FEC 469 Payload ID. 471 8. The Repair FEC Payload IDs and repair packet payloads are 472 provided back by the FEC scheme to the FEC Framework. 474 9. The FEC Framework constructs FEC repair packets according to 475 [RFC6363] Figure 7, using the FEC Payload IDs and repair packet 476 payloads provided by the FEC scheme. 478 10. The FEC repair packets are sent using normal transport-layer 479 procedures. The port(s) and multicast group(s) to be used for 480 FEC repair packets are defined in the FEC Framework 481 Configuration Information. 483 +----------------------+ 484 | Application | 485 +----------------------+ 486 | 487 | (1) New Application Data Unit (ADU) 488 v 489 +---------------------+ +----------------+ 490 | FEC Framework | | FEC Scheme | 491 | |-------------------------->| | 492 | | (2) New ADU |(3) Update of | 493 | | | encoding | 494 | |<--------------------------| window | 495 |(5) Construct FEC | (4) Explicit Source | | 496 | source packet | FEC Payload ID(s) |(7) FEC | 497 | |<--------------------------| encoding | 498 |(9) Construct FEC | (8) Repair FEC Payload ID | | 499 | repair packet(s) | + Repair symbol(s) +----------------+ 500 +---------------------+ 501 | 502 | (6) FEC source packet 503 | (10) FEC repair packets 504 v 505 +----------------------+ 506 | Transport Layer | 507 | (e.g., UDP) | 508 +----------------------+ 510 Figure 2: Sender Operation with Convolutional FEC Codes 512 +----------------------+ 513 | Application | 514 +----------------------+ 515 | 516 | (1) New Application Data Unit (ADU) 517 v 518 +---------------------+ +----------------+ 519 | FEC Framework | | FEC Scheme | 520 | |-------------------------->| | 521 | | (2) New ADU |(3) Update of | 522 | | | encoding | 523 | |<--------------------------| window | 524 |(5) Construct FEC | (4) Explicit Source | | 525 | source packet | FEC Payload ID(s) |(7) FEC | 526 | |<--------------------------| encoding | 527 |(9) Construct FEC | (8) Repair FEC Payload ID | | 528 | repair packet(s) | + Repair symbol(s) +----------------+ 529 +---------------------+ 530 | | 531 |(6) Source |(10) Repair payloads 532 | packets | 533 | + -- -- -- -- -+ 534 | | RTP | 535 | +-- -- -- -- --+ 536 v v 537 +----------------------+ 538 | Transport Layer | 539 | (e.g., UDP) | 540 +----------------------+ 542 Figure 3: Sender Operation with RTP Repair Flows 544 4.3. Receiver Operation with Sliding Window FEC Codes 546 With a Sliding Window FEC scheme, the following operations, 547 illustrated in Figure 4 for the case of UDP repair flows, and in 548 Figure 5 for the case of RTP repair flows. The only differences with 549 respect to block FEC codes lie in steps (4) and (5). Therefore this 550 section does not repeat the other steps of [RFC6363], Section 4.3, 551 "Receiver Operation". The new steps (4) and (5) are: 553 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC 554 Source Payload IDs when the Explicit Source FEC Payload ID field 555 is not used) to insert source and repair packets into the 556 decoding window in the right way. If at least one source packet 557 is missing and at least one repair packet has been received and 558 the rank of the associated linear system permits it, then FEC 559 decoding can be performed in order to recover missing source 560 payloads. The FEC scheme determines whether source packets have 561 been lost and whether enough repair packets have been received to 562 decode any or all of the missing source payloads. 564 5. The FEC scheme returns the received and decoded ADUs to the FEC 565 Framework, along with indications of any ADUs that were missing 566 and could not be decoded. 568 +----------------------+ 569 | Application | 570 +----------------------+ 571 ^ 572 |(6) ADUs 573 | 574 +----------------------+ +----------------+ 575 | FEC Framework | | FEC Scheme | 576 | |<--------------------------| | 577 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding 578 | IDs and pass IDs & |-------------------------->| | 579 | payloads to FEC |(3) Explicit Source FEC +----------------+ 580 | scheme | Payload IDs 581 +----------------------+ Repair FEC Payload IDs 582 ^ Source payloads 583 | Repair payloads 584 |(1) FEC source 585 | and repair packets 586 +----------------------+ 587 | Transport Layer | 588 | (e.g., UDP) | 589 +----------------------+ 591 Figure 4: Receiver Operation with Sliding Window FEC Codes 593 +----------------------+ 594 | Application | 595 +----------------------+ 596 ^ 597 |(6) ADUs 598 | 599 +----------------------+ +----------------+ 600 | FEC Framework | | FEC Scheme | 601 | |<--------------------------| | 602 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding| 603 | IDs and pass IDs & |-------------------------->| | 604 | payloads to FEC |(3) Explicit Source FEC +----------------+ 605 | scheme | Payload IDs 606 +----------------------+ Repair FEC Payload IDs 607 ^ ^ Source payloads 608 | | Repair payloads 609 |Source pkts |Repair payloads 610 | | 611 +-- |- -- -- -- -- -- -+ 612 |RTP| | RTP Processing | 613 | | +-- -- -- --|-- -+ 614 | +-- -- -- -- -- |--+ | 615 | | RTP Demux | | 616 +-- -- -- -- -- -- -- -+ 617 ^ 618 |(1) FEC source and repair packets 619 | 620 +----------------------+ 621 | Transport Layer | 622 | (e.g., UDP) | 623 +----------------------+ 625 Figure 5: Receiver Operation with RTP Repair Flows 627 5. Protocol Specification 629 5.1. General 631 This section discusses the protocol elements for the FEC Framework 632 specific to Sliding Window FEC schemes. The global formats of source 633 data packets (i.e., [RFC6363], Figure 6) and repair data packets 634 (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding 635 Window FEC codes. They are not repeated here. 637 5.2. FEC Framework Configuration Information 639 The FEC Framework Configuration Information considerations of 640 [RFC6363], Section 5.5, equally applies to this FECFRAME extension 641 and is not repeated here. 643 5.3. FEC Scheme Requirements 645 The FEC scheme requirements of [RFC6363], Section 5.6, mostly apply 646 to this FECFRAME extension and are not repeated here. An exception 647 though is the "full specification of the FEC code", item (4), that is 648 specific to block FEC codes. The following item (4) applies instead: 650 4. A full specification of the Sliding Window FEC code 652 This specification MUST precisely define the valid FEC-Scheme- 653 Specific Information values, the valid FEC Payload ID values, and 654 the valid packet payload sizes (where packet payload refers to 655 the space within a packet dedicated to carrying encoding 656 symbols). 658 Furthermore, given valid values of the FEC-Scheme-Specific 659 Information, a valid Repair FEC Payload ID value, a valid packet 660 payload size, and a valid encoding window (i.e., a set of source 661 symbols), the specification MUST uniquely define the values of 662 the encoding symbols to be included in the repair packet payload 663 with the given Repair FEC Payload ID value. 665 Additionally, the FEC scheme associated to a Sliding Window FEC Code: 667 o MUST define the relationships between ADUs and the associated 668 source symbols (mapping); 670 o MUST define the management of the encoding window that slides over 671 the set of ADUs. Appendix A provides a non normative example; 673 o MUST define the management of the decoding window, consisting of a 674 system of linear equations (in case of a linear FEC code); 676 6. Feedback 678 The discussion of [RFC6363], Section 6, equally applies to this 679 FECFRAME extension and is not repeated here. 681 7. Transport Protocols 683 The discussion of [RFC6363], Section 7, equally applies to this 684 FECFRAME extension and is not repeated here. 686 8. Congestion Control 688 The discussion of [RFC6363], Section 8, equally applies to this 689 FECFRAME extension and is not repeated here. 691 9. Implementation Status 693 Editor's notes: RFC Editor, please remove this section motivated by 694 RFC 7942 before publishing the RFC. Thanks! 696 An implementation of FECFRAME extended to Sliding Window codes 697 exists: 699 o Organisation: Inria 701 o Description: This is an implementation of FECFRAME extended to 702 Sliding Window codes and supporting the RLC FEC Scheme [RLC-ID]. 703 It is based on: (1) a proprietary implementation of FECFRAME, made 704 by Inria and Expway for which interoperability tests have been 705 conducted; and (2) a proprietary implementation of RLC Sliding 706 Window FEC Codes. 708 o Maturity: the basic FECFRAME maturity is "production", the 709 FECFRAME extension maturity is "under progress". 711 o Coverage: the software implements a subset of [RFC6363], as 712 specialized by the 3GPP eMBMS standard [MBMSTS]. This software 713 also covers the additional features of FECFRAME extended to 714 Sliding Window codes, in particular the RLC FEC Scheme. 716 o Lincensing: proprietary. 718 o Implementation experience: maximum. 720 o Information update date: March 2017. 722 o Contact: vincent.roca@inria.fr 724 10. Security Considerations 726 This FECFRAME extension does not add any new security consideration. 727 All the considerations of [RFC6363], Section 9, apply to this 728 document as well. 730 11. Operations and Management Considerations 732 This FECFRAME extension does not add any new Operations and 733 Management Consideration. All the considerations of [RFC6363], 734 Section 10, apply to this document as well. 736 12. IANA Considerations 738 A FEC scheme for use with this FEC Framework is identified via its 739 FEC Encoding ID. It is subject to IANA registration in the "FEC 740 Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of 741 [RFC6363], Section 11, apply and are not repeated here. 743 13. Acknowledgments 745 TBD 747 14. References 749 14.1. Normative References 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, 753 DOI 10.17487/RFC2119, March 1997, 754 . 756 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 757 Correction (FEC) Framework", RFC 6363, 758 DOI 10.17487/RFC6363, October 2011, 759 . 761 14.2. Informative References 763 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 764 Protocols and codecs", 3GPP TS 26.346, March 2009, 765 . 767 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 768 Correction (FEC) Building Block", RFC 5052, 769 DOI 10.17487/RFC5052, August 2007, 770 . 772 [RFC6364] Begen, A., "Session Description Protocol Elements for the 773 Forward Error Correction (FEC) Framework", RFC 6364, 774 DOI 10.17487/RFC6364, October 2011, 775 . 777 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 778 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 779 DOI 10.17487/RFC6681, August 2012, 780 . 782 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 783 Parity Check (LDPC) Staircase Forward Error Correction 784 (FEC) Scheme for FECFRAME", RFC 6816, 785 DOI 10.17487/RFC6816, December 2012, 786 . 788 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 789 Matsuzono, "Simple Reed-Solomon Forward Error Correction 790 (FEC) Scheme for FECFRAME", RFC 6865, 791 DOI 10.17487/RFC6865, February 2013, 792 . 794 [RLC-ID] Roca, V., "Sliding Window Random Linear Code (RLC) Forward 795 Erasure Correction (FEC) Scheme for FECFRAME", Work 796 in Progress, Transport Area Working Group (TSVWG) draft- 797 roca-tsvwg-rlc-fec-scheme (Work in Progress), June 2017, 798 . 801 Appendix A. About Sliding Encoding Window Management (non Normative) 803 The FEC Framework does not specify the management of the sliding 804 encoding window which is the responsibility of the FEC Scheme. This 805 annex provides a few hints with respect to the management of this 806 encoding window. 808 Source symbols are added to the sliding encoding window each time a 809 new ADU arrives, where the following information is provided for this 810 ADU by the FEC Framework: a description of the source flow with which 811 the ADU is associated, the ADU itself, and the length of the ADU. 812 This information is sufficient for the FEC scheme to map the ADU to 813 the corresponding source symbols. 815 Source symbols and the corresponding ADUs are removed from the 816 sliding encoding window, for instance: 818 o after a certain delay, when an "old" ADU of a real-time flow times 819 out. The source symbol retention delay in the sliding encoding 820 window should therefore be initialized according to the real-time 821 features of incoming flow(s). 823 o once the sliding encoding window has reached its maximum size 824 (there is usually an upper limit to the sliding encoding window 825 size). In that case the oldest symbol is removed each time a new 826 source symbol is added. 828 Several aspects exist that can impact the sliding encoding window 829 management: 831 o at the source flows level: real-time constraints can limit the 832 total time source symbols can remain in the encoding window; 834 o at the FEC code level: there may be theoretical or practical 835 limitations (e.g., because of computational complexity) that limit 836 the number of source symbols in the encoding window. 838 o at the FEC scheme level: signaling and window management are 839 intrinsically related. For instance, an encoding window composed 840 of a non sequential set of source symbols requires an appropriate 841 signaling to inform a receiver of the composition of the encoding 842 window. On the opposite, an encoding window always composed of a 843 sequential set of source symbols simplifies signaling: providing 844 the identity of the first source symbol plus their number is 845 sufficient. 847 Authors' Addresses 849 Vincent Roca 850 INRIA 851 Grenoble 852 France 854 EMail: vincent.roca@inria.fr 856 Ali Begen 857 Networked Media 858 Konya 859 Turkey 861 EMail: ali.begen@networked.media