idnits 2.17.1 draft-quic-coding-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2017) is 2368 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'QUIC-WG' is mentioned on line 92, but not defined == Unused Reference: 'NC-Taxonomy' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC6363' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'QUIC-Connect' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'QUIC-Loss' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'QUIC-Overview' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'QUIC-TLS' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'QUIC-Trans' is defined on line 279, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-irtf-nwcrg-network-coding-taxonomy-05 ** Downref: Normative reference to an Informational draft: draft-irtf-nwcrg-network-coding-taxonomy (ref. 'NC-Taxonomy') -- Unexpected draft version: The latest known version of draft-iyengar-quic-loss-recovery is -01, but you're referring to -06. == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-06 Summary: 1 error (**), 0 flaws (~~), 12 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: Standards Track M. Montpetit 5 Expires: May 3, 2018 Triangle Video 6 V. Roca 7 INRIA 8 October 30, 2017 10 Network Layer Coding for QUIC: Requirements 11 draft-quic-coding-00 13 Abstract 15 This document presents the motivation and requirements for the use 16 of Network Level Packet Erasure Coding to improve the performance of 17 the QUIC protocol that is proposed a new transport protocol. The 18 document does not specify a specific code but lists the salient 19 features that a code should have in order to deal with know loss 20 patterns on QUIC paths. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. QUIC Background . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 11.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Appendix A. Revision information . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 In addition, while most of the the terminology in this document is 79 conform to the taxonomy presented in [[NC-Taxonomy]] for clarity and 80 comparison with existing QUIC documents we continue to use the word 81 packet to indication the entity that will be encoded vs. symbol in 82 the taxonomy document. 84 NOTE: while using drafts in references is not compliant with IETF/ 85 IRTF rules they will be replaced by RFCs as they become available. 87 2. Introduction 89 The QUIC (Quick UDP-based Internet Connection)protocol is currently 90 being proposed as new transport protocol than multiplexes connections 91 over UDP. The major elements have been defined and are being 92 implemented by the QUIC IETF working group [QUIC-WG] including wire 93 format, connection establishment, stream multiplexing, stream and 94 connection-level flow control, and data encryption [numerous draft 95 references]. This document addresses an outstanding element of the 96 QUIC protocol, namely how to account and correct for packet losses at 97 the network layer that will have a very negative impact on transport 98 delay, throughput and reliability. This document presents the 99 salient features and requirements for a network coding (NC) protocol 100 to provide the QUIC packet loss recovery it requires. NC provides a 101 structured, algebraic mechanism to recover lost packets based on a 102 vast heritage of Forward Error Correction (FEC) and has shown better 103 performance of packet recovery than XORs or repetition codes to deal 104 with the losses in the Internet. The Network Coding taxonomy 105 document [[NC-Taxonomy]] contains an overview of top NC concepts. 106 Note: we need a small NC draft that explains how it works. 108 3. QUIC Background 110 This section will completed in a future version. For the needs of 111 the current document we need to know that the QUIC packet format 112 contains a unique packet identifier (ID) and a connection ID. 113 Details will be obtained from [[QUIC-Connect]] and [[QUIC-Trans]] 115 4. Motivation 117 The QUIC protocol from its early implementations, wanted to address 118 packet losses in the Internet as they can greatly impact protocol 119 performance and impact the performance congestion control mechanisms 120 [[QUIC-Loss]]. For example TCP goodput goes below 20% with 3% loss 121 [are there any other references besides the famous Mathis curve?]. 122 In this section we review the motivations behind the use of a network 123 coding approach to reduce the impact of packet losses on QUIC. It is 124 important to note that we limit the sources of the losses to IP layer 125 and above and losses in lower layers are addressed by other 126 standardization organization. 128 It is known (is it?) that the main sources of losses in the Internet 129 include (but are not limited to): 131 o Queuing losses across multiple flows 132 o Intermittent timeouts 133 o Connection losses 134 o Residual physical or MAC layer losses 135 o Misrouting 136 o other? 138 The main feature of all the patterns associated with the loss events 139 above is the fact that losses appear in clusters (burst or correlated 140 losses). Hence they are not the 'random losses' that can be 141 recovered by non structured mechanisms like XOR or repetitions codes 142 even with high overhead or simple block codes with fixed window 143 sizes. Hence because of the correlated losses, the first requirement 144 for a good code for QUIC is one that allows variable window sizes 145 that allow to vary with the size of the burst. That will be better 146 suited to recover the losses with statistically approximately the 147 same overhead as the average packet loss without limitations on the 148 loss pattern. 150 5. Architecture 152 In order to define the potential NC solution, a detailed architecture 153 is necessary. Hence, the main QUIC/NC architecture topics to be 154 addressed includes the following (each will become a subsection in 155 the future). 157 o Type of connection: while unicast and/or multicast/broadcast 158 communications are possible over QUIC it is assumed that an 159 initial implementation will be limited to unicast. 160 o Addressing single source flow or multiple flows: at the the coding 161 level, if there is a multiplexing on top of the coding level, 162 already managed by QUIC machinery, it may be totally transparent. 163 We can assume that individual packets and connections can be 164 individually identified. 165 o Use of feedback: since the code will need to deal with correlated 166 losses can it benefit from feedback to manage the window as 167 opposed to a fully unidirectional source-destination mechanism. 168 This will allow not to lose any packet part of a current 169 generation before the loss burst ends (we need a reference on 170 window growth and maximum size) 171 o Minimization of latency:Latency is key for the solution design. 172 This includes reducing extra delay due to encoding/decoding at the 173 ingress, egress and intermediate nodes (middleboxes) especially on 174 delay sensitive paths. At the same time long bandwidth-delay 175 product networks coding should reduce the overall end-to-end delay 176 experienced by an application significantly by minimizing the 177 effect of packet losses and retransmission on TCP congestion 178 control and throughput. 179 o Throughput aspects: it is expected that the QUIC flows will 180 include high throughput flows, very low throughput flows and mixed 181 sizes flows. 182 o Interactions with other functionalities: Interactons with 183 congestion control and encryption will also be key. Directions 184 will be taken from [[QUIC-Loss]] and [[QUIC-TLS]] and other 185 relevant documents 186 o Code changes and future proofing: any protocol designed within 187 QUIC should be able to maybe use more than one code to change 188 codes easily by without major impact this is to address different 189 network conditions or improve performance if a new code was to be 190 developed. It is assumed that the code remain the same for the 191 full QUIC session lifetime but that within a session at least for 192 the beginning it should be possible to turn off the coding to 193 prevent catastrophic congestion collapse for example. 195 6. Use-cases 197 Note: this will be detailed in the next version of the document 199 7. Requirements 201 The initial requirements for the QUIC NC are presented below. This 202 list will help to chose the best solution amongst existing codes. 204 Requirements: 206 o Simplicity/low complexity: both encoding and decoding operations 207 should be simple and ass little complexity to the QUIC operations; 208 the use of systematic coding will be encouraged. 209 o Low overhead: the NC overhead to compensate for all losses should 210 be as close as possible to the average loss on the path as to not 211 create additional congestion condition. 212 o In network coding: there should be ways to create additional coded 213 symbols inside the network either directly or via partial or full 214 decoding. 215 o Multipath: there should be ways to take advantage of multipath 216 communications for example to send packets and coded symbols on 217 different paths to reduce delay and overhead on some delay or loss 218 sensitive paths. 219 o Licensing/IPR: the solution should be license/patent free. 221 8. Next Steps 223 Besides adding the sections missing in the document based on future 224 discussion it is proposed to define a strawman architecture based on 225 existing codes and using the standard APIs being developed in the RG. 227 9. IANA Considerations 229 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 231 This memo includes no request to IANA. 233 10. Security Considerations 235 Security: While NC will not impact security in itself it will be 236 important to verify how NC interacts with current encryption used in 237 QUIC and presented in [[QUIC-TLS]]. 239 11. References 241 11.1. Normative References 243 [NC-Taxonomy] 244 Abramson, B. and et. al., "Network Coding Taxonomy", 245 Internet-draft draft-irtf-nwcrg-network-coding-taxonomy- 246 05.txt, July 2017. 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 254 Correction (FEC) Framework", RFC 6363, 255 DOI 10.17487/RFC6363, October 2011, 256 . 258 11.2. Informative References 260 [QUIC-Connect] 261 Roskind, J., "QUIC: Quick UDP Internet Connections", URL 262 https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ- 263 saqsQx7rFV-ev2jRFUoVD34/preview#. 265 [QUIC-Loss] 266 Iyengar, J. and I. Swett, "QUIC Loss Detection and 267 Congestion Control", Internet-draft draft-iyengar-quic- 268 loss-recovery-06.txt, September 2017. 270 [QUIC-Overview] 271 "QUIC Overview", 272 URL https://datatracker.ietf.org/wg/quic/about/. 274 [QUIC-TLS] 275 Thomson, M. and R. Harrison, "Using Transport Layer 276 Security (TLS) to Secure QUIC", Internet-draft -06.txt, 277 September 2017. 279 [QUIC-Trans] 280 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 281 and Secure Transport", Internet-draft draft-ietf-quic- 282 transport-06.txt, September 2017. 284 Appendix A. Revision information 286 XXX RFC-Ed please remove this section prior to publication. 288 Authors' Addresses 290 Ian Swett 291 Google 292 Cambridge, MA 293 USA 295 EMail: ianswett@google.com 297 Marie-Jose Montpetit 298 Triangle Video 299 Boston, MA 300 USA 302 EMail: marie@mjmontpetit.com 304 Vincent Roca 305 INRIA 306 Grenoble 307 France 309 EMail: vincent.roca@inria.fr