idnits 2.17.1 draft-swett-nwcrg-coding-for-quic-04.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 == Line 603 has weird spacing: '... varint fec_...' -- The document date (March 9, 2020) is 1499 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 (~~), 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: September 10, 2020 Triangle Video 6 V. Roca 7 INRIA 8 F. Michel 9 UCLouvain 10 March 9, 2020 12 Coding for QUIC 13 draft-swett-nwcrg-coding-for-quic-04 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 September 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . 4 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 Negotiation . . . . . . . . . . . . . . . . . 13 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 94 9.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 QUIC is a new transport that aims at improving network performance by 100 enabling out of order delivery, partial reliability, and methods of 101 recovery besides retransmission, while also improving security. This 102 document specifies a framework to enable FEC codes to be used to 103 recover from lost packets within a single QUIC stream or across 104 several QUIC streams. 106 The ability to add FEC coding in QUIC may be beneficial in several 107 situations: 109 o for a robust transmission of latency sensitive traffic, for 110 instance real-time flows, since it enables to recover packet 111 losses independently of the round trip time; 113 o for short sessions, in order to protect the last few packets sent, 114 since it enables to recover from tail losses more rapidely than 115 through retransmissions; 117 o for the transmission of contents to a large set of QUIC reception 118 endpoints, since the same repair frame may help recovering several 119 different packet losses at different receivers; 121 o for multipath communications, since repair traffic adds diversity 122 and flexibility. 124 This framework does not mandate the use of any specific FEC code 125 (i.e., how to encode and decode) nor FEC Scheme (i.e., that specifies 126 both a FEC code and how to use it, in particular in terms of 127 signaling). Instead it allows to negotiate the FEC Scheme to use at 128 session startup, assuming that more than one solution could 129 potentially be offered concurrently. Without loss of generality, we 130 assume that the encoding operations compute a linear combination of 131 QUIC packets, regardless of whether these codes are of block type (as 132 with Reed-Solomon codes [RFC5510]) or sliding window type (as with 133 RLC codes [RFC8681]). 135 2. Definitions and Abbreviations 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 Terms and definitions that apply to coding are available in 142 [nc-taxonomy]. More specifically, this document uses the following 143 definitions: 145 Packet versus Symbol: a Packet is the unit of data that is exchanged 146 over the network while a Symbol is the unit of data that is 147 manipulated during the encoding and decoding operations 149 Source Symbol: a unit of data originating from the source that is 150 used as input to encoding operations 152 Repair Symbol: a unit of data that is the result of a coding 153 operation 155 This document uses the following abbreviations: 157 E: size of an encoding symbol (i.e., source or repair symbol), 158 assumed fixed (in bytes) 160 3. General Design Considerations 162 This section lists a few general considerations that govern the 163 framework for FEC coding support in QUIC. 165 3.1. FEC Code versus FEC Scheme, Block Codes versus Sliding Window 166 Codes 168 A FEC code specifies the details of encoding and decoding operations. 169 In addition to that, a FEC Scheme defines the additional protocol 170 aspects required to use a particular FEC code [nc-taxonomy]. In 171 particular the FEC Scheme defines signaling (e.g., information 172 contained in Source and Repair Packet header or trailers) needed to 173 synchronize encoders and decoders. 175 Block coding (e.g., Reed-Solomon [RFC5510]) and sliding window coding 176 (e.g., RLC [RFC8681]) are two broad classes of FEC codes 177 [nc-taxonomy]. In the first case, the input flow must be first 178 segmented into a sequence of blocks, FEC encoding and decoding being 179 performed independently on a per-block basis. In the second case 180 rely, a sliding encoding window continuously slides over the input 181 flow. It is envisioned that the two classes of codes could be used 182 to bring FEC protection to QUIC, usually with an advantage for 183 sliding window codes when it comes to low latency communications. 185 3.2. FEC Scheme Negotiation 187 There are multiple FEC Scheme candidates. Therefore a negotiation 188 step is needed to select one or more codes to be used over a QUIC 189 session. This will be implemented using the one step negotiation of 190 the new QUIC negotiation mechanism [QUIC-transport], during the QUIC 191 handshake. 193 Editor's notes: 195 * It is likely that FEC Scheme negotiation requires the use of a 196 new dedicated Extension Frame Type. To Be Clarified and text 197 updated. 199 * It is not clear whether negotiation is meant to select a 200 **single** FEC Scheme or **multiple** FEC Schemes. In the 201 second case (multiple FEC) it is required to have a 202 complementary mechanism to indicate which FEC Scheme is used 203 in a given REPAIR frame (which could be done through as many 204 REPAIR frame type values as potential FEC Scheme negotiated). 205 Is it what we want to achieve? Not sure. 207 3.3. FEC Protection Within an Encrypted Channel 209 FEC encoding is applied before any QUIC encryption and authentication 210 processing. Source symbols, that constitute the data units used by 211 the FEC codec, contain cleartext data (application and/or QUIC data). 213 3.4. About Middleboxes 215 The coding approach described in this document does not allow on path 216 elements (middleboxes) to take part in FEC protection. The traffic 217 being encrypted end-to-end, the middleboxes are not in position to 218 perform FEC decoding, nor to add any redundant traffic. 220 4. FEC Protection Principles 222 The present section explains how FEC encoding can be applied to QUIC. 223 It defines the general ideas for mapping QUIC packet frames to source 224 symbols, as well as the associated signaling. This section does not 225 define the FEC Scheme specific details that need to be specified in a 226 companion document. 228 4.1. Cross Packet Frames FEC Encoding 230 A QUIC packet payload consists in a set of QUIC frames. These frames 231 either carry application data (e.g., in a STREAM or DATAGRAM frame) 232 or control information (e.g., a MAX_DATA frame). Each packet is 233 either entirely received or lost, and is uniquely identified by a 234 monotonically increasing Packet Number. 236 Through the use of FEC encoding, application data can be protected 237 proactively against packet losses, without requiring to go through 238 packet retransmission. In addition to application data, QUIC 239 transfers might benefit from protecting control frames having a 240 potential impact on the transmission throughput, such as MAX_DATA or 241 MAX_STREAM_DATA frames. Therefore this document introduces an FEC 242 protection across all -- or a subset of -- the frames of a given QUIC 243 packet. This design choice impacts the QUIC packet to source symbols 244 mapping, as well as signaling aspects, both of them being discussed 245 hereafter. 247 4.2. Source Symbol Definition 249 The cross packet frames FEC encoding approach considers the sequence 250 of frames (or a sub-sequence of them) transmitted within a given QUIC 251 packet, seen as the QUIC packet payload. From this payload, it 252 defines a mapping to source symbols (see Section 4.2.1 and 253 Section 4.2.2). Source symbols are then used for encoding purposes, 254 producing one or more repair symbols, the details of which depend on 255 the FEC Scheme considered. However source symbols are never sent per 256 se on the network. Instead the original QUIC packet, plus a 257 dedicated signaling header, are sent and therefore implicitely carry 258 those source symbols. The QUIC packets, containing one or more 259 repair symbols, are sent on the network. 261 The only modification to the original QUIC packet is the addition of 262 a dedicated FEC_SRC_FPI frame type, meant to carry source symbol 263 signaling (known as Source FEC Payload Information, or FPI). On the 264 opposite, frames that carry one or more repair symbols use a 265 dedicated REPAIR frame type. In both cases, in order to facilitate 266 experiments and enable backward compatibility, the FEC_SRC_FPI and 267 REPAIR frame types are chosen within the type range dedicated to 268 "Extension Frames". Thereby, a legacy receiver will automatically 269 ignore these unknown frame types. As QUIC packets can be of 270 different lengths, a special care must be taken to ensure having a 271 fixed Source Symbol size to ease FEC Scheme implementations. 273 4.2.1. Packet Payload to Packet Chunk Mapping 275 This section defines a mechanism to segment a QUIC packet payload, 276 composed of several frames, into fixed-size payload chunks, of size 277 E-1 bytes or E-1-4 bytes for the first chunk when the QUIC Packet 278 Number needs to be added ((Section 4.2.2). Depending on the relative 279 value of E-1 (or E-1-4) and the QUIC packet payload size, a packet 280 can potentially contain more than one chunks. This is a first step 281 into producing source symbols. Figure 1 illustrates this process. 283 ||< E-1 >|< E-1 >|< E-1 >| 284 | | | | | 285 +------|-------|-------|-------|-------| 286 QUIC pkt 0 |Header| Packet Payload | chunks 0, 1, 2, 3 287 +------|-----+-|-------|-------|-------+ 288 QUIC pkt 1 |Header| 0 | Packet Payload | chunks 4, 5, 6 289 +------|---+-+-|-------|-------| 290 QUIC pkt 2 |Header| 0 | Packet Payload | chunks 7, 8, 9 291 +------|---+---|-------|-------| 293 Figure 1: Example of QUIC packet to chunk mapping, when the E-1 value 294 is relatively small, with prepended zero padding when needed (here 295 packets 1 and 2), and assuming the first chunk contains the QUIC 296 Packet Number in 4 bytes compressed version. 298 4.2.2. Packet Chunk to Source Symbol Mapping 300 The second step consists in producing the source symbols. A source 301 symbols is the concatenation of a single byte of metadata, 302 potentially followed by the Packet Number of the associated source, 303 plus a packet chunk. Figure 2 illustrates the situation where a 304 compressed QUIC packet number is added (in general for the first 305 chunk of a QUIC packet). Figure 3 illustrates the situation where 306 there is no QUIC packet number (in general for the following chunk(s) 307 of a QUIC packet). When the QUIC packet number is present, this 308 identifier can be recovered by a receiver after successful FEC 309 decoding. It means that a RECOVERED frame can be generated to the 310 sender to indicated that this packet (identified by the QUIC packet 311 number) has been recovered. Each source symbol is of fixed-size E 312 bytes. These source symbols are only used during encoding and 313 decoding and are not sent as-is on the network. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+ 318 | meta data | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Packet Number (4 bytes) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Packet chunk (E-1-4 bytes) ... 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 2: Source symbol format with Packet Number information (e.g., 326 first packet chunk). 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+ 331 | meta data | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Packet chunk (E-1 bytes) ... 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 3: Source symbol format without Packet Number information 337 (e.g., packet chunks except the first one). 339 7 6 5 4 3 2 1 0 340 +-+-+-+-+-+-+-+-+ 341 |Resvd (0)|N|S|E| 342 +-+-+-+-+-+-+-+-+ 344 Figure 4: Source symbol metadata format. 346 Figure 4 shows the format of the 1 byte metadata. The fields are the 347 following: 349 Reserved field (5 bits): for this specification, this field MUST be 350 equal to zero. 352 Packet Number (N) field (1 bit): this field indicates that the 353 following 4 bytes contain the Packet Number (short 32-bit 354 representation) of the associated QUIC packet ([QUIC-transport] 355 section 17.1., Packet Number Encoding and Decoding). 357 Start (S) bit (1 bit): this field, when set to 1, indicates that 358 this source symbol contains the first chunk of the packet 359 payload. 361 End bit (E) (1 bit): this field, when set to 1, indicates that this 362 source symbol contains the last chunk of the packet payload. 364 Note that with a QUIC packet containing a single chunk, the 365 associated metadata will contain S=E=1. On the opposite, a source 366 symbol containing a intermediate chunk (i.e., neither the first nor 367 the last chunk of the QUIC packet), the associated metadata will 368 contain S=E=0. 370 QUIC packet 371 ||< E-1 >|< E-1 >|< E-1 >| 372 +------|----+--|-------|-------|-------| 373 |Header| 0 | Packet Payload | 4 packet chunks 374 +------|----+--|-------|-------|-------| 375 / | | \ 376 v v v v 377 +-+--+----+ +-+-------+ +-+-------+ +-+-------+ 378 |m|pn|chnk| |m| chunk| |m| chunk| |m| chunk| 4 source symbols 379 +-+--+----+ +-+-------+ +-+-------+ +-+-------+ 380 | | | | | | | | 381 |< --E-- >| |< --E-- >| |< --E-- >| |< --E-- >| 383 Figure 5: Example of packet chunk to source symbol mapping, when the 384 E value is relatively small, in presence of the QUIC Packet Number 385 for the first chunk. 387 Figure 5 shows an example where the 4 source symbols are created from 388 the payload of a given QUIC packet. The first chunk may contain zero 389 padding at the beginning in order to align the protected packet 390 payload size to a multiple of E-1, and the first source symbol may 391 contain the QUIC Packet Number. 393 Each source symbol is uniquely identified allowing to determine 394 unambiguously its position in the source symbol flow. What 395 information to associate to a source symbol to uniquely identify it 396 is FEC Scheme dependent. Section 4.3 gives insight on this topic. 398 4.2.2.1. Open questions: Content of Source Symbols Metadata? Removing 399 certain frames from FEC protection? 401 NB: section to remove once fixed. 403 During the FEC encoding phase, additional data can be added to the 404 source symbol. These data are only added during the encoding and 405 MUST NOT be transmitted on the network. The encoder and decoder MUST 406 agree on the addition of these data to the source symbol in order to 407 avoid decoding errors. Here are some examples of data that can be 408 added to a source symbol during encoding and that will be decoded 409 upon a source symbol recovery: 411 o The packet number: adding the packet number allows the decoder to 412 know which packet has been recovered and potentially send a 413 feedback of which packet has been recovered to the QUIC sender. 415 o Additional QUIC frames: the FEC encoder can for example add 416 PADDING frames to a source symbol before proceeding to encoding. 417 Adding PADDING frames to source symbols before encoding allows 418 protecting packets of different sizes. The smaller packet payload 419 will be added PADDING frames to reach a size that is a multiple of 420 E-1. 422 Note: Maybe the decision of adding data such as padding in the 423 source symbols should be left to the underlying FEC Scheme. 425 Besides adding data to source symbols before encoding, some frames 426 can be removed from the source symbol if their protection is not 427 crucial for the transmission in order to reduce the size of the 428 source symbol. For example, ACK frames can be systematically 429 stripped out of the source symbols. Stream frames of non-delay- 430 sensitive streams could also be removed from the source symbol. The 431 encoder and decoder MUST agree on which frames must be stripped out 432 of packet payloads. This information might for example be encoded in 433 the Source Symbol ID by the FEC encoder. 435 Note: We might want to propose standard ways/algorithms to add/ 436 remove data before the encoding ? 438 TODO: Add a mechanism to add QUIC packet identifier to the metadata. 439 It's useful. 441 4.2.3. Source Symbol Size (E) Considerations 443 The source symbol size, E, MUST be strictly greater than zero bytes 444 and strictly smaller than the minimum PMTU value allowed by QUIC. 445 The packet header is not part of the FEC-protected data. When the 446 packet payload size is not a multiple of E-1, zero-padding MUST be 447 added at the beginning of the first chunk of the packet payload. 448 This is equivalent to inserting PADDING frames at the beginning of 449 the payload. This zero-padding, only used for FEC encoding, SHOULD 450 NOT be sent on the wire. 452 The choice of an appropriate value for E may depends on the use case 453 (in particular on the nature of application data). A reasonably 454 small value reduces the expected value of the added padding needed to 455 align the payload size with a multiple of E-1, which can be a good 456 approach when dealing with QUIC packets whose size significantly 457 vary. However an overly small value also increases processing 458 complexity (FEC encoding and decoding are performed over a larger 459 linear system since there are more source symbols), so there is an 460 incentive to use a larger value. An appropriate balance should be 461 found, and this choice is considered as out of scope for this 462 document. Since a repair symbol will transit through a frame, the E 463 value must take this into account to avoid having REPAIR frames that 464 do not fit into a single QUIC packet. 466 4.3. Source Symbol Signaling 468 An explicit signaling is needed by a decoder to identify the source 469 symbols and their position in the block (i.e., for block codes) or 470 coding window (i.e., for sliding window codes). While the QUIC 471 packet number increases monotonically, it cannot be used to identify 472 the position of a packet in the coding window as the packet number is 473 not needed to increase by 1 for each new packet. There is thus an 474 ambiguity on the decoder-side between lost packets and packets that 475 do not exist. Similarly to FECFRAME, we propose to assign a 476 identifier to source symbols to avoid this ambiguity. This 477 identifier is opaque to the protocol and will be defined by the 478 underlying FEC schemes. This is out of the scope of this document. 479 An example of identifier could be an integer increasing by 1 for each 480 new source symbol 482 In order to announce the source symbol identifier to the FEC decoder, 483 we propose to add a new frame, the FEC_SRC_FPI frame to packets whose 484 payload will contain one or more source symbols from the FEC decoder 485 point of view. The FEC_SRC_FPI frame is part of the packet payload 486 itself. Any packet containing a FEC_SRC_FPI frame MUST see its 487 payload considered as one or more source symbol(s). 489 The FEC_SRC_FPI frame format is FEC Scheme specific and MUST be 490 specified in the associated document. 492 4.4. Repair Symbol Signaling 494 An explicit signaling is needed by a decoder for each repair symbol 495 received through a REPAIR frame. The goals are manyfold: identifying 496 the repair symbols and their position in the block (i.e., for block 497 codes) or coding window (i.e., for sliding window codes); carrying 498 information on the way this repair symbol has been produced (e.g., 499 with sliding window codes, it can indicate the encoding window 500 composition). 502 One or more repair symbols can be present in a given QUIC packet. 503 When there are multiple symbols, they SHOULD be concatenated in the 504 same REPAIR frame. How to achieve this goal is FEC Scheme specific 505 and therefore must be defined in the document describing this FEC 506 Scheme. 508 4.5. Signaling a Symbol Recovery 510 When all the source symbols of a given QUIC packet have been lost but 511 are recovered during FEC decoding, a QUIC receiver SHOULD advertise 512 it to the sender in order to avoid the retransmission of already 513 available data. However, the QUIC receiver MUST NOT acknowledge this 514 recovered packet through a regular acknowledement, as it would 515 interfere with the behaviour of loss-based congestion controls such 516 as [Cubic]. Therefore this document introduces a dedicated RECOVERED 517 frame, that enables a receiver to indicate that a specific QUIC 518 packet has been recovered through FEC decoding. 520 The RECOVERED frame works at the packet level. It is therefore 521 required to be able to identify to which packet the recovered source 522 symbols belong to. This is made possible by the QUIC packet 523 identifier field added to the meta data prior to FEC encoding 524 (Section 4.2.2). 526 4.6. About Gaps in the Set of Source Symbols Considered During Encoding 528 A given FEC Scheme MAY support or not the presence of gaps in the set 529 of source symbols that constitute a block (for Block codes) or an 530 encoding window (for Sliding Window codes). A potential cause for 531 non contiguous sets of source symbols is the acknowledgment of one of 532 them. When this happens, the QUIC sending endpoint may want to 533 remove this source symbol from further FEC encodings. This is 534 particularly true with Sliding Window codes because of their 535 flexibility during FEC encoding (i.e., the encoding window can change 536 between two consecutive FEC encodings). 538 Supporting gaps can be motivated by the desire to reduce encoding and 539 decoding complexity since there are fewer variables. However this 540 choice has major consequences in terms of signaling. Indeed each 541 repair symbol transmitted MUST be accompanied by enough information 542 for the QUIC decoding endpoint to unambiguously identify the exact 543 composition of the block or encoding window. Without any gap, the 544 identity of the first source symbol plus the number of symbols in the 545 block or encoding window is sufficient. With gaps, a more complex 546 encoding needs to be used, perhaps similar to the encoding used for 547 selective acknowledgments. 549 Whether gaps are supported MUST be clarified in each FEC Scheme. 551 5. FEC Scheme Negotiation in QUIC 553 FEC Scheme negotiation has two goals: 555 o Selecting a FEC Scheme (or FEC Schemes) that can be used by the 556 QUIC transmission and reception endpoints. This process requires 557 an exchange between them; 559 o Communicating a certain number of parameters, the "Configuration 560 Information", that are not expected to change over the session 561 lifetime. For instance, this is the case of the symbol size 562 parameter, E (in bytes), that needs either to be agreed between 563 the endpoints, or chosen by the sender and communicated to the 564 receiver(s); 566 Editor's notes: 568 * It is likely that FEC Scheme negotiation requires the use of a 569 new dedicated Extension Frame Type. The details remain TBD. 571 * The Negotiation Frame Type format remains TBD. 573 * How to communicate the parameters remains TBD. 575 * The present document only provides high level principles, the 576 details are of course the responsibility of the FEC Scheme. 578 * In case negotiation is different when protecting a single 579 versus several streams, this section may be moved to the 580 respective sections. 582 * How does it work in case of a multicast session? 584 * Do we negotiate here a FEC Scheme on a per-Stream basis (or 585 group of Streams to be protected jointly)? Or do we negotiate 586 a FEC Scheme on a QUIC session basis, therefore to be used for 587 all the Streams that need FEC protection? 589 5.1. FEC Scheme Negotiation 591 Before defining the transport parameters, we define two structures, 592 encoder_fec_scheme_t and decoder_fec_scheme_t, in Figure 6. The 593 config field is an opaque field allowing the decoder to define 594 supported configuration information for the associated FEC Scheme. A 595 FEC Scheme specification MUST define the set of valid configurations 596 for the FEC Scheme. 598 struct { 599 varint fec_scheme_id; 600 } encoder_fec_scheme_t 602 struct { 603 varint fec_scheme_id; 604 uint16_t config_length; 605 uint8_t config[config_length]; 606 } decoder_fec_scheme_t 608 Figure 6: encoder_fec_scheme_t and decoder_fec_scheme_t structures. 610 The following three transport parameters are used by the QUIC 611 endpoints to negotiate the FEC Scheme used during the connection. 613 o supported_encoder_fec_schemes: list of supported FEC schemes for 614 the encoding part listed from the most to the least preferred. 615 The value of this parameter consists in a list of 616 encoder_fec_scheme_t. When announcing a FEC Scheme, the encoder 617 MUST be able handle every FEC Scheme configuration considered 618 valid. 620 o supported_decoder_fec_schemes: list of supported FEC schemes for 621 the decoding part listed from the most to the least preferred. 622 The value of this parameter consists in a list of 623 decoder_fec_scheme_t, each one representing the ID of a supported 624 FEC Scheme. 626 o receiving_symbol_size: the size in bytes of the symbols the peer 627 is willing to receive and recover. The value is a 16-bits 628 integer. 630 Since communications can be bidirectional, each QUIC endpoint can 631 provide the three parameters. Conversely, providing an empty list 632 indicates this endpoint does not support FEC for the associated 633 communication path (e.g., an empty supported_decoder_fec_schemes list 634 indicates this endpoint cannot perform FEC decoding). 636 The decoding FEC Scheme of a QUIC endpoint is set to the first FEC 637 Scheme listed in its own supported_decoder_fec_schemes that also 638 appears in the peer's supported_encoder_fec_schemes. The encoding 639 FEC Scheme of a QUIC endpoint is set to the first FEC Scheme listed 640 in the peer's supported_decoder_fec_schemes that also appears in its 641 own supported_encoder_fec_schemes. The encoder-side symbol size (E) 642 of a QUIC endpoint is set to the value announced by the peer's 643 receiving_symbol_size transport parameter. The decoder-side symbol 644 size of a QUIC endpoint is set to the value announced in its own 645 receiving_symbol_size transport parameter. 647 Host 1 Host 2 648 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - 649 supported_encoder_fec_schemes{RLC_GF256,REED_SOLOMON,XOR} 650 supported_decoder_fec_schemes{REED_SOLOMON,XOR} 651 receiving_symbol_size{500} 653 - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 654 supported_encoder_fec_schemes{RLC_GF256,REED_SOLOMON,XOR} 655 supported_decoder_fec_schemes{RLC_GF256,REED_SOLOMON} 656 receiving_symbol_size{200} 658 ENCODER_FEC_SCHEME = REED_SOLOMON 659 DECODER_FEC_SCHEME = RLC_GF256 660 ENCODER_SYMBOL_SIZE = 500 661 DECODER_SYMBOL_SIZE = 200 663 ENCODER_FEC_SCHEME = RLC_GF256 664 DECODER_FEC_SCHEME = REED_SOLOMON 665 ENCODER_SYMBOL_SIZE = 200 666 DECODER_SYMBOL_SIZE = 500 668 Figure 7: Example FEC Schemes negotiation during the QUIC handshake. 670 It is possible that the QUIC endpoint that receives one or more FEC 671 Scheme proposals from the initiator cannot select any of them. In 672 that case the negotiation process fails and no FEC protection is 673 used. 675 6. Security Considerations 677 TBD 679 7. IANA Considerations 681 TBD 683 8. Acknowledgments 685 TBD 687 9. References 688 9.1. Normative References 690 [Cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 691 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 692 RFC 8312, DOI 10.17487/RFC8312, February 2018, 693 . 695 [QUIC-transport] 696 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 697 Multiplexed and Secure Transport", draft-ietf-quic- 698 transport (Work in Progress) (work in progress), January 699 2019, . 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, 704 DOI 10.17487/RFC2119, March 1997, 705 . 707 9.2. Informative References 709 [nc-taxonomy] 710 Roca (Ed.) et al., V., "Taxonomy of Coding Techniques for 711 Efficient Network Communications", Request For 712 Comments RFC 8406, June 2018, 713 . 716 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 717 "Reed-Solomon Forward Error Correction (FEC) Schemes", 718 RFC 5510, DOI 10.17487/RFC5510, April 2009, 719 . 721 [RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 722 (RLC) Forward Erasure Correction (FEC) Schemes for 723 FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020, 724 . 726 Authors' Addresses 728 Ian Swett 729 Google 730 Cambridge, MA 731 US 733 Email: ianswett@google.com 734 Marie-Jose Montpetit 735 Triangle Video 736 Boston, MA 737 US 739 Email: marie@mjmontpetit.com 741 Vincent Roca 742 INRIA 743 Univ. Grenoble Alpes 744 France 746 Email: vincent.roca@inria.fr 748 Francois Michel 749 UCLouvain 750 Louvain-la-Neuve 751 Belgium 753 Email: francois.michel@uclouvain.be