idnits 2.17.1 draft-ietf-tsvwg-fecframe-ext-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6363, but the abstract doesn't seem to directly say this. It does mention RFC6363 though, so this could be OK. 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 (September 19, 2018) is 2018 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 (==), 3 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: March 23, 2019 September 19, 2018 8 Forward Error Correction (FEC) Framework Extension to Sliding Window 9 Codes 10 draft-ietf-tsvwg-fecframe-ext-06 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. The present document updates FECFRAME to support FEC Codes 20 based on a sliding encoding window, in addition to Block FEC Codes, 21 in a 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 March 23, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 18 82 Appendix A. About Sliding Encoding Window Management (non 83 Normative) . . . . . . . . . . . . . . . . . . . . . 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 transports 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. This approach 124 has major impacts on FEC encoding and decoding delays. The data 125 packets of continuous media flow(s) may be passed to the transport 126 layer immediately, without delay. But the block creation time, that 127 depends on the number of source symbols in this block, impacts both 128 the FEC encoding delay (since encoding requires that all source 129 symbols be known), and mechanically the packet loss recovery delay at 130 a receiver (since no repair symbol for the current block can be 131 generated and therefore received before that time). Therefore a good 132 value for the block size is necessarily a balance between the maximum 133 FEC decoding latency at the receivers (which must be in line with the 134 most stringent real-time requirement of the protected flow(s), hence 135 an incentive to reduce the block size), and the desired robustness 136 against long loss bursts (which increases with the block size, hence 137 an incentive to increase this size). 139 This document updates [RFC6363] in order to also support FEC codes 140 based on a sliding encoding window (A.K.A. convolutional codes) 141 [RFC8406]. This encoding window, either of fixed or variable size, 142 slides over the set of source symbols. FEC encoding is launched 143 whenever needed, from the set of source symbols present in the 144 sliding encoding window at that time. This approach significantly 145 reduces FEC-related latency, since repair symbols can be generated 146 and passed to the transport layer on-the-fly, at any time, and can be 147 regularly received by receivers to quickly recover packet losses. 148 Using sliding window FEC codes is therefore highly beneficial to 149 real-time flows, one of the primary targets of FECFRAME. [RLC-ID] 150 provides an example of such FEC Scheme for FECFRAME, built upon the 151 simple sliding window Random Linear Codes (RLC). 153 This document is fully backward compatible with [RFC6363]. Indeed: 155 o this extension does not prevent nor compromise 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. This is made possible with the FEC Encoding ID 162 that identifies the FEC Scheme used and which is carried in the 163 FEC Framework Configuration Information (see section 5.5 of 164 [RFC6363]). For instance, when the Session Description Protocol 165 (SDP) is used to carry the FEC Framework Configuration 166 Information, the FEC Encoding ID can be communicated in the 167 "encoding-id=" parameter of a "fec-repair-flow" attribute 168 [RFC6364]. This mechanism is the basic approach for a FECFRAME 169 receiver to determine whether or not it supports the FEC Scheme 170 used in a given FECFRAME session; 172 This document leverages on [RFC6363] and re-uses its structure. It 173 proposes new sections specific to sliding window FEC codes whenever 174 required. The only exception is Section 3 that provides a quick 175 summary of FECFRAME in order to facilitate the understanding of this 176 document to readers not familiar with the concepts and terminology. 178 2. Definitions and Abbreviations 180 The following list of definitions and abbreviations is copied from 181 [RFC6363], adding only the Block/sliding window FEC Code and 182 Encoding/Decoding Window definitions (tagged with "ADDED"): 184 Application Data Unit (ADU): The unit of source data provided as 185 payload to the transport layer. 187 ADU Flow: A sequence of ADUs associated with a transport-layer flow 188 identifier (such as the standard 5-tuple {source IP address, 189 source port, destination IP address, destination port, transport 190 protocol}). 192 AL-FEC: Application-layer Forward Error Correction. 194 Application Protocol: Control protocol used to establish and control 195 the source flow being protected, e.g., the Real-Time Streaming 196 Protocol (RTSP). 198 Content Delivery Protocol (CDP): A complete application protocol 199 specification that, through the use of the framework defined in 200 this document, is able to make use of FEC schemes to provide FEC 201 capabilities. 203 FEC Code: An algorithm for encoding data such that the encoded data 204 flow is resilient to data loss. Note that, in general, FEC codes 205 may also be used to make a data flow resilient to corruption, but 206 that is not considered in this document. 208 Block FEC Code: (ADDED) An FEC Code that operates on blocks, i.e., 209 for which the input flow MUST be segmented into a sequence of 210 blocks, FEC encoding and decoding being performed independently 211 on a per-block basis. 213 Sliding Window FEC Code: (ADDED) An FEC Code that can generate 214 repair symbols on-the-fly, at any time, from the set of source 215 symbols present in the sliding encoding window at that time. 216 These codes are also known as convolutional codes. 218 FEC Framework: A protocol framework for the definition of Content 219 Delivery Protocols using FEC, such as the framework defined in 220 this document. 222 FEC Framework Configuration Information: Information that controls 223 the operation of the FEC Framework. 225 FEC Payload ID: Information that identifies the contents of a packet 226 with respect to the FEC Scheme. 228 FEC Repair Packet: At a sender (respectively, at a receiver), a 229 payload submitted to (respectively, received from) the transport 230 protocol containing one or more repair symbols along with a 231 Repair FEC Payload ID and possibly an RTP header. 233 FEC Scheme: A specification that defines the additional protocol 234 aspects required to use a particular FEC code with the FEC 235 Framework. 237 FEC Source Packet: At a sender (respectively, at a receiver), a 238 payload submitted to (respectively, received from) the transport 239 protocol containing an ADU along with an optional Explicit Source 240 FEC Payload ID. 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, using an unreliable datagram service 258 such as UDP. 260 Encoding Window: (ADDED) Set of Source Symbols available at the 261 sender/coding node that are used to generate a repair symbol, 262 with a Sliding Window FEC Code. 264 Decoding Window: (ADDED) Set of received or decoded source and 265 repair symbols available at a receiver that are used to decode 266 erased 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., in our case, by a congested router, or because 280 the number of transmission errors exceeds the correction 281 capabilities of the physical-layer code) or received. When a 282 packet is received, it is assumed that this packet is not 283 corrupted (i.e., in our case, the bit-errors, if any, are fixed 284 by the physical-layer code and therefore hidden to the upper 285 layers). 287 Repair Symbol: Encoding symbol that is not a source symbol. 289 Source Block: Group of ADUs that are to be FEC protected as a single 290 block. This notion is restricted to Block FEC Codes. 292 Source Symbol: Unit of data used during the encoding process. 294 Systematic Code: FEC code in which the source symbols are part of 295 the encoding symbols. 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 299 document are to be interpreted as described in [RFC2119]. 301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 303 "OPTIONAL" in this document are to be interpreted as described in BCP 304 14 [RFC2119] [RFC8174] when, and only when, they appear in all 305 capitals, as shown here. 307 3. Summary of Architecture Overview 309 The architecture of [RFC6363], Section 3, equally applies to this 310 FECFRAME extension and is not repeated here. However we provide 311 hereafter a quick summary to facilitate the understanding of this 312 document to readers not familiar with the concepts and terminology. 314 +----------------------+ 315 | Application | 316 +----------------------+ 317 | 318 | (1) Application Data Units (ADUs) 319 | 320 v 321 +----------------------+ +----------------+ 322 | FEC Framework | | | 323 | |-------------------------->| FEC Scheme | 324 |(2) Construct source |(3) Source Block | | 325 | blocks | |(4) FEC Encoding| 326 |(6) Construct FEC |<--------------------------| | 327 | Source and Repair | | | 328 | Packets |(5) Explicit Source FEC | | 329 +----------------------+ Payload IDs +----------------+ 330 | Repair FEC Payload IDs 331 | Repair symbols 332 | 333 |(7) FEC Source and Repair Packets 334 v 335 +----------------------+ 336 | Transport Protocol | 337 +----------------------+ 339 Figure 1: FECFRAME architecture at a sender. 341 The FECFRAME architecture is illustrated in Figure 1 from the 342 sender's point of view, in case of a block FEC Scheme. It shows an 343 application generating an ADU flow (other flows, from other 344 applications, may co-exist). These ADUs, of variable size, must be 345 somehow mapped to source symbols of fixed size. This is the goal of 346 an ADU to symbols mapping process that is FEC Scheme specific (see 347 below). Once the source block is built, taking into account both the 348 FEC Scheme constraints (e.g., in terms of maximum source block size) 349 and the application's flow constraints (e.g., in terms of real-time 350 constraints), the associated source symbols are handed to the FEC 351 Scheme in order to produce an appropriate number of repair symbols. 352 FEC Source Packets (containing ADUs) and FEC Repair Packets 353 (containing one or more repair symbols each) are then generated and 354 sent using an appropriate transport protocol (more precisely 355 [RFC6363], Section 7, requires a transport protocol providing an 356 unreliable datagram service, such as UDP). In practice FEC Source 357 Packets may be passed to the transport layer as soon as available, 358 without having to wait for FEC encoding to take place. In that case 359 a copy of the associated source symbols needs to be kept within 360 FECFRAME for future FEC encoding purposes. 362 At a receiver (not shown), FECFRAME processing operates in a similar 363 way, taking as input the incoming FEC Source and Repair Packets 364 received. In case of FEC Source Packet losses, the FEC decoding of 365 the associated block may recover all (in case of successful decoding) 366 or a subset potentially empty (otherwise) of the missing source 367 symbols. After source symbol to ADU mapping, when lost ADUs are 368 recovered, they are then assigned to their respective flow (see 369 below). ADUs are returned to the application(s), either in their 370 initial transmission order (in that case ADUs received after an 371 erased one will be delayed until FEC decoding has taken place) or not 372 (in that case each ADU is returned as soon as it is received or 373 recovered), depending on the application requirements. 375 FECFRAME features two subtle mechanisms: 377 o ADUs to source symbols mapping: in order to manage variable size 378 ADUs, FECFRAME and FEC Schemes can use small, fixed size symbols 379 and create a mapping between ADUs and symbols. To each ADU this 380 mechanism prepends a length field (plus a flow identifier, see 381 below) and pads the result to a multiple of the symbol size. A 382 small ADU may be mapped to a single source symbol while a large 383 one may be mapped to multiple symbols. The mapping details are 384 FEC Scheme dependant and must be defined in the associated 385 document; 387 o Assignment of decoded ADUs to flows in multi-flow configurations: 388 when multiple flows are multiplexed over the same FECFRAME 389 instance, a problem is to assign a decoded ADU to the right flow 390 (UDP port numbers and IP addresses traditionally used to map 391 incoming ADUs to flows are not recovered during FEC decoding). To 392 make it possible, at the FECFRAME sending instance, each ADU is 393 prepended with a flow identifier (1 byte) during the ADU to source 394 symbols mapping (see above). The flow identifiers are also shared 395 between all FECFRAME instances as part of the FEC Framework 396 Configuration Information. This (flow identifier + length + 397 application payload + padding), called ADUI, is then FEC 398 protected. Therefore a decoded ADUI contains enough information 399 to assign the ADU to the right flow. 401 A few aspects are not covered by FECFRAME, namely: 403 o [RFC6363] section 8 does not detail any congestion control 404 mechanism, but only provides high level normative requirements; 406 o the possibility of having feedbacks from receiver(s) is considered 407 out of scope, although such a mechanism may exist within the 408 application (e.g., through RCTP control messages); 410 o flow adaptation at a FECFRAME sender (e.g., how to set the FEC 411 code rate based on transmission conditions) is not detailed, but 412 it needs to comply with the congestion control normative 413 requirements (see above). 415 4. Procedural Overview 417 4.1. General 419 The general considerations of [RFC6363], Section 4.1, that are 420 specific to block FEC codes are not repeated here. 422 With a Sliding Window FEC Code, the FEC Source Packet MUST contain 423 information to identify the position occupied by the ADU within the 424 source flow, in terms specific to the FEC Scheme. This information 425 is known as the Source FEC Payload ID, and the FEC Scheme is 426 responsible for defining and interpreting it. 428 With a Sliding Window FEC Code, the FEC Repair Packets MUST contain 429 information that identifies the relationship between the contained 430 repair payloads and the original source symbols used during encoding. 431 This information is known as the Repair FEC Payload ID, and the FEC 432 Scheme is responsible for defining and interpreting it. 434 The Sender Operation ([RFC6363], Section 4.2.) and Receiver Operation 435 ([RFC6363], Section 4.3) are both specific to block FEC codes and 436 therefore omitted below. The following two sections detail similar 437 operations for Sliding Window FEC codes. 439 4.2. Sender Operation with Sliding Window FEC Codes 441 With a Sliding Window FEC Scheme, the following operations, 442 illustrated in Figure 2 for the generic case (non-RTP repair flows), 443 and in Figure 3 for the case of RTP repair flows, describe a possible 444 way to generate compliant source and repair flows: 446 1. A new ADU is provided by the application. 448 2. The FEC Framework communicates this ADU to the FEC Scheme. 450 3. The sliding encoding window is updated by the FEC Scheme. The 451 ADU to source symbols mapping as well as the encoding window 452 management details are both the responsibility of the FEC Scheme 453 and MUST be detailed there. Appendix A provides non normative 454 hints about what FEC Scheme designers need to consider; 456 4. The Source FEC Payload ID information of the source packet is 457 determined by the FEC Scheme. If required by the FEC Scheme, 458 the Source FEC Payload ID is encoded into the Explicit Source 459 FEC Payload ID field and returned to the FEC Framework. 461 5. The FEC Framework constructs the FEC Source Packet according to 462 [RFC6363] Figure 6, using the Explicit Source FEC Payload ID 463 provided by the FEC Scheme if applicable. 465 6. The FEC Source Packet is sent using normal transport-layer 466 procedures. This packet is sent using the same ADU flow 467 identification information as would have been used for the 468 original source packet if the FEC Framework were not present 469 (e.g., the source and destination addresses and UDP port numbers 470 on the IP datagram carrying the source packet will be the same 471 whether or not the FEC Framework is applied). 473 7. When the FEC Framework needs to send one or several FEC Repair 474 Packets (e.g., according to the target Code Rate), it asks the 475 FEC Scheme to create one or several repair packet payloads from 476 the current sliding encoding window along with their Repair FEC 477 Payload ID. 479 8. The Repair FEC Payload IDs and repair packet payloads are 480 provided back by the FEC Scheme to the FEC Framework. 482 9. The FEC Framework constructs FEC Repair Packets according to 483 [RFC6363] Figure 7, using the FEC Payload IDs and repair packet 484 payloads provided by the FEC Scheme. 486 10. The FEC Repair Packets are sent using normal transport-layer 487 procedures. The port(s) and multicast group(s) to be used for 488 FEC Repair Packets are defined in the FEC Framework 489 Configuration Information. 491 +----------------------+ 492 | Application | 493 +----------------------+ 494 | 495 | (1) New Application Data Unit (ADU) 496 v 497 +---------------------+ +----------------+ 498 | FEC Framework | | FEC Scheme | 499 | |-------------------------->| | 500 | | (2) New ADU |(3) Update of | 501 | | | encoding | 502 | |<--------------------------| window | 503 |(5) Construct FEC | (4) Explicit Source | | 504 | Source Packet | FEC Payload ID(s) |(7) FEC | 505 | |<--------------------------| encoding | 506 |(9) Construct FEC | (8) Repair FEC Payload ID | | 507 | Repair Packet(s) | + Repair symbol(s) +----------------+ 508 +---------------------+ 509 | 510 | (6) FEC Source Packet 511 | (10) FEC Repair Packets 512 v 513 +----------------------+ 514 | Transport Protocol | 515 +----------------------+ 517 Figure 2: Sender Operation with Sliding Window FEC Codes 519 +----------------------+ 520 | Application | 521 +----------------------+ 522 | 523 | (1) New Application Data Unit (ADU) 524 v 525 +---------------------+ +----------------+ 526 | FEC Framework | | FEC Scheme | 527 | |-------------------------->| | 528 | | (2) New ADU |(3) Update of | 529 | | | encoding | 530 | |<--------------------------| window | 531 |(5) Construct FEC | (4) Explicit Source | | 532 | Source Packet | FEC Payload ID(s) |(7) FEC | 533 | |<--------------------------| encoding | 534 |(9) Construct FEC | (8) Repair FEC Payload ID | | 535 | Repair Packet(s) | + Repair symbol(s) +----------------+ 536 +---------------------+ 537 | | 538 |(6) Source |(10) Repair payloads 539 | packets | 540 | + -- -- -- -- -+ 541 | | RTP | 542 | +-- -- -- -- --+ 543 v v 544 +----------------------+ 545 | Transport Protocol | 546 +----------------------+ 548 Figure 3: Sender Operation with Sliding Window FEC Codes and RTP 549 Repair Flows 551 4.3. Receiver Operation with Sliding Window FEC Codes 553 With a Sliding Window FEC Scheme, the following operations, 554 illustrated in Figure 4 for the generic case (non-RTP repair flows), 555 and in Figure 5 for the case of RTP repair flows. The only 556 differences with respect to block FEC codes lie in steps (4) and (5). 557 Therefore this section does not repeat the other steps of [RFC6363], 558 Section 4.3, "Receiver Operation". The new steps (4) and (5) are: 560 4. The FEC Scheme uses the received FEC Payload IDs (and derived FEC 561 Source Payload IDs when the Explicit Source FEC Payload ID field 562 is not used) to insert source and repair packets into the 563 decoding window in the right way. If at least one source packet 564 is missing and at least one repair packet has been received and 565 the rank of the associated linear system permits it, then FEC 566 decoding can be performed in order to recover missing source 567 payloads. The FEC Scheme determines whether source packets have 568 been lost and whether enough repair packets have been received to 569 decode any or all of the missing source payloads. 571 5. The FEC Scheme returns the received and decoded ADUs to the FEC 572 Framework, along with indications of any ADUs that were missing 573 and could not be decoded. 575 +----------------------+ 576 | Application | 577 +----------------------+ 578 ^ 579 |(6) ADUs 580 | 581 +----------------------+ +----------------+ 582 | FEC Framework | | FEC Scheme | 583 | |<--------------------------| | 584 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding 585 | IDs and pass IDs & |-------------------------->| | 586 | payloads to FEC |(3) Explicit Source FEC +----------------+ 587 | scheme | Payload IDs 588 +----------------------+ Repair FEC Payload IDs 589 ^ Source payloads 590 | Repair payloads 591 |(1) FEC Source 592 | and Repair Packets 593 +----------------------+ 594 | Transport Protocol | 595 +----------------------+ 597 Figure 4: Receiver Operation with Sliding Window FEC Codes 599 +----------------------+ 600 | Application | 601 +----------------------+ 602 ^ 603 |(6) ADUs 604 | 605 +----------------------+ +----------------+ 606 | FEC Framework | | FEC Scheme | 607 | |<--------------------------| | 608 |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding| 609 | IDs and pass IDs & |-------------------------->| | 610 | payloads to FEC |(3) Explicit Source FEC +----------------+ 611 | scheme | Payload IDs 612 +----------------------+ Repair FEC Payload IDs 613 ^ ^ Source payloads 614 | | Repair payloads 615 |Source pkts |Repair payloads 616 | | 617 +-- |- -- -- -- -- -- -+ 618 |RTP| | RTP Processing | 619 | | +-- -- -- --|-- -+ 620 | +-- -- -- -- -- |--+ | 621 | | RTP Demux | | 622 +-- -- -- -- -- -- -- -+ 623 ^ 624 |(1) FEC Source and Repair Packets 625 | 626 +----------------------+ 627 | Transport Protocol | 628 +----------------------+ 630 Figure 5: Receiver Operation with Sliding Window FEC Codes and RTP 631 Repair Flows 633 5. Protocol Specification 635 5.1. General 637 This section discusses the protocol elements for the FEC Framework 638 specific to Sliding Window FEC schemes. The global formats of source 639 data packets (i.e., [RFC6363], Figure 6) and repair data packets 640 (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding 641 Window FEC codes. They are not repeated here. 643 5.2. FEC Framework Configuration Information 645 The FEC Framework Configuration Information considerations of 646 [RFC6363], Section 5.5, equally applies to this FECFRAME extension 647 and is not repeated here. 649 5.3. FEC Scheme Requirements 651 The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply 652 to this FECFRAME extension and are not repeated here. An exception 653 though is the "full specification of the FEC code", item (4), that is 654 specific to block FEC codes. The following item (4-bis) applies in 655 case of Sliding Window FEC schemes: 657 4-bis. A full specification of the Sliding Window FEC code 659 This specification MUST precisely define the valid FEC-Scheme- 660 Specific Information values, the valid FEC Payload ID values, and 661 the valid packet payload sizes (where packet payload refers to 662 the space within a packet dedicated to carrying encoding 663 symbols). 665 Furthermore, given valid values of the FEC-Scheme-Specific 666 Information, a valid Repair FEC Payload ID value, a valid packet 667 payload size, and a valid encoding window (i.e., a set of source 668 symbols), the specification MUST uniquely define the values of 669 the encoding symbol (or symbols) to be included in the repair 670 packet payload with the given Repair FEC Payload ID value. 672 Additionally, the FEC Scheme associated to a Sliding Window FEC Code: 674 o MUST define the relationships between ADUs and the associated 675 source symbols (mapping); 677 o MUST define the management of the encoding window that slides over 678 the set of ADUs. Appendix A provides non normative hints about 679 what FEC Scheme designers need to consider; 681 o MUST define the management of the decoding window, consisting of a 682 system of linear equations (in case of a linear FEC code); 684 6. Feedback 686 The discussion of [RFC6363], Section 6, equally applies to this 687 FECFRAME extension and is not repeated here. 689 7. Transport Protocols 691 The discussion of [RFC6363], Section 7, equally applies to this 692 FECFRAME extension and is not repeated here. 694 8. Congestion Control 696 The discussion of [RFC6363], Section 8, equally applies to this 697 FECFRAME extension and is not repeated here. 699 9. Implementation Status 701 Editor's notes: RFC Editor, please remove this section motivated by 702 RFC 7942 before publishing the RFC. Thanks! 704 An implementation of FECFRAME extended to Sliding Window codes 705 exists: 707 o Organisation: Inria 709 o Description: This is an implementation of FECFRAME extended to 710 Sliding Window codes and supporting the RLC FEC Scheme [RLC-ID]. 711 It is based on: (1) a proprietary implementation of FECFRAME, made 712 by Inria and Expway for which interoperability tests have been 713 conducted; and (2) a proprietary implementation of RLC Sliding 714 Window FEC Codes. 716 o Maturity: the basic FECFRAME maturity is "production", the 717 FECFRAME extension maturity is "under progress". 719 o Coverage: the software implements a subset of [RFC6363], as 720 specialized by the 3GPP eMBMS standard [MBMSTS]. This software 721 also covers the additional features of FECFRAME extended to 722 Sliding Window codes, in particular the RLC FEC Scheme. 724 o Lincensing: proprietary. 726 o Implementation experience: maximum. 728 o Information update date: March 2018. 730 o Contact: vincent.roca@inria.fr 732 10. Security Considerations 734 This FECFRAME extension does not add any new security consideration. 735 All the considerations of [RFC6363], Section 9, apply to this 736 document as well. 738 11. Operations and Management Considerations 740 This FECFRAME extension does not add any new Operations and 741 Management Consideration. All the considerations of [RFC6363], 742 Section 10, apply to this document as well. 744 12. IANA Considerations 746 No IANA actions are required for this document. 748 A FEC Scheme for use with this FEC Framework is identified via its 749 FEC Encoding ID. It is subject to IANA registration in the "FEC 750 Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of 751 [RFC6363], Section 11, apply and are not repeated here. 753 13. Acknowledgments 755 The authors would like to thank Christer Holmberg, David Black, Gorry 756 Fairhurst, and Emmanuel Lochin for their valuable feedbacks on this 757 document. This document being an extension to [RFC6363], the authors 758 would also like to thank Mark Watson as the main author this RFC. 760 14. References 762 14.1. Normative References 764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, 766 DOI 10.17487/RFC2119, March 1997, 767 . 769 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 770 Correction (FEC) Framework", RFC 6363, 771 DOI 10.17487/RFC6363, October 2011, 772 . 774 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 775 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 776 May 2017, . 778 14.2. Informative References 780 [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 781 Protocols and codecs", 3GPP TS 26.346, March 2009, 782 . 784 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 785 Correction (FEC) Building Block", RFC 5052, 786 DOI 10.17487/RFC5052, August 2007, 787 . 789 [RFC6364] Begen, A., "Session Description Protocol Elements for the 790 Forward Error Correction (FEC) Framework", RFC 6364, 791 DOI 10.17487/RFC6364, October 2011, 792 . 794 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 795 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 796 DOI 10.17487/RFC6681, August 2012, 797 . 799 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 800 Parity Check (LDPC) Staircase Forward Error Correction 801 (FEC) Scheme for FECFRAME", RFC 6816, 802 DOI 10.17487/RFC6816, December 2012, 803 . 805 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 806 Matsuzono, "Simple Reed-Solomon Forward Error Correction 807 (FEC) Scheme for FECFRAME", RFC 6865, 808 DOI 10.17487/RFC6865, February 2013, 809 . 811 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 812 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 813 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 814 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 815 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 816 June 2018, . 818 [RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 819 (RLC) Forward Erasure Correction (FEC) Scheme for 820 FECFRAME", Work in Progress, Transport Area Working Group 821 (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in 822 Progress), September 2018, . 825 Appendix A. About Sliding Encoding Window Management (non Normative) 827 The FEC Framework does not specify the management of the sliding 828 encoding window which is the responsibility of the FEC Scheme. This 829 annex only provides a few non normative hints. 831 Source symbols are added to the sliding encoding window each time a 832 new ADU is available at the sender, after the ADU to source symbol 833 mapping specific to the FEC Scheme. 835 Source symbols are removed from the sliding encoding window, for 836 instance: 838 o after a certain delay, when an "old" ADU of a real-time flow times 839 out. The source symbol retention delay in the sliding encoding 840 window should therefore be initialized according to the real-time 841 features of incoming flow(s) when applicable; 843 o once the sliding encoding window has reached its maximum size 844 (there is usually an upper limit to the sliding encoding window 845 size). In that case the oldest symbol is removed each time a new 846 source symbol is added. 848 Several considerations can impact the management of this sliding 849 encoding window: 851 o at the source flows level: real-time constraints can limit the 852 total time source symbols can remain in the encoding window; 854 o at the FEC code level: theoretical or practical limitations (e.g., 855 because of computational complexity) can limit the number of 856 source symbols in the encoding window; 858 o at the FEC Scheme level: signaling and window management are 859 intrinsically related. For instance, an encoding window composed 860 of a non sequential set of source symbols requires an appropriate 861 signaling to inform a receiver of the composition of the encoding 862 window, and the associated transmission overhead can limit the 863 maximum encoding window size. On the opposite, an encoding window 864 always composed of a sequential set of source symbols simplifies 865 signaling: providing the identity of the first source symbol plus 866 their number is sufficient, which creates a fixed and relatively 867 small transmission overhead. 869 Authors' Addresses 871 Vincent Roca 872 INRIA 873 Univ. Grenoble Alpes 874 France 876 EMail: vincent.roca@inria.fr 878 Ali Begen 879 Networked Media 880 Konya 881 Turkey 883 EMail: ali.begen@networked.media