idnits 2.17.1 draft-roca-nwcrg-rlc-fec-scheme-for-quic-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 (March 9, 2020) is 1502 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 nwcrg V. Roca, Ed. 3 Internet-Draft INRIA 4 Intended status: Informational F. Michel 5 Expires: September 10, 2020 UCLouvain 6 I. Swett 7 Google 8 M-J. Montpetit 9 Triangle Video 10 March 9, 2020 12 Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) 13 Schemes for QUIC 14 draft-roca-nwcrg-rlc-fec-scheme-for-quic-03 16 Abstract 18 This document specifies Sliding Window Random Linear Code (RLC) 19 Forward Erasure Correction (FEC) Schemes for the QUIC transport 20 protocol, in order to recover from packet losses. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3 58 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Source Symbols Mapping . . . . . . . . . . . . . . . . . 3 60 3.2. Source Symbols identification . . . . . . . . . . . . . . 4 61 3.3. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 4 62 3.4. Coding Coefficients Generation Function . . . . . . . . . 4 63 4. Sliding Window RLC FEC Scheme over GF(2^^8) . . . . . . . . . 5 64 4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 5 65 4.1.1. Configuration Information . . . . . . . . . . . . . . 5 66 4.1.2. SRC FPI Frame Format . . . . . . . . . . . . . . . . 5 67 4.1.3. REPAIR Frame Format . . . . . . . . . . . . . . . . . 6 68 4.1.4. Additional Procedures . . . . . . . . . . . . . . . . 7 69 4.2. FEC Code Specification . . . . . . . . . . . . . . . . . 7 70 4.2.1. Encoding Side . . . . . . . . . . . . . . . . . . . . 7 71 4.2.2. Decoding Side . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 8.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 QUIC [QUIC-transport] is a transport protocol that aims at improving 83 network performance by enabling stream multiplexing, partial 84 reliability, and methods of recovery besides retransmission, while 85 also improving security. This document specifies FEC schemes for 86 Sliding Window Random Linear Code (RLC) [RFC8681] to recover from 87 lost packets within a single QUIC stream or across several QUIC 88 streams, compliant with the FEC coding framework for QUIC 89 [Coding4QUIC]. 91 The ability to add FEC coding in QUIC may be beneficial in several 92 situations: 94 o for a robust transmission of latency-sensitive traffic, for 95 instance real-time flows, since it enables to recover packet 96 losses independently of the round trip time; 98 o for the transmission of contents to a large set of QUIC reception 99 endpoints, since the same repair frame may help recovering several 100 different packet losses at different receivers; 102 o for multipath communications, since repair traffic adds diversity. 104 2. Definitions and Abbreviations 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 Terms and definitions that apply to coding are available in 111 [nc-taxonomy]. More specifically, this document uses the following 112 definitions: 114 Packet versus Symbol: a Packet is the unit of data that is exchanged 115 over the network while a Symbol is the unit of data that is 116 manipulated during the encoding and decoding operations 118 Source Symbol: a unit of data originating from the source that is 119 used as input to encoding operations 121 Repair Symbol: a unit of data that is the result of a coding 122 operation 124 This document uses the following abbreviations: 126 E: size of an encoding symbol (i.e., source or repair symbol), 127 assumed fixed (in bytes) 129 3. Procedures 131 This section introduces the procedures that are used by these FEC 132 Schemes. 134 3.1. Source Symbols Mapping 136 The present FEC Scheme follows the source symbols mapping specified 137 in [Coding4QUIC]. Figure 1 illustrates this mapping. 139 QUIC packet 140 ||< E-1 >|< E-1 >|< E-1 >| 141 +------|----+--|-------|-------|-------| 142 |Header| 0 | Packet Payload | 4 packet chunks 143 +------|----+--|-------|-------|-------| 144 / | | \ 145 v v v v 146 +-+--+----+ +-+-------+ +-+-------+ +-+-------+ 147 |m|pn|chnk| |m| chunk| |m| chunk| |m| chunk| 4 source symbols 148 +-+--+----+ +-+-------+ +-+-------+ +-+-------+ 149 | | | | | | | | 150 |< --E-- >| |< --E-- >| |< --E-- >| |< --E-- >| 152 Figure 1: Example of source symbol mapping, when the E value is 153 relatively small. 155 3.2. Source Symbols identification 157 Similarly to [RFC8681], the present FEC Scheme assigns a unique 158 identifier (ID) to each produced source symbol. The IDs are assigned 159 to the produced source symbols in the ascending order. The IDs start 160 at MUST start 0 and MUST be contiguous. For any symbol with ID x, 161 the source symbol with ID x+1 is : 163 o The source symbol containing the next packet chunk in the same 164 QUIC packet as the source symbol X, if it exists. 166 o The source symbol containing the first packet chunk of the next 167 generated FEC-protected QUIC packet 169 Do we want to authorize a wrapping of the source symbol ID ? It would 170 be a lot easier if wrapping is not permitted. 172 3.3. Pseudo-Random Number Generator (PRNG) 174 The RLC FEC Schemes defined in this document rely on the TinyMT32 175 PRNG defined in [RFC8682] along with the two mapping functions to 176 4-bit and 8-bit unsigned integers defined in [RFC8681]. 178 3.4. Coding Coefficients Generation Function 180 The coding coefficients, used during the encoding process, are 181 generated at the RLC encoder by the generate_coding_coefficients() 182 function each time a new repair symbol needs to be produced. This 183 specification uses the generate_coding_coefficients() defined in 184 [RFC8681]. 186 4. Sliding Window RLC FEC Scheme over GF(2^^8) 188 This fully-specified FEC Scheme defines the Sliding Window Random 189 Linear Codes (RLC) over GF(2^^8). 191 4.1. Formats and Codes 193 4.1.1. Configuration Information 195 This section provides the RLC configuration information that needs to 196 be shared during QUIC negotiation between the QUIC sender and 197 receiver endpoints in order to synchronize them. 199 o FEC Encoding ID (8 bits): the value assigned to this fully 200 specified FEC Scheme MUST be XXXX, as assigned by IANA 201 (Section 6). This FEC Encoding ID is used during the QUIC 202 negotiation to uniquely identify the RLC FEC Scheme for QUIC; 204 o Encoding symbol size, E (in bytes) (16 bits): a non-negative 205 integer that indicates the size of each source and repair symbol, 206 in bytes. This element is required both by the QUIC sender 207 endpoint (RLC encoder) and the QUIC receiver endpoint(s) (RLC 208 decoder). 210 TODO: specify exact format, with binary encoding, to be carried 211 within the opaque 32-bit field during negotiation. 213 4.1.2. SRC FPI Frame Format 215 The RLC FEC Scheme requires explicit signaling of the Source Symbols 216 it transmits. The QUIC packets whose payload is protected by FEC 217 MUST contain an SRC FPI frame with the following format. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | ID of First Source Symbol in Packet (i) ... 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 2: SRC FPI frame format. 227 The SRC FPI frame contains the ID of the first source symbol 228 contained in this packet. Each source symbol contains a packet chunk 229 of E-1 bytes long. If the payload to protect is longer than E-1 230 bytes, this means that the packet contains several packet chunks. In 231 this case the source symbol ID will increase by exactly one for each 232 additional packet chunk contained in the payload to protect. 234 Note: This frame is not idempotent. In the current version of QUIC, 235 all the frames are idempotent (but this is not especially 236 required). It would be great to preserve this property (a quick 237 fix would be to add the packet number in the frame, but it takes 238 a lot of space and I don't think it is very useful). Another bad 239 property is that the frames are not independant anymore (several 240 SRC FPI frames contained in the same packet have a confusing 241 meaning). I really think that the correct solution would be a 242 (encrypted) header field but I guess it is more complicated to 243 propose (maybe in v2 we'll have a mechanism to define dynamic 244 encrypted header fields during negotiation). 246 4.1.3. REPAIR Frame Format 248 The RLC FEC Scheme requires QUIC REPAIR frames to convey enough 249 information. This section specifies the REPAIR frame format specific 250 to the RLC FEC Scheme. Note that the notion of REPAIR frame format 251 is equivalent to the notion of Repair FEC Payload ID in [RFC8681]. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | ID of First Source Symbol in EW (i) ... 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Repair_Key | NSS | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | DT | NRS | Repair Symbols ... 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 3: REPAIR frame format when protecting a single QUIC stream. 265 More precisely, the REPAIR frame format is composed of the following 266 fields (Figure 3): 268 ID of the first Source Symbol in the Encoding Window (variable-size 269 field): 270 a variable-length integer specifying the ID of the first source 271 symbol in the encoding window. When a FEC REPAIR frame contains 272 several repair symbols, this value applies to all of them; 274 Repair_Key (16-bit field): this unsigned integer is used as a seed 275 by the coefficient generation function (Section 3.4) in order to 276 generate the desired number of coding coefficients. When a FEC 277 Repair Packet contains several repair symbols, this repair key 278 value is that of the first repair symbol. The remaining repair 279 keys can be deduced by incrementing by 1 this value, up to a 280 maximum value of 65535 after which it loops back to 0. 282 Number of Source Symbols in the encoding window, NSS (16-bit field): 284 this unsigned integer indicates the number of source symbols in 285 the encoding window when this repair symbol was generated. When a 286 REPAIR frame contains several repair symbols, the NSS value 287 applies to all of them; 289 Density Threshold for the coding coefficients, DT (4-bit field): thi 290 s unsigned integer carries the Density Threshold (DT) used by the 291 coding coefficient generation function Section 3.4. More 292 precisely, it controls the probability of having a non zero coding 293 coefficient, which equals (DT+1) / 16. When a REPAIR frame 294 contains several repair symbols, the DT value applies to all of 295 them; 297 Number of Repair Symbols contained in the frame, NRS (12-bit field): 299 this unsigned integer specifies the number of Repair Symbols 300 contained in this REPAIR frame; 302 Repair Symbols: data for this repair symbol(s). This field is NRS*E 303 bytes long. 305 4.1.4. Additional Procedures 307 4.2. FEC Code Specification 309 This RLC FEC Scheme relies on the FEC code specification defined in 310 [RFC8681]. 312 4.2.1. Encoding Side 314 [RFC8681] high level description of a Sliding Window RLC encoder also 315 applies here to this FEC Scheme. 317 4.2.2. Decoding Side 319 [RFC8681] high level description of a Sliding Window RLC decoder also 320 applies here to this FEC Scheme. 322 5. Security Considerations 324 TBD 326 6. IANA Considerations 328 This document registers two values in the "QUIC FEC Encoding IDs" 329 registry as follows: 331 o XXXX refers to the Sliding Window Random Linear Codes (RLC) over 332 GF(2^^8) FEC Scheme for a Single QUIC Stream, as defined in 333 Section 4 of this document. 335 7. Acknowledgments 337 TBD 339 8. References 341 8.1. Normative References 343 [Coding4QUIC] 344 Swett, I., Montpetit, M-J., Roca, V., and F. Michel, 345 "Coding for QUIC", Work in Progress, NWCRG draft-swett- 346 nwcrg-coding-for-quic (Work in Progress), March 2020, 347 . 350 [QUIC-transport] 351 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 352 Multiplexed and Secure Transport", draft-ietf-quic- 353 transport (Work in Progress) (work in progress), November 354 2019, . 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 363 (RLC) Forward Erasure Correction (FEC) Schemes for 364 FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020, 365 . 367 [RFC8682] Saito, M., Matsumoto, M., Roca, V., Ed., and E. Baccelli, 368 "TinyMT32 Pseudorandom Number Generator (PRNG)", RFC 8682, 369 DOI 10.17487/RFC8682, January 2020, 370 . 372 8.2. Informative References 374 [nc-taxonomy] 375 Roca (Ed.) et al., V., "Taxonomy of Coding Techniques for 376 Efficient Network Communications", Request For 377 Comments RFC 8406, June 2018, 378 . 381 Authors' Addresses 383 Vincent Roca (editor) 384 INRIA 385 Univ. Grenoble Alpes 386 France 388 Email: vincent.roca@inria.fr 390 Francois Michel 391 UCLouvain 392 Louvain-la-Neuve 393 Belgium 395 Email: francois.michel@uclouvain.be 397 Ian Swett 398 Google 399 Cambridge, MA 400 US 402 Email: ianswett@google.com 404 Marie-Jose Montpetit 405 Triangle Video 406 Boston, MA 407 US 409 Email: marie@mjmontpetit.com