nwcrg I. Swett
Internet-Draft Google
Intended status: Informational M. Montpetit
Expires: September 4, 2018 Triangle Video
V. Roca
INRIA
March 3, 2018
Coding for QUIC
draft-swett-nwcrg-coding-for-quic-00
Abstract
This document introduces means of integrating loss recovery coding in
the proposed QUIC transport protocol. While no specific code is
specified, the document defines how to integrate recent coding
research to recover packets lost in QUIC sessions. This research
targets the codes themselves as well as how to use them in real world
protocols. Loss recover should improve the QUIC performance in
sessions impacted by loss.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Swett, et al. Expires September 4, 2018 [Page 1]
Internet-Draft Coding for QUIC March 2018
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Design Considerations . . . . . . . . . . . . . . . . . . . . 3
2.1. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Coding Symbol . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Normative References . . . . . . . . . . . . . . . . . . 4
3.2. Informative References . . . . . . . . . . . . . . . . . 4
Appendix A. Appendix: Reference Algorithms . . . . . . . . . . . 5
Appendix B. Appendix: Participating Middleboxes . . . . . . . . 5
Appendix C. Appendix: APIS . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
QUIC is a new transport that wants to improve network performance by
enabling out of order delivery, partial reliability, and methods of
recovery besides retransmission while also improving security. This
document specifies a design to enable error correcting codes to be
used to recover lost data in QUIC. Error correcting codes have the
ability to recover packet losses in less than 1 round trip at the
cost of more total data transmission and decoding delay. The design
does not specify a code but allows to negotiate it hence assumes that
more than one code could be offered concurrently as well as leaving
open the possibility of new codes in the future. Without loss of
generality in the document we consider that the encoding operations
compute a linear combination of QUIC packets. Terms and definitions
that apply to coding are available in RFC xxxx [nc-taxonomy]
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Swett, et al. Expires September 4, 2018 [Page 2]
Internet-Draft Coding for QUIC March 2018
2. Design Considerations
2.1. Framing
A new QUIC frame type is defined within the current framework
[quic-basics] to add the error correction feature. This new frame
type contains inputs to the negotiated loss recovery algorithm as
specified by the specific algorithm and coded information. THis
frame payload begins with arguments that point to the negotiated
function that generates the coding coefficients to be applied to the
remaining payload. It also indicates the identity of the first
packet in the coding window and its size as well as other necessary
input. There are currently a number of options for identifying the
coded packets. Firstly we can assign a new coded sequence number.
If all packets are encoded in a session, then we can specify which
packet is the first and with the window size it will be easy to
recover the packets. If some packets are encoded and some are not
then there could be gaps in the numbering that is not due to loss and
we may need to specify which packets are inside the window using a
form of run-length-encoding. We can specify a fixed-length field in
order to identify the packets. Secondly, we could use the QUIC
packet numbering which would reduce the overhead. This has the same
functionality as using a sequence number except that in that case the
gaps in numbering could be due to path migration and not losses Note:
a reference will be provided in a later version.
2.2. Coding Symbol
One of the the design consideration is the definition of the code
symbol. In order to minimize the impact on the QUIC design, the QUIC
loss recovery (QLR) will be applied inside the QUIC encrypted packet
payloads. Hence raw packets are used as symbols, the units of
recovery are what the coding coefficients are applied to. Any packet
payloads smaller than the coded payload will be implicitly padded
with zeros as to prevent the detection of coding on any path. To
allow for the coded packets to have more encrypted payload than other
packets, any QUIC PADDING frames(type 0x00) [quic-basics] will be
removed from the payload before applying the algorithm. This new
frame type contains inputs to the negotiated loss recovery algorithm
as specified by the specific algorithm and coded information.We want
to keep the coding implementation simple, provide for code
negotiation and stay independent of any encryption mechanism. It is
thus proposed to apply loss recovery code before the encryption,
hence to clear data. This allows the encryption operation to be
unencumbered by coding. Hence raw packets will be used as coding
symbols. The downside of this approach is that it does not enable
non-participating middleboxes to add or remove encoding from packets
but this is considered insignificant compared to the complexities of
Swett, et al. Expires September 4, 2018 [Page 3]
Internet-Draft Coding for QUIC March 2018
interacting with security mechanisms. In addition, it is assumed
that the the entire packet content will constitute a single source
symbol. This choice is motivated by the desire to simplify the
implementation. Coding should be applied to all QUIC packets except
the 0RTT payloads. 0RTT payloads are sent prior to negotiation, and
the QUIC negotiation mechanism does not allow sending extension
frames prior to handshake completion.
2.3. Negotiation
There are already multiple candidates for the QUIC FEC and we assume
that others may become available in the future as research
continues.In order to stay as generic as possible and enable QUIC
network operators to select their coding technology, it is assumed
that a coding negotiation will be implemented to select one or more
codes to be used over a QUIC session.This will be implemented using
the one step negotiation of the new QUIC negotiation mechanism
[quic-basics]. Each available coding algorithm should use the
standard FEC frame [RFC3452] but reserve a different codepoint. We
want to ensure that coding negotiation occurs during the QUIC
handshake and can be used in all short header QUIC packets. Finally,
to make the code selection as generic as possible, each algorithm
should specifies a sequence of coding coefficients or a function to
generate them, window sizes as necessary as well as meta information
to ensure the conformant performance of the coding and decoding
operations
3. References
3.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
3.2. Informative References
[nc-taxonomy]
Roca et al., V., "draft-irtf-nwcrg-network-coding-
taxonomy-07", 2018.
[quic-basics]
Iyengar, J. and M. Thomson, "draft-ietf-quic-transport-
09", 2018.
[RFC3452] Luby et al., M., "RFC 3452: Forward Error Correction (FEC)
Building Block", 2002.
Swett, et al. Expires September 4, 2018 [Page 4]
Internet-Draft Coding for QUIC March 2018
[RFC5053] Luby et al., M., "RFC 5053: Raptor Forward Error
Correction Scheme for Object Delivery", 2007.
[RFC5510] Lacan et al., J., "RFC 5510: Reed-Solomon Forward Error
Correction (FEC) Schemes", 2009.
[RLNC] Ho et al., T., "A Random Linear Network Coding Approach to
Multicast", 2006.
[Tetrys] Detchart, J., Lochin, E., Lacan, J., and V. Roca, "draft-
detchart-nwcrg-tetrys-03", 2016.
Appendix A. Appendix: Reference Algorithms
This ID does not mandate nor depends on any coding scheme. However,
in order to have an initial implementation with good performance and
not encumbered by intellectual property and proprietary
implementations, it is suggested to use the Raptor (RFC 5053) as a
reference algorithm. However, since the Raptor code perform badly
with small blocks, depending on the application, another alternative
is to use Reed-Solomon (RFC 5510) codes. It is assumed that other
candidates that are free of IPR may become candidates in the future.
Appendix B. Appendix: Participating Middleboxes
The coding approach described in this document does allow on path
elements that have the ephemeral keys to decrypt packets and add or
remove FEC packets.
Appendix C. Appendix: APIS
It is planned that the QUIC coding mechanism will conform to any
common API defined in the research group.
Authors' Addresses
Ian Swett
Google
Cambridge, MA
US
Email: ianswett@google.com
Swett, et al. Expires September 4, 2018 [Page 5]
Internet-Draft Coding for QUIC March 2018
Marie-Jose Montpetit
Triangle Video
Boston, MA
US
Email: marie@mjmontpetit.com
Vincent Roca
INRIA
Grenoble, France
US
Email: vincent.roca@inria.fr
Swett, et al. Expires September 4, 2018 [Page 6]