idnits 2.17.1
draft-swett-nwcrg-coding-for-quic-02.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 (February 4, 2019) is 1879 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 nwcrg I. Swett
3 Internet-Draft Google
4 Intended status: Informational M-J. Montpetit
5 Expires: August 8, 2019 Triangle Video
6 V. Roca
7 INRIA
8 February 4, 2019
10 Coding for QUIC
11 draft-swett-nwcrg-coding-for-quic-02
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 August 8, 2019.
44 Copyright Notice
46 Copyright (c) 2019 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 . . . . . . . . . . 8
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 . 12
81 6.2. Block or Encoding Window Management . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . 14
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{FEC_Encoding_ID1 | other}
307 supported_fec_scheme_64b{FEC_Encoding_ID2 | other}
309 choose FEC Scheme 1
310 - - - - - - - - - - - - - - - - - - - - - - >
311 supported_fec_scheme_32b{FEC_Encoding_ID1 | 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 It is possible that the QUIC endpoint that receives one or more FEC
324 Scheme proposals from the initiator cannot select any of them. In
325 that case the negotiation process fails...
327 Editor's notes:
329 * So what? How does it finishes? Consequences?
331 * Can the second QUIC endpoint change the proposed static
332 parameters? In that case can the initator refuse?
334 4.2. FEC Scheme Configuration Information
336 Let us now focus on the communication of configuration information
337 specific to the selected FEC Scheme. In Figure 1, the
338 supported_fec_scheme_32b{FS1_Encoding_ID} contains a field meant to
339 carry the FEC Encoding ID of the FEC Scheme selected plus addditional
340 configuration information if any. If a 32 bit opaque field is not
341 sufficient, the supported_fec_scheme_64b can be used instead and
342 proposes a 64 bit opaque field.
344 5. Procedures when Protecting a Single QUIC Stream
346 This section focusses on the simple case where FEC protection is
347 applied to a single QUIC stream. We consider a unidirectional data
348 flow between a QUIC sending endpoint and one (or more) QUIC reception
349 endpoints.
351 5.1. Application data, STREAM Frame data and Source Symbols
353 Application data is kept in a transmission buffer at a QUIC sending
354 endpoint, and sent within STREAM frames. Each STREAM frame that
355 carries data contains an Offset field that indicates the offset
356 within the stream of the first byte of the Stream Data field, as well
357 as a Length field that indicates the number of bytes contained in the
358 Stream Data field. Upon receiving a STREAM frame, using the Offset
359 and Length fields, a QUIC reception endpoint can easily store data in
360 its reception buffer. But since a QUIC Packet may be lost during
361 transmission, the reception buffer may have gaps.
363 Figure 2 illustrates how source symbols are mapped to the QUIC
364 transmission or reception buffers (same principle on either side).
365 Since any source (and repair) symbol is of fixed size (E bytes) for a
366 given stream, since QUIC guaranties that the first byte in the stream
367 has an offset of 0, the position of each source symbol is known by
368 both ends.
370 < -E- > < -E- > < -E- > < -E- >
371 +-------+-------+-------+-------+
372 |< -- Frame 1 -- >< ----- Frame | source symbols 0, 1, 2, 3
373 +-------+-------+-------+-------+
374 | 2 ----- >< --- Frame 3 -- >< -| source symbols 4, 5, 6, 7
375 +-------+-------+----+--+-------+
376 | Frame 4 - >< -F5- >| source symbols 8, 9 and 10
377 +-------+-------+----+ (incomplete)
379 Figure 2: Example of source symbol mapping, when the E value is
380 relatively small.
382 Any value for E is possible, from a single byte to several hundreds
383 or thousands of bytes, as long as a frame containing a repair symbol
384 (E bytes long) can fit into a QUIC packet. In general, the source
385 symbols are not aligned with data chunks sent in the STREAM frames.
386 A given STREAM frame may carry all the bytes of a given source
387 symbol. But when a source symbol straddles two or more (e.g., if E
388 is large compared to usual frame size) STREAM frames, a proper
389 reception of these two (or more) STREAM frames is needed for a QUIC
390 reception endpoint to consider that the source symbol is available
391 for FEC decoding operations. The choice of an appropriate value for
392 E may depend on the use case (in particular on the nature of
393 application data). A reasonably small value reduces the probability
394 that a source symbol straddles two or more STREAM frames, a situation
395 that is considered as potentially harmful (the unit of control, the
396 source symbol, and unit of transmission, the frame, are not aligned).
397 However an overly small value also increases processing complexity
398 (FEC encoding and decoding are performed over a larger linear system)
399 so there is an incentive to use a larger value. An appropriate
400 balance should be found, and this choice is considered as out of
401 scope for this document.
403 5.2. Signaling Considerations within STREAM and REPAIR Frames
405 Once the initial negotiation succeeded and an appropriate FEC Scheme
406 has been chosen between the QUIC endpoints, data is exchanged as
407 follows. Source data is transmitted within STREAM frames, as would
408 happen without any FEC based loss recovery mechanism (in particular
409 without considering source symbols boundaries). Repair data,
410 computed during FEC encoding, on the opposite, is sent within a
411 dedicated REPAIR frame type, chosen within the type range dedicated
412 to "Extension Frames". In both cases, the same Stream ID is used
413 since both flows relate to the same stream.
415 The REPAIR frame format is FEC Scheme dependent. The document
416 specifying a FEC Scheme to be used with QUIC MUST define the REPAIR
417 frame format, among other things. The REPAIR frame MUST carry enough
418 information for a QUIC reception endpoint to understand exactly how
419 this repair symbol(s) has(ve) been generated. It implies that each
420 REPAIR symbol MUST communicate the block (with block codes) or
421 encoding window (with Sliding Window codes) composition. When there
422 is no gap in the source symbol set, this MAY be achieved by
423 communicating:
425 o the offset of the first source symbol of the block or encoding
426 window;
428 o the number of source symbols in the block or encoding window,
429 which can be either a number of symbols or a number of bytes since
430 symbols are of fixed size, E.
432 Note that unlike FEC Schemes for FLUTE/ALC, NORM, and FECFRAME, here
433 there is no notion of Encoding Symbol Id (ESI). The use of an offset
434 within the stream, with the guaranty that no wrapping to zero can
435 occur, provides an alternative mechanism to identify any source
436 symbol.
438 As explained above, source data is transmitted without any
439 modification, which provides backward compatibility. This is an
440 advantage in situations where the same QUIC stream is simultaneously
441 delivered to several QUIC reception endpoints (multicast): it enables
442 a given FEC Scheme to be used even if a subset of the QUIC reception
443 endpoints do not support it.
445 Editor's notes:
447 * This I-D proposes to define a single generic REPAIR frame
448 type, but an alternative could be to have a one-to-one mapping
449 between a REPAIR frame type and a specific FEC Scheme.
451 * The use of frame type within the Extension Frames range for
452 REPAIR frames is meant to facilitate experimentations. If the
453 use of coding in QUIC is recognized as having benefits, a
454 dedicated (or more, see above) frame type could be selected
455 later on.
457 5.3. Management of Silent Periods and End of Stream
459 If an application does not submit fresh data for some time, the last
460 source symbol may not be totally filled. It follows that this last
461 source symbol cannot be considered during FEC encoding and therefore
462 the associated bytes of the application stream are not protected. A
463 similar problem arrives when a stream is finished, the application
464 having no more data to submit to QUIC. Here also, the bytes of the
465 last incomplete source symbol are not protected by FEC encoding.
467 In order to solve this problem, it is RECOMMENDED that a QUIC sending
468 endpoint:
470 o Identifies when such a situation is likely to occur, for instance
471 by waiting no more than a certain time during an application
472 silent period;
474 o Upon time-out, the application falls back to the alternative re-
475 transmission based loss recovery mechanism for the bytes of the
476 last incomplete source symbol;
478 Editor's notes: Clearly, the above mechanism requires more thoughts
479 as well as experimental work. The "end of stream" situation may
480 be addressed through zero padding perhaps easily. However the
481 use of zero padding for transitory silent periods may add a lot
482 of specification and implementation complexity...
484 6. Procedures when Protecting Several QUIC Streams
486 This section focusses on the general case where FEC protection is
487 globally applied across two or more QUIC streams.
489 Editor's notes: It is not clear whether this use-case is needed. It
490 adds specification and implementation complexity that need to be
491 balanced with the expected benefits.
493 * Receiver: A first complexity comes from the requirement to
494 identify to which stream a decoded source symbol belongs to.
495 This is also one of the main difficulty for FECFRAME (both
496 with block and sliding window codes) which required to
497 distinguish an ADU (submitted by the application) from an ADUI
498 (the same ADU plus an additional FlowID among other things).
499 Do we want this level of complexity?
501 * Sender: Another complexity comes from the encoding window
502 management at a sender. With multiple streams, shifting the
503 encoding window to the right needs to be done based on
504 timestamps associated to source symbols of the various
505 streams: the oldest source symbol across all the streams will
506 be removed.
508 * When two largely different streams are protected togethers
509 (e.g., a high definition 4K video flow plus the associated
510 relatively low-rate audio stream), is this extra complexity
511 balanced by significant performance improvements compared to
512 an independent protection on each stream (intuition is yes,
513 the low bitrate flow is better protected iff the encoding
514 window is large enough)? And when the various streams have a
515 comparable bitrate? More work (incl. experimental work) is
516 needed to answer this question.
518 6.1. Application data, STREAM Frame data and Source Symbols
520 Within each stream, the source symbols MUST be defined as in the
521 simple case of a single stream. Figure 2 remains valid.
523 6.2. Block or Encoding Window Management
525 The details of how to create the block or encoding window are
526 specific to the FEC Scheme. A possible approach is the following.
528 When creating the block (block FEC code) or encoding window (sliding
529 window FEC code), the source symbols to consider of each stream are
530 appended. All the relevant source symbols of the first stream are
531 appended, followed by all the source symbols of the second stream,
532 etc. These sequences do not follow any timing consideration in order
533 to simplify signaling.
535 Figure 3 illustrates, in case of a Sliding Window FEC Scheme, an
536 encoding window with source symbols belonging to two streams, of
537 Stream ID 120 and 51 respectively.
539 < ----------- Stream ID 120 ---------- > < --- Stream ID 51 --- >
540 +-------+-------+-------+-------+-------+-------+-------+-------+
541 | | | | | | | | |
542 +-------+-------+-------+-------+-------+-------+-------+-------+
543 ^ < -E- > ^
544 | |
545 offset = 0x42f0, length = 5*E offset = 0x0f24, length = 3*E
547 Figure 3: Example of encoding window of a Sliding Window FEC Scheme
548 and FEC protection across two streams.
550 6.3. Signaling Considerations within STREAM and REPAIR Frames
552 Source data on each stream is transmitted within STREAM frames, as
553 would happen without any FEC based loss recovery mechanism.
555 Repair symbols, generated during FEC encoding as a linear combination
556 of source symbols that belong to one or more of the streams, are
557 transmitted within REPAIR frames. Each REPAIR frame can be
558 associated to any of the input streams it protects, and therefore
559 associated to any of the associated Stream IDs.
561 Editor's notes: Check that indeed, with FEC protection across
562 several streams, assigning a REPAIR frame to any of the streams
563 it protects is meaningful. Should an approach for selecting one
564 stream (and Stream ID) be preferred?
566 The REPAIR frame format is FEC Scheme dependent and MUST be defined
567 by document specifying a FEC Scheme. One of the key information of
568 this REPAIR frame is the composition of the block (with block codes)
569 or encoding window (with sliding window codes) used to perform FEC
570 encoding. Indeed, this is the only manner to convey this information
571 since an application flow is not predictable (e.g., if an application
572 flow is momentarily suspended, the composition of the block or
573 encoding window will be affected). One possibility is to list, in
574 each REPAIR frame header:
576 o the actual number of streams considered (the maximum number is
577 known after the negotiation step, but if one of the streams
578 remains silent for some time, it may not contribute during
579 encoding and therefore be absent from the block or encoding
580 window);
582 o for each stream concerned, its Stream ID, the offset of the first
583 source symbol considered as well as the length, i.e., the number
584 of bytes considered.
586 This approach does not enable to keep track of the source symbol
587 ordering across streams, but enables a non ambiguous description of
588 the encoding window.
590 The FEC Scheme specification MUST also detail how to manage the block
591 or encoding window. For instance, should the oldest source symbol of
592 any stream be removed from the encoding window when this latter is
593 shifted to the right? This would mean that a timestamp is attached
594 to each source symbol in order to identify the oldest one across all
595 streams.
597 7. Security Considerations
599 TBD
601 8. IANA Considerations
603 TBD
605 9. Acknowledgments
607 TBD
609 10. References
610 10.1. Normative References
612 [QUIC-transport]
613 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
614 Multiplexed and Secure Transport", draft-ietf-quic-
615 transport (Work in Progress) (work in progress), January
616 2019, .
619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
620 Requirement Levels", BCP 14, RFC 2119,
621 DOI 10.17487/RFC2119, March 1997,
622 .
624 10.2. Informative References
626 [nc-taxonomy]
627 Roca (Ed.) et al., V., "Taxonomy of Coding Techniques for
628 Efficient Network Communications", Request For
629 Comments RFC 8406, June 2018,
630 .
633 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
634 "Reed-Solomon Forward Error Correction (FEC) Schemes",
635 RFC 5510, DOI 10.17487/RFC5510, April 2009,
636 .
638 [RLC] Roca, V. and B. Teibi, "Sliding Window Random Linear Code
639 (RLC) Forward Erasure Correction (FEC) Scheme for
640 FECFRAME", Work in Progress, Transport Area Working Group
641 (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in
642 Progress), February 2019, .
645 Authors' Addresses
647 Ian Swett
648 Google
649 Cambridge, MA
650 US
652 Email: ianswett@google.com
653 Marie-Jose Montpetit
654 Triangle Video
655 Boston, MA
656 US
658 Email: marie@mjmontpetit.com
660 Vincent Roca
661 INRIA
662 Univ. Grenoble Alpes
663 France
665 Email: vincent.roca@inria.fr