idnits 2.17.1 draft-roca-rmt-goe-ldpc-01.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 abstract seems to contain references ([GOE], [RFC5170], [RFC5052]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2012) is 4259 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-roca-rmt-goe-fec-00 -- Duplicate reference: draft-roca-rmt-goe-fec, mentioned in 'GOEatIETF81', was also mentioned in 'GOE'. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT V. Roca 3 Internet-Draft A. Roumy 4 Intended status: Experimental INRIA 5 Expires: February 1, 2013 B. Sayadi 6 Alcatel-Lucent, Bell Labs 7 July 31, 2012 9 The Generalized Object Encoding (GOE) LDPC-Staircase FEC Scheme 10 draft-roca-rmt-goe-ldpc-01 12 Abstract 14 This document describes a Generalized Object Encoding (GOE) FEC 15 Scheme for the protection of one or multiple objects, in the context 16 of a Content Delivery Protocol (CDP) like FLUTE/ALC, FCAST/ALC or 17 FCAST/NORM. Unlike [RFC5052], the GOE approach [GOE] decouples the 18 definition of Generalized Objects over which FEC encoding takes place 19 homogeneously, from the natural source object boundaries. This 20 separation enables either an Unequal Erasure Protection (UEP) of 21 different portions of a given source object, or an efficient and 22 global protection of a set of potentially small files, depending on 23 the way the Generalized Objects are defined. 25 The present document defines the GOE LDPC-Staircase FEC Scheme, i.e., 26 the GOE version of the FEC Encoding ID 3 (LDPC-Staircase) defined in 27 [RFC5170] with the further restriction that the number of encoding 28 symbols per group (i.e., the number of symbols sent in the same 29 packet) MUST be equal to 1 (G=1). This document does not change the 30 LDPC-Staircase code definition, and therefore it inherits most of 31 [RFC5170]. It only modifies the FEC Payload ID and FEC OTI, i.e., it 32 addresses the problem of UEP and efficient file bundle protection by 33 means of pure signaling approach. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 1, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Traditional FEC Schemes, as per [RFC5052] . . . . . . . . 4 70 1.2. GOE FEC Scheme Principles . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.1. Definitions, Notations and Abbreviations . . . . . . . . . 6 73 2.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . 6 74 2.1.2. Notations . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . 7 76 3. Formats and Codes with FEC Encoding ID XXX for 77 LDPC-Staircase Codes . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. FEC Payload ID (for Repair Packets Only) . . . . . . . . . 7 79 3.2. FEC Object Transmission Information . . . . . . . . . . . 8 80 3.2.1. Mandatory Elements . . . . . . . . . . . . . . . . . . 8 81 3.2.2. Common Elements . . . . . . . . . . . . . . . . . . . 8 82 3.2.3. Scheme-Specific Elements . . . . . . . . . . . . . . . 8 83 3.2.4. Encoding Format . . . . . . . . . . . . . . . . . . . 9 84 4. Procedures with FEC Encoding ID XXX for LDPC-Staircase 85 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 4.1. Determining the Encoding Symbol Length (E) . . . . . . . . 11 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 6. Operational Considerations . . . . . . . . . . . . . . . . . . 11 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 1.1. Traditional FEC Schemes, as per [RFC5052] 100 The use of Forward Error Correction (FEC) codes is a classic solution 101 to improve the reliability of unicast, multicast and broadcast 102 Content Delivery Protocols (CDP) and applications [RFC3453]. The 103 [RFC5052] document describes a generic framework to use FEC schemes 104 with objects (e.g., files) delivery applications based on the ALC 105 [RFC5775] and NORM [RFC5740] reliable multicast transport protocols. 107 More specifically, the [RFC5053] (Raptor) and [RFC5170] (LDPC- 108 Staircase) FEC schemes introduce erasure codes based on sparse parity 109 check matrices for object delivery protocols like ALC and NORM. 110 Similarly, the [RFC5510] document introduces Reed-Solomon codes based 111 on Vandermonde matrices for the same object delivery protocols. 113 The way these FEC schemes is used leads to two limitations 114 [ExtendedFEC]. First of all, [RFC5052] defines an approach where the 115 same FEC encoding is applied to all the blocks of a given object, 116 i.e., the whole object is encoded using the same FEC scheme, with the 117 same target code rate, resulting in an equivalent protection. This 118 approach may not suit situations where some subsets of an object 119 deserve a higher erasure protection than the others. 121 A second limitation is associated to the protection of a large set of 122 small objects. [RFC5052] defines an approach where each object is 123 protected individually. This feature limits the robustness of their 124 delivery: since there is a small number of source and repair packets 125 for a given small object, a significant number of these packets may 126 be erased thereby preventing this object to be decoded at a receiver. 127 For instance, if the source and repair packets of a given object are 128 transmitted in sequence (which may not be the best strategy), a 129 packet erasure burst will significantly impact transmission 130 robustness. Other transmission ordering strategies (e.g., with long 131 packet interleavings or random ordering strategies) can reduce the 132 impacts of packet erasure bursts, but they do not solve the 133 fundamental problem of the protection of small objects. On the 134 opposite a global FEC protection of all the objects of this set, 135 using a single FEC encoding (when possible), provides optimal 136 transmission robustness, since all the objects can be decoded as long 137 as the erasure rate remains lower than the protection brought by the 138 FEC code rate. 140 1.2. GOE FEC Scheme Principles 142 In order to mitigate the limitations of the traditional FEC Schemes, 143 a better approach consists in decoupling FEC protection from the 144 natural object boundaries. This is the goal of the Generalized 145 Object Encoding (GOE) approach [GOE]. The set of source objects is 146 first encoded using the No-Code FEC Scheme [RFC5445]. Each source 147 symbol of each source object is therefore individually identified by 148 its {TOI (i.e., ALC or NORM object identifier); SBN (source block 149 identifier); ESI (symbol identifier)} tupple. Each Generalized 150 Object is then defined as a sequence of consecutive No-Code encoding 151 symbols, that starts at a given symbol, identified by its {TOI, SBN, 152 ESI} tuple, and that is composed of a given number of such symbols. 153 Each Generalized Object is then FEC encoded using an appropriate FEC 154 code, with an appropriate code rate. Of course a Generalized Object 155 may be a subset of a given source object or at the opposite may 156 encompass several source objects. The key point when defining 157 Generalized Objects is that all the corresponding source symbols 158 require an equal erasure protection. 160 The GOE approach is independent of the nature of the FEC code, in the 161 sense that the general mechanisms it defines is not restricted to a 162 single type of FEC code. On the opposite, the GOE approach can be 163 associated to any of the existing FEC schemes, re-using their code 164 definition. However a new FEC Encoding ID value, a new FEC Object 165 Transmission Information (FEC OTI) and a new FEC Payload ID (FPI) 166 must be defined in order to accommodate the GOE specifics. This 167 means that a dedicated FEC Scheme must be defined. For instance, 168 [GOE] defines the GOE Reed-Solomon FEC Scheme for the particular case 169 of Reed-Solomon codes over GF(2^^8) and no encoding symbol group, the 170 GOE equivalent to FEC Encoding ID 5 defined in [RFC5510]. 172 The present document defines the GOE LDPC-Staircase FEC Scheme, i.e., 173 the GOE version of the FEC Encoding ID 3 (LDPC-Staircase) defined in 174 [RFC5170], with the further restriction that the number of encoding 175 symbols per group (i.e., the number of symbols sent in the same 176 packet) MUST be equal to 1 (G=1). 178 Please refer to [GOE] for the details on the GOE procedures at a 179 sender and at a receiver. An evaluation of GOE can also be found in 180 [GOE.RR7699]. Finally [GOEatIETF81] provides a high level overview 181 of GOE. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [RFC2119]. 189 2.1. Definitions, Notations and Abbreviations 191 2.1.1. Definitions 193 This document uses the following terms and definitions. Some of them 194 are FEC scheme specific and are in line with [RFC5052]: 195 Source Packet: a data packet containing only source symbols, that is 196 sent over the packet erasure channel. Most of the time a source 197 packet will contain a single source symbol. 198 Repair Packet: a data packet containing only repair symbols, that is 199 sent over the packet erasure channel. Most of the time a repair 200 packet will contain a single repair symbol. 201 Packet Erasure Channel: a communication path where packets are 202 either dropped (e.g., by a congested router, or because the number 203 of transmission errors exceeds the correction capabilities of the 204 physical layer codes) or received. When a packet is received, it 205 is assumed that this packet is not corrupted. 206 Systematic code: FEC code in which the source symbols are part of 207 the encoding symbols. The Reed-Solomon codes introduced in this 208 document are systematic. 209 Code rate: the k/n ratio, i.e., the ratio between the number of 210 source symbols and the number of encoding symbols. By definition, 211 the code rate is such that: 0 < code rate <= 1. A code rate close 212 to 1 indicates that a small number of repair symbols have been 213 produced during the encoding process. 214 Object: the object (e.g., file) submitted to the CDP by the user. 215 Generalized Object: a group of consecutive source symbols, that 216 belong to one or several objects (as defined above) and that are 217 considered together for the purpose of a GOE scheme. Generalized 218 objects may be a subset of a given object or at the opposite 219 encompass several objects. The key point when defining 220 generalized objects is that all the source symbols of a 221 generalized object require an equal erasure protection. 222 Source symbol: unit of data used during the encoding process. In 223 this specification, there is always one source symbol per ADU. 224 Encoding symbol: unit of data generated by the encoding process. 225 With systematic codes, source symbols are part of the encoding 226 symbols. 227 Repair symbol: encoding symbol that is not a source symbol. 228 Source block: a block of k source symbols that are considered 229 together for the encoding. 231 2.1.2. Notations 233 This document uses the following notations: 235 k denotes the number of source symbols in a source block. 236 n denotes the number of encoding symbols generated for a source 237 block. 238 E denotes the encoding symbol length in bytes. 239 NO denotes the number of source objects to be considered. 241 2.1.3. Abbreviations 243 This document uses the following abbreviations: 244 ADU stands for Application Data Unit. 245 TOI stands for Transmission Object Identifier. 246 SBN stands for Source Block Number, i.e., a block identifier. 247 ESI stands for Encoding Symbol ID. 248 FEC stands for Forward Error (or Erasure) Correction code. 249 LDPC stands for Low Density Parity Check. 250 MDS stands for Maximum Distance Separable code. 251 UEP stands for Unequal Erasure Protection. 252 FEC OTI stands for FEC Object Transmission Information. 254 3. Formats and Codes with FEC Encoding ID XXX for LDPC-Staircase Codes 256 This section introduces the formats and codes associated with the 257 Fully-Specified FEC Scheme with FEC Encoding ID XXX, which focuses on 258 LDPC-Staircase Codes. This GOE FEC Scheme is the GOE equivalent to 259 FEC Encoding ID 3 defined in [RFC5170], with the further restriction 260 that the number of encoding symbols per group (i.e., the number of 261 symbols sent in the same packet) MUST be equal to 1 (G=1). 263 3.1. FEC Payload ID (for Repair Packets Only) 265 The FEC Payload ID, to be used only with repair packets, i.e., 266 packets containing a repair symbol each, is composed of the Source 267 Block Number (SBN) and the Encoding Symbol ID (ESI). There is no 268 change in terms of format with respect to [RFC5170] but a restriction 269 in terms of valid ESI as explained below: 271 o The Source Block Number (12-bit field) identifies from which 272 source block of the object the encoding symbol in the payload is 273 generated. There is a maximum of 2^^12 blocks per object. 274 o The Encoding Symbol ID (20-bit field) identifies which specific 275 encoding symbol generated from the source block is carried in the 276 packet payload. There is a maximum of 2^^20 encoding symbols per 277 block. The first k values (0 to k - 1) identify source symbols; 278 the remaining n-k values (k to n-k-1) identify repair symbols. 279 Since only repair symbols are considered by this GOE FEC scheme, 280 only the k to n-k-1 values, inclusive, MUST be used. 282 There MUST be exactly one FEC Payload ID per repair packet (since 283 G=1). This FEC Payload ID refers to the one and only symbol of the 284 packet. 286 0 1 2 3 287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Source Block Number | Encoding Symbol ID (20 bits) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 1: FEC Payload ID Encoding Format with FEC Encoding ID XXX 294 3.2. FEC Object Transmission Information 296 3.2.1. Mandatory Elements 298 o FEC Encoding ID: the Fully-Specified FEC Scheme described in this 299 section uses FEC Encoding ID XXX. 301 3.2.2. Common Elements 303 The Common elements are the same as those specified in [RFC5170] for 304 FEC Encoding ID 3, namely: the Transfer-Length (L), the Encoding- 305 Symbol-Length (E), the Maximum-Source-Block-Length (B), and the Max- 306 Number-of-Encoding-Symbols (max_n). These common elements refer to 307 the Generalized Object for which LDPC-Staircase encoding is needed. 309 3.2.3. Scheme-Specific Elements 311 The following element MUST be defined with the present FEC scheme. 312 It defines the composition of a generalized object: 314 o N1m3: an integer between 0 (default) and 7, inclusive. The target 315 number of "1s" per column in the left side of the parity check 316 matrix, N1, is then equal to N1m3 + 3. See [RFC5170] for 317 guidelines on how to set N1m3. 318 o G: in this specification, G MUST be equal to 1. 319 o the Initial Source Symbol TOI (ISS_TOI) identifies the TOI of the 320 first source symbol of this generalized object. The exact format 321 of this field depends on the TOI format, which is CDP and use-case 322 specific. For instance the TOI field of an ALC session is stored 323 in a field of length 32*O+16*H bits, where O and H are the TOI 324 flag and Half-word flag defined in LCT's header; 325 o the ISS TOI size (ISS_O) two bit field determines the TOI size, 326 which is equal to 32*ISS_O + 30 bits. This flexibility is meant 327 to be compatible with any NORM or ALC TOI format; 329 o the ISS Source Block Number (ISS_SBN) identifies the SBN of the 330 first source symbol of this generalized object, within its 331 original object. This is a 16 bit field, since this value results 332 from the No-Code FEC encoding of the original object; 333 o the ISS Encoding Symbol ID (ISS_ESI) identifies the ESI of the 334 first source symbol of this generalized object, within its 335 original block. This is a 16 bit field, since this value results 336 from the No-Code FEC encoding of the original object; 337 o the Generalized Object Size identifies the size, in terms of 338 number of source symbols that compose this generalized object; 340 3.2.4. Encoding Format 342 This section shows the two possible encoding formats of the above FEC 343 OTI. The present document does not specify when one encoding format 344 or the other should be used. 346 3.2.4.1. Using the General EXT_FTI Format 348 The FEC OTI binary format is the following, when the EXT_FTI 349 mechanism is used (e.g., within the ALC [RFC5775] or NORM [RFC5740] 350 protocols). 352 0 1 2 3 353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | HET = 64 | HEL | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 357 | Transfer-Length (L) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Encoding Symbol Length (E) | N1m3| G = 1 | B (MSB) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | B (LSB) | Max Nb of Enc. Symbols (max_n) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | PRNG seed | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |*_O| | 366 +-+-+ ISS_TOI (length = 32*ISS_O + 30 bits) + 367 | ... | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | ISS Source Block Number | ISS Encoding Symbol ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Generalized Object Size | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 2: EXT_FTI Header Format with FEC Encoding ID XXX 376 3.2.4.2. Using the FDT Instance (FLUTE specific) 378 When it is desired that the FEC OTI be carried in the FDT Instance of 379 a FLUTE session [FLUTE], the following XML attributes must be 380 described for the associated object: 381 o FEC-OTI-FEC-Encoding-ID 382 o FEC-OTI-Transfer-Length (L) 383 o FEC-OTI-Encoding-Symbol-Length (E) 384 o FEC-OTI-Maximum-Source-Block-Length (B) 385 o FEC-OTI-Max-Number-of-Encoding-Symbols (max_n) 386 o FEC-OTI-Scheme-Specific-Info 387 The FEC-OTI-Scheme-Specific-Info contains the string resulting from 388 the Base64 encoding (in the XML Schema xs:base64Binary sense) of the 389 following value: 391 0 1 2 3 392 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | PRNG seed | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |*_O| | 397 +-+-+ ISS_TOI (length = 32*ISS_O + 30 bits) + 398 | ... | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | ISS Source Block Number | ISS Encoding Symbol ID | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Generalized Object Size | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | N1m3| G = 1 | 405 +-+-+-+-+-+-+-+-+ 407 Figure 3: FEC OTI Scheme Specific Information To Be Included in the 408 FDT Instance 410 During Base64 encoding, the FEC OTI Scheme-Specific Information (of 411 variable length) is transformed into a string of printable characters 412 (in the 64-character alphabet) that is added to the FEC-OTI-Scheme- 413 Specific-Info attribute. 415 4. Procedures with FEC Encoding ID XXX for LDPC-Staircase Codes 417 This section defines procedures that MUST be applied to FEC Encoding 418 ID XXX. The block partitioning algorithm that is defined in Section 419 9.1 of [RFC5052] MUST be used. The procedure called "Determining the 420 Maximum Source Block Length (B)" in [RFC5170] MUST be used. The 421 procedure called "Determining the Maximum Number of Encoding Symbols 422 Generated for Any Source Block (max_n)" in [RFC5170] MUST be used. 424 The procedure called "Determining the Number of Encoding Symbols of a 425 Block" in [RFC5170] MUST be used. The procedure called "Identifying 426 the G Symbols of an Encoding Symbol Group" in [RFC5170] MUST NOT be 427 used, since this specification requires that the number of encoding 428 symbols per group MUST be equal to 1 (G=1). The procedure called 429 "Pseudo-Random Number Generator" in [RFC5170] MUST be used. 431 4.1. Determining the Encoding Symbol Length (E) 433 The E parameter usually depends on the maximum transmission unit on 434 the path Maximum Transmission Unit (PMTU) from the source to each 435 receiver. This PMTU may be known, may be discovered, or may be 436 estimated, depending on the target use case. In order to minimize 437 the protocol header overhead (e.g., the Layered Coding Transport 438 (LCT), UDP, IPv4, or IPv6 headers in the case of ALC), E MAY be 439 chosen to be as large as possible. In that case, E is chosen so that 440 the size of a packet composed of a single encoding symbol remains 441 below but close to the PMTU (or by the minimum PMTU to each possible 442 destinations in case of one-to-many sessions). This value E is also 443 the source symbol size (i.e., the source symbols, before FEC 444 encoding, and the encoding symbols, after FEC encoding, are of equal 445 size). 447 This size MUST be used to segment all of the NO source objects 448 considered by the GOE FEC schemes for this CDP into source symbols. 449 By doing so, a Generalized Object that straddles several objects 450 (among the NO possibles) benefits from the same source symbol size 451 across source object boundaries. 453 5. Security Considerations 455 TBD 457 6. Operational Considerations 459 LDPC-Staircase codes have excellent erasure recovery capabilities 460 with large source blocks, close to ideal MDS codes. For instance, 461 with a medium source block size k=1024, CR=2/3, N1=5, G=1, with a 462 hybrid ITerative/Maximum Likelihood (IT/ML) decoding approach (see 463 below) and when all symbols are sent in a random order (see below), 464 the average overhead amounts to 0.64% (corresponding to 6.5 symbols 465 in addition to k) and receiving 1043 symbols (corresponding to a 1.9% 466 overhead) is sufficient to reduce the decoding failure probability to 467 5.1*10^^-5. 469 LDPC-Staircase codes are also a good solution whenever processing 470 requirements at a software encoder or decoder must be kept to a 471 minimum. This is true when the decoder uses an IT decoding 472 algorithm, or an ML algorithm (we use a Gaussian Elimination as the 473 ML algorithm) when this latter is carefully implemented and the 474 source block size kept reasonable, or a mixture of both techniques 475 which is the recommended solution. For instance an average decoding 476 speed between 1.3 Gbps (corresponding to a very bad channel, close to 477 the theoretical decoding limit and requiring an ML decoding) and 4.3 478 Gbps (corresponding to a medium quality channel where IT decoding is 479 sufficient) are easily achieved with a source block size composed of 480 k=1024 source symbols, a code rate CR=2/3 (i.e., 512 repair symbols), 481 1024 byte long symbols, G=1, and N1=5, on an Intel Xeon 5120/1.86GHz 482 workstation running Linux/64 bits. Additionally, with a hybrid IT/ML 483 approach, a receiver can decide if and when ML decoding is used, 484 depending on local criteria (e.g., battery or CPU capabilities), 485 independently from other receivers. 487 As the source block size decreases, the erasure recovery capabilities 488 of LDPC codes in general also decrease. In the case of LDPC- 489 Staircase codes, in order to compensate this phenomenon, it is 490 recommended to increase the N1 parameter and to use a hybrid IT/ML 491 decoding approach. For instance, with a small source block size 492 k=256 symbols, CR=2/3, N1=7, and G=1, the average overhead amounts to 493 0.67% (corresponding to 1.7 symbols in addition to k), and receiving 494 267 symbols (corresponding to a 4.3% overhead) is sufficient to 495 reduce the decoding failure probability to 1.4*10^^-5. Using N1=9 496 further improves these results if need be, which also enables to use 497 LDPC-Staircase codes with k=100 symbols for instance. 499 With very small source blocks (e.g., a few tens symbols), using for 500 instance Reed-Solomon codes [RFC5510] or 2D parity check codes MAY be 501 more appropriate. 503 The way the FEC Repair Packets are transmitted is of high importance. 504 A good strategy, that works well for any kind of channel loss model, 505 consists in sending FEC Repair Packets in random order (rather than 506 in sequence) while FEC Source Packets are sent first and in sequence. 507 Sending all packets in a random order is another possibility, but it 508 requires that all repair symbols for a source block be produced 509 first, which adds some extra delay at a sender. 511 For further information, the interested reader can refer for instance 512 to [Cunche08][CunchePHD10]. 514 7. IANA Considerations 516 Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA 517 registration. For general guidelines on IANA considerations as they 518 apply to this document, see [RFC5052]. 520 This document assigns the Fully-Specified FEC Encoding ID XXX under 521 the "ietf:rmt:fec:encoding" name-space to "Generalized Object 522 Encoding for LDPC-Staircase codes". 524 8. Acknowledgments 526 TBD 528 9. References 530 9.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", RFC 2119. 535 [ExtendedFEC] 536 Roca, V., Roumy, A., and B. Sayadi, "The Need for Extended 537 Forward Erasure Correction (FEC) Schemes: Problem 538 Position", Work in 539 progress draft-roca-rmt-extended-fec-problem, July 2012. 541 [GOE] Roca, V., Roumy, A., and B. Sayadi, "The Generalized 542 Object Encoding (GOE) Approach for the Forward Erasure 543 Correction (FEC) Protection of Objects and its Application 544 to Reed-Solomon Codes over GF(2^^8)", Work in 545 progress draft-roca-rmt-goe-fec, July 2012. 547 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity 548 Check (LDPC) Forward Error Correction", RFC 5170, 549 June 2008. 551 9.2. Informative References 553 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 554 M., and J. Crowcroft, "The Use of Forward Error Correction 555 (FEC) in Reliable Multicast", RFC 3453, December 2002. 557 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) 558 Schemes", RFC 5445, March 2009. 560 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 561 Correction (FEC) Building Block", RFC 5052, August 2007. 563 [GOE.RR7699] 564 Roumy, A., Roca, V., Sayadi, B., and R. Imad, "Unequal 565 Erasure Protection and Object Bundle Protection with the 566 Generalized Object Encoding Approach", INRIA Research 567 Report RR-7699, http://hal.inria.fr/inria-00612583_v1/en/, 568 July 2011. 570 [GOEatIETF81] 571 Roca, V., Roumy, A., and B. Sayadi, "The GOE FEC schemes 572 (draft-roca-rmt-goe-fec-00) and UOD-RaptorQ versus GOE", 573 Slides presented during the RMT meeting at IETF81, http:// 574 www.ietf.org/proceedings/81/slides/rmt-2.pdf, July 2011. 576 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 577 "Reed-Solomon Forward Error Correction (FEC) Schemes", 578 RFC 5510, April 2009. 580 [RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, 581 "Raptor Forward Error Correction Scheme", RFC 5053, 582 June 2007. 584 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 585 "NACK-Oriented Reliable Multicast (NORM) Transport 586 Protocol", RFC 5740, November 2009. 588 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 589 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 590 April 2010. 592 [FLUTE] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 593 "FLUTE - File Delivery over Unidirectional Transport", 594 Work in Progress, July 2012. 596 [Cunche08] 597 Cunche, M. and V. Roca, "Optimizing the Error Recovery 598 Capabilities of LDPC-Staircase Codes Featuring a Gaussian 599 Elimination Decoding Scheme", 10th IEEE International 600 Workshop on Signal Processing for Space Communications 601 (SPSC'08), October 2008. 603 [CunchePHD10] 604 Cunche, M., "High performances AL-FEC codes for the 605 erasure channel : variation around LDPC codes", PhD 606 dissertation (in 607 French), http://tel.archives-ouvertes.fr/tel-00451336/en/, 608 June 2010. 610 Authors' Addresses 612 Vincent Roca 613 INRIA 614 655, av. de l'Europe 615 Inovallee; Montbonnot 616 ST ISMIER cedex 38334 617 France 619 Email: vincent.roca@inria.fr 620 URI: http://planete.inrialpes.fr/people/roca/ 622 Aline Roumy 623 INRIA 624 Campus Universitaire de Beaulieu 625 RENNES Cedex 35042 626 France 628 Email: aline.roumy@inria.fr 629 URI: http://www.irisa.fr/prive/Aline.Roumy/ 631 Bessem Sayadi 632 Alcatel-Lucent, Bell Labs 633 France 635 Email: bessem.sayadi@alcatel-lucent.com