idnits 2.17.1 draft-abilash-quic-network-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 abstract seems to contain references ([MEG2016], [I-D.ietf-quic-transport]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (January 4, 2017) is 2666 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) == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC A. Menon 3 Internet-Draft R. Mukherjee 4 Intended status: Standards Track 128 Technology 5 Expires: July 8, 2017 January 4, 2017 7 Network Enhancements for QUIC 8 draft-abilash-quic-network-00 10 Abstract 12 QUIC aims to improve performance by multiplexing streams and various 13 other enhancements [I-D.ietf-quic-transport]. QUIC performs better 14 than existing transport protocols in most cases. However, its 15 performance suffers compared to HTTP under very high bandwidth when 16 large amounts of data needs to be downloaded [MEG2016]. This is 17 because QUIC is an end to end protocol and provides no means for the 18 intermediate network elements to contribute to QUIC improvements. 19 This draft proposes a change to the QUIC protocol header that will 20 allow session aware routers and other middleboxes to prioritize 21 streams in QUIC packets, divert high priority streams to low loss 22 paths, and adjust packet pacing on a per stream basis. This opens 23 the door to many possible future in-network enhancements. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 8, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 61 3. QUIC Network . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Stream Header . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Stream Demultiplexing and Multiplexing . . . . . . . . . 4 64 3.3. Multi-Path . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Moving Streams . . . . . . . . . . . . . . . . . . . . . 5 66 3.5. QUIC State Machine . . . . . . . . . . . . . . . . . . . 5 67 3.6. Stream based Packet Pacing . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 QUIC employs stream multiplexing by interleaving frames from multiple 79 streams into one conversation between QUIC endpoints. These streams 80 are identified by a Stream ID and multiplexed on top of the same UDP 81 flow. These streams do not have any priority assigned to them and 82 all of them are treated with the same priority. A high priority 83 stream is affected by network conditions similar to low priority 84 streams. [MEG2016] shows studies where HTTP performs better than 85 QUIC because it opens multiple connections for each stream. When 86 large amounts of data are to be downloaded and when there is high 87 bandwidth available, QUIC underperforms compared to HTTP. 89 This draft proposes to make the Stream ID visible in the public 90 header and add a priority byte. Session aware routers and other 91 middleboxes can demultiplex streams at the initiator edge and 92 multiplex them back at the termination edge. With these enhancements 93 QUIC now simulates opening multiple connections similar to HTTP with 94 priorities in high bandwidth cases. Coupled with inherent QUIC 95 protocol enhancements and network participation, QUIC will be able to 96 perform better than traditional transport protocols in all network 97 conditions. 99 2. Conventions and Definitions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119. 105 In this document, these words will appear with that interpretation 106 only when in ALL CAPS. Lower case uses of these words are not to be 107 interpreted as carrying significance described in RFC 2119. 109 Definition of terms that are used in this document: 111 o Client: The endpoint initiating a QUIC connection. 113 o Server: The endpoint accepting incoming QUIC connections. 115 o Stream: A logical, bi-directional channel of ordered bytes within 116 a QUIC connection. 118 o Stream ID: The identifier for streams within a QUIC connection. 120 o Connection: A conversation between two QUIC endpoints with a 121 single encryption context that multiplexes streams within it. 123 o Connection ID: The identifier for a QUIC connection. 125 o Initiation Edge: The first network element on the path from the 126 Client to the Server that supports QUIC network optimizations. 128 o Termination Edge: The last network element on the path from the 129 Client to the Server that supports QUIC network optimizations. 131 3. QUIC Network 133 Modern Enterprise WAN or SD-WAN deployments are moving towards 134 session/flow aware routing which provides insight into applications 135 for improved performance. These typical WAN deployments have edge 136 routers at the Client and Server side which would originate and 137 terminate sessions. These sessions could be based on the unique five 138 tuple of the packet or any other application attribute that makes it 139 unique. The Connection ID of the QUIC protocol is a natural 140 identifier to classify QUIC sessions. Each QUIC Connection will have 141 a unique session within these session aware routers or middleboxes. 143 3.1. Stream Header 145 The Stream ID of the stream multiplexed into a QUIC connection with a 146 Connection ID must be visible in the public header. A priority byte 147 is added to indicate relative priority of the stream. 149 +--------+--------+--------+--------+--------+------------+ 150 |Type (8)| Stream ID (8, 16, 24, or 32 bits) |Priority (8)| 151 | | (Variable length SLEN bytes) | | 152 +--------+--------+--------+--------+--------+------------+ 154 Figure 1 QUIC Network Stream Header 156 o Type: Same as specified in the QUIC protocol. 158 o Stream ID: Same as specified in the QUIC protocol. 160 o Priority: Field indicating priority for each stream. It has 161 values from 0-255. 0 indicates lowest priority and 255 indicates 162 highest priority. 164 Stream 1 and Stream 3 will have the highest priority by default as 165 they are special streams to carry initial handshake and headers 166 respectively. 168 QUIC packets are always authenticated and the payload is typically 169 fully encrypted. The parts of the packet header which are not 170 encrypted are still authenticated by the receiver, so as to thwart 171 any packet injection or manipulation by third parties. There is no 172 change in this and is as defined in the QUIC protocol. 174 A public flag needs to be set by the Client as an indication to the 175 network elements to demultiplex the packets on a per stream basis. 176 This can be done during the initial crypto handshake (stream 1). The 177 client can set this flag requesting network elements to apply QUIC 178 optimizations. The network elements that honor these requests can 179 reset this flag on the return from the Server. This allows the 180 client to learn that it can rely on the network for QUIC related 181 network optimizations. Public flag 0x80 is currently unused and can 182 could be used for this purpose. 184 3.2. Stream Demultiplexing and Multiplexing 186 Session aware routers and middleboxes can demultiplex streams at the 187 Initiation Edge and multiplex them back at the Termination Edge. 188 Consider a QUIC connection that has 3 streams all initiated by the 189 Client. In Figure 2, QUIC packets with Stream IDs 5, 7, and 9 are 190 sent across as 3 different flows between router 1 (Initiation Edge) 191 and router 2 (Termination Edge). 193 Stream 5 194 ---------------------- 195 / \ 196 +--------+/ Stream 7 \+--------+ 197 Client---|Router 1|--------------------------|Router 2|---Server 198 +--------+\ /+--------+ 199 \ Stream 9 / 200 ---------------------- 201 Initiation Edge Termination Edge 203 Figure 2 QUIC Sample Network 205 Multiplexing the connection across multiple flows during high 206 bandwidth and high loss network conditions when large amounts of data 207 are being downloaded spreads the packet losses across these different 208 flows. By setting the priority of these streams it is possible to 209 ensure that high value flows do not incur any losses. 211 3.3. Multi-Path 213 Exposing the Stream ID and its priority can help prioritize traffic 214 across different paths. In typical SD-WAN deployments there are 215 multiple paths - usually a high cost MPLS path and a lower cost 216 Internet path. By prioritizing streams, high value streams could be 217 sent over the MPLS path while lower value streams can be sent over 218 the Internet path. 220 3.4. Moving Streams 222 In other deployments, the Internet path can be used to send all 223 traffic and when there are packet losses discovered beyond acceptable 224 limits then the Initiation Edge can switch high value streams to the 225 MPLS path. SD-WAN routers provide many such enhancements that 226 applications supporting QUIC can avail by exposing the Stream ID. 228 3.5. QUIC State Machine 230 A QUIC state machine can be employed on a per stream basis on these 231 session aware routers. The state machine helps with the life cycle 232 of the session (creation/termination). The proposed state machine 233 will do the following: 235 3.6. Stream based Packet Pacing 237 QUIC employs a packet pacing mechanism based on the inter-packet 238 arrival rate. However, session aware routers will have a flow per 239 stream. Hence the packet rate can be adjusted on a per stream basis 240 and not for the whole connection. For example, if there are 3 241 streams 5, 7, and 9. Stream 5 and 7 may have good inter-arrival rate 242 while stream 9 may experience some delay due to network conditions. 243 In this scenario, the packets can be paced differently just for 244 stream 9 which was affected by the network and not the other streams. 245 Streams 5 and 7 can continue to provide high throughput results 246 without affecting their latency. This can help with congestion 247 control techniques. 249 When a QUIC packet with a new Connection ID is received, it will 250 validate that the Stream ID of this packet is 1. Stream 1 will 251 have the highest priority. 253 Any subsequent packet with a different Stream ID will create a new 254 sub-session for this Connection ID and stream. 256 If a FIN is seen in both directions for a stream, then the session 257 for that stream will be removed from the router. 259 If a RST_STREAM is received, then the session for that stream will 260 be terminated in the router. 262 Once a stream session has been terminated, any new packets with 263 that Stream ID will not be forwarded and will be responded to with 264 a RST_STREAM packet. 266 A connection termination would terminate all stream sessions. 268 The state machine need not be limited to the above functionalities. 269 This can also be useful to employ per stream flow and congestion 270 control techniques. 272 4. IANA Considerations 274 This document makes no request of IANA. 276 5. Security Considerations 278 The security considerations for QUIC network enhancements are 279 believed to be the same as for QUIC. 281 6. Acknowledgements 283 This document has benefited from input from Patrick MeLampy. 285 7. References 287 7.1. Normative References 289 [I-D.ietf-quic-transport] 290 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 291 and Secure Transport", draft-ietf-quic-transport-00 (work 292 in progress), November 2016. 294 7.2. Informative References 296 [MEG2016] Megyesi, P., Kramer, Z., and S. Molnar, "How quick is 297 QUIC", Proc. IEEE ICC 2016, Kuala Lumpur, Malaysia, May 298 2016. 300 Authors' Addresses 302 Abilash Menon 303 128 Technology 305 Email: amenon@128technology.com 307 Ritesh Mukherjee 308 128 Technology 310 Email: rmukherjee@128technology.com