idnits 2.17.1 draft-roca-nwcrg-fecframev2-problem-position-03.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 (November 14, 2016) is 2720 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 IRTF Network Coding Research Group (NWCRG) V. Roca 3 Internet-Draft INRIA 4 Intended status: Informational November 14, 2016 5 Expires: May 18, 2017 7 FECFRAMEv2: Adding Sliding Encoding Window Capabilities to the FEC 8 Framework: Problem Position 9 draft-roca-nwcrg-fecframev2-problem-position-03 11 Abstract 13 The Forward Error Correction (FEC) Framework (or FECFRAME) (RFC 6363) 14 has been defined by the FECFRAME IETF WG to enable the use of FEC 15 Encoding with real-time flows in a flexible manner. The original 16 FECFRAME specification only considers the use of block FEC codes, 17 wherein the input flow(s) is(are) segmented into a sequence of blocks 18 and FEC encoding performed independently on a per-block basis. This 19 document discusses an extension of FECFRAME in order to enable a 20 sliding (potentially elastic) window encoding of the input flow(s), 21 using convolutional FEC codes for the erasure channel, as an 22 alternative to block FEC codes. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 18, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notations, Definitions and Abbreviations . . . . . . . . . . 4 60 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 61 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Key features of FECFRAME . . . . . . . . . . . . . . . . . . 5 63 3.1. FECFRAME is more a shim layer than a protocol 64 instantiation . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. FECFRAME is highly flexible . . . . . . . . . . . . . . . 6 66 3.3. Details are in each FEC Scheme . . . . . . . . . . . . . 6 67 3.4. FECFRAME needs session-level description . . . . . . . . 7 68 4. Application of FECFRAME (RFC 6363) to network coding use- 69 cases: a discussion . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Block versus convolutional codes . . . . . . . . . . . . 7 71 4.2. End-to-end versus in-network re-coding . . . . . . . . . 8 72 4.3. Single versus multi-sources, intra versus inter-flows 73 coding . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.4. Single versus multi-paths . . . . . . . . . . . . . . . . 8 75 5. Architectural considerations for FECFRAMEv2 . . . . . . . . . 9 76 5.1. FECFRAMEv2 in sliding encoding window mode . . . . . . . 9 77 5.2. ADU(I) to source symbol mapping . . . . . . . . . . . . . 11 78 5.3. Sliding encoding window management . . . . . . . . . . . 12 79 5.4. Encoding Symbol Identifiers (ESI) . . . . . . . . . . . . 13 80 5.5. Block and convolutional co-existence in a given 81 FECFRAMEv2 session . . . . . . . . . . . . . . . . . . . 14 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 10.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The Forward Error Correction (FEC) Framework (or FECFRAME) [RFC6363], 94 produced by the FECFRAME IETF WG [fecframe-charter], describes a 95 framework for using Forward Error Correction (FEC) codes with 96 applications in public and private IP networks to provide protection 97 against packet loss. The framework supports applying FEC to 98 arbitrary packet flows over unreliable transport and is primarily 99 intended for real-time, or streaming, media. This framework can be 100 used to define Content Delivery Protocols that provide FEC for 101 streaming media delivery or other packet flows. Content Delivery 102 Protocols defined using this framework can support any FEC scheme 103 (and associated FEC codes) that is compliant with various 104 requirements defined in [RFC6363]. Thus, Content Delivery Protocols 105 can be defined that are not specific to a particular FEC scheme, and 106 FEC schemes can be defined that are not specific to a particular 107 Content Delivery Protocol. 109 However, it is REQUIRED in [RFC6363] that the FEC scheme operate in a 110 block manner, i.e., the input flow(s) MUST be segmented into a 111 sequence of blocks, and FEC encoding (at a sender/coding node) and 112 decoding (at a receiver/decoding node) MUST be performed 113 independently on a per-block basis. This approach has a major impact 114 on coding and decoding delays when used with block FEC codes (e.g., 115 [RFC6681], [RFC6816] or [RFC6865]) since encoding requires that all 116 the source symbols be known at the encoder. In case of continuous 117 input flow(s), even if source symbols can be sent immediately, repair 118 symbols are necessarily delayed by the block creation time, that 119 directly depends on the block size (i.e., the number of source 120 symbols in this block, k). This block creation time is also the 121 minimum decoding latency any receiver will experience in case of 122 erasures, since no repair symbol for the current block can be 123 received before. A good value for the block size is necessarily a 124 good balance between the minimum decoding latency at the receivers 125 (which must be in line with the most stringent real-time requirement 126 of the flow(s)) and the desired robustness in front of long erasure 127 bursts (which depends on the block size). 129 On the opposite, a convolutional code associated to a sliding 130 encoding window (of fixed size) or a sliding elastic encoding window 131 (of variable size) removes this minimum decoding delay, since repair 132 symbols can be generated and sent on-the-fly, at any time, from the 133 source symbols present in the current encoding window. Using a 134 sliding encoding window mode is therefore highly beneficial to real- 135 time flows, one of the primary targets of FECFRAME. 137 The present document introduces the FECFRAME framework specificities, 138 its limits, and options to extend it to sliding (optionally elastic) 139 encoding windows and convolutional codes. 141 2. Notations, Definitions and Abbreviations 143 2.1. Requirements Notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2.2. Definitions 151 This document uses the following definitions, that are mostly 152 inspired from [RFC5052], [RFC6363] and [nc-taxonomy-id]. 154 Packet Erasure Channel: 156 a communication path where packets are either dropped (e.g., by a 157 congested router or because the number of transmission errors 158 exceeds the correction capabilities of the physical layer codes) 159 or received. When a packet is received, it is assumed that this 160 packet is not corrupted 162 Systematic Code: 164 code in which the Source Symbols are part of the Output Symbols 166 Input Symbol: 168 a unit of data that is provided as an input to the coding process, 169 in a given coding node. It may be a source symbol or an already 170 encoded repair symbol if in-network re-coding is considered 172 Output Symbol: 174 a unit of data that is produced as an output of the coding 175 process, in a given coding node 177 Application Data Unit (ADU): 179 The unit of source data provided as payload to the transport 180 layer. Depending on the use-case, an ADU may use an RTP 181 encapsulation. 183 ADU Information (ADUI): 185 a unit of data constituted by the ADU and the associated Flow ID, 186 Length and Padding fields (Section 5.2). 188 Source Symbol: 190 an original unit of data, before any coding process is applied. 191 Source symbols are the result of the fragmentation of ADUIs. 193 Repair Symbol: 195 an Output Symbol that is not a Source Symbol. 197 FEC Source Packet: 199 At a sender (respectively, at a receiver) a payload submitted to 200 (respectively, received from) the transport protocol containing an 201 ADU along with an Explicit Source FEC Payload ID (if present). 203 FEC Repair Packet: 205 At a sender (respectively, at a receiver) a payload submitted to 206 (respectively, received from) the transport protocol containing a 207 repair symbol (or several repair symbols with certain FEC Schemes) 208 along with a Repair FEC Payload ID (and possibly an RTP header in 209 some cases). 211 (Source) ADU Flow: 213 A sequence of ADUs associated with a transport-layer flow 214 identifier (such as the standard 5-tuple {Source IP address, 215 source port, destination IP address, destination port, transport 216 protocol}). Depending on the use-case, several ADU flows may be 217 protected together by the FECFRAME framework. 219 FEC Source Packet Flow: 221 A sequence of FEC Source Packets. 223 FEC Repair Packet Flow: 225 A sequence of FEC Repair Packets. 227 FEC Framework Configuration Information (FFCI): 229 Information which controls the operation of the FEC Framework. 230 The FFCI enables the synchronization of the FECFRAME sender and 231 receiver instances. 233 3. Key features of FECFRAME 234 3.1. FECFRAME is more a shim layer than a protocol instantiation 236 FECFRAME is not a full featured Protocol Instantiation (unlike ALC 237 [RFC5775] and NORM [RFC5740] for instance). It is more a shim layer, 238 or more precisely a framework for using FEC inside existing transport 239 protocols. For instance when FECFRAME is used end-to-end inside a 240 single RTP/UDP stream (the simplest use-case), RTP [RFC3550] and UDP 241 are the transport protocols and FECFRAME is a functional component 242 that performs FEC encoding/decoding and generates RTP compliant 243 repair packets. Even if specific headers are defined for the 244 associated FEC Scheme, FECFRAME is not a full featured transport 245 protocol. 247 3.2. FECFRAME is highly flexible 249 FECFRAME is highly flexible in the way it can be used. In particular 250 FECFRAME: 252 o can protect a single RTP flow [RFC3550], repair packets being 253 themselves RTP packets, possibly multiplexed in the same UDP 254 connection but using a different Payload Type (PT) to distinguish 255 them from source packets. This is particularly useful if backward 256 compatibility is mandatory: non-FECFRAME aware receivers simply 257 drop packets with unknown PT. However this should be regarded as 258 a particular case; 260 o can protect a single source flow that does NOT use RTP, where 261 repair packets are NOT RTP packets either; 263 o can protect several source flows, from the same source or from 264 several sources, some of them being RTP flows but not necessarily 265 the other ones; 267 o can generate a single repair flow or multiple repair flows; 269 o can be used with any upper protocols (RTP or any other protocol) 270 and transport protocols (e.g., UDP, DCCP) if this latter preserves 271 datagram boundaries; 273 o can be used with unicast or multicast/broadcast transmissions; 275 3.3. Details are in each FEC Scheme 277 In the FECFRAME architecture, most technical details are in the FEC 278 Scheme. In particular a FEC Scheme defines: 280 o FEC code specifications and associated FEC Encoding ID; 281 o the way source symbols are created from the data units coming from 282 the application(s), called Application Data Units (ADU); 284 o signaling for FEC Source Packets (optional), called Source FEC 285 Payload ID; 287 o signaling for FEC Repair Packets (mandatory), called Repair FEC 288 Payload ID; 290 3.4. FECFRAME needs session-level description 292 FECFRAME works in conjunction with SDP (or a similar protocol) to 293 specify high level per FECFRAME Instance (i.e., per-session) 294 signaling [RFC6364]. This information, called FEC Framework 295 Configuration Information [RFC6363], describes: 297 o the incoming flows (content description and flow identification); 299 o the outgoing flows, for source and repair packets; 301 o what FEC Scheme is used, identified via the FEC Encoding ID; 303 o and the FEC Scheme specific parameters. 305 In practice, the FEC Scheme is valid for the whole FECFRAME Instance 306 duration, since no update mechanism has been defined to carry a new 307 SDP session description reliably and in real-time to all the 308 potential receivers. This is different from ALC or NORM where the 309 FEC Scheme selection is made on a per-object manner (rather than per- 310 session). 312 4. Application of FECFRAME (RFC 6363) to network coding use-cases: a 313 discussion 315 The FECFRAME framework has a certain number of features and 316 restrictions. We discuss each of them below, at the light of the 317 use-cases identified for Network Coding. 319 4.1. Block versus convolutional codes 321 FECFRAME, as described in [RFC6363], MUST be associated to block FEC 322 codes. For instance ([RFC6363], section 5.1) says: 324 "1. Construction of a source block from ADUs. The FEC code will 325 be applied to this source block to produce the repair payloads." 327 Therefore the input flow(s) is (resp. are) segmented into a sequence 328 of blocks, FEC encoding being performed independently on a per-block 329 basis. 331 However this is not a fundamental limitation, in the sense that the 332 same FECFRAME architecture can be used with sliding (potentially 333 elastic) encoding windows, associated with convolutional codes. To 334 that purpose it is sufficient: 336 o to update [RFC6363] adding the support of sliding (potentially 337 elastic) encoding windows along with the source block approach; 339 o to specify dedicated FEC Schemes, working with convolutional FEC 340 codes for the erasure channel. All the details of the codes, the 341 required signaling, the management of the sliding encoding window 342 and creation of source symbols will be defined in these FEC 343 Schemes. 345 4.2. End-to-end versus in-network re-coding 347 The FECFRAME architecture, as specified in [RFC6363], MUST feature a 348 single encoding node and a single decoding node. These nodes may be 349 the source and destination nodes, or may be middle-boxes, or any 350 combination. 352 The question of having multiple in-network re-coding operations is 353 not considered in [RFC6363]. The question whether this is feasible 354 and appropriate, given the typical FECFRAME use-cases, is an open 355 question that remains to be discussed. 357 4.3. Single versus multi-sources, intra versus inter-flows coding 359 FECFRAME, as specified in [RFC6363], can globally protect several 360 flows that can originate either from a single source or from multiple 361 sources. This also means that FECFRAME can perform both intra-flow 362 coding or inter-flows coding. The only requirement is that those 363 flows be identified and signaled to the FECFRAME encoder and decoder 364 via the FEC Framework Configuration Information (e.g., it can be 365 detailed in the SDP description). 367 From this point of view, FECFRAME is already in line with advanced 368 network-coding use-cases. 370 4.4. Single versus multi-paths 372 FECFRAME, as specified in [RFC6363], does not specify nor restrict 373 how the FEC Source Packet Flow(s) and FEC Repair Packet Flow(s) are 374 to be transmitted: whether they go through the same path (e.g., when 375 they are sent to the same UDP connection) or through multiple paths 376 is irrelevant to FECFRAME since it is an operational and management 377 aspect. However, it is anticipated that when several repair flows 378 are generated, offering different protections levels (e.g., through 379 different code-rates), these repair flows will often use different 380 paths, to better accommodate receiver heterogeneity. 382 From this point of view, FECFRAME is already in line with advanced 383 network-coding use-cases. 385 5. Architectural considerations for FECFRAMEv2 387 Several architectural considerations are now discussed for version 2 388 of FECFRAME. We assume hereafter that FECFRAMEv2 follows the initial 389 spirit of FECFRAME, i.e., is only applied in end-to-end (see 390 Section 4.2). From what follows we show that adding sliding encoding 391 window support to FECFRAMEv2 is simple and can coexist with legacy 392 FECFRAME flows. Extending FECFRAMEv2 to other situations, e.g., with 393 in-network re-coding, is not considered in this document. 395 5.1. FECFRAMEv2 in sliding encoding window mode 396 +----------------------+ 397 | Application | 398 +----------------------+ 399 | 400 | (1) Application Data Units (ADUs) 401 v 402 +----------------------+ +----------------+ 403 | FEC Framework v2 | | | 404 | |-------------------------->| FEC Scheme | 405 |(2) Update of sliding | (3) Source Symbols of | | 406 | encoding window | the sliding window | | 407 | |<--------------------------| | 408 | | (4) Explicit Source | | 409 |(7) Construct FEC | FEC Payload ID(s) |(5) FEC Encoding| 410 | source and repair |<--------------------------| (optional) | 411 | packet(s) | (6) Repair FEC Payload ID | | 412 +----------------------+ + Repair symbol(s) +----------------+ 413 | 414 | (8) FEC source packets and FEC repair packets 415 v 416 +----------------------+ 417 | Transport Layer | 418 | (e.g., UDP) | 419 +----------------------+ 421 Figure 1: Architecture of FECFRAMEv2 in sliding encoding window mode, 422 at a sender/coding node. 424 Figure 1 (adapted from [RFC6865]) illustrates the general 425 architecture of FECFRAMEv2 when working in sliding encoding window 426 mode. The difference with respect to the [RFC6363] architecture lies 427 in steps 2 to 6. Instead of creating a source block, composed of a 428 certain number of ADUs plus their associated flow/length/padding 429 information (see for instance [RFC6865]), FECFRAMEv2 in sliding 430 encoding window mode continuously updates this window (step 2) and 431 communicates the set of symbols to the FEC Scheme (step 3). This 432 latter then returns the Explicit Source FEC Payload ID(s) (step 4) so 433 that the new symbol(s) can be sent immediately. When FECFRAMEv2 434 needs to send one or several FEC repair packets (this is determined 435 by the desired target code rate), it asks the FEC Scheme to create 436 one or several repair symbols (step 5) along with their Repair FEC 437 Payload ID (step 6). The associated FEC Repair Packets are then sent 438 (steps 7 and 8). 440 When FECFRAMEv2 works with a block FEC Scheme, Figure 2 and Figure 3 441 of [RFC6363] remain valid, without any change. 443 5.2. ADU(I) to source symbol mapping 445 Let us now detail the ADU to source symbol mapping. As in FECFRAME, 446 each ADU is first prepended with its {flow ID, length} information 447 (respectively the F and L fields of Figure 2) and potentially zero 448 padded to align to a multiple of the target symbol length ("0 449 padding" field of Figure 2). This augmented ADU is called ADUI. 451 ADUIs are then mapped to source symbols. Since incoming ADUs can 452 have largely varying sizes, it makes sense to use a symbol size 453 significantly lower than the PMTU (as in [MBMS], section 8.2.2.7) 454 which means that large ADUIs will be segmented into several source 455 symbols while small ADUIs may fit into a single or low number of 456 symbols. This has the advantage of limiting transmission overhead if 457 at the same time the FEC Scheme enables the transmission of several 458 repair symbols in the same FEC Repair Packet. However one may also 459 choose to associate a symbol size equal to the maximum ADUI size of 460 the current block, in case of a block FEC Scheme, as in [RFC6816] or 461 [RFC6865], in order to always have a one-to-one mapping between ADUIs 462 and source symbols. 464 The block versus sliding window mode does have an impact on the 465 strategy chosen. More precisely: 467 o FECFRAMEv2 in sliding window mode MUST use a fixed symbol size, 468 indicated in the FEC Framework Configuration Information (FFCI). 470 o FECFRAMEv2 in block mode and FECFRAME MAY use a dynamic symbol 471 size, chosen on a per-block basis, or MAY use a fixed symbol size, 472 indicated in the FEC Framework Configuration Information (FFCI). 474 In any case it is recommended that the symbol size be small enough 475 with respect to the PMTU. 477 FEC code related considerations can impact the choice of a symbol 478 size (assuming they are of fixed size). This is out of the scope of 479 this document. 481 Figure 2 illustrates the creation of the ADUIs from incoming ADUs and 482 the mapping to source symbols in case of small, fixed size symbols. 484 Symbol Length Symbol Length 485 <-----------------------><-----------------------> 486 +----+----+-------------------------+------------+ 487 |F[i]|L[i]|ADU[i] | 0 padding | => symbols j, j+1 488 +----+----+-------+-----+-----------+------------+ 489 |Fi+1|Li+1|ADUi+1 | 0 | => symbol j+2 490 +----+----+-------+---+-+ 491 |Fi+2|Li+2|ADUi+2 |0| => symbols j+3 492 +----+----+-----------+-+------+-----------------+ 493 |Fi+3|Li+3|ADUi+3 | 0 padding | => symbols j+4, j+5 494 +----+----+--------------------+-----------------+ 496 Figure 2: ADUI and source symbols, case of small symbol sizes, for 497 either FECFRAME or FECFRAMEv2. 499 5.3. Sliding encoding window management 501 Let us now detail the sliding window update process at a sender. Two 502 kinds of limitations exist that impact the sliding window management: 504 o at the FEC Scheme level: this latter can have internal or 505 practical limitations (e.g., for complexity reasons) that limit 506 the number of source symbols in the encoding window; 508 o at the FECFRAMEv2 instance level: the source flows can have real- 509 time constraints that limit the number of source symbols in the 510 encoding window; 512 The most stringent limitation defines the maximum window size in 513 terms of either number of source symbols or number of ADUs (depending 514 on the relationship between them, see Section 5.2, they can be equal 515 or not). 517 Source symbols are added to the sliding encoding window as ADUs 518 arrive. 520 Source symbols (and the corresponding ADUs) are removed from the 521 sliding encoding window: 523 o after a certain delay, for situations where the sliding encoding 524 window is managed on a time basis. The motivation is that an old 525 ADU of a real-time flow becomes useless after a certain delay. 526 The ADU retention delay in the sliding encoding window is 527 therefore initialized according to the real-time features of 528 incoming flow(s); 530 o once the sliding encoding window has reached its maximum size, 531 when there is an upper limit to the sliding encoding window size; 533 o when the sliding encoding window is of fixed size, the oldest 534 symbol is removed each time a new symbol is added; 536 o if the sender knows that a particular ADU has been correctly 537 received by the receiver(s), the corresponding source symbol(s) 538 is(are) removed. Of course this mechanism requires that an 539 acknowledgement mechanism be setup to inform the FECFRAMEv2 sender 540 of good ADU reception, which is out of the scope of FECFRAMEv2. 542 5.4. Encoding Symbol Identifiers (ESI) 544 Any **source** symbol of a flow MUST be uniquely identified during 545 the full duration where this symbol is useful. 547 Depending on the FEC Scheme being used, a **repair** symbol of a flow 548 may or not need to be uniquely identified during the full duration 549 where this symbol is useful. For instance, being able to identify a 550 repair symbol is OPTIONAL with Random Linear Codes (RLC) since the 551 coding window content and associated coding vector are communicated 552 in the Repair FEC Payload ID and nothing else is needed to process 553 this repair symbol. But being able to identify a repair symbol is 554 REQUIRED with FEC Schemes that use this symbol identifier during the 555 encoding and decoding processes (this is the case for instance with 556 any block FEC code and some of the convolutional FEC codes). 558 In block mode, the encoding symbols are uniquely identified both by 559 their Source Block Number (SBN) and Encoding Symbol ID (ESI), the 560 first k ESI values identifying source symbols and the remaining n-k 561 ESI values the repair symbols [RFC5052]. In sliding encoding window 562 mode, the situation is totally different: 564 o since there is no block, there is no SBN; 566 o since there is no block, the ESI space that identifies source 567 symbols is linear, each source symbol having an ESI that is 1 568 greater than the previous source symbol, except when a wrap-around 569 to zero occurs after reaching the maximum ESI value permitted by 570 the ESI field size (see below); 572 o an ESI space dedicated to repair symbols is used when the FEC 573 Scheme requires repair symbols to be identified. This ESI space 574 is logically different from the ESI space used for source symbols. 575 Therefore the same ESI value identifies different symbols 576 depending on whether we are considering a FEC source packet or FEC 577 repair packet. This is the context (e.g., the transport 578 identifiers like the destination UDP port number) that enables a 579 FECFRAME receiver to distinguish between source and repair 580 symbols, not the ESI value; 582 Since the ESI space is limited by the header/trailer ESI field size 583 to b bits (as specified by the FEC Scheme), wrap-around to zero is 584 unavoidable with long FECFRAMEv2 sessions. This has two 585 consequences: 587 o the maximum sliding encoding window size MUST be smaller than 588 2^^b, and in practice be significantly smaller; 590 o if the network may significantly delay packets, there is a risk of 591 confusion if an ESI wrap-around takes place in the meantime, since 592 the delayed symbol may be misinterpreted as a fresh symbol. A 593 security margin is therefore needed that consists in having a "b" 594 value sufficiently large to avoid such confusions. What security 595 margin to consider is a deployment decision that also depends on 596 the various flow transmission bitrates. Note that a timestamp 597 information carried in FEC Source Packets may help identifying 598 delayed packets. However this is not a generic mechanism since 599 ADU flows are not required to use RTP framing. 601 5.5. Block and convolutional co-existence in a given FECFRAMEv2 session 603 When two (or more) FEC Repair Packet Flows are used in a given 604 FECFRAME session, it is possible to have both a block FEC Scheme on 605 one flow and a convolutional FEC Scheme on the other flow, both of 606 them protecting the same ADU flow(s). This can be useful in order to 607 preserve backward compatibility, legacy receivers joining the FEC 608 Repair Packet Flow corresponding to the block FEC Scheme and ignoring 609 the other flow. 611 The SDP description associated to this FECFRAMEv2 session indicates 612 if a FEC Repair Packet flow works in block mode or sliding encoding 613 window mode. This is done through the FEC Encoding ID communicated 614 via the "a=fec-repair-flow: encoding-id=0; ..." attribute [RFC6364] 615 (or "a=FEC-declaration:VALUE encoding-id=VALUE" attribute in case of 616 [MBMS]). Then, from this FEC Encoding ID, the FECFRAME receiver can 617 easily deduce if the FEC Scheme corresponds to a block or a 618 convolutional FEC code. 620 6. Security Considerations 622 Adding the new sliding window mode to FECFRAMEv2 (what this document 623 is about) in addition to the block mode of FECFRAME, while keeping 624 the end-to-end approach of FECFRAME, does not fundamentally change 625 the situation from a security point of view. Therefore all the 626 security considerations detailed in [RFC6363] also apply to 627 FECFRAMEv2. More precisely: 629 o the problem statement, section 9.1 of [RFC6363]; 630 o the attacks against the data flows, section 9.2 of [RFC6363]; 632 o the attacks against the FEC parameters, section 9.3 of [RFC6363]; 634 o the discussion related to the FEC protection of several source 635 flows, section 9.4 of [RFC6363]; 637 o and the baseline secure FEC Framework operation, section 9.5 of 638 [RFC6363]; 640 all apply to FECFRAMEv2, regardless of whether it follows a block or 641 sliding window mode. Security considerations specific to a FEC 642 Scheme, if any, will have to be discussed in the associated FEC 643 Scheme document. 645 7. Privacy Considerations 647 Adding the new sliding window mode to FECFRAMEv2 (what this document 648 is about), in addition to the block mode of FECFRAME, does not change 649 the situation from a privacy point of view. Those considerations 650 will be discussed in an update of [RFC6363]. 652 8. IANA Considerations 654 N/A 656 9. Acknowledgments 658 The author wants to thank Morten V. Pedersen for his comments to 659 this document. 661 10. References 663 10.1. Normative References 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 669 Jacobson, "RTP: A Transport Protocol for Real-Time 670 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 671 July 2003, . 673 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 674 Correction (FEC) Building Block", RFC 5052, 675 DOI 10.17487/RFC5052, August 2007, 676 . 678 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 679 Correction (FEC) Framework", RFC 6363, 680 DOI 10.17487/RFC6363, October 2011, 681 . 683 [RFC6364] Begen, A., "Session Description Protocol Elements for the 684 Forward Error Correction (FEC) Framework", RFC 6364, 685 DOI 10.17487/RFC6364, October 2011, 686 . 688 10.2. Informative References 690 [fecframe-charter] 691 FECFRAME WG, IETF., "FEC Framework (fecframe) charter", 692 URL: http://www.ietf.org/wg/concluded/fecframe.html, March 693 2013. 695 [MBMS] 3rd Generation Partnership Project (3GPP) SA4 Working 696 Group, , "Multimedia Broadcast/Multicast Service (MBMS): 697 Protocols and codecs", 3GPP TS 698 26.346 http://www.3gpp.org/DynaReport/26346.htm, March 699 2016. 701 [nc-taxonomy-id] 702 Firoiu, V., Adamson, B., Roca, V., Adjih, C., Bilbao, J., 703 Fitzek, F., Masucci, A., and M. Montpetit, "Network Coding 704 Taxonomy", draft-irtf-nwcrg-network-coding-taxonomy-00 705 (work in progress), November 2014. 707 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 708 "NACK-Oriented Reliable Multicast (NORM) Transport 709 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 710 . 712 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 713 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 714 DOI 10.17487/RFC5775, April 2010, 715 . 717 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward 718 Error Correction (FEC) Schemes for FECFRAME", RFC 6681, 719 DOI 10.17487/RFC6681, August 2012, 720 . 722 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 723 Parity Check (LDPC) Staircase Forward Error Correction 724 (FEC) Scheme for FECFRAME", RFC 6816, 725 DOI 10.17487/RFC6816, December 2012, 726 . 728 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 729 Matsuzono, "Simple Reed-Solomon Forward Error Correction 730 (FEC) Scheme for FECFRAME", RFC 6865, 731 DOI 10.17487/RFC6865, February 2013, 732 . 734 Author's Address 736 Vincent Roca 737 INRIA 738 655, av. de l'Europe 739 Inovallee; Montbonnot 740 ST ISMIER cedex 38334 741 France 743 Email: vincent.roca@inria.fr 744 URI: http://privatics.inrialpes.fr/people/roca/