< draft-swett-nwcrg-coding-for-quic-01.txt   draft-swett-nwcrg-coding-for-quic-02.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: December 23, 2018 Triangle Video Expires: August 8, 2019 Triangle Video
V. Roca V. Roca
INRIA INRIA
June 21, 2018 February 4, 2019
Coding for QUIC Coding for QUIC
draft-swett-nwcrg-coding-for-quic-01 draft-swett-nwcrg-coding-for-quic-02
Abstract Abstract
This document focusses on the integration of FEC coding in the QUIC This document focusses 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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 December 23, 2018. This Internet-Draft will expire on August 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . 4
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 3.5. FEC Protection at the Stream Level . . . . . . . . . . . 5
3.6. About Gaps in the Set of Source Symbols Considered During 3.6. About Gaps in the Set of Source Symbols Considered During
Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5
4. FEC Scheme Negotiation in QUIC . . . . . . . . . . . . . . . 6 4. FEC Scheme Negotiation in QUIC . . . . . . . . . . . . . . . 6
4.1. FEC Scheme Selection Process . . . . . . . . . . . . . . 7 4.1. FEC Scheme Selection Process . . . . . . . . . . . . . . 7
4.2. FEC Scheme Configuration Information . . . . . . . . . . 7 4.2. FEC Scheme Configuration Information . . . . . . . . . . 8
5. Procedures when Protecting a Single QUIC Stream . . . . . . . 8 5. Procedures when Protecting a Single QUIC Stream . . . . . . . 8
5.1. Application data, STREAM Frame data and Source Symbols . 8 5.1. Application data, STREAM Frame data and Source Symbols . 8
5.2. Signaling Considerations within STREAM and REPAIR Frames 9 5.2. Signaling Considerations within STREAM and REPAIR Frames 9
5.3. Management of Silent Periods and End of Stream . . . . . 10 5.3. Management of Silent Periods and End of Stream . . . . . 10
6. Procedures when Protecting Several QUIC Streams . . . . . . . 11 6. Procedures when Protecting Several QUIC Streams . . . . . . . 11
6.1. Application data, STREAM Frame data and Source Symbols . 11 6.1. Application data, STREAM Frame data and Source Symbols . 12
6.2. Block or Encoding Window Management . . . . . . . . . . . 11 6.2. Block or Encoding Window Management . . . . . . . . . . . 12
6.3. Signaling Considerations within STREAM and REPAIR Frames 12 6.3. Signaling Considerations within STREAM and REPAIR Frames 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
skipping to change at page 7, line 24 skipping to change at page 7, line 24
all the Streams that need FEC protection? all the Streams that need FEC protection?
4.1. FEC Scheme Selection Process 4.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 1 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{FS1_Encoding_ID | other} supported_fec_scheme_32b{FEC_Encoding_ID1 | other}
supported_fec_scheme_64b{FS1_Encoding_ID | other} supported_fec_scheme_64b{FEC_Encoding_ID2 | other}
choose FEC Scheme "FS1" choose FEC Scheme 1
- - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - >
supported_fec_scheme_32b{FS1_Encoding_ID | other} supported_fec_scheme_32b{FEC_Encoding_ID1 | other}
Figure 1: Example FEC Scheme selection process, during the initial Figure 1: 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 4.2).
It is possible that the QUIC endpoint that receives one or more FEC
Scheme proposals from the initiator cannot select any of them. In
that case the negotiation process fails...
Editor's notes:
* So what? How does it finishes? Consequences?
* Can the second QUIC endpoint change the proposed static
parameters? In that case can the initator refuse?
4.2. FEC Scheme Configuration Information 4.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 1, 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.
skipping to change at page 8, line 44 skipping to change at page 9, line 6
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| 2 ----- >< --- Frame 3 -- >< -| source symbols 4, 5, 6, 7 | 2 ----- >< --- Frame 3 -- >< -| source symbols 4, 5, 6, 7
+-------+-------+----+--+-------+ +-------+-------+----+--+-------+
| Frame 4 - >< -F5- >| source symbols 8, 9 and 10 | Frame 4 - >< -F5- >| source symbols 8, 9 and 10
+-------+-------+----+ (incomplete) +-------+-------+----+ (incomplete)
Figure 2: Example of source symbol mapping, when the E value is Figure 2: Example of source symbol mapping, when the E value is
relatively small. relatively small.
Any value for E is possible, from a single byte to several hundreds Any value for E is possible, from a single byte to several hundreds
or thousands of bytes. In general, the source symbols are not or thousands of bytes, as long as a frame containing a repair symbol
aligned with data chunks sent in the STREAM frames. A given STREAM (E bytes long) can fit into a QUIC packet. In general, the source
frame may carry all the bytes of a given source symbol. But when a symbols are not aligned with data chunks sent in the STREAM frames.
source symbol straddles two or more (e.g., if E is large compared to A given STREAM frame may carry all the bytes of a given source
usual frame size) STREAM frames, a proper reception of these two (or symbol. But when a source symbol straddles two or more (e.g., if E
more) STREAM frames is needed for a QUIC reception endpoint to is large compared to usual frame size) STREAM frames, a proper
consider that the source symbol is available for FEC decoding reception of these two (or more) STREAM frames is needed for a QUIC
operations. The choice of an appropriate value for E may depend on reception endpoint to consider that the source symbol is available
the use case (in particular on the nature of application data). A for FEC decoding operations. The choice of an appropriate value for
reasonably small value reduces the probability that a source symbol E may depend on the use case (in particular on the nature of
straddles two or more STREAM frames, a situation that is considered application data). A reasonably small value reduces the probability
as potentially harmful (the unit of control, the source symbol, and that a source symbol straddles two or more STREAM frames, a situation
unit of transmission, the frame, are not aligned). However an overly that is considered as potentially harmful (the unit of control, the
small value also increases processing complexity (FEC encoding and source symbol, and unit of transmission, the frame, are not aligned).
decoding are performed over a larger linear system) so there is an However an overly small value also increases processing complexity
incentive to use a larger value. An appropriate balance should be (FEC encoding and decoding are performed over a larger linear system)
found, and this choice is considered as out of scope for this so there is an incentive to use a larger value. An appropriate
document. 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 5.2. Signaling Considerations within STREAM and REPAIR Frames
Once the initial negotiation succeeded and an appropriate FEC Scheme Once the initial negotiation succeeded and an appropriate FEC Scheme
has been chosen between the QUIC endpoints, data is exchanged as has been chosen between the QUIC endpoints, data is exchanged as
follows. Source data is transmitted within STREAM frames, as would follows. Source data is transmitted within STREAM frames, as would
happen without any FEC based loss recovery mechanism (in particular happen without any FEC based loss recovery mechanism (in particular
without considering source symbols boundaries). Repair data, without considering source symbols boundaries). Repair data,
computed during FEC encoding, on the opposite, is sent within a computed during FEC encoding, on the opposite, is sent within a
dedicated REPAIR frame type, chosen within the type range dedicated dedicated REPAIR frame type, chosen within the type range dedicated
to "Extension Frames". In both cases, the same Stream ID is used to "Extension Frames". In both cases, the same Stream ID is used
since both flows relate to the same stream. since both flows relate to the same stream.
The REPAIR frame format is FEC Scheme dependent. The document The REPAIR frame format is FEC Scheme dependent. The document
specifying a FEC Scheme to be used with QUIC MUST define the REPAIR specifying a FEC Scheme to be used with QUIC MUST define the REPAIR
frame format, among other things. The REPAIR frame MUST carry enough frame format, among other things. The REPAIR frame MUST carry enough
information for a QUIC reception endpoint to understand exactly how information for a QUIC reception endpoint to understand exactly how
this repair symbol(s) has(ve) been generated. It implies that each this repair symbol(s) has(ve) been generated. It implies that each
REPAIR symbol MUST communicate the block (with block codes) or REPAIR symbol MUST communicate the block (with block codes) or
encoding window (with Sliding Window codes) composition. This MAY be encoding window (with Sliding Window codes) composition. When there
achieved by communicating in case there is no gap in the source is no gap in the source symbol set, this MAY be achieved by
symbol set (see XXX): communicating:
o the offset of the first source symbol of the block or encoding o the offset of the first source symbol of the block or encoding
window; window;
o the number of source symbols in 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 which can be either a number of symbols or a number of bytes since
symbols are of fixed size, E. symbols are of fixed size, E.
Note that unlike FEC Schemes for FLUTE/ALC, NORM, and FECFRAME, here Note that unlike FEC Schemes for FLUTE/ALC, NORM, and FECFRAME, here
there is no notion of Encoding Symbol Id (ESI), an identifier managed there is no notion of Encoding Symbol Id (ESI). The use of an offset
in a sequential manner to identify source and repair symbols. The within the stream, with the guaranty that no wrapping to zero can
use of an offset within the stream, with the guaranty that no occur, provides an alternative mechanism to identify any source
wrapping to zero can occur, provides an alternative mechanism to symbol.
identify any source symbol.
As explained above, source data is transmitted without any As explained above, source data is transmitted without any
modification, which provides backward compatibility. This is modification, which provides backward compatibility. This is an
advantage in situations where the same QUIC stream is delivered to advantage in situations where the same QUIC stream is simultaneously
several QUIC reception endpoints (multicast): it may be appropriate delivered to several QUIC reception endpoints (multicast): it enables
to select a given FEC Scheme even if it is known that a subset of the a given FEC Scheme to be used even if a subset of the QUIC reception
QUIC reception endpoints do not support it. endpoints do not support it.
Editor's notes: Editor's notes:
* This I-D proposes to define a single generic REPAIR frame * This I-D proposes to define a single generic REPAIR frame
type, but an alternative could be to have a one-to-one mapping type, but an alternative could be to have a one-to-one mapping
between a REPAIR frame type and a specific FEC Scheme. between a REPAIR frame type and a specific FEC Scheme.
* The use of frame type within the Extension Frames range for * The use of frame type within the Extension Frames range for
REPAIR frames is meant to facilitate experimentations. If the REPAIR frames is meant to facilitate experimentations. If the
use of coding in QUIC is recognized as having benefits, a use of coding in QUIC is recognized as having benefits, a
skipping to change at page 13, line 35 skipping to change at page 14, line 4
8. IANA Considerations 8. IANA Considerations
TBD TBD
9. Acknowledgments 9. Acknowledgments
TBD TBD
10. References 10. References
10.1. Normative References 10.1. Normative References
[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-12 (work in progress), May 2018, transport (Work in Progress) (work in progress), January
<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 10.2. Informative References
[nc-taxonomy] [nc-taxonomy]
Roca et al., V., "Taxonomy of Coding Techniques for Roca (Ed.) et al., V., "Taxonomy of Coding Techniques for
Efficient Network Communications", draft-irtf-nwcrg- Efficient Network Communications", Request For
network-coding-taxonomy (Work in Progress) (work in Comments RFC 8406, June 2018,
progress), March 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., "Sliding Window Random Linear Code (RLC) Forward [RLC] Roca, V. and B. Teibi, "Sliding Window Random Linear Code
Erasure Correction (FEC) Scheme for FECFRAME", Work (RLC) Forward Erasure Correction (FEC) Scheme for
in Progress, Transport Area Working Group (TSVWG) draft- FECFRAME", Work in Progress, Transport Area Working Group
ietf-tsvwg-rlc-fec-scheme (Work in Progress), May 2018, (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in
<https://tools.ietf.org/html/ Progress), February 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
 End of changes. 20 change blocks. 
56 lines changed or deleted 66 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/