idnits 2.17.1 draft-swett-nwcrg-coding-for-quic-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2018) is 2136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-12 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 nwcrg I. Swett 3 Internet-Draft Google 4 Intended status: Informational M-J. Montpetit 5 Expires: December 23, 2018 Triangle Video 6 V. Roca 7 INRIA 8 June 21, 2018 10 Coding for QUIC 11 draft-swett-nwcrg-coding-for-quic-01 13 Abstract 15 This document focusses on the integration of FEC coding in the QUIC 16 transport protocol, in order to recover from packet losses. This 17 document does not specify any FEC code but defines mechanisms to 18 negotiate and integrate FEC Schemes in QUIC. By using proactive loss 19 recovery, it is expected to improve QUIC performance in sessions 20 impacted by packet losses. More precisely it is expected to improve 21 QUIC performance with real-time sessions (since FEC coding makes 22 packet loss recovery insensitive to the round trip time), with 23 multicast sessions (since the same repair packet can recover several 24 different losses at several receivers), and with multipath sessions 25 (since repair packets add diversity). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 23, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3 63 3. General Design Considerations . . . . . . . . . . . . . . . . 4 64 3.1. FEC Code versus FEC Scheme, Block Codes versus Sliding 65 Window Codes . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. FEC Scheme Negotiation . . . . . . . . . . . . . . . . . 4 67 3.3. FEC Protection Within an Encrypted Channel . . . . . . . 5 68 3.4. About Middleboxes . . . . . . . . . . . . . . . . . . . . 5 69 3.5. FEC Protection at the Stream Level . . . . . . . . . . . 5 70 3.6. About Gaps in the Set of Source Symbols Considered During 71 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. FEC Scheme Negotiation in QUIC . . . . . . . . . . . . . . . 6 73 4.1. FEC Scheme Selection Process . . . . . . . . . . . . . . 7 74 4.2. FEC Scheme Configuration Information . . . . . . . . . . 7 75 5. Procedures when Protecting a Single QUIC Stream . . . . . . . 8 76 5.1. Application data, STREAM Frame data and Source Symbols . 8 77 5.2. Signaling Considerations within STREAM and REPAIR Frames 9 78 5.3. Management of Silent Periods and End of Stream . . . . . 10 79 6. Procedures when Protecting Several QUIC Streams . . . . . . . 11 80 6.1. Application data, STREAM Frame data and Source Symbols . 11 81 6.2. Block or Encoding Window Management . . . . . . . . . . . 11 82 6.3. Signaling Considerations within STREAM and REPAIR Frames 12 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 88 10.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 QUIC is a new transport that aims at improving network performance by 94 enabling out of order delivery, partial reliability, and methods of 95 recovery besides retransmission, while also improving security. This 96 document specifies a framework to enable FEC codes to be used to 97 recover from lost packets within a single QUIC stream or across 98 several QUIC streams. 100 The ability to add FEC coding in QUIC may be beneficial in several 101 situations: 103 o for a robust transmission of latency sensitive traffic, for 104 instance real-time flows, since it enables to recover packet 105 losses independently of the round trip time; 107 o for the transmission of contents to a large set of QUIC reception 108 endpoints, since the same repair frame may help recovering several 109 different packet losses at different receivers; 111 o for multipath communications, since repair traffic adds diversity. 113 This framework does not mandate the use of any specific FEC code 114 (i.e., how to encode and decode) nor FEC Scheme (i.e., that specifies 115 both a FEC code and how to use it, in particular in terms of 116 signaling). Instead it allows to negotiate the FEC Scheme to use at 117 session startup, assuming that more than one solution could 118 potentially be offered concurrently. Without loss of generality, we 119 assume that the encoding operations compute a linear combination of 120 QUIC packets, regardless of whether these codes are of block type (as 121 with Reed-Solomon codes [RFC5510]) or sliding window type (as with 122 RLC codes [RLC]). 124 2. Definitions and Abbreviations 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 Terms and definitions that apply to coding are available in 131 [nc-taxonomy]. More specifically, this document uses the following 132 definitions: 134 Packet versus Symbol: a Packet is the unit of data that is exchanged 135 over the network while a Symbol is the unit of data that is 136 manipulated during the encoding and decoding operations 138 Source Symbol: a unit of data originating from the source that is 139 used as input to encoding operations 141 Repair Symbol: a unit of data that is the result of a coding 142 operation 144 This document uses the following abbreviations: 146 E: size of an encoding symbol (i.e., source or repair symbol), 147 assumed fixed (in bytes) 149 3. General Design Considerations 151 This section lists a few general considerations that govern the 152 framework for FEC coding support in QUIC. 154 3.1. FEC Code versus FEC Scheme, Block Codes versus Sliding Window 155 Codes 157 A FEC code specifies the details of encoding and decoding operations. 158 In addition to that, a FEC Scheme defines the additional protocol 159 aspects required to use a particular FEC code [nc-taxonomy]. In 160 particular the FEC Scheme defines signaling (e.g., information 161 contained in Source and Repair Packet header or trailers) needed to 162 synchronize encoders and decoders. 164 Block coding (e.g., Reed-Solomon [RFC5510]) and sliding window coding 165 (e.g., RLC [RLC]) are two broad classes of FEC codes [nc-taxonomy]. 166 In the first case, the input flow must be first segmented into a 167 sequence of blocks, FEC encoding and decoding being performed 168 independently on a per-block basis. In the second case rely, a 169 sliding encoding window continuously slides over the input flow. It 170 is envisioned that the two classes of codes could be used to bring 171 FEC protection to QUIC, usually with an advantage for sliding window 172 codes when it comes to low latency communications. 174 3.2. FEC Scheme Negotiation 176 There are multiple FEC Scheme candidates. Therefore a negotiation 177 step is needed to select one or more codes to be used over a QUIC 178 session. This will be implemented using the one step negotiation of 179 the new QUIC negotiation mechanism [QUIC-transport], during the QUIC 180 handshake. 182 Editor's notes: 184 * It is likely that FEC Scheme negotiation requires the use of a 185 new dedicated Extension Frame Type. To Be Clarified and text 186 updated. 188 * It is not clear whether negotiation is meant to select a 189 **single** FEC Scheme or **multiple** FEC Schemes. In the 190 second case (multiple FEC) it is required to have a 191 complementary mechanism to indicate which FEC Scheme is used 192 in a given REPAIR frame (which could be done through as many 193 REPAIR frame type values as potential FEC Scheme negotiated). 194 Is it what we want to achieve? Not sure. 196 * It is not clear whether negotiation is carried out at QUIC 197 level (and therefore for multiple streams) or at a stream 198 level (and therefore multiple streams may use multiple FEC 199 Schemes). The terminology used above should be updated to 200 reflect the choice. 202 3.3. FEC Protection Within an Encrypted Channel 204 FEC encoding is applied before any QUIC encryption and authentication 205 processing. Source symbols, that constitute the data units used by 206 the FEC codec, contain cleartext application data. 208 3.4. About Middleboxes 210 The coding approach described in this document does not allow on path 211 elements (middleboxes) to take part in FEC protection. The traffic 212 being encrypted end-to-end, the middleboxes are not in position to 213 perform FEC decoding, nor to add any redundant traffic. 215 3.5. FEC Protection at the Stream Level 217 Streams in QUIC provide a lightweight, ordered byte-stream 218 abstraction. FEC encoding is applied at the stream level, within a 219 single stream or across two or more streams of the same QUIC session. 220 This is motivated by the fact that FEC protection is not necessarily 221 beneficial to all data streams, but only to a subset of them. For 222 instance FEC protection can be highly beneficial to live video 223 streams to which the proactive erasure correction feature of FEC, 224 independent of the RTT, should be highly beneficial. On the 225 opposite, FEC protection is probably less attractive for latency 226 insensitive bulk unicast flows. 228 In order to facilitate experiments, and in order to enable backward 229 compatibility, the STREAM frames that carry application data are kept 230 unmodified. On the opposite, frames that carry one or more repair 231 symbols use a dedicated REPAIR frame type, chosen within the type 232 range dedicated to "Extension Frames". 234 3.6. About Gaps in the Set of Source Symbols Considered During Encoding 236 A given FEC Scheme MAY support or not the presence of gaps in the set 237 of source symbols that constitute a block (for Block codes) or an 238 encoding window (for Sliding Window codes). A potential cause for 239 non contiguous sets of source symbols is the acknowledgment of one of 240 them. When this happens, the QUIC sending endpoint may want to 241 remove this source symbol from further FEC encodings. This is 242 particularly true with Sliding Window codes because of their 243 flexibility during FEC encoding (i.e., the encoding window can change 244 between two consecutive FEC encodings). 246 Supporting gaps can be motivated by the desire to reduce encoding and 247 decoding complexity since there are fewer variables. However this 248 choice has major consequences in terms of signaling. Indeed each 249 repair symbol transmitted MUST be accompanied with enough information 250 for the QUIC decoding endpoint to unambiguously identify the exact 251 composition of the block or encoding window. Without any gap, the 252 identity of the first source symbol plus the number of symbols in the 253 block or encoding window is sufficient. With gaps, a more complex 254 encoding needs to be used, perhaps similar to the encoding used for 255 selective acknowledgments. 257 Whether or not gaps are supported MUST be clarified in each FEC 258 Scheme. 260 4. FEC Scheme Negotiation in QUIC 262 FEC Scheme negotiation has two goals: 264 o Selecting a FEC Scheme (or FEC Schemes) that can be used by the 265 QUIC transmission and reception endpoints. This process requires 266 an exchange between them; 268 o Communicating a certain number of parameters, the "Configuration 269 Information", that are not expected to change over the session 270 lifetime. For instance, this is the case of the symbol size 271 parameter, E (in bytes), that needs either to be agreed between 272 the endpoints, or chosen by the sender and communicated to the 273 receiver(s); 275 Editor's notes: 277 * It is likely that FEC Scheme negotiation requires the use of a 278 new dedicated Extension Frame Type. The details remain TBD. 280 * The Negotiation Frame Type format remains TBD. 282 * How to communicate the parameters remains TBD. 284 * The present document only provides high level principles, the 285 details are of course the responsibility of the FEC Scheme. 287 * In case negotiation is different when protecting a single 288 versus several streams, this section may be moved to the 289 respective sections. 291 * How does it work in case of a multicast session? 293 * Do we negotiate here a FEC Scheme on a per-Stream basis (or 294 group of Streams to be protected jointly)? Or do we negotiate 295 a FEC Scheme on a QUIC session basis, therefore to be used for 296 all the Streams that need FEC protection? 298 4.1. FEC Scheme Selection Process 300 Let us consider the FEC Scheme selection process between the QUIC 301 endpoints. Figure 1 illustrates the principle when a QUIC reception 302 endpoint initiates the exchange. 304 QUIC sender QUIC receiver 305 < - - - - - - - - - - - - - - - - - - - - - - 306 supported_fec_scheme_32b{FS1_Encoding_ID | other} 307 supported_fec_scheme_64b{FS1_Encoding_ID | other} 309 choose FEC Scheme "FS1" 310 - - - - - - - - - - - - - - - - - - - - - - > 311 supported_fec_scheme_32b{FS1_Encoding_ID | other} 313 Figure 1: Example FEC Scheme selection process, during the initial 314 negotiation. 316 The supported_fec_scheme_16b and supported_fec_scheme_32b are two new 317 TransportParameterId to be added to the "Table 7: Initial QUIC 318 Transport Parameters Entries" Section 13.1, of [QUIC-transport]. The 319 supported_fec_scheme_32b contains a 32-bit data field to carry opaque 320 32-bit value, while the supported_fec_scheme_64b contains a 64-bit 321 data field to carry opaque 64-bit value (see Section 4.2). 323 4.2. FEC Scheme Configuration Information 325 Let us now focus on the communication of configuration information 326 specific to the selected FEC Scheme. In Figure 1, the 327 supported_fec_scheme_32b{FS1_Encoding_ID} contains a field meant to 328 carry the FEC Encoding ID of the FEC Scheme selected plus addditional 329 configuration information if any. If a 32 bit opaque field is not 330 sufficient, the supported_fec_scheme_64b can be used instead and 331 proposes a 64 bit opaque field. 333 5. Procedures when Protecting a Single QUIC Stream 335 This section focusses on the simple case where FEC protection is 336 applied to a single QUIC stream. We consider a unidirectional data 337 flow between a QUIC sending endpoint and one (or more) QUIC reception 338 endpoints. 340 5.1. Application data, STREAM Frame data and Source Symbols 342 Application data is kept in a transmission buffer at a QUIC sending 343 endpoint, and sent within STREAM frames. Each STREAM frame that 344 carries data contains an Offset field that indicates the offset 345 within the stream of the first byte of the Stream Data field, as well 346 as a Length field that indicates the number of bytes contained in the 347 Stream Data field. Upon receiving a STREAM frame, using the Offset 348 and Length fields, a QUIC reception endpoint can easily store data in 349 its reception buffer. But since a QUIC Packet may be lost during 350 transmission, the reception buffer may have gaps. 352 Figure 2 illustrates how source symbols are mapped to the QUIC 353 transmission or reception buffers (same principle on either side). 354 Since any source (and repair) symbol is of fixed size (E bytes) for a 355 given stream, since QUIC guaranties that the first byte in the stream 356 has an offset of 0, the position of each source symbol is known by 357 both ends. 359 < -E- > < -E- > < -E- > < -E- > 360 +-------+-------+-------+-------+ 361 |< -- Frame 1 -- >< ----- Frame | source symbols 0, 1, 2, 3 362 +-------+-------+-------+-------+ 363 | 2 ----- >< --- Frame 3 -- >< -| source symbols 4, 5, 6, 7 364 +-------+-------+----+--+-------+ 365 | Frame 4 - >< -F5- >| source symbols 8, 9 and 10 366 +-------+-------+----+ (incomplete) 368 Figure 2: Example of source symbol mapping, when the E value is 369 relatively small. 371 Any value for E is possible, from a single byte to several hundreds 372 or thousands of bytes. In general, the source symbols are not 373 aligned with data chunks sent in the STREAM frames. A given STREAM 374 frame may carry all the bytes of a given source symbol. But when a 375 source symbol straddles two or more (e.g., if E is large compared to 376 usual frame size) STREAM frames, a proper reception of these two (or 377 more) STREAM frames is needed for a QUIC reception endpoint to 378 consider that the source symbol is available for FEC decoding 379 operations. The choice of an appropriate value for E may depend on 380 the use case (in particular on the nature of application data). A 381 reasonably small value reduces the probability that a source symbol 382 straddles two or more STREAM frames, a situation that is considered 383 as potentially harmful (the unit of control, the source symbol, and 384 unit of transmission, the frame, are not aligned). However an overly 385 small value also increases processing complexity (FEC encoding and 386 decoding are performed over a larger linear system) so there is an 387 incentive to use a larger value. An appropriate balance should be 388 found, and this choice is considered as out of scope for this 389 document. 391 5.2. Signaling Considerations within STREAM and REPAIR Frames 393 Once the initial negotiation succeeded and an appropriate FEC Scheme 394 has been chosen between the QUIC endpoints, data is exchanged as 395 follows. Source data is transmitted within STREAM frames, as would 396 happen without any FEC based loss recovery mechanism (in particular 397 without considering source symbols boundaries). Repair data, 398 computed during FEC encoding, on the opposite, is sent within a 399 dedicated REPAIR frame type, chosen within the type range dedicated 400 to "Extension Frames". In both cases, the same Stream ID is used 401 since both flows relate to the same stream. 403 The REPAIR frame format is FEC Scheme dependent. The document 404 specifying a FEC Scheme to be used with QUIC MUST define the REPAIR 405 frame format, among other things. The REPAIR frame MUST carry enough 406 information for a QUIC reception endpoint to understand exactly how 407 this repair symbol(s) has(ve) been generated. It implies that each 408 REPAIR symbol MUST communicate the block (with block codes) or 409 encoding window (with Sliding Window codes) composition. This MAY be 410 achieved by communicating in case there is no gap in the source 411 symbol set (see XXX): 413 o the offset of the first source symbol of the block or encoding 414 window; 416 o the number of source symbols in the block or encoding window, 417 which can be either a number of symbols or a number of bytes since 418 symbols are of fixed size, E. 420 Note that unlike FEC Schemes for FLUTE/ALC, NORM, and FECFRAME, here 421 there is no notion of Encoding Symbol Id (ESI), an identifier managed 422 in a sequential manner to identify source and repair symbols. The 423 use of an offset within the stream, with the guaranty that no 424 wrapping to zero can occur, provides an alternative mechanism to 425 identify any source symbol. 427 As explained above, source data is transmitted without any 428 modification, which provides backward compatibility. This is 429 advantage in situations where the same QUIC stream is delivered to 430 several QUIC reception endpoints (multicast): it may be appropriate 431 to select a given FEC Scheme even if it is known that a subset of the 432 QUIC reception endpoints do not support it. 434 Editor's notes: 436 * This I-D proposes to define a single generic REPAIR frame 437 type, but an alternative could be to have a one-to-one mapping 438 between a REPAIR frame type and a specific FEC Scheme. 440 * The use of frame type within the Extension Frames range for 441 REPAIR frames is meant to facilitate experimentations. If the 442 use of coding in QUIC is recognized as having benefits, a 443 dedicated (or more, see above) frame type could be selected 444 later on. 446 5.3. Management of Silent Periods and End of Stream 448 If an application does not submit fresh data for some time, the last 449 source symbol may not be totally filled. It follows that this last 450 source symbol cannot be considered during FEC encoding and therefore 451 the associated bytes of the application stream are not protected. A 452 similar problem arrives when a stream is finished, the application 453 having no more data to submit to QUIC. Here also, the bytes of the 454 last incomplete source symbol are not protected by FEC encoding. 456 In order to solve this problem, it is RECOMMENDED that a QUIC sending 457 endpoint: 459 o Identifies when such a situation is likely to occur, for instance 460 by waiting no more than a certain time during an application 461 silent period; 463 o Upon time-out, the application falls back to the alternative re- 464 transmission based loss recovery mechanism for the bytes of the 465 last incomplete source symbol; 467 Editor's notes: Clearly, the above mechanism requires more thoughts 468 as well as experimental work. The "end of stream" situation may 469 be addressed through zero padding perhaps easily. However the 470 use of zero padding for transitory silent periods may add a lot 471 of specification and implementation complexity... 473 6. Procedures when Protecting Several QUIC Streams 475 This section focusses on the general case where FEC protection is 476 globally applied across two or more QUIC streams. 478 Editor's notes: It is not clear whether this use-case is needed. It 479 adds specification and implementation complexity that need to be 480 balanced with the expected benefits. 482 * Receiver: A first complexity comes from the requirement to 483 identify to which stream a decoded source symbol belongs to. 484 This is also one of the main difficulty for FECFRAME (both 485 with block and sliding window codes) which required to 486 distinguish an ADU (submitted by the application) from an ADUI 487 (the same ADU plus an additional FlowID among other things). 488 Do we want this level of complexity? 490 * Sender: Another complexity comes from the encoding window 491 management at a sender. With multiple streams, shifting the 492 encoding window to the right needs to be done based on 493 timestamps associated to source symbols of the various 494 streams: the oldest source symbol across all the streams will 495 be removed. 497 * When two largely different streams are protected togethers 498 (e.g., a high definition 4K video flow plus the associated 499 relatively low-rate audio stream), is this extra complexity 500 balanced by significant performance improvements compared to 501 an independent protection on each stream (intuition is yes, 502 the low bitrate flow is better protected iff the encoding 503 window is large enough)? And when the various streams have a 504 comparable bitrate? More work (incl. experimental work) is 505 needed to answer this question. 507 6.1. Application data, STREAM Frame data and Source Symbols 509 Within each stream, the source symbols MUST be defined as in the 510 simple case of a single stream. Figure 2 remains valid. 512 6.2. Block or Encoding Window Management 514 The details of how to create the block or encoding window are 515 specific to the FEC Scheme. A possible approach is the following. 517 When creating the block (block FEC code) or encoding window (sliding 518 window FEC code), the source symbols to consider of each stream are 519 appended. All the relevant source symbols of the first stream are 520 appended, followed by all the source symbols of the second stream, 521 etc. These sequences do not follow any timing consideration in order 522 to simplify signaling. 524 Figure 3 illustrates, in case of a Sliding Window FEC Scheme, an 525 encoding window with source symbols belonging to two streams, of 526 Stream ID 120 and 51 respectively. 528 < ----------- Stream ID 120 ---------- > < --- Stream ID 51 --- > 529 +-------+-------+-------+-------+-------+-------+-------+-------+ 530 | | | | | | | | | 531 +-------+-------+-------+-------+-------+-------+-------+-------+ 532 ^ < -E- > ^ 533 | | 534 offset = 0x42f0, length = 5*E offset = 0x0f24, length = 3*E 536 Figure 3: Example of encoding window of a Sliding Window FEC Scheme 537 and FEC protection across two streams. 539 6.3. Signaling Considerations within STREAM and REPAIR Frames 541 Source data on each stream is transmitted within STREAM frames, as 542 would happen without any FEC based loss recovery mechanism. 544 Repair symbols, generated during FEC encoding as a linear combination 545 of source symbols that belong to one or more of the streams, are 546 transmitted within REPAIR frames. Each REPAIR frame can be 547 associated to any of the input streams it protects, and therefore 548 associated to any of the associated Stream IDs. 550 Editor's notes: Check that indeed, with FEC protection across 551 several streams, assigning a REPAIR frame to any of the streams 552 it protects is meaningful. Should an approach for selecting one 553 stream (and Stream ID) be preferred? 555 The REPAIR frame format is FEC Scheme dependent and MUST be defined 556 by document specifying a FEC Scheme. One of the key information of 557 this REPAIR frame is the composition of the block (with block codes) 558 or encoding window (with sliding window codes) used to perform FEC 559 encoding. Indeed, this is the only manner to convey this information 560 since an application flow is not predictable (e.g., if an application 561 flow is momentarily suspended, the composition of the block or 562 encoding window will be affected). One possibility is to list, in 563 each REPAIR frame header: 565 o the actual number of streams considered (the maximum number is 566 known after the negotiation step, but if one of the streams 567 remains silent for some time, it may not contribute during 568 encoding and therefore be absent from the block or encoding 569 window); 571 o for each stream concerned, its Stream ID, the offset of the first 572 source symbol considered as well as the length, i.e., the number 573 of bytes considered. 575 This approach does not enable to keep track of the source symbol 576 ordering across streams, but enables a non ambiguous description of 577 the encoding window. 579 The FEC Scheme specification MUST also detail how to manage the block 580 or encoding window. For instance, should the oldest source symbol of 581 any stream be removed from the encoding window when this latter is 582 shifted to the right? This would mean that a timestamp is attached 583 to each source symbol in order to identify the oldest one across all 584 streams. 586 7. Security Considerations 588 TBD 590 8. IANA Considerations 592 TBD 594 9. Acknowledgments 596 TBD 598 10. References 600 10.1. Normative References 602 [QUIC-transport] 603 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 604 Multiplexed and Secure Transport", draft-ietf-quic- 605 transport-12 (work in progress), May 2018, 606 . 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, 611 DOI 10.17487/RFC2119, March 1997, 612 . 614 10.2. Informative References 616 [nc-taxonomy] 617 Roca et al., V., "Taxonomy of Coding Techniques for 618 Efficient Network Communications", draft-irtf-nwcrg- 619 network-coding-taxonomy (Work in Progress) (work in 620 progress), March 2018, . 623 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 624 "Reed-Solomon Forward Error Correction (FEC) Schemes", 625 RFC 5510, DOI 10.17487/RFC5510, April 2009, 626 . 628 [RLC] Roca, V., "Sliding Window Random Linear Code (RLC) Forward 629 Erasure Correction (FEC) Scheme for FECFRAME", Work 630 in Progress, Transport Area Working Group (TSVWG) draft- 631 ietf-tsvwg-rlc-fec-scheme (Work in Progress), May 2018, 632 . 635 Authors' Addresses 637 Ian Swett 638 Google 639 Cambridge, MA 640 US 642 Email: ianswett@google.com 644 Marie-Jose Montpetit 645 Triangle Video 646 Boston, MA 647 US 649 Email: marie@mjmontpetit.com 651 Vincent Roca 652 INRIA 653 Univ. Grenoble Alpes 654 France 656 Email: vincent.roca@inria.fr