idnits 2.17.1 draft-swett-nwcrg-coding-for-quic-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 3, 2018) is 2247 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5053' is defined on line 190, but no explicit reference was found in the text == Unused Reference: 'RFC5510' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'RLNC' is defined on line 196, but no explicit reference was found in the text == Unused Reference: 'Tetrys' is defined on line 199, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3452 (Obsoleted by RFC 5052, RFC 5445) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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. Montpetit 5 Expires: September 4, 2018 Triangle Video 6 V. Roca 7 INRIA 8 March 3, 2018 10 Coding for QUIC 11 draft-swett-nwcrg-coding-for-quic-00 13 Abstract 15 This document introduces means of integrating loss recovery coding in 16 the proposed QUIC transport protocol. While no specific code is 17 specified, the document defines how to integrate recent coding 18 research to recover packets lost in QUIC sessions. This research 19 targets the codes themselves as well as how to use them in real world 20 protocols. Loss recover should improve the QUIC performance in 21 sessions impacted by loss. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 4, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 2. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Coding Symbol . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 3.2. Informative References . . . . . . . . . . . . . . . . . 4 66 Appendix A. Appendix: Reference Algorithms . . . . . . . . . . . 5 67 Appendix B. Appendix: Participating Middleboxes . . . . . . . . 5 68 Appendix C. Appendix: APIS . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 QUIC is a new transport that wants to improve network performance by 74 enabling out of order delivery, partial reliability, and methods of 75 recovery besides retransmission while also improving security. This 76 document specifies a design to enable error correcting codes to be 77 used to recover lost data in QUIC. Error correcting codes have the 78 ability to recover packet losses in less than 1 round trip at the 79 cost of more total data transmission and decoding delay. The design 80 does not specify a code but allows to negotiate it hence assumes that 81 more than one code could be offered concurrently as well as leaving 82 open the possibility of new codes in the future. Without loss of 83 generality in the document we consider that the encoding operations 84 compute a linear combination of QUIC packets. Terms and definitions 85 that apply to coding are available in RFC xxxx [nc-taxonomy] 87 1.1. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. Design Considerations 95 2.1. Framing 97 A new QUIC frame type is defined within the current framework 98 [quic-basics] to add the error correction feature. This new frame 99 type contains inputs to the negotiated loss recovery algorithm as 100 specified by the specific algorithm and coded information. THis 101 frame payload begins with arguments that point to the negotiated 102 function that generates the coding coefficients to be applied to the 103 remaining payload. It also indicates the identity of the first 104 packet in the coding window and its size as well as other necessary 105 input. There are currently a number of options for identifying the 106 coded packets. Firstly we can assign a new coded sequence number. 107 If all packets are encoded in a session, then we can specify which 108 packet is the first and with the window size it will be easy to 109 recover the packets. If some packets are encoded and some are not 110 then there could be gaps in the numbering that is not due to loss and 111 we may need to specify which packets are inside the window using a 112 form of run-length-encoding. We can specify a fixed-length field in 113 order to identify the packets. Secondly, we could use the QUIC 114 packet numbering which would reduce the overhead. This has the same 115 functionality as using a sequence number except that in that case the 116 gaps in numbering could be due to path migration and not losses Note: 117 a reference will be provided in a later version. 119 2.2. Coding Symbol 121 One of the the design consideration is the definition of the code 122 symbol. In order to minimize the impact on the QUIC design, the QUIC 123 loss recovery (QLR) will be applied inside the QUIC encrypted packet 124 payloads. Hence raw packets are used as symbols, the units of 125 recovery are what the coding coefficients are applied to. Any packet 126 payloads smaller than the coded payload will be implicitly padded 127 with zeros as to prevent the detection of coding on any path. To 128 allow for the coded packets to have more encrypted payload than other 129 packets, any QUIC PADDING frames(type 0x00) [quic-basics] will be 130 removed from the payload before applying the algorithm. This new 131 frame type contains inputs to the negotiated loss recovery algorithm 132 as specified by the specific algorithm and coded information.We want 133 to keep the coding implementation simple, provide for code 134 negotiation and stay independent of any encryption mechanism. It is 135 thus proposed to apply loss recovery code before the encryption, 136 hence to clear data. This allows the encryption operation to be 137 unencumbered by coding. Hence raw packets will be used as coding 138 symbols. The downside of this approach is that it does not enable 139 non-participating middleboxes to add or remove encoding from packets 140 but this is considered insignificant compared to the complexities of 141 interacting with security mechanisms. In addition, it is assumed 142 that the the entire packet content will constitute a single source 143 symbol. This choice is motivated by the desire to simplify the 144 implementation. Coding should be applied to all QUIC packets except 145 the 0RTT payloads. 0RTT payloads are sent prior to negotiation, and 146 the QUIC negotiation mechanism does not allow sending extension 147 frames prior to handshake completion. 149 2.3. Negotiation 151 There are already multiple candidates for the QUIC FEC and we assume 152 that others may become available in the future as research 153 continues.In order to stay as generic as possible and enable QUIC 154 network operators to select their coding technology, it is assumed 155 that a coding negotiation will be implemented to select one or more 156 codes to be used over a QUIC session.This will be implemented using 157 the one step negotiation of the new QUIC negotiation mechanism 158 [quic-basics]. Each available coding algorithm should use the 159 standard FEC frame [RFC3452] but reserve a different codepoint. We 160 want to ensure that coding negotiation occurs during the QUIC 161 handshake and can be used in all short header QUIC packets. Finally, 162 to make the code selection as generic as possible, each algorithm 163 should specifies a sequence of coding coefficients or a function to 164 generate them, window sizes as necessary as well as meta information 165 to ensure the conformant performance of the coding and decoding 166 operations 168 3. References 170 3.1. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, 174 DOI 10.17487/RFC2119, March 1997, 175 . 177 3.2. Informative References 179 [nc-taxonomy] 180 Roca et al., V., "draft-irtf-nwcrg-network-coding- 181 taxonomy-07", 2018. 183 [quic-basics] 184 Iyengar, J. and M. Thomson, "draft-ietf-quic-transport- 185 09", 2018. 187 [RFC3452] Luby et al., M., "RFC 3452: Forward Error Correction (FEC) 188 Building Block", 2002. 190 [RFC5053] Luby et al., M., "RFC 5053: Raptor Forward Error 191 Correction Scheme for Object Delivery", 2007. 193 [RFC5510] Lacan et al., J., "RFC 5510: Reed-Solomon Forward Error 194 Correction (FEC) Schemes", 2009. 196 [RLNC] Ho et al., T., "A Random Linear Network Coding Approach to 197 Multicast", 2006. 199 [Tetrys] Detchart, J., Lochin, E., Lacan, J., and V. Roca, "draft- 200 detchart-nwcrg-tetrys-03", 2016. 202 Appendix A. Appendix: Reference Algorithms 204 This ID does not mandate nor depends on any coding scheme. However, 205 in order to have an initial implementation with good performance and 206 not encumbered by intellectual property and proprietary 207 implementations, it is suggested to use the Raptor (RFC 5053) as a 208 reference algorithm. However, since the Raptor code perform badly 209 with small blocks, depending on the application, another alternative 210 is to use Reed-Solomon (RFC 5510) codes. It is assumed that other 211 candidates that are free of IPR may become candidates in the future. 213 Appendix B. Appendix: Participating Middleboxes 215 The coding approach described in this document does allow on path 216 elements that have the ephemeral keys to decrypt packets and add or 217 remove FEC packets. 219 Appendix C. Appendix: APIS 221 It is planned that the QUIC coding mechanism will conform to any 222 common API defined in the research group. 224 Authors' Addresses 226 Ian Swett 227 Google 228 Cambridge, MA 229 US 231 Email: ianswett@google.com 232 Marie-Jose Montpetit 233 Triangle Video 234 Boston, MA 235 US 237 Email: marie@mjmontpetit.com 239 Vincent Roca 240 INRIA 241 Grenoble, France 242 US 244 Email: vincent.roca@inria.fr