< draft-swett-nwcrg-coding-for-quic-02.txt   draft-swett-nwcrg-coding-for-quic-03.txt >
nwcrg I. Swett nwcrg I. Swett
Internet-Draft Google Internet-Draft Google
Intended status: Informational M-J. Montpetit Intended status: Informational M-J. Montpetit
Expires: August 8, 2019 Triangle Video Expires: January 9, 2020 Triangle Video
V. Roca V. Roca
INRIA INRIA
February 4, 2019 F. Michel
UCLouvain
July 8, 2019
Coding for QUIC Coding for QUIC
draft-swett-nwcrg-coding-for-quic-02 draft-swett-nwcrg-coding-for-quic-03
Abstract Abstract
This document focusses on the integration of FEC coding in the QUIC This document focuses on the integration of FEC coding in the QUIC
transport protocol, in order to recover from packet losses. This transport protocol, in order to recover from packet losses. This
document does not specify any FEC code but defines mechanisms to document does not specify any FEC code but defines mechanisms to
negotiate and integrate FEC Schemes in QUIC. By using proactive loss negotiate and integrate FEC Schemes in QUIC. By using proactive loss
recovery, it is expected to improve QUIC performance in sessions recovery, it is expected to improve QUIC performance in sessions
impacted by packet losses. More precisely it is expected to improve impacted by packet losses. More precisely it is expected to improve
QUIC performance with real-time sessions (since FEC coding makes QUIC performance with real-time sessions (since FEC coding makes
packet loss recovery insensitive to the round trip time), with packet loss recovery insensitive to the round trip time), with short
multicast sessions (since the same repair packet can recover several sessions (since FEC coding can help recovering from tail losses more
different losses at several receivers), and with multipath sessions rapidely than through retransmissions), with multicast sessions
(since repair packets add diversity). (since the same repair packet can recover several different losses at
several receivers), and with multipath sessions (since repair packets
add diversity and flexibility).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3
3. General Design Considerations . . . . . . . . . . . . . . . . 4 3. General Design Considerations . . . . . . . . . . . . . . . . 4
3.1. FEC Code versus FEC Scheme, Block Codes versus Sliding 3.1. FEC Code versus FEC Scheme, Block Codes versus Sliding
Window Codes . . . . . . . . . . . . . . . . . . . . . . 4 Window Codes . . . . . . . . . . . . . . . . . . . . . . 4
3.2. FEC Scheme Negotiation . . . . . . . . . . . . . . . . . 4 3.2. FEC Scheme Negotiation . . . . . . . . . . . . . . . . . 5
3.3. FEC Protection Within an Encrypted Channel . . . . . . . 5 3.3. FEC Protection Within an Encrypted Channel . . . . . . . 5
3.4. About Middleboxes . . . . . . . . . . . . . . . . . . . . 5 3.4. About Middleboxes . . . . . . . . . . . . . . . . . . . . 5
3.5. FEC Protection at the Stream Level . . . . . . . . . . . 5 4. FEC Protection Principles . . . . . . . . . . . . . . . . . . 5
3.6. About Gaps in the Set of Source Symbols Considered During 4.1. Cross Packet Frames FEC Encoding . . . . . . . . . . . . 5
Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Source Symbol Definition . . . . . . . . . . . . . . . . 6
4. FEC Scheme Negotiation in QUIC . . . . . . . . . . . . . . . 6 4.2.1. Packet Payload to Packet Chunk Mapping . . . . . . . 6
4.1. FEC Scheme Selection Process . . . . . . . . . . . . . . 7 4.2.2. Packet Chunk to Source Symbol Mapping . . . . . . . . 7
4.2. FEC Scheme Configuration Information . . . . . . . . . . 8 4.2.2.1. Open questions: Content of Source Symbols
5. Procedures when Protecting a Single QUIC Stream . . . . . . . 8 Metadata? Removing certain frames from FEC
5.1. Application data, STREAM Frame data and Source Symbols . 8 protection? . . . . . . . . . . . . . . . . . . . 9
5.2. Signaling Considerations within STREAM and REPAIR Frames 9 4.2.3. Source Symbol Size (E) Considerations . . . . . . . . 10
5.3. Management of Silent Periods and End of Stream . . . . . 10 4.3. Source Symbol Signaling . . . . . . . . . . . . . . . . . 11
6. Procedures when Protecting Several QUIC Streams . . . . . . . 11 4.4. Repair Symbol Signaling . . . . . . . . . . . . . . . . . 11
6.1. Application data, STREAM Frame data and Source Symbols . 12 4.5. Signaling a Symbol Recovery . . . . . . . . . . . . . . . 11
6.2. Block or Encoding Window Management . . . . . . . . . . . 12 4.6. About Gaps in the Set of Source Symbols Considered During
6.3. Signaling Considerations within STREAM and REPAIR Frames 12 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. FEC Scheme Negotiation in QUIC . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. FEC Scheme Selection Process . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. FEC Scheme Configuration Information . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
QUIC is a new transport that aims at improving network performance by QUIC is a new transport that aims at improving network performance by
enabling out of order delivery, partial reliability, and methods of enabling out of order delivery, partial reliability, and methods of
recovery besides retransmission, while also improving security. This recovery besides retransmission, while also improving security. This
document specifies a framework to enable FEC codes to be used to document specifies a framework to enable FEC codes to be used to
recover from lost packets within a single QUIC stream or across recover from lost packets within a single QUIC stream or across
several QUIC streams. several QUIC streams.
The ability to add FEC coding in QUIC may be beneficial in several The ability to add FEC coding in QUIC may be beneficial in several
situations: situations:
o for a robust transmission of latency sensitive traffic, for o for a robust transmission of latency sensitive traffic, for
instance real-time flows, since it enables to recover packet instance real-time flows, since it enables to recover packet
losses independently of the round trip time; losses independently of the round trip time;
o for short sessions, in order to protect the last few packets sent,
since it enables to recover from tail losses more rapidely than
through retransmissions;
o for the transmission of contents to a large set of QUIC reception o for the transmission of contents to a large set of QUIC reception
endpoints, since the same repair frame may help recovering several endpoints, since the same repair frame may help recovering several
different packet losses at different receivers; different packet losses at different receivers;
o for multipath communications, since repair traffic adds diversity. o for multipath communications, since repair traffic adds diversity
and flexibility.
This framework does not mandate the use of any specific FEC code This framework does not mandate the use of any specific FEC code
(i.e., how to encode and decode) nor FEC Scheme (i.e., that specifies (i.e., how to encode and decode) nor FEC Scheme (i.e., that specifies
both a FEC code and how to use it, in particular in terms of both a FEC code and how to use it, in particular in terms of
signaling). Instead it allows to negotiate the FEC Scheme to use at signaling). Instead it allows to negotiate the FEC Scheme to use at
session startup, assuming that more than one solution could session startup, assuming that more than one solution could
potentially be offered concurrently. Without loss of generality, we potentially be offered concurrently. Without loss of generality, we
assume that the encoding operations compute a linear combination of assume that the encoding operations compute a linear combination of
QUIC packets, regardless of whether these codes are of block type (as QUIC packets, regardless of whether these codes are of block type (as
with Reed-Solomon codes [RFC5510]) or sliding window type (as with with Reed-Solomon codes [RFC5510]) or sliding window type (as with
skipping to change at page 5, line 7 skipping to change at page 5, line 27
updated. updated.
* It is not clear whether negotiation is meant to select a * It is not clear whether negotiation is meant to select a
**single** FEC Scheme or **multiple** FEC Schemes. In the **single** FEC Scheme or **multiple** FEC Schemes. In the
second case (multiple FEC) it is required to have a second case (multiple FEC) it is required to have a
complementary mechanism to indicate which FEC Scheme is used complementary mechanism to indicate which FEC Scheme is used
in a given REPAIR frame (which could be done through as many in a given REPAIR frame (which could be done through as many
REPAIR frame type values as potential FEC Scheme negotiated). REPAIR frame type values as potential FEC Scheme negotiated).
Is it what we want to achieve? Not sure. Is it what we want to achieve? Not sure.
* It is not clear whether negotiation is carried out at QUIC
level (and therefore for multiple streams) or at a stream
level (and therefore multiple streams may use multiple FEC
Schemes). The terminology used above should be updated to
reflect the choice.
3.3. FEC Protection Within an Encrypted Channel 3.3. FEC Protection Within an Encrypted Channel
FEC encoding is applied before any QUIC encryption and authentication FEC encoding is applied before any QUIC encryption and authentication
processing. Source symbols, that constitute the data units used by processing. Source symbols, that constitute the data units used by
the FEC codec, contain cleartext application data. the FEC codec, contain cleartext data (application and/or QUIC data).
3.4. About Middleboxes 3.4. About Middleboxes
The coding approach described in this document does not allow on path The coding approach described in this document does not allow on path
elements (middleboxes) to take part in FEC protection. The traffic elements (middleboxes) to take part in FEC protection. The traffic
being encrypted end-to-end, the middleboxes are not in position to being encrypted end-to-end, the middleboxes are not in position to
perform FEC decoding, nor to add any redundant traffic. perform FEC decoding, nor to add any redundant traffic.
3.5. FEC Protection at the Stream Level 4. FEC Protection Principles
Streams in QUIC provide a lightweight, ordered byte-stream The present section explains how FEC encoding can be applied to QUIC.
abstraction. FEC encoding is applied at the stream level, within a It defines the general ideas for mapping QUIC packet frames to source
single stream or across two or more streams of the same QUIC session. symbols, as well as the associated signaling. This section does not
This is motivated by the fact that FEC protection is not necessarily define the FEC Scheme specific details that need to be specified in a
beneficial to all data streams, but only to a subset of them. For companion document.
instance FEC protection can be highly beneficial to live video
streams to which the proactive erasure correction feature of FEC,
independent of the RTT, should be highly beneficial. On the
opposite, FEC protection is probably less attractive for latency
insensitive bulk unicast flows.
In order to facilitate experiments, and in order to enable backward 4.1. Cross Packet Frames FEC Encoding
compatibility, the STREAM frames that carry application data are kept
unmodified. On the opposite, frames that carry one or more repair
symbols use a dedicated REPAIR frame type, chosen within the type
range dedicated to "Extension Frames".
3.6. About Gaps in the Set of Source Symbols Considered During Encoding A QUIC packet payload consists in a set of QUIC frames. These frames
either carry application data (e.g., in a STREAM or DATAGRAM frame)
or control information (e.g., a MAX_DATA frame). Each packet is
either entirely received or lost, and is uniquely identified by a
monotonically increasing Packet Number.
Through the use of FEC encoding, application data can be protected
proactively against packet losses, without requiring to go through
packet retransmission. In addition to application data, QUIC
transfers might benefit from protecting control frames having a
potential impact on the transmission throughput, such as MAX_DATA or
MAX_STREAM_DATA frames. Therefore this document introduces an FEC
protection across all -- or a subset of -- the frames of a given QUIC
packet. This design choice impacts the QUIC packet to source symbols
mapping, as well as signaling aspects, both of them being discussed
hereafter.
4.2. Source Symbol Definition
The cross packet frames FEC encoding approach considers the sequence
of frames (or a sub-sequence of them) transmitted within a given QUIC
packet, seen as the QUIC packet payload. From this payload, it
defines a mapping to source symbols (see Section 4.2.1 and
Section 4.2.2). Source symbols are then used for encoding purposes,
producing one or more repair symbols, the details of which depend on
the FEC Scheme considered. However source symbols are never sent per
se on the network. Instead the original QUIC packet, plus a
dedicated signaling header, are sent and therefore implicitely carry
those source symbols. The QUIC packets, containing one or more
repair symbols, are sent on the network.
The only modification to the original QUIC packet is the addition of
a dedicated FEC_SRC_FPI frame type, meant to carry source symbol
signaling (known as Source FEC Payload Information, or FPI). On the
opposite, frames that carry one or more repair symbols use a
dedicated REPAIR frame type. In both cases, in order to facilitate
experiments and enable backward compatibility, the FEC_SRC_FPI and
REPAIR frame types are chosen within the type range dedicated to
"Extension Frames". Thereby, a legacy receiver will automatically
ignore these unknown frame types. As QUIC packets can be of
different lengths, a special care must be taken to ensure having a
fixed Source Symbol size to ease FEC Scheme implementations.
4.2.1. Packet Payload to Packet Chunk Mapping
This section defines a mechanism to segment a QUIC packet payload,
composed of several frames, into fixed-size payload chunks, of size
E-1 bytes or E-1-4 bytes for the first chunk when the QUIC Packet
Number needs to be added ((Section 4.2.2). Depending on the relative
value of E-1 (or E-1-4) and the QUIC packet payload size, a packet
can potentially contain more than one chunks. This is a first step
into producing source symbols. Figure 1 illustrates this process.
|<E-1-4>|< E-1 >|< E-1 >|< E-1 >|
| | | | |
+------|-------|-------|-------|-------|
QUIC pkt 0 |Header| Packet Payload | chunks 0, 1, 2, 3
+------|-----+-|-------|-------|-------+
QUIC pkt 1 |Header| 0 | Packet Payload | chunks 4, 5, 6
+------|---+-+-|-------|-------|
QUIC pkt 2 |Header| 0 | Packet Payload | chunks 7, 8, 9
+------|---+---|-------|-------|
Figure 1: Example of QUIC packet to chunk mapping, when the E-1 value
is relatively small, with prepended zero padding when needed (here
packets 1 and 2), and assuming the first chunk contains the QUIC
Packet Number in 4 bytes compressed version.
4.2.2. Packet Chunk to Source Symbol Mapping
The second step consists in producing the source symbols. A source
symbols is the concatenation of a single byte of metadata,
potentially followed by the Packet Number of the associated source,
plus a packet chunk. Figure 2 illustrates the situation where a
compressed QUIC packet number is added (in general for the first
chunk of a QUIC packet). Figure 3 illustrates the situation where
there is no QUIC packet number (in general for the following chunk(s)
of a QUIC packet). When the QUIC packet number is present, this
identifier can be recovered by a receiver after successful FEC
decoding. It means that a RECOVERED frame can be generated to the
sender to indicated that this packet (identified by the QUIC packet
number) has been recovered. Each source symbol is of fixed-size E
bytes. These source symbols are only used during encoding and
decoding and are not sent as-is on the network.
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| meta data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet chunk (E-1-4 bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Source symbol format with Packet Number information (e.g.,
first packet chunk).
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| meta data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet chunk (E-1 bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Source symbol format without Packet Number information
(e.g., packet chunks except the first one).
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|Resvd (0)|N|S|E|
+-+-+-+-+-+-+-+-+
Figure 4: Source symbol metadata format.
Figure 4 shows the format of the 1 byte metadata. The fields are the
following:
Reserved field (5 bits): for this specification, this field MUST be
equal to zero.
Packet Number (N) field (1 bit): this field indicates that the
following 4 bytes contain the Packet Number (short 32-bit
representation) of the associated QUIC packet ([QUIC-transport]
section 17.1., Packet Number Encoding and Decoding).
Start (S) bit (1 bit): this field, when set to 1, indicates that
this source symbol contains the first chunk of the packet
payload.
End bit (E) (1 bit): this field, when set to 1, indicates that this
source symbol contains the last chunk of the packet payload.
Note that with a QUIC packet containing a single chunk, the
associated metadata will contain S=E=1. On the opposite, a source
symbol containing a intermediate chunk (i.e., neither the first nor
the last chunk of the QUIC packet), the associated metadata will
contain S=E=0.
QUIC packet
|<E-1-4>|< E-1 >|< E-1 >|< E-1 >|
+------|----+--|-------|-------|-------|
|Header| 0 | Packet Payload | 4 packet chunks
+------|----+--|-------|-------|-------|
/ | | \
v v v v
+-+--+----+ +-+-------+ +-+-------+ +-+-------+
|m|pn|chnk| |m| chunk| |m| chunk| |m| chunk| 4 source symbols
+-+--+----+ +-+-------+ +-+-------+ +-+-------+
| | | | | | | |
|< --E-- >| |< --E-- >| |< --E-- >| |< --E-- >|
Figure 5: Example of packet chunk to source symbol mapping, when the
E value is relatively small, in presence of the QUIC Packet Number
for the first chunk.
Figure 5 shows an example where the 4 source symbols are created from
the payload of a given QUIC packet. The first chunk may contain zero
padding at the begining in order to align the protected packet
payload size to a multiple of E-1, and the first source symbol may
contain the QUIC Packet Number.
Each source symbol is uniquely identified allowing to determine
unambiguously its position in the source symbol flow. What
information to associate to a source symbol to uniquely identify it
is FEC Scheme dependant. Section 4.3 gives insight on this topic.
4.2.2.1. Open questions: Content of Source Symbols Metadata? Removing
certain frames from FEC protection?
NB: section to remove once fixed.
During the FEC encoding phase, additional data can be added to the
source symbol. These data are only added during the encoding and
MUST NOT be transmitted on the network. The encoder and decoder MUST
agree on the addition of these data to the source symbol in order to
avoid decoding errors. Here are some examples of data that can be
added to a source symbol during encoding and that will be decoded
upon a source symbol recovery:
o The packet number: adding the packet number allows the decoder to
know which packet has been recovered and potentially send a
feedback of which packet has been recovered to the QUIC sender.
o Additional QUIC frames: the FEC encoder can for example add
PADDING frames to a source symbol before proceeding to encoding.
Adding PADDING frames to source symbols before encoding allows
protecting packets of different sizes. The smaller packet payload
will be added PADDING frames to reach a size that is a multiple of
E-1.
Note: Maybe the decision of adding data such as padding in the
source symbols should be left to the underlying FEC Scheme.
Besides adding data to source symbols before encoding, some frames
can be removed from the source symbol if their protection is not
crucial for the transmission in order to reduce the size of the
source symbol. For example, ACK frames can be systematically
stripped out of the source symbols. Stream frames of non-delay-
sensitive streams could also be removed from the source symbol. The
encoder and decoder MUST agree on which frames must be stripped out
of packet payloads. This information might for example be encoded in
the Source Symbol ID by the FEC encoder.
Note: We might want to propose standard ways/algorithms to add/
remove data before the encoding ?
TODO: Add a mechanism to add QUIC packet identifier to the metadata.
It's useful.
4.2.3. Source Symbol Size (E) Considerations
The source symbol size, E, MUST be strictly greater than zero bytes
and strictly smaller than the minimum PMTU value allowed by QUIC.
The packet header is not part of the FEC-protected data. When the
packet payload size is not a multiple of E-1, zero-padding MUST be
added at the beginning of the first chunk of the packet payload.
This is equivalent to inserting PADDING frames at the beginning of
the payload. This zero-padding, only used for FEC encoding, SHOULD
NOT be sent on the wire.
The choice of an appropriate value for E may depends on the use case
(in particular on the nature of application data). A reasonably
small value reduces the expected value of the added padding needed to
align the payload size with a multiple of E-1, which can be a good
approach when dealing with QUIC packets whose size significantly
vary. However an overly small value also increases processing
complexity (FEC encoding and decoding are performed over a larger
linear system since there are more source symbols), so there is an
incentive to use a larger value. An appropriate balance should be
found, and this choice is considered as out of scope for this
document. Since a repair symbol will transit through a frame, the E
value must take this into account to avoid having REPAIR frames that
do not fit into a single QUIC packet.
4.3. Source Symbol Signaling
An explicit signaling is needed by a decoder to identify the source
symbols and their position in the block (i.e., for block codes) or
coding window (i.e., for sliding window codes). While the QUIC
packet number increases monotonically, it cannot be used to identify
the position of a packet in the coding window as the packet number is
not needed to increase by 1 for each new packet. There is thus an
ambiguity on the decoder-side between lost packets and packets that
do not exist. Similarly to FECFRAME, we propose to assign a
identifier to source symbols to avoid this ambiguity. This
identifier is opaque to the protocol and will be defined by the
underlying FEC schemes. This is out of the scope of this document.
An example of identifier could be an integer increasing by 1 for each
new source symbol
In order to announce the source symbol identifier to the FEC decoder,
we propose to add a new frame, the FEC_SRC_FPI frame to packets whose
payload will contain one or more source symbols from the FEC decoder
point of view. The FEC_SRC_FPI frame is part of the packet payload
itself. Any packet containing a FEC_SRC_FPI frame MUST see its
payload considered as one or more source symbol(s).
The FEC_SRC_FPI frame format is FEC Scheme specific and MUST be
specified in the associated document.
4.4. Repair Symbol Signaling
An explicit signaling is needed by a decoder for each repair symbol
received through a REPAIR frame. The goals are manyfold: identifying
the repair symbols and their position in the block (i.e., for block
codes) or coding window (i.e., for sliding window codes); carrying
information on the way this repair symbol has been produced (e.g.,
with sliding window codes, it can indicate the encoding window
composition).
One or more repair symbols can be present in a given QUIC packet.
When there are multiple symbols, they SHOULD be concatenated in the
same REPAIR frame. How to achieve this goal is FEC Scheme specific
and therefore must be defined in the document describing this FEC
Scheme.
4.5. Signaling a Symbol Recovery
When all the source symbols of a given QUIC packet have been lost but
are recovered during FEC decoding, a QUIC receiver SHOULD advertise
it to the sender in order to avoid the retransmission of already
available data. However, the QUIC receiver MUST NOT acknowledge this
recovered packet through a regular acknowledement, as it would
interfere with the behaviour of loss-based congestion controls such
as [Cubic]. Therefore this document introduces a dedicated RECOVERED
frame, that enables a receiver to indicate that a specific QUIC
packet has been recovered through FEC decoding.
The RECOVERED frame works at the packet level. It is therefore
required to be able to identify to which packet the recovered source
symbols belong to. This is made possible by the QUIC packet
identifier field added to the meta data prior to FEC encoding
(Section 4.2.2).
4.6. About Gaps in the Set of Source Symbols Considered During Encoding
A given FEC Scheme MAY support or not the presence of gaps in the set A given FEC Scheme MAY support or not the presence of gaps in the set
of source symbols that constitute a block (for Block codes) or an of source symbols that constitute a block (for Block codes) or an
encoding window (for Sliding Window codes). A potential cause for encoding window (for Sliding Window codes). A potential cause for
non contiguous sets of source symbols is the acknowledgment of one of non contiguous sets of source symbols is the acknowledgment of one of
them. When this happens, the QUIC sending endpoint may want to them. When this happens, the QUIC sending endpoint may want to
remove this source symbol from further FEC encodings. This is remove this source symbol from further FEC encodings. This is
particularly true with Sliding Window codes because of their particularly true with Sliding Window codes because of their
flexibility during FEC encoding (i.e., the encoding window can change flexibility during FEC encoding (i.e., the encoding window can change
between two consecutive FEC encodings). between two consecutive FEC encodings).
skipping to change at page 6, line 23 skipping to change at page 12, line 42
for the QUIC decoding endpoint to unambiguously identify the exact for the QUIC decoding endpoint to unambiguously identify the exact
composition of the block or encoding window. Without any gap, the composition of the block or encoding window. Without any gap, the
identity of the first source symbol plus the number of symbols in the identity of the first source symbol plus the number of symbols in the
block or encoding window is sufficient. With gaps, a more complex block or encoding window is sufficient. With gaps, a more complex
encoding needs to be used, perhaps similar to the encoding used for encoding needs to be used, perhaps similar to the encoding used for
selective acknowledgments. selective acknowledgments.
Whether or not gaps are supported MUST be clarified in each FEC Whether or not gaps are supported MUST be clarified in each FEC
Scheme. Scheme.
4. FEC Scheme Negotiation in QUIC 5. FEC Scheme Negotiation in QUIC
FEC Scheme negotiation has two goals: FEC Scheme negotiation has two goals:
o Selecting a FEC Scheme (or FEC Schemes) that can be used by the o Selecting a FEC Scheme (or FEC Schemes) that can be used by the
QUIC transmission and reception endpoints. This process requires QUIC transmission and reception endpoints. This process requires
an exchange between them; an exchange between them;
o Communicating a certain number of parameters, the "Configuration o Communicating a certain number of parameters, the "Configuration
Information", that are not expected to change over the session Information", that are not expected to change over the session
lifetime. For instance, this is the case of the symbol size lifetime. For instance, this is the case of the symbol size
skipping to change at page 7, line 16 skipping to change at page 13, line 32
versus several streams, this section may be moved to the versus several streams, this section may be moved to the
respective sections. respective sections.
* How does it work in case of a multicast session? * How does it work in case of a multicast session?
* Do we negotiate here a FEC Scheme on a per-Stream basis (or * Do we negotiate here a FEC Scheme on a per-Stream basis (or
group of Streams to be protected jointly)? Or do we negotiate group of Streams to be protected jointly)? Or do we negotiate
a FEC Scheme on a QUIC session basis, therefore to be used for a FEC Scheme on a QUIC session basis, therefore to be used for
all the Streams that need FEC protection? all the Streams that need FEC protection?
4.1. FEC Scheme Selection Process 5.1. FEC Scheme Selection Process
Let us consider the FEC Scheme selection process between the QUIC Let us consider the FEC Scheme selection process between the QUIC
endpoints. Figure 1 illustrates the principle when a QUIC reception endpoints. Figure 6 illustrates the principle when a QUIC reception
endpoint initiates the exchange. endpoint initiates the exchange.
QUIC sender QUIC receiver QUIC sender QUIC receiver
< - - - - - - - - - - - - - - - - - - - - - - < - - - - - - - - - - - - - - - - - - - - - -
supported_fec_scheme_32b{FEC_Encoding_ID1 | other} supported_fec_scheme_32b{FEC_Encoding_ID1 | other}
supported_fec_scheme_64b{FEC_Encoding_ID2 | other} supported_fec_scheme_64b{FEC_Encoding_ID2 | other}
choose FEC Scheme 1 choose FEC Scheme 1
- - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - >
supported_fec_scheme_32b{FEC_Encoding_ID1 | other} supported_fec_scheme_32b{FEC_Encoding_ID1 | other}
Figure 1: Example FEC Scheme selection process, during the initial Figure 6: Example FEC Scheme selection process, during the initial
negotiation. negotiation.
The supported_fec_scheme_16b and supported_fec_scheme_32b are two new The supported_fec_scheme_16b and supported_fec_scheme_32b are two new
TransportParameterId to be added to the "Table 7: Initial QUIC TransportParameterId to be added to the "Table 7: Initial QUIC
Transport Parameters Entries" Section 13.1, of [QUIC-transport]. The Transport Parameters Entries" Section 13.1, of [QUIC-transport]. The
supported_fec_scheme_32b contains a 32-bit data field to carry opaque supported_fec_scheme_32b contains a 32-bit data field to carry opaque
32-bit value, while the supported_fec_scheme_64b contains a 64-bit 32-bit value, while the supported_fec_scheme_64b contains a 64-bit
data field to carry opaque 64-bit value (see Section 4.2). data field to carry opaque 64-bit value (see Section 5.2).
It is possible that the QUIC endpoint that receives one or more FEC It is possible that the QUIC endpoint that receives one or more FEC
Scheme proposals from the initiator cannot select any of them. In Scheme proposals from the initiator cannot select any of them. In
that case the negotiation process fails... that case the negotiation process fails...
Editor's notes: Editor's notes:
* So what? How does it finishes? Consequences? * So what? How does it finishes? Consequences?
* Can the second QUIC endpoint change the proposed static * Can the second QUIC endpoint change the proposed static
parameters? In that case can the initator refuse? parameters? In that case can the initator refuse?
4.2. FEC Scheme Configuration Information 5.2. FEC Scheme Configuration Information
Let us now focus on the communication of configuration information Let us now focus on the communication of configuration information
specific to the selected FEC Scheme. In Figure 1, the specific to the selected FEC Scheme. In Figure 6, the
supported_fec_scheme_32b{FS1_Encoding_ID} contains a field meant to supported_fec_scheme_32b{FS1_Encoding_ID} contains a field meant to
carry the FEC Encoding ID of the FEC Scheme selected plus addditional carry the FEC Encoding ID of the FEC Scheme selected plus addditional
configuration information if any. If a 32 bit opaque field is not configuration information if any. If a 32 bit opaque field is not
sufficient, the supported_fec_scheme_64b can be used instead and sufficient, the supported_fec_scheme_64b can be used instead and
proposes a 64 bit opaque field. proposes a 64 bit opaque field.
5. Procedures when Protecting a Single QUIC Stream 6. Security Considerations
This section focusses on the simple case where FEC protection is
applied to a single QUIC stream. We consider a unidirectional data
flow between a QUIC sending endpoint and one (or more) QUIC reception
endpoints.
5.1. Application data, STREAM Frame data and Source Symbols
Application data is kept in a transmission buffer at a QUIC sending
endpoint, and sent within STREAM frames. Each STREAM frame that
carries data contains an Offset field that indicates the offset
within the stream of the first byte of the Stream Data field, as well
as a Length field that indicates the number of bytes contained in the
Stream Data field. Upon receiving a STREAM frame, using the Offset
and Length fields, a QUIC reception endpoint can easily store data in
its reception buffer. But since a QUIC Packet may be lost during
transmission, the reception buffer may have gaps.
Figure 2 illustrates how source symbols are mapped to the QUIC
transmission or reception buffers (same principle on either side).
Since any source (and repair) symbol is of fixed size (E bytes) for a
given stream, since QUIC guaranties that the first byte in the stream
has an offset of 0, the position of each source symbol is known by
both ends.
< -E- > < -E- > < -E- > < -E- >
+-------+-------+-------+-------+
|< -- Frame 1 -- >< ----- Frame | source symbols 0, 1, 2, 3
+-------+-------+-------+-------+
| 2 ----- >< --- Frame 3 -- >< -| source symbols 4, 5, 6, 7
+-------+-------+----+--+-------+
| Frame 4 - >< -F5- >| source symbols 8, 9 and 10
+-------+-------+----+ (incomplete)
Figure 2: Example of source symbol mapping, when the E value is
relatively small.
Any value for E is possible, from a single byte to several hundreds
or thousands of bytes, as long as a frame containing a repair symbol
(E bytes long) can fit into a QUIC packet. In general, the source
symbols are not aligned with data chunks sent in the STREAM frames.
A given STREAM frame may carry all the bytes of a given source
symbol. But when a source symbol straddles two or more (e.g., if E
is large compared to usual frame size) STREAM frames, a proper
reception of these two (or more) STREAM frames is needed for a QUIC
reception endpoint to consider that the source symbol is available
for FEC decoding operations. The choice of an appropriate value for
E may depend on the use case (in particular on the nature of
application data). A reasonably small value reduces the probability
that a source symbol straddles two or more STREAM frames, a situation
that is considered as potentially harmful (the unit of control, the
source symbol, and unit of transmission, the frame, are not aligned).
However an overly small value also increases processing complexity
(FEC encoding and decoding are performed over a larger linear system)
so there is an incentive to use a larger value. An appropriate
balance should be found, and this choice is considered as out of
scope for this document.
5.2. Signaling Considerations within STREAM and REPAIR Frames
Once the initial negotiation succeeded and an appropriate FEC Scheme
has been chosen between the QUIC endpoints, data is exchanged as
follows. Source data is transmitted within STREAM frames, as would
happen without any FEC based loss recovery mechanism (in particular
without considering source symbols boundaries). Repair data,
computed during FEC encoding, on the opposite, is sent within a
dedicated REPAIR frame type, chosen within the type range dedicated
to "Extension Frames". In both cases, the same Stream ID is used
since both flows relate to the same stream.
The REPAIR frame format is FEC Scheme dependent. The document
specifying a FEC Scheme to be used with QUIC MUST define the REPAIR
frame format, among other things. The REPAIR frame MUST carry enough
information for a QUIC reception endpoint to understand exactly how
this repair symbol(s) has(ve) been generated. It implies that each
REPAIR symbol MUST communicate the block (with block codes) or
encoding window (with Sliding Window codes) composition. When there
is no gap in the source symbol set, this MAY be achieved by
communicating:
o the offset of the first source symbol of the block or encoding
window;
o the number of source symbols in the block or encoding window,
which can be either a number of symbols or a number of bytes since
symbols are of fixed size, E.
Note that unlike FEC Schemes for FLUTE/ALC, NORM, and FECFRAME, here
there is no notion of Encoding Symbol Id (ESI). The use of an offset
within the stream, with the guaranty that no wrapping to zero can
occur, provides an alternative mechanism to identify any source
symbol.
As explained above, source data is transmitted without any
modification, which provides backward compatibility. This is an
advantage in situations where the same QUIC stream is simultaneously
delivered to several QUIC reception endpoints (multicast): it enables
a given FEC Scheme to be used even if a subset of the QUIC reception
endpoints do not support it.
Editor's notes:
* This I-D proposes to define a single generic REPAIR frame
type, but an alternative could be to have a one-to-one mapping
between a REPAIR frame type and a specific FEC Scheme.
* The use of frame type within the Extension Frames range for
REPAIR frames is meant to facilitate experimentations. If the
use of coding in QUIC is recognized as having benefits, a
dedicated (or more, see above) frame type could be selected
later on.
5.3. Management of Silent Periods and End of Stream
If an application does not submit fresh data for some time, the last
source symbol may not be totally filled. It follows that this last
source symbol cannot be considered during FEC encoding and therefore
the associated bytes of the application stream are not protected. A
similar problem arrives when a stream is finished, the application
having no more data to submit to QUIC. Here also, the bytes of the
last incomplete source symbol are not protected by FEC encoding.
In order to solve this problem, it is RECOMMENDED that a QUIC sending
endpoint:
o Identifies when such a situation is likely to occur, for instance
by waiting no more than a certain time during an application
silent period;
o Upon time-out, the application falls back to the alternative re-
transmission based loss recovery mechanism for the bytes of the
last incomplete source symbol;
Editor's notes: Clearly, the above mechanism requires more thoughts
as well as experimental work. The "end of stream" situation may
be addressed through zero padding perhaps easily. However the
use of zero padding for transitory silent periods may add a lot
of specification and implementation complexity...
6. Procedures when Protecting Several QUIC Streams
This section focusses on the general case where FEC protection is
globally applied across two or more QUIC streams.
Editor's notes: It is not clear whether this use-case is needed. It
adds specification and implementation complexity that need to be
balanced with the expected benefits.
* Receiver: A first complexity comes from the requirement to
identify to which stream a decoded source symbol belongs to.
This is also one of the main difficulty for FECFRAME (both
with block and sliding window codes) which required to
distinguish an ADU (submitted by the application) from an ADUI
(the same ADU plus an additional FlowID among other things).
Do we want this level of complexity?
* Sender: Another complexity comes from the encoding window
management at a sender. With multiple streams, shifting the
encoding window to the right needs to be done based on
timestamps associated to source symbols of the various
streams: the oldest source symbol across all the streams will
be removed.
* When two largely different streams are protected togethers
(e.g., a high definition 4K video flow plus the associated
relatively low-rate audio stream), is this extra complexity
balanced by significant performance improvements compared to
an independent protection on each stream (intuition is yes,
the low bitrate flow is better protected iff the encoding
window is large enough)? And when the various streams have a
comparable bitrate? More work (incl. experimental work) is
needed to answer this question.
6.1. Application data, STREAM Frame data and Source Symbols
Within each stream, the source symbols MUST be defined as in the
simple case of a single stream. Figure 2 remains valid.
6.2. Block or Encoding Window Management
The details of how to create the block or encoding window are
specific to the FEC Scheme. A possible approach is the following.
When creating the block (block FEC code) or encoding window (sliding
window FEC code), the source symbols to consider of each stream are
appended. All the relevant source symbols of the first stream are
appended, followed by all the source symbols of the second stream,
etc. These sequences do not follow any timing consideration in order
to simplify signaling.
Figure 3 illustrates, in case of a Sliding Window FEC Scheme, an
encoding window with source symbols belonging to two streams, of
Stream ID 120 and 51 respectively.
< ----------- Stream ID 120 ---------- > < --- Stream ID 51 --- >
+-------+-------+-------+-------+-------+-------+-------+-------+
| | | | | | | | |
+-------+-------+-------+-------+-------+-------+-------+-------+
^ < -E- > ^
| |
offset = 0x42f0, length = 5*E offset = 0x0f24, length = 3*E
Figure 3: Example of encoding window of a Sliding Window FEC Scheme
and FEC protection across two streams.
6.3. Signaling Considerations within STREAM and REPAIR Frames
Source data on each stream is transmitted within STREAM frames, as
would happen without any FEC based loss recovery mechanism.
Repair symbols, generated during FEC encoding as a linear combination
of source symbols that belong to one or more of the streams, are
transmitted within REPAIR frames. Each REPAIR frame can be
associated to any of the input streams it protects, and therefore
associated to any of the associated Stream IDs.
Editor's notes: Check that indeed, with FEC protection across
several streams, assigning a REPAIR frame to any of the streams
it protects is meaningful. Should an approach for selecting one
stream (and Stream ID) be preferred?
The REPAIR frame format is FEC Scheme dependent and MUST be defined
by document specifying a FEC Scheme. One of the key information of
this REPAIR frame is the composition of the block (with block codes)
or encoding window (with sliding window codes) used to perform FEC
encoding. Indeed, this is the only manner to convey this information
since an application flow is not predictable (e.g., if an application
flow is momentarily suspended, the composition of the block or
encoding window will be affected). One possibility is to list, in
each REPAIR frame header:
o the actual number of streams considered (the maximum number is
known after the negotiation step, but if one of the streams
remains silent for some time, it may not contribute during
encoding and therefore be absent from the block or encoding
window);
o for each stream concerned, its Stream ID, the offset of the first
source symbol considered as well as the length, i.e., the number
of bytes considered.
This approach does not enable to keep track of the source symbol
ordering across streams, but enables a non ambiguous description of
the encoding window.
The FEC Scheme specification MUST also detail how to manage the block TBD
or encoding window. For instance, should the oldest source symbol of
any stream be removed from the encoding window when this latter is
shifted to the right? This would mean that a timestamp is attached
to each source symbol in order to identify the oldest one across all
streams.
7. Security Considerations 7. IANA Considerations
TBD TBD
8. IANA Considerations 8. Acknowledgments
TBD TBD
9. Acknowledgments 9. References
TBD 9.1. Normative References
10. References [Cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
10.1. Normative References R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/info/rfc8312>.
[QUIC-transport] [QUIC-transport]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport (Work in Progress) (work in progress), January transport (Work in Progress) (work in progress), January
2019, <https://datatracker.ietf.org/doc/ 2019, <https://datatracker.ietf.org/doc/
draft-ietf-quic-transport/>. draft-ietf-quic-transport/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 9.2. Informative References
[nc-taxonomy] [nc-taxonomy]
Roca (Ed.) et al., V., "Taxonomy of Coding Techniques for Roca (Ed.) et al., V., "Taxonomy of Coding Techniques for
Efficient Network Communications", Request For Efficient Network Communications", Request For
Comments RFC 8406, June 2018, Comments RFC 8406, June 2018,
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-irtf-nwcrg-network-coding-taxonomy/>. draft-irtf-nwcrg-network-coding-taxonomy/>.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
"Reed-Solomon Forward Error Correction (FEC) Schemes", "Reed-Solomon Forward Error Correction (FEC) Schemes",
RFC 5510, DOI 10.17487/RFC5510, April 2009, RFC 5510, DOI 10.17487/RFC5510, April 2009,
<https://www.rfc-editor.org/info/rfc5510>. <https://www.rfc-editor.org/info/rfc5510>.
[RLC] Roca, V. and B. Teibi, "Sliding Window Random Linear Code [RLC] Roca, V. and B. Teibi, "Sliding Window Random Linear Code
(RLC) Forward Erasure Correction (FEC) Scheme for (RLC) Forward Erasure Correction (FEC) Scheme for
FECFRAME", Work in Progress, Transport Area Working Group FECFRAME", Work in Progress, Transport Area Working Group
(TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in
Progress), February 2019, <https://tools.ietf.org/html/ Progress), June 2019, <https://tools.ietf.org/html/
draft-ietf-tsvwg-rlc-fec-scheme>. draft-ietf-tsvwg-rlc-fec-scheme>.
Authors' Addresses Authors' Addresses
Ian Swett Ian Swett
Google Google
Cambridge, MA Cambridge, MA
US US
Email: ianswett@google.com Email: ianswett@google.com
skipping to change at line 666 skipping to change at page 16, line 17
US US
Email: marie@mjmontpetit.com Email: marie@mjmontpetit.com
Vincent Roca Vincent Roca
INRIA INRIA
Univ. Grenoble Alpes Univ. Grenoble Alpes
France France
Email: vincent.roca@inria.fr Email: vincent.roca@inria.fr
Francois Michel
UCLouvain
Louvain-la-Neuve
Belgium
Email: francois.michel@uclouvain.be
 End of changes. 34 change blocks. 
323 lines changed or deleted 370 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/