idnits 2.17.1 draft-swett-nwcrg-coding-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 (July 8, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8312 (ref. 'Cubic') (Obsoleted by RFC 9438) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: January 9, 2020 Triangle Video 6 V. Roca 7 INRIA 8 F. Michel 9 UCLouvain 10 July 8, 2019 12 Coding for QUIC 13 draft-swett-nwcrg-coding-for-quic-03 15 Abstract 17 This document focuses on the integration of FEC coding in the QUIC 18 transport protocol, in order to recover from packet losses. This 19 document does not specify any FEC code but defines mechanisms to 20 negotiate and integrate FEC Schemes in QUIC. By using proactive loss 21 recovery, it is expected to improve QUIC performance in sessions 22 impacted by packet losses. More precisely it is expected to improve 23 QUIC performance with real-time sessions (since FEC coding makes 24 packet loss recovery insensitive to the round trip time), with short 25 sessions (since FEC coding can help recovering from tail losses more 26 rapidely than through retransmissions), with multicast sessions 27 (since the same repair packet can recover several different losses at 28 several receivers), and with multipath sessions (since repair packets 29 add diversity and flexibility). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 9, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3 67 3. General Design Considerations . . . . . . . . . . . . . . . . 4 68 3.1. FEC Code versus FEC Scheme, Block Codes versus Sliding 69 Window Codes . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. FEC Scheme Negotiation . . . . . . . . . . . . . . . . . 5 71 3.3. FEC Protection Within an Encrypted Channel . . . . . . . 5 72 3.4. About Middleboxes . . . . . . . . . . . . . . . . . . . . 5 73 4. FEC Protection Principles . . . . . . . . . . . . . . . . . . 5 74 4.1. Cross Packet Frames FEC Encoding . . . . . . . . . . . . 5 75 4.2. Source Symbol Definition . . . . . . . . . . . . . . . . 6 76 4.2.1. Packet Payload to Packet Chunk Mapping . . . . . . . 6 77 4.2.2. Packet Chunk to Source Symbol Mapping . . . . . . . . 7 78 4.2.2.1. Open questions: Content of Source Symbols 79 Metadata? Removing certain frames from FEC 80 protection? . . . . . . . . . . . . . . . . . . . 9 81 4.2.3. Source Symbol Size (E) Considerations . . . . . . . . 10 82 4.3. Source Symbol Signaling . . . . . . . . . . . . . . . . . 11 83 4.4. Repair Symbol Signaling . . . . . . . . . . . . . . . . . 11 84 4.5. Signaling a Symbol Recovery . . . . . . . . . . . . . . . 11 85 4.6. About Gaps in the Set of Source Symbols Considered During 86 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5. FEC Scheme Negotiation in QUIC . . . . . . . . . . . . . . . 12 88 5.1. FEC Scheme Selection Process . . . . . . . . . . . . . . 13 89 5.2. FEC Scheme Configuration Information . . . . . . . . . . 14 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 9.2. Informative References . . . . . . . . . . . . . . . . . 15 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 QUIC is a new transport that aims at improving network performance by 102 enabling out of order delivery, partial reliability, and methods of 103 recovery besides retransmission, while also improving security. This 104 document specifies a framework to enable FEC codes to be used to 105 recover from lost packets within a single QUIC stream or across 106 several QUIC streams. 108 The ability to add FEC coding in QUIC may be beneficial in several 109 situations: 111 o for a robust transmission of latency sensitive traffic, for 112 instance real-time flows, since it enables to recover packet 113 losses independently of the round trip time; 115 o for short sessions, in order to protect the last few packets sent, 116 since it enables to recover from tail losses more rapidely than 117 through retransmissions; 119 o for the transmission of contents to a large set of QUIC reception 120 endpoints, since the same repair frame may help recovering several 121 different packet losses at different receivers; 123 o for multipath communications, since repair traffic adds diversity 124 and flexibility. 126 This framework does not mandate the use of any specific FEC code 127 (i.e., how to encode and decode) nor FEC Scheme (i.e., that specifies 128 both a FEC code and how to use it, in particular in terms of 129 signaling). Instead it allows to negotiate the FEC Scheme to use at 130 session startup, assuming that more than one solution could 131 potentially be offered concurrently. Without loss of generality, we 132 assume that the encoding operations compute a linear combination of 133 QUIC packets, regardless of whether these codes are of block type (as 134 with Reed-Solomon codes [RFC5510]) or sliding window type (as with 135 RLC codes [RLC]). 137 2. Definitions and Abbreviations 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 Terms and definitions that apply to coding are available in 144 [nc-taxonomy]. More specifically, this document uses the following 145 definitions: 147 Packet versus Symbol: a Packet is the unit of data that is exchanged 148 over the network while a Symbol is the unit of data that is 149 manipulated during the encoding and decoding operations 151 Source Symbol: a unit of data originating from the source that is 152 used as input to encoding operations 154 Repair Symbol: a unit of data that is the result of a coding 155 operation 157 This document uses the following abbreviations: 159 E: size of an encoding symbol (i.e., source or repair symbol), 160 assumed fixed (in bytes) 162 3. General Design Considerations 164 This section lists a few general considerations that govern the 165 framework for FEC coding support in QUIC. 167 3.1. FEC Code versus FEC Scheme, Block Codes versus Sliding Window 168 Codes 170 A FEC code specifies the details of encoding and decoding operations. 171 In addition to that, a FEC Scheme defines the additional protocol 172 aspects required to use a particular FEC code [nc-taxonomy]. In 173 particular the FEC Scheme defines signaling (e.g., information 174 contained in Source and Repair Packet header or trailers) needed to 175 synchronize encoders and decoders. 177 Block coding (e.g., Reed-Solomon [RFC5510]) and sliding window coding 178 (e.g., RLC [RLC]) are two broad classes of FEC codes [nc-taxonomy]. 179 In the first case, the input flow must be first segmented into a 180 sequence of blocks, FEC encoding and decoding being performed 181 independently on a per-block basis. In the second case rely, a 182 sliding encoding window continuously slides over the input flow. It 183 is envisioned that the two classes of codes could be used to bring 184 FEC protection to QUIC, usually with an advantage for sliding window 185 codes when it comes to low latency communications. 187 3.2. FEC Scheme Negotiation 189 There are multiple FEC Scheme candidates. Therefore a negotiation 190 step is needed to select one or more codes to be used over a QUIC 191 session. This will be implemented using the one step negotiation of 192 the new QUIC negotiation mechanism [QUIC-transport], during the QUIC 193 handshake. 195 Editor's notes: 197 * It is likely that FEC Scheme negotiation requires the use of a 198 new dedicated Extension Frame Type. To Be Clarified and text 199 updated. 201 * It is not clear whether negotiation is meant to select a 202 **single** FEC Scheme or **multiple** FEC Schemes. In the 203 second case (multiple FEC) it is required to have a 204 complementary mechanism to indicate which FEC Scheme is used 205 in a given REPAIR frame (which could be done through as many 206 REPAIR frame type values as potential FEC Scheme negotiated). 207 Is it what we want to achieve? Not sure. 209 3.3. FEC Protection Within an Encrypted Channel 211 FEC encoding is applied before any QUIC encryption and authentication 212 processing. Source symbols, that constitute the data units used by 213 the FEC codec, contain cleartext data (application and/or QUIC data). 215 3.4. About Middleboxes 217 The coding approach described in this document does not allow on path 218 elements (middleboxes) to take part in FEC protection. The traffic 219 being encrypted end-to-end, the middleboxes are not in position to 220 perform FEC decoding, nor to add any redundant traffic. 222 4. FEC Protection Principles 224 The present section explains how FEC encoding can be applied to QUIC. 225 It defines the general ideas for mapping QUIC packet frames to source 226 symbols, as well as the associated signaling. This section does not 227 define the FEC Scheme specific details that need to be specified in a 228 companion document. 230 4.1. Cross Packet Frames FEC Encoding 232 A QUIC packet payload consists in a set of QUIC frames. These frames 233 either carry application data (e.g., in a STREAM or DATAGRAM frame) 234 or control information (e.g., a MAX_DATA frame). Each packet is 235 either entirely received or lost, and is uniquely identified by a 236 monotonically increasing Packet Number. 238 Through the use of FEC encoding, application data can be protected 239 proactively against packet losses, without requiring to go through 240 packet retransmission. In addition to application data, QUIC 241 transfers might benefit from protecting control frames having a 242 potential impact on the transmission throughput, such as MAX_DATA or 243 MAX_STREAM_DATA frames. Therefore this document introduces an FEC 244 protection across all -- or a subset of -- the frames of a given QUIC 245 packet. This design choice impacts the QUIC packet to source symbols 246 mapping, as well as signaling aspects, both of them being discussed 247 hereafter. 249 4.2. Source Symbol Definition 251 The cross packet frames FEC encoding approach considers the sequence 252 of frames (or a sub-sequence of them) transmitted within a given QUIC 253 packet, seen as the QUIC packet payload. From this payload, it 254 defines a mapping to source symbols (see Section 4.2.1 and 255 Section 4.2.2). Source symbols are then used for encoding purposes, 256 producing one or more repair symbols, the details of which depend on 257 the FEC Scheme considered. However source symbols are never sent per 258 se on the network. Instead the original QUIC packet, plus a 259 dedicated signaling header, are sent and therefore implicitely carry 260 those source symbols. The QUIC packets, containing one or more 261 repair symbols, are sent on the network. 263 The only modification to the original QUIC packet is the addition of 264 a dedicated FEC_SRC_FPI frame type, meant to carry source symbol 265 signaling (known as Source FEC Payload Information, or FPI). On the 266 opposite, frames that carry one or more repair symbols use a 267 dedicated REPAIR frame type. In both cases, in order to facilitate 268 experiments and enable backward compatibility, the FEC_SRC_FPI and 269 REPAIR frame types are chosen within the type range dedicated to 270 "Extension Frames". Thereby, a legacy receiver will automatically 271 ignore these unknown frame types. As QUIC packets can be of 272 different lengths, a special care must be taken to ensure having a 273 fixed Source Symbol size to ease FEC Scheme implementations. 275 4.2.1. Packet Payload to Packet Chunk Mapping 277 This section defines a mechanism to segment a QUIC packet payload, 278 composed of several frames, into fixed-size payload chunks, of size 279 E-1 bytes or E-1-4 bytes for the first chunk when the QUIC Packet 280 Number needs to be added ((Section 4.2.2). Depending on the relative 281 value of E-1 (or E-1-4) and the QUIC packet payload size, a packet 282 can potentially contain more than one chunks. This is a first step 283 into producing source symbols. Figure 1 illustrates this process. 285 ||< E-1 >|< E-1 >|< E-1 >| 286 | | | | | 287 +------|-------|-------|-------|-------| 288 QUIC pkt 0 |Header| Packet Payload | chunks 0, 1, 2, 3 289 +------|-----+-|-------|-------|-------+ 290 QUIC pkt 1 |Header| 0 | Packet Payload | chunks 4, 5, 6 291 +------|---+-+-|-------|-------| 292 QUIC pkt 2 |Header| 0 | Packet Payload | chunks 7, 8, 9 293 +------|---+---|-------|-------| 295 Figure 1: Example of QUIC packet to chunk mapping, when the E-1 value 296 is relatively small, with prepended zero padding when needed (here 297 packets 1 and 2), and assuming the first chunk contains the QUIC 298 Packet Number in 4 bytes compressed version. 300 4.2.2. Packet Chunk to Source Symbol Mapping 302 The second step consists in producing the source symbols. A source 303 symbols is the concatenation of a single byte of metadata, 304 potentially followed by the Packet Number of the associated source, 305 plus a packet chunk. Figure 2 illustrates the situation where a 306 compressed QUIC packet number is added (in general for the first 307 chunk of a QUIC packet). Figure 3 illustrates the situation where 308 there is no QUIC packet number (in general for the following chunk(s) 309 of a QUIC packet). When the QUIC packet number is present, this 310 identifier can be recovered by a receiver after successful FEC 311 decoding. It means that a RECOVERED frame can be generated to the 312 sender to indicated that this packet (identified by the QUIC packet 313 number) has been recovered. Each source symbol is of fixed-size E 314 bytes. These source symbols are only used during encoding and 315 decoding and are not sent as-is on the network. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+ 320 | meta data | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Packet Number (4 bytes) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Packet chunk (E-1-4 bytes) ... 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 2: Source symbol format with Packet Number information (e.g., 328 first packet chunk). 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+ 333 | meta data | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Packet chunk (E-1 bytes) ... 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 3: Source symbol format without Packet Number information 339 (e.g., packet chunks except the first one). 341 7 6 5 4 3 2 1 0 342 +-+-+-+-+-+-+-+-+ 343 |Resvd (0)|N|S|E| 344 +-+-+-+-+-+-+-+-+ 346 Figure 4: Source symbol metadata format. 348 Figure 4 shows the format of the 1 byte metadata. The fields are the 349 following: 351 Reserved field (5 bits): for this specification, this field MUST be 352 equal to zero. 354 Packet Number (N) field (1 bit): this field indicates that the 355 following 4 bytes contain the Packet Number (short 32-bit 356 representation) of the associated QUIC packet ([QUIC-transport] 357 section 17.1., Packet Number Encoding and Decoding). 359 Start (S) bit (1 bit): this field, when set to 1, indicates that 360 this source symbol contains the first chunk of the packet 361 payload. 363 End bit (E) (1 bit): this field, when set to 1, indicates that this 364 source symbol contains the last chunk of the packet payload. 366 Note that with a QUIC packet containing a single chunk, the 367 associated metadata will contain S=E=1. On the opposite, a source 368 symbol containing a intermediate chunk (i.e., neither the first nor 369 the last chunk of the QUIC packet), the associated metadata will 370 contain S=E=0. 372 QUIC packet 373 ||< E-1 >|< E-1 >|< E-1 >| 374 +------|----+--|-------|-------|-------| 375 |Header| 0 | Packet Payload | 4 packet chunks 376 +------|----+--|-------|-------|-------| 377 / | | \ 378 v v v v 379 +-+--+----+ +-+-------+ +-+-------+ +-+-------+ 380 |m|pn|chnk| |m| chunk| |m| chunk| |m| chunk| 4 source symbols 381 +-+--+----+ +-+-------+ +-+-------+ +-+-------+ 382 | | | | | | | | 383 |< --E-- >| |< --E-- >| |< --E-- >| |< --E-- >| 385 Figure 5: Example of packet chunk to source symbol mapping, when the 386 E value is relatively small, in presence of the QUIC Packet Number 387 for the first chunk. 389 Figure 5 shows an example where the 4 source symbols are created from 390 the payload of a given QUIC packet. The first chunk may contain zero 391 padding at the begining in order to align the protected packet 392 payload size to a multiple of E-1, and the first source symbol may 393 contain the QUIC Packet Number. 395 Each source symbol is uniquely identified allowing to determine 396 unambiguously its position in the source symbol flow. What 397 information to associate to a source symbol to uniquely identify it 398 is FEC Scheme dependant. Section 4.3 gives insight on this topic. 400 4.2.2.1. Open questions: Content of Source Symbols Metadata? Removing 401 certain frames from FEC protection? 403 NB: section to remove once fixed. 405 During the FEC encoding phase, additional data can be added to the 406 source symbol. These data are only added during the encoding and 407 MUST NOT be transmitted on the network. The encoder and decoder MUST 408 agree on the addition of these data to the source symbol in order to 409 avoid decoding errors. Here are some examples of data that can be 410 added to a source symbol during encoding and that will be decoded 411 upon a source symbol recovery: 413 o The packet number: adding the packet number allows the decoder to 414 know which packet has been recovered and potentially send a 415 feedback of which packet has been recovered to the QUIC sender. 417 o Additional QUIC frames: the FEC encoder can for example add 418 PADDING frames to a source symbol before proceeding to encoding. 419 Adding PADDING frames to source symbols before encoding allows 420 protecting packets of different sizes. The smaller packet payload 421 will be added PADDING frames to reach a size that is a multiple of 422 E-1. 424 Note: Maybe the decision of adding data such as padding in the 425 source symbols should be left to the underlying FEC Scheme. 427 Besides adding data to source symbols before encoding, some frames 428 can be removed from the source symbol if their protection is not 429 crucial for the transmission in order to reduce the size of the 430 source symbol. For example, ACK frames can be systematically 431 stripped out of the source symbols. Stream frames of non-delay- 432 sensitive streams could also be removed from the source symbol. The 433 encoder and decoder MUST agree on which frames must be stripped out 434 of packet payloads. This information might for example be encoded in 435 the Source Symbol ID by the FEC encoder. 437 Note: We might want to propose standard ways/algorithms to add/ 438 remove data before the encoding ? 440 TODO: Add a mechanism to add QUIC packet identifier to the metadata. 441 It's useful. 443 4.2.3. Source Symbol Size (E) Considerations 445 The source symbol size, E, MUST be strictly greater than zero bytes 446 and strictly smaller than the minimum PMTU value allowed by QUIC. 447 The packet header is not part of the FEC-protected data. When the 448 packet payload size is not a multiple of E-1, zero-padding MUST be 449 added at the beginning of the first chunk of the packet payload. 450 This is equivalent to inserting PADDING frames at the beginning of 451 the payload. This zero-padding, only used for FEC encoding, SHOULD 452 NOT be sent on the wire. 454 The choice of an appropriate value for E may depends on the use case 455 (in particular on the nature of application data). A reasonably 456 small value reduces the expected value of the added padding needed to 457 align the payload size with a multiple of E-1, which can be a good 458 approach when dealing with QUIC packets whose size significantly 459 vary. However an overly small value also increases processing 460 complexity (FEC encoding and decoding are performed over a larger 461 linear system since there are more source symbols), so there is an 462 incentive to use a larger value. An appropriate balance should be 463 found, and this choice is considered as out of scope for this 464 document. Since a repair symbol will transit through a frame, the E 465 value must take this into account to avoid having REPAIR frames that 466 do not fit into a single QUIC packet. 468 4.3. Source Symbol Signaling 470 An explicit signaling is needed by a decoder to identify the source 471 symbols and their position in the block (i.e., for block codes) or 472 coding window (i.e., for sliding window codes). While the QUIC 473 packet number increases monotonically, it cannot be used to identify 474 the position of a packet in the coding window as the packet number is 475 not needed to increase by 1 for each new packet. There is thus an 476 ambiguity on the decoder-side between lost packets and packets that 477 do not exist. Similarly to FECFRAME, we propose to assign a 478 identifier to source symbols to avoid this ambiguity. This 479 identifier is opaque to the protocol and will be defined by the 480 underlying FEC schemes. This is out of the scope of this document. 481 An example of identifier could be an integer increasing by 1 for each 482 new source symbol 484 In order to announce the source symbol identifier to the FEC decoder, 485 we propose to add a new frame, the FEC_SRC_FPI frame to packets whose 486 payload will contain one or more source symbols from the FEC decoder 487 point of view. The FEC_SRC_FPI frame is part of the packet payload 488 itself. Any packet containing a FEC_SRC_FPI frame MUST see its 489 payload considered as one or more source symbol(s). 491 The FEC_SRC_FPI frame format is FEC Scheme specific and MUST be 492 specified in the associated document. 494 4.4. Repair Symbol Signaling 496 An explicit signaling is needed by a decoder for each repair symbol 497 received through a REPAIR frame. The goals are manyfold: identifying 498 the repair symbols and their position in the block (i.e., for block 499 codes) or coding window (i.e., for sliding window codes); carrying 500 information on the way this repair symbol has been produced (e.g., 501 with sliding window codes, it can indicate the encoding window 502 composition). 504 One or more repair symbols can be present in a given QUIC packet. 505 When there are multiple symbols, they SHOULD be concatenated in the 506 same REPAIR frame. How to achieve this goal is FEC Scheme specific 507 and therefore must be defined in the document describing this FEC 508 Scheme. 510 4.5. Signaling a Symbol Recovery 512 When all the source symbols of a given QUIC packet have been lost but 513 are recovered during FEC decoding, a QUIC receiver SHOULD advertise 514 it to the sender in order to avoid the retransmission of already 515 available data. However, the QUIC receiver MUST NOT acknowledge this 516 recovered packet through a regular acknowledement, as it would 517 interfere with the behaviour of loss-based congestion controls such 518 as [Cubic]. Therefore this document introduces a dedicated RECOVERED 519 frame, that enables a receiver to indicate that a specific QUIC 520 packet has been recovered through FEC decoding. 522 The RECOVERED frame works at the packet level. It is therefore 523 required to be able to identify to which packet the recovered source 524 symbols belong to. This is made possible by the QUIC packet 525 identifier field added to the meta data prior to FEC encoding 526 (Section 4.2.2). 528 4.6. About Gaps in the Set of Source Symbols Considered During Encoding 530 A given FEC Scheme MAY support or not the presence of gaps in the set 531 of source symbols that constitute a block (for Block codes) or an 532 encoding window (for Sliding Window codes). A potential cause for 533 non contiguous sets of source symbols is the acknowledgment of one of 534 them. When this happens, the QUIC sending endpoint may want to 535 remove this source symbol from further FEC encodings. This is 536 particularly true with Sliding Window codes because of their 537 flexibility during FEC encoding (i.e., the encoding window can change 538 between two consecutive FEC encodings). 540 Supporting gaps can be motivated by the desire to reduce encoding and 541 decoding complexity since there are fewer variables. However this 542 choice has major consequences in terms of signaling. Indeed each 543 repair symbol transmitted MUST be accompanied with enough information 544 for the QUIC decoding endpoint to unambiguously identify the exact 545 composition of the block or encoding window. Without any gap, the 546 identity of the first source symbol plus the number of symbols in the 547 block or encoding window is sufficient. With gaps, a more complex 548 encoding needs to be used, perhaps similar to the encoding used for 549 selective acknowledgments. 551 Whether or not gaps are supported MUST be clarified in each FEC 552 Scheme. 554 5. FEC Scheme Negotiation in QUIC 556 FEC Scheme negotiation has two goals: 558 o Selecting a FEC Scheme (or FEC Schemes) that can be used by the 559 QUIC transmission and reception endpoints. This process requires 560 an exchange between them; 562 o Communicating a certain number of parameters, the "Configuration 563 Information", that are not expected to change over the session 564 lifetime. For instance, this is the case of the symbol size 565 parameter, E (in bytes), that needs either to be agreed between 566 the endpoints, or chosen by the sender and communicated to the 567 receiver(s); 569 Editor's notes: 571 * It is likely that FEC Scheme negotiation requires the use of a 572 new dedicated Extension Frame Type. The details remain TBD. 574 * The Negotiation Frame Type format remains TBD. 576 * How to communicate the parameters remains TBD. 578 * The present document only provides high level principles, the 579 details are of course the responsibility of the FEC Scheme. 581 * In case negotiation is different when protecting a single 582 versus several streams, this section may be moved to the 583 respective sections. 585 * How does it work in case of a multicast session? 587 * Do we negotiate here a FEC Scheme on a per-Stream basis (or 588 group of Streams to be protected jointly)? Or do we negotiate 589 a FEC Scheme on a QUIC session basis, therefore to be used for 590 all the Streams that need FEC protection? 592 5.1. FEC Scheme Selection Process 594 Let us consider the FEC Scheme selection process between the QUIC 595 endpoints. Figure 6 illustrates the principle when a QUIC reception 596 endpoint initiates the exchange. 598 QUIC sender QUIC receiver 599 < - - - - - - - - - - - - - - - - - - - - - - 600 supported_fec_scheme_32b{FEC_Encoding_ID1 | other} 601 supported_fec_scheme_64b{FEC_Encoding_ID2 | other} 603 choose FEC Scheme 1 604 - - - - - - - - - - - - - - - - - - - - - - > 605 supported_fec_scheme_32b{FEC_Encoding_ID1 | other} 607 Figure 6: Example FEC Scheme selection process, during the initial 608 negotiation. 610 The supported_fec_scheme_16b and supported_fec_scheme_32b are two new 611 TransportParameterId to be added to the "Table 7: Initial QUIC 612 Transport Parameters Entries" Section 13.1, of [QUIC-transport]. The 613 supported_fec_scheme_32b contains a 32-bit data field to carry opaque 614 32-bit value, while the supported_fec_scheme_64b contains a 64-bit 615 data field to carry opaque 64-bit value (see Section 5.2). 617 It is possible that the QUIC endpoint that receives one or more FEC 618 Scheme proposals from the initiator cannot select any of them. In 619 that case the negotiation process fails... 621 Editor's notes: 623 * So what? How does it finishes? Consequences? 625 * Can the second QUIC endpoint change the proposed static 626 parameters? In that case can the initator refuse? 628 5.2. FEC Scheme Configuration Information 630 Let us now focus on the communication of configuration information 631 specific to the selected FEC Scheme. In Figure 6, the 632 supported_fec_scheme_32b{FS1_Encoding_ID} contains a field meant to 633 carry the FEC Encoding ID of the FEC Scheme selected plus addditional 634 configuration information if any. If a 32 bit opaque field is not 635 sufficient, the supported_fec_scheme_64b can be used instead and 636 proposes a 64 bit opaque field. 638 6. Security Considerations 640 TBD 642 7. IANA Considerations 644 TBD 646 8. Acknowledgments 648 TBD 650 9. References 652 9.1. Normative References 654 [Cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 655 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 656 RFC 8312, DOI 10.17487/RFC8312, February 2018, 657 . 659 [QUIC-transport] 660 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 661 Multiplexed and Secure Transport", draft-ietf-quic- 662 transport (Work in Progress) (work in progress), January 663 2019, . 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, 668 DOI 10.17487/RFC2119, March 1997, 669 . 671 9.2. Informative References 673 [nc-taxonomy] 674 Roca (Ed.) et al., V., "Taxonomy of Coding Techniques for 675 Efficient Network Communications", Request For 676 Comments RFC 8406, June 2018, 677 . 680 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 681 "Reed-Solomon Forward Error Correction (FEC) Schemes", 682 RFC 5510, DOI 10.17487/RFC5510, April 2009, 683 . 685 [RLC] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 686 (RLC) Forward Erasure Correction (FEC) Scheme for 687 FECFRAME", Work in Progress, Transport Area Working Group 688 (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in 689 Progress), June 2019, . 692 Authors' Addresses 694 Ian Swett 695 Google 696 Cambridge, MA 697 US 699 Email: ianswett@google.com 700 Marie-Jose Montpetit 701 Triangle Video 702 Boston, MA 703 US 705 Email: marie@mjmontpetit.com 707 Vincent Roca 708 INRIA 709 Univ. Grenoble Alpes 710 France 712 Email: vincent.roca@inria.fr 714 Francois Michel 715 UCLouvain 716 Louvain-la-Neuve 717 Belgium 719 Email: francois.michel@uclouvain.be