idnits 2.17.1 draft-roca-tsvwg-fecframev2-04.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 (June 27, 2017) is 2492 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: December 29, 2017 Networked Media 6 June 27, 2017 8 Forward Error Correction (FEC) Framework Extension to Sliding Window 9 Codes 10 draft-roca-tsvwg-fecframev2-04 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 December 29, 2017. 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 . . . . . 9 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 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 received 93 without any corruption or totally lost (e.g., because of a congested 94 router, of a poor signal-to-noise ratio in a wireless network, or 95 because the number of bit errors exceeds the correction capabilities 96 of a low-layer error correcting code). 98 For these use-cases, Forward Error Correction (FEC) applied within 99 the transport or application layer, is an efficient technique to 100 improve packet transmission robustness in presence of packet losses 101 (or "erasures"), without going through packet retransmissions that 102 create a delay often incompatible with real-time constraints. The 103 FEC Building Block defined in [RFC5052] provides a framework for the 104 definition of Content Delivery Protocols (CDPs) that make use of 105 separately defined FEC schemes. Any CDP defined according to the 106 requirements of the FEC Building Block can then easily be used with 107 any FEC scheme that is also defined according to the requirements of 108 the FEC Building Block. 110 Then FECFRAME [RFC6363] provides a framework to define Content 111 Delivery Protocols (CDPs) that provide FEC protection for arbitrary 112 packet flows over unreliable transports such as UDP. It is primarily 113 intended for real-time or streaming media applications, using 114 broadcast, multicast, or on-demand delivery. 116 However [RFC6363] only considers block FEC schemes defined in 117 accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], 118 [RFC6816] or [RFC6865]). These codes require the input flow(s) to be 119 segmented into a sequence of blocks. Then FEC encoding (at a sender 120 or an encoding middlebox) and decoding (at a receiver or a decoding 121 middlebox) are both performed on a per-block basis. This approach 122 has major impacts on FEC encoding and decoding delays. The data 123 packets of continuous media flow(s) can be sent immediately, without 124 delay. But the block creation time, that depends on the number k of 125 source symbols in this block, impacts the FEC encoding delay since 126 encoding requires that all source symbols be known. This block 127 creation time also impacts the decoding delay a receiver will 128 experience in case of erasures, since no repair symbol for the 129 current block can be received before. Therefore a good value for the 130 block size is necessarily a balance between the maximum decoding 131 latency at the receivers (which must be in line with the most 132 stringent real-time requirement of the protected flow(s), hence an 133 incentive to reduce the block size), and the desired robustness 134 against long loss bursts (which increases with the block size, hence 135 an incentive to increase this size). 137 This document extends [RFC6363] in order to also support FEC codes 138 based on a sliding encoding window (A.K.A. convolutional codes). 139 This encoding window, either of fixed or variable size, slides over 140 the set of source symbols. FEC encoding is launched whenever needed, 141 from the set of source symbols present in the sliding encoding window 142 at that time. This approach significantly reduces FEC-related 143 latency, since repair symbols can be generated and sent on-the-fly, 144 at any time, and can be regularly received by receivers to quickly 145 recover packet losses. Using sliding window FEC codes is therefore 146 highly beneficial to real-time flows, one of the primary targets of 147 FECFRAME. [RLC-ID] provides an example of such FEC Scheme for 148 FECFRAME, built upon the simple sliding window Random Linear Codes 149 (RLC). 151 This document is fully backward compatible with [RFC6363] that it 152 extends but does not replace. Indeed: 154 o this extension does not prevent nor compromize in any way the 155 support of block FEC codes. Both types of codes can nicely co- 156 exist, just like different block FEC schemes can co-exist; 158 o any receiver, for instance a legacy receiver that only supports 159 block FEC schemes, can easily identify the FEC scheme used in a 160 FECFRAME session thanks to the associated SDP file and its FEC 161 Encoding ID information (i.e., the "encoding-id=" parameter of a 162 "fec-repair-flow" attribute, [RFC6364]). This mechanism is not 163 specific to this extension but is the basic approach for a 164 FECFRAME receiver to determine whether or not it supports the FEC 165 scheme used in a given FECFRAME session; 167 This document leverages on [RFC6363] and re-uses its structure. It 168 proposes new sections specific to sliding window FEC codes whenever 169 required. The only exception is Section Section 3 that provides a 170 quick summary of FECFRAME in order to facilitate the understanding of 171 this document to readers not familiar with the concepts and 172 terminology. 174 2. Definitions and Abbreviations 176 The following list of definitions and abbreviations is copied from 177 [RFC6363], adding only the Block/sliding window FEC Code and 178 Encoding/Decoding Window definitions: 180 Application Data Unit (ADU): The unit of source data provided as 181 payload to the transport layer. 183 ADU Flow: A sequence of ADUs associated with a transport-layer flow 184 identifier (such as the standard 5-tuple {source IP address, 185 source port, destination IP address, destination port, transport 186 protocol}). 188 AL-FEC: Application-layer Forward Error Correction. 190 Application Protocol: Control protocol used to establish and control 191 the source flow being protected, e.g., the Real-Time Streaming 192 Protocol (RTSP). 194 Content Delivery Protocol (CDP): A complete application protocol 195 specification that, through the use of the framework defined in 196 this document, is able to make use of FEC schemes to provide FEC 197 capabilities. 199 FEC Code: An algorithm for encoding data such that the encoded data 200 flow is resilient to data loss. Note that, in general, FEC codes 201 may also be used to make a data flow resilient to corruption, but 202 that is not considered in this document. 204 Block FEC Code: An FEC Code that operates in a block manner, i.e., 205 for which the input flow MUST be segmented into a sequence of 206 blocks, FEC encoding and decoding being performed independently 207 on a per-block basis. 209 Sliding Window (or Convolutional) FEC Code: An FEC Code that can 210 generate repair symbols on-the-fly, at any time, from the set of 211 source symbols present in the sliding encoding window at that 212 time. 214 FEC Framework: A protocol framework for the definition of Content 215 Delivery Protocols using FEC, such as the framework defined in 216 this document. 218 FEC Framework Configuration Information: Information that controls 219 the operation of the FEC Framework. 221 FEC Payload ID: Information that identifies the contents of a packet 222 with respect to the FEC scheme. 224 FEC Repair Packet: At a sender (respectively, at a receiver), a 225 payload submitted to (respectively, received from) the transport 226 protocol containing one or more repair symbols along with a 227 Repair FEC Payload ID and possibly an RTP header. 229 FEC Scheme: A specification that defines the additional protocol 230 aspects required to use a particular FEC code with the FEC 231 Framework. 233 FEC Source Packet: At a sender (respectively, at a receiver), a 234 payload submitted to (respectively, received from) the transport 235 protocol containing an ADU along with an optional Explicit Source 236 FEC Payload ID. 238 Protection Amount: The relative increase in data sent due to the use 239 of FEC. 241 Repair Flow: The packet flow carrying FEC data. 243 Repair FEC Payload ID: A FEC Payload ID specifically for use with 244 repair packets. 246 Source Flow: The packet flow to which FEC protection is to be 247 applied. A source flow consists of ADUs. 249 Source FEC Payload ID: A FEC Payload ID specifically for use with 250 source packets. 252 Source Protocol: A protocol used for the source flow being 253 protected, e.g., RTP. 255 Transport Protocol: The protocol used for the transport of the 256 source and repair flows, e.g., UDP and the Datagram Congestion 257 Control Protocol (DCCP). 259 Encoding Window: Set of Source Symbols available at the sender/ 260 coding node that are used to generate a repair symbol, with a 261 Sliding Window FEC Code. 263 Decoding Window: Set of received or decoded source and repair 264 symbols available at a receiver that are used to decode erased 265 source symbols, with a Sliding Window FEC Code. 267 Code Rate: The ratio between the number of source symbols and the 268 number of encoding symbols. By definition, the code rate is such 269 that 0 < code rate <= 1. A code rate close to 1 indicates that a 270 small number of repair symbols have been produced during the 271 encoding process. 273 Encoding Symbol: Unit of data generated by the encoding process. 274 With systematic codes, source symbols are part of the encoding 275 symbols. 277 Packet Erasure Channel: A communication path where packets are 278 either lost (e.g., by a congested router, or because the number 279 of transmission errors exceeds the correction capabilities of the 280 physical-layer codes) or received. When a packet is received, it 281 is assumed that this packet is not corrupted. 283 Repair Symbol: Encoding symbol that is not a source symbol. 285 Source Block: Group of ADUs that are to be FEC protected as a single 286 block. This notion is restricted to Block FEC Codes. 288 Source Symbol: Unit of data used during the encoding process. 290 Systematic Code: FEC code in which the source symbols are part of 291 the encoding symbols. 293 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 294 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 295 document are to be interpreted as described in [RFC2119]. 297 3. Architecture Overview 299 The architecture of [RFC6363], Section 3, equally applies to this 300 FECFRAME extension and is not repeated here. However we provide 301 hereafter a quick summary to facilitate the understanding of this 302 document to readers not familiar with the concepts and terminology. 304 +----------------------+ 305 | Application | 306 +----------------------+ 307 | 308 | (1) Application Data Units (ADUs) 309 | 310 v 311 +----------------------+ +----------------+ 312 | FEC Framework | | | 313 | |-------------------------->| FEC Scheme | 314 |(2) Construct source |(3) Source Block | | 315 | blocks | |(4) FEC Encoding| 316 |(6) Construct FEC |<--------------------------| | 317 | source and repair | | | 318 | packets |(5) Explicit Source FEC | | 319 +----------------------+ Payload IDs +----------------+ 320 | Repair FEC Payload IDs 321 | Repair symbols 322 | 323 |(7) FEC source and repair packets 324 v 325 +----------------------+ 326 | Transport Layer | 327 | (e.g., UDP) | 328 +----------------------+ 330 Figure 1: FECFRAME architecture at a sender. 332 The FECFRAME architecture is illustrated in Figure 1 from the 333 sender's point of view, in case of a block FEC Scheme. It shows an 334 application generating an ADU flow (other flows, from other 335 applications, may co-exist). These ADUs, of variable size, must be 336 somehow mapped to source symbols of fixed size. This is the goal of 337 an ADU to symbols mapping process that is FEC Scheme specific (see 338 below). Once the source block is built, taking into account both the 339 FEC Scheme constraints (e.g., in terms of maximum source block size) 340 and the application's flow constraints (e.g., real-time constraints), 341 the associated source symbols are handed to the FEC Scheme in order 342 to produce an appropriate number of repair symbols. FEC Source 343 Packets (containing ADUs) and FEC Repair Packets (containing one or 344 more repair symbols each) are then generated and sent using UDP (more 345 precisely [RFC6363], Section 7, requires a transport protocol 346 providing an unreliable datagram service, like UDP or DCCP). In 347 practice FEC Source Packets can be sent as soon as available, without 348 having to wait for FEC encoding to take place. In that case a copy 349 of the associated source symbols need to be kept within FECFRAME for 350 future FEC encoding purposes. 352 At a receiver (not shown), FECFRAME processing operates in a similar 353 way, taking as input the incoming FEC source and repair packets 354 received. In case of FEC source packet losses, when the FEC decoding 355 of the associated block recovers all the missing source symbols, the 356 lost ADUs are recovered and assigned to their respective flow (see 357 below). ADUs are then returned to the application(s), either in 358 order or not depending on the application requirements. 360 FECFRAME features two subtle mechanisms: 362 o ADUs to source symbols mapping: in order to manage variable size 363 ADUs, FECFRAME and FEC Schemes can use small, fixed size, symbols 364 and create a mapping between ADUs and symbols. To each ADU this 365 mechanism prepends a length field (plus a flow identifier, see 366 below) and pads the result to a multiple of the symbol size. A 367 small ADU may be mapped to a single source symbol while a large 368 one may be mapped to multiple symbols. The mapping details are 369 FEC Scheme dependant and must be defined there. 371 o Assignment of decoded ADUs to flows in multi-flow configurations: 372 when multiple flows are multiplexed over the same FECFRAME 373 instance, a problem is to assign a decoded ADU to the right flow 374 (UDP port numbers/IP addresses traditionally used to map incoming 375 ADUs to flows are not recovered during FEC decoding). To make it 376 possible, at the FECFRAME sending instance, each ADU is prepended 377 with a flow identifier (1 byte) before doing the mapping to source 378 symbols (see above). This (flow ID + length + application payload 379 + padding), called ADUI, is then FEC protected. Therefore a 380 decoded ADUI contains enough information to assign the ADU to the 381 right flow. 383 A few aspects are not considered by FECFRAME, namely: 385 o congestion control (see [RFC6363], section 8 for a more detailed 386 discussion); 388 o feedbacks from receiver(s) (although they may exist within the 389 application, e.g., through RCTP control messages); 391 o flow adaptation at a FECFRAME sender (e.g., by adjusting the FEC 392 code rate based on channel conditions, since there is no feedback 393 mechanism within FECFRAME); 395 4. Procedural Overview 397 4.1. General 399 The general considerations of [RFC6363], Section 4.1, that are 400 specific to block FEC codes are not repeated here. 402 With a Sliding Window FEC Code, the FEC source packet MUST contain 403 information to identify the position occupied by the ADU within the 404 source flow, in terms specific to the FEC scheme. This information 405 is known as the Source FEC Payload ID, and the FEC scheme is 406 responsible for defining and interpreting it. 408 With a Sliding Window FEC Code, the FEC repair packets MUST contain 409 information that identifies the relationship between the contained 410 repair payloads and the original source symbols used during encoding. 411 This information is known as the Repair FEC Payload ID, and the FEC 412 scheme is responsible for defining and interpreting it. 414 The Sender Operation ([RFC6363], Section 4.2.) and Receiver Operation 415 ([RFC6363], Section 4.3) are both specific to block FEC codes and 416 therefore omitted below. The following two sections detail similar 417 operations for Sliding Window FEC codes. 419 4.2. Sender Operation with Sliding Window FEC Codes 421 With a Sliding Window FEC scheme, the following operations, 422 illustrated in Figure 2 for the case of UDP repair flows, and in 423 Figure 3 for the case of RTP repair flows, describe a possible way to 424 generate compliant source and repair flows: 426 1. A new ADU is provided by the application. 428 2. The FEC Framework communicates this ADU to the FEC scheme. 430 3. The sliding encoding window is updated by the FEC scheme. The 431 ADU to source symbols mapping as well as the encoding window 432 management details are both the responsibility of the FEC scheme 433 and MUST be detailed there. Appendix A provides some hints on 434 the way it might be performed. 436 4. The Source FEC Payload ID information of the source packet is 437 determined by the FEC scheme. If required by the FEC scheme, 438 the Source FEC Payload ID is encoded into the Explicit Source 439 FEC Payload ID field and returned to the FEC Framework. 441 5. The FEC Framework constructs the FEC source packet according to 442 [RFC6363] Figure 6, using the Explicit Source FEC Payload ID 443 provided by the FEC scheme if applicable. 445 6. The FEC source packet is sent using normal transport-layer 446 procedures. This packet is sent using the same ADU flow 447 identification information as would have been used for the 448 original source packet if the FEC Framework were not present 449 (for example, in the UDP case, the UDP source and destination 450 addresses and ports on the IP datagram carrying the source 451 packet will be the same whether or not the FEC Framework is 452 applied). 454 7. When the FEC Framework needs to send one or several FEC repair 455 packets (e.g., according to the target Code Rate), it asks the 456 FEC scheme to create one or several repair packet payloads from 457 the current sliding encoding window along with their Repair FEC 458 Payload ID. 460 8. The Repair FEC Payload IDs and repair packet payloads are 461 provided back by the FEC scheme to the FEC Framework. 463 9. The FEC Framework constructs FEC repair packets according to 464 [RFC6363] Figure 7, using the FEC Payload IDs and repair packet 465 payloads provided by the FEC scheme. 467 10. The FEC repair packets are sent using normal transport-layer 468 procedures. The port(s) and multicast group(s) to be used for 469 FEC repair packets are defined in the FEC Framework 470 Configuration Information. 472 +----------------------+ 473 | Application | 474 +----------------------+ 475 | 476 | (1) New Application Data Unit (ADU) 477 v 478 +---------------------+ +----------------+ 479 | FEC Framework | | FEC Scheme | 480 | |-------------------------->| | 481 | | (2) New ADU |(3) Update of | 482 | | | encoding | 483 | |<--------------------------| window | 484 |(5) Construct FEC | (4) Explicit Source | | 485 | source packet | FEC Payload ID(s) |(7) FEC | 486 | |<--------------------------| encoding | 487 |(9) Construct FEC | (8) Repair FEC Payload ID | | 488 | repair packet(s) | + Repair symbol(s) +----------------+ 489 +---------------------+ 490 | 491 | (6) FEC source packet 492 | (10) FEC repair packets 493 v 494 +----------------------+ 495 | Transport Layer | 496 | (e.g., UDP) | 497 +----------------------+ 499 Figure 2: Sender Operation with Convolutional FEC Codes 501 +----------------------+ 502 | Application | 503 +----------------------+ 504 | 505 | (1) New Application Data Unit (ADU) 506 v 507 +---------------------+ +----------------+ 508 | FEC Framework | | FEC Scheme | 509 | |-------------------------->| | 510 | | (2) New ADU |(3) Update of | 511 | | | encoding | 512 | |<--------------------------| window | 513 |(5) Construct FEC | (4) Explicit Source | | 514 | source packet | FEC Payload ID(s) |(7) FEC | 515 | |<--------------------------| encoding | 516 |(9) Construct FEC | (8) Repair FEC Payload ID | | 517 | repair packet(s) | + Repair symbol(s) +----------------+ 518 +---------------------+ 519 | | 520 |(6) Source |(10) Repair payloads 521 | packets | 522 | + -- -- -- -- -+ 523 | | RTP | 524 | +-- -- -- -- --+ 525 v v 526 +----------------------+ 527 | Transport Layer | 528 | (e.g., UDP) | 529 +----------------------+ 531 Figure 3: Sender Operation with RTP Repair Flows 533 4.3. Receiver Operation with Sliding Window FEC Codes 535 With a Sliding Window FEC scheme, the following operations, 536 illustrated in Figure 4 for the case of UDP repair flows, and in 537 Figure 5 for the case of RTP repair flows. The only differences with 538 respect to block FEC codes lie in steps (4) and (5). Therefore this 539 section does not repeat the other steps of [RFC6363], Section 4.3, 540 "Receiver Operation". The new steps (4) and (5) are: 542 4. The FEC scheme uses the received FEC Payload IDs (and derived FEC 543 Source Payload IDs when the Explicit Source FEC Payload ID field 544 is not used) to insert source and repair packets into the 545 decoding window in the right way. If at least one source packet 546 is missing and at least one repair packet has been received and 547 the rank of the associated linear system permits it, then FEC 548 decoding can be performed in order to recover missing source 549 payloads. The FEC scheme determines whether source packets have 550 been lost and whether enough repair packets have been received to 551 decode any or all of the missing source payloads. 553 5. The FEC scheme returns the received and decoded ADUs to the FEC 554 Framework, along with indications of any ADUs that were missing 555 and could not be decoded. 557 +----------------------+ 558 | Application | 559 +----------------------+ 560 ^ 561 |(6) ADUs 562 | 563 +----------------------+ +----------------+ 564 | FEC Framework | | FEC Scheme | 565 | |<--------------------------| | 566 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding 567 | IDs and pass IDs & |-------------------------->| | 568 | payloads to FEC |(3) Explicit Source FEC +----------------+ 569 | scheme | Payload IDs 570 +----------------------+ Repair FEC Payload IDs 571 ^ Source payloads 572 | Repair payloads 573 |(1) FEC source 574 | and repair packets 575 +----------------------+ 576 | Transport Layer | 577 | (e.g., UDP) | 578 +----------------------+ 580 Figure 4: Receiver Operation with Sliding Window FEC Codes 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 |Source pkts |Repair payloads 599 | | 600 +-- |- -- -- -- -- -- -+ 601 |RTP| | RTP Processing | 602 | | +-- -- -- --|-- -+ 603 | +-- -- -- -- -- |--+ | 604 | | RTP Demux | | 605 +-- -- -- -- -- -- -- -+ 606 ^ 607 |(1) FEC source and repair packets 608 | 609 +----------------------+ 610 | Transport Layer | 611 | (e.g., UDP) | 612 +----------------------+ 614 Figure 5: Receiver Operation with RTP Repair Flows 616 5. Protocol Specification 618 5.1. General 620 This section discusses the protocol elements for the FEC Framework 621 specific to Sliding Window FEC schemes. The global formats of source 622 data packets (i.e., [RFC6363], Figure 6) and repair data packets 623 (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding 624 Window FEC codes. They are not repeated here. 626 5.2. FEC Framework Configuration Information 628 The FEC Framework Configuration Information considerations of 629 [RFC6363], Section 5.5, equally applies to this FECFRAME extension 630 and is not repeated here. 632 5.3. FEC Scheme Requirements 634 The FEC scheme requirements of [RFC6363], Section 5.6, mostly apply 635 to this FECFRAME extension and are not repeated here. An exception 636 though is the "full specification of the FEC code", item (4), that is 637 specific to block FEC codes. The following item (4) applies instead: 639 4. A full specification of the Sliding Window FEC code 641 This specification MUST precisely define the valid FEC-Scheme- 642 Specific Information values, the valid FEC Payload ID values, and 643 the valid packet payload sizes (where packet payload refers to 644 the space within a packet dedicated to carrying encoding 645 symbols). 647 Furthermore, given valid values of the FEC-Scheme-Specific 648 Information, a valid Repair FEC Payload ID value, a valid packet 649 payload size, and a valid encoding window (i.e., a set of source 650 symbols), the specification MUST uniquely define the values of 651 the encoding symbols to be included in the repair packet payload 652 with the given Repair FEC Payload ID value. 654 Additionally, the FEC scheme associated to a Sliding Window FEC Code: 656 o MUST define the relationships between ADUs and the associated 657 source symbols (mapping); 659 o MUST define the management of the encoding window that slides over 660 the set of ADUs. Appendix A provides a non normative example; 662 o MUST define the management of the decoding window, consisting of a 663 system of linear equations (in case of a linear FEC code); 665 6. Feedback 667 The discussion of [RFC6363], Section 6, equally applies to this 668 FECFRAME extension and is not repeated here. 670 7. Transport Protocols 672 The discussion of [RFC6363], Section 7, equally applies to this 673 FECFRAME extension and is not repeated here. 675 8. Congestion Control 677 The discussion of [RFC6363], Section 8, equally applies to this 678 FECFRAME extension and is not repeated here. 680 9. Implementation Status 682 Editor's notes: RFC Editor, please remove this section motivated by 683 RFC 7942 before publishing the RFC. Thanks! 685 An implementation of FECFRAME extended to Sliding Window codes 686 exists: 688 o Organisation: Inria 690 o Description: This is an implementation of FECFRAME extended to 691 Sliding Window codes and supporting the RLC FEC Scheme [RLC-ID]. 692 It is based on: (1) a proprietary implementation of FECFRAME, made 693 by Inria and Expway for which interoperability tests have been 694 conducted; and (2) a proprietary implementation of RLC Sliding 695 Window FEC Codes. 697 o Maturity: the basic FECFRAME maturity is "production", the 698 FECFRAME extension maturity is "under progress". 700 o Coverage: the software implements a subset of [RFC6363], as 701 specialized by the 3GPP eMBMS standard [MBMSTS]. This software 702 also covers the additional features of FECFRAME extended to 703 Sliding Window codes, in particular the RLC FEC Scheme. 705 o Lincensing: proprietary. 707 o Implementation experience: maximum. 709 o Information update date: March 2017. 711 o Contact: vincent.roca@inria.fr 713 10. Security Considerations 715 This FECFRAME extension does not add any new security consideration. 716 All the considerations of [RFC6363], Section 9, apply to this 717 document as well. 719 11. Operations and Management Considerations 721 This FECFRAME extension does not add any new Operations and 722 Management Consideration. All the considerations of [RFC6363], 723 Section 10, apply to this document as well. 725 12. IANA Considerations 727 A FEC scheme for use with this FEC Framework is identified via its 728 FEC Encoding ID. It is subject to IANA registration in the "FEC 729 Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of 730 [RFC6363], Section 11, apply and are not repeated here. 732 13. Acknowledgments 734 TBD 736 14. References 738 14.1. Normative References 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 742 RFC2119, March 1997, 743 . 745 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 746 Correction (FEC) Framework", RFC 6363, DOI 10.17487/ 747 RFC6363, October 2011, 748 . 750 14.2. Informative References 752 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 753 Protocols and codecs", 3GPP TS 26.346, March 2009, 754 . 756 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 757 Correction (FEC) Building Block", RFC 5052, DOI 10.17487/ 758 RFC5052, August 2007, 759 . 761 [RFC6364] Begen, A., "Session Description Protocol Elements for the 762 Forward Error Correction (FEC) Framework", RFC 6364, DOI 763 10.17487/RFC6364, October 2011, 764 . 766 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 767 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 768 DOI 10.17487/RFC6681, August 2012, 769 . 771 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 772 Parity Check (LDPC) Staircase Forward Error Correction 773 (FEC) Scheme for FECFRAME", RFC 6816, DOI 10.17487/ 774 RFC6816, December 2012, 775 . 777 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 778 Matsuzono, "Simple Reed-Solomon Forward Error Correction 779 (FEC) Scheme for FECFRAME", RFC 6865, DOI 10.17487/ 780 RFC6865, February 2013, 781 . 783 [RLC-ID] Roca, V., "The Sliding Window Random Linear Code (RLC) 784 Forward Erasure Correction (FEC) Scheme for FECFRAME", 785 Work in Progress, Transport Area Working Group (TSVWG) 786 draft-roca-tsvwg-rlc-fec-scheme (Work in Progress), June 787 2017, . 790 Appendix A. About Sliding Encoding Window Management (non Normative) 792 The FEC Framework does not specify the management of the sliding 793 encoding window which is the responsibility of the FEC Scheme. This 794 annex provides a few hints with respect to the management of this 795 encoding window. 797 Source symbols are added to the sliding encoding window each time a 798 new ADU arrives, where the following information is provided for this 799 ADU by the FEC Framework: a description of the source flow with which 800 the ADU is associated, the ADU itself, and the length of the ADU. 801 This information is sufficient for the FEC scheme to map the ADU to 802 the corresponding source symbols. 804 Source symbols and the corresponding ADUs are removed from the 805 sliding encoding window, for instance: 807 o after a certain delay, when an "old" ADU of a real-time flow times 808 out. The source symbol retention delay in the sliding encoding 809 window should therefore be initialized according to the real-time 810 features of incoming flow(s). 812 o once the sliding encoding window has reached its maximum size 813 (there is usually an upper limit to the sliding encoding window 814 size). In that case the oldest symbol is removed each time a new 815 source symbol is added. 817 Several aspects exist that can impact the sliding encoding window 818 management: 820 o at the source flows level: real-time constraints can limit the 821 total time source symbols can remain in the encoding window; 823 o at the FEC code level: there may be theoretical or practical 824 limitations (e.g., because of computational complexity) that limit 825 the number of source symbols in the encoding window. 827 o at the FEC scheme level: signaling and window management are 828 intrinsically related. For instance, an encoding window composed 829 of a non sequential set of source symbols requires an appropriate 830 signaling to inform a receiver of the composition of the encoding 831 window. On the opposite, an encoding window always composed of a 832 sequential set of source symbols simplifies signaling: providing 833 the identity of the first source symbol plus their number is 834 sufficient. 836 Authors' Addresses 838 Vincent Roca 839 INRIA 840 Grenoble 841 France 843 EMail: vincent.roca@inria.fr 845 Ali Begen 846 Networked Media 847 Konya 848 Turkey 850 EMail: ali.begen@networked.media