idnits 2.17.1 draft-tiesel-quic-unreliable-streams-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.draft-ietf-quic-applicability-01' is defined on line 313, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-quic-applicability-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group P. Tiesel 3 Internet-Draft M. Palmer 4 Intended status: Informational B. Chandrasekaran 5 Expires: May 3, 2018 A. Feldmann 6 TU Berlin 7 J. Ott 8 TU Munich 9 October 30, 2017 11 Considerations for Unreliable Streams in QUIC 12 draft-tiesel-quic-unreliable-streams-01 14 Abstract 16 This memo outlines how to support unreliable streams as well as 17 partially-reliable streams within QUIC. The intention of this 18 document is to collect requirements and considerations, to frame the 19 design space, and to give an example how unreliable stream support 20 could be realized. 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Modes of Unreliable Transmission . . . . . . . . . . . . . . 3 59 4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 3 60 4.1. Unreliable Stream Support Negotiation . . . . . . . . . . 4 61 4.2. Stream as a Message . . . . . . . . . . . . . . . . . . . 4 62 4.3. Stream ID 0x0 . . . . . . . . . . . . . . . . . . . . . . 4 63 4.4. Congestion Control on Unreliable Streams . . . . . . . . 4 64 4.5. Flow Control on Unreliable Streams . . . . . . . . . . . 4 65 4.6. Stream Open . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.7. Retransmission of Partially-Reliable Stream Data . . . . 5 67 4.8. Stream Close . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Application Interface Considerations . . . . . . . . . . . . 5 69 5.1. Retransmissions within Unreliable Streams . . . . . . . . 5 70 5.2. Presentation of Unreliable Streams . . . . . . . . . . . 6 71 5.3. Prioritization of Unreliable Streams . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 9. Informative References . . . . . . . . . . . . . . . . . . . 7 76 Appendix A. Implemenation Proposal . . . . . . . . . . . . . . . 8 77 A.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 8 78 A.2. Stream Close . . . . . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Conventions and Definitions 83 The words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and 84 "MAY" are used in this document. It's not shouting; when these words 85 are capitalized, they have a special meaning as defined in [RFC2119]. 87 2. Introduction 89 This memo describes how QUIC can provide reliable, partially- 90 reliable, and unreliable transmissions within the same connection. 91 There are many use cases for unreliable delivery of stream data, 92 e.g., to meet deadlines for data delivery in the presence of short- 93 time congestion by avoiding head-of-line blocking. For partial 94 reliable streams, the sender can decide which frames to retransmit. 95 This model allows applications to request the required kind of 96 reliability on a per-stream level and to mix of reliable and 97 unreliable transmissions within the same stream. Still, some control 98 data or metadata often needs to be transmitted reliably. 100 This draft is based on [I-D.draft-ietf-quic-transport-07] with the 101 addition of uni-directional streams (https://github.com/quicwg/base- 102 drafts/pull/885) and variable-length integer encoding 103 (https://github.com/quicwg/base-drafts/pull/877). It gives a 104 comprehensive overview about considerations for adding support for 105 unreliable streams to QUIC in a way that each stream is either fully 106 reliable or unreliable (including partially-reliable). Our 107 implementation proposal in Appendix A needs minimal changes to the 108 wire format - the third least significant bit of the Stream ID is 109 repurposed to signal whether a stream is reliable or partial reliable 110 / unreliable. 112 3. Modes of Unreliable Transmission 114 o Reliable transmission suggests that all application data is re- 115 transmitted if lost. 117 o Unreliable transmission suggests that no application data is re- 118 transmitted if lost. 120 o Partial reliable transmission suggests that some application data 121 is re-transmitted if lost. 123 In principle, the way [I-D.draft-ietf-quic-recovery-06] realizes 124 reliable transmission allows to realize all three levels of 125 reliability mentioned above without changing the wire format. The 126 combination of packet-based acknowledgments with stream-based 127 retransmits allows deciding on a per stream-frame or byte range base 128 whether or how a lost stream frame is retransmitted. For this memo, 129 we define unreliable streams as streams, for which some or all lost 130 stream frames are not re-transmitted. Thus, our definition covers 131 fully unreliable as well as partially-reliable transmission. 133 4. Protocol Considerations 135 For clear application semantic, the receiver must be able to know 136 whether to rely on the sender to retransmit lost stream data. 137 Therefore, an endpoint opening an unreliable stream MUST indicate 138 that lost stream data might not be retransmitted. The indication 139 must either be carried on each frame, that could be received first by 140 an endpoint, or the indication must be transmitted reliably and 141 acknowledged before the first frame of an unreliable stream is sent. 143 We anticipate two options to indicate whether a stream is unreliable: 145 o Indicate unreliable streams within the Stream ID. 147 o Leave the signaling of unreliable streams completely to the 148 application layer. 150 The authors advocate for the former option. This approach does not 151 introduce complex interwinding between QUIC and the application. 153 4.1. Unreliable Stream Support Negotiation 155 Support of unreliable streams should be optional to reduce the 156 complexity of a minimal QUIC implementation. An endpoint signals its 157 willingness to receiving unreliable stream frames during the TLS 158 handshake using the transport parameter allow_unreliable_streams in 159 analogy to the omit_connection_id flag specified in 160 [I-D.draft-ietf-quic-transport-07]. An application that makes no use 161 of partial delivery of stream data, should not signal willingness to 162 allow unreliable streams. 164 4.2. Stream as a Message 166 Unreliable streams are particularly useful if QUIC streams are used 167 as a message abstraction. If the messages can be sent using a single 168 stream frame on a unidirectional stream, the state committed at the 169 sender-side and receiver-side can be minimized, and signaling of 170 stream close can be omitted. The loss of such a frame does not 171 introduce state at the perceived receiver, nor does it require the 172 sender to keep state for retransmission. 174 4.3. Stream ID 0x0 176 Data of stream 0x0 MUST be transmitted reliably as TLS expects 177 reliable transmission. 179 4.4. Congestion Control on Unreliable Streams 181 Unreliable streams are subject to regular congestion control. 183 It should be clarified that ACK and RST_STREAM Frames are not subject 184 to congestion control. 186 4.5. Flow Control on Unreliable Streams 188 Unreliable streams are subject to regular flow control on connection 189 and stream level. 191 Note: It is up to further discussion under which assumptions this 192 can be relaxed. 194 4.6. Stream Open 196 A receiver may want to treat reliable and unreliable streams 197 differently, e.g., in the way state is represented or how the stream 198 data is presented to the application. Therefore, the receiver needs 199 to know upon the reception of the first stream frame whether the 200 respective stream is reliable or unreliable. 202 As the first frame sent may be lost or re-ordered, it is not 203 sufficient to mark the first stream frame. Instead, it is necessary 204 to either reliably transmit the fact whether a stream is reliable or 205 unreliable or to have all frames of the stream annotated. 207 4.7. Retransmission of Partially-Reliable Stream Data 209 Retransmissions of partially-reliable stream data SHOULD always 210 contain the same data, as was sent in the original transmission. 212 Note: It is up to further discussion under which assumptions this 213 can be relaxed. 215 4.8. Stream Close 217 As frames of unreliable streams may not be retransmitted, the loss of 218 a frame indicating the end of a stream may result in a "zombie" 219 stream state. A QUIC version with unreliable stream support MUST 220 ensure that either such a zombie state does not occur or include a 221 mechanism to clean up streams in such a zombie state, e.g., by using 222 a window of active unreliable stream ids. 224 The authors advocate for solving this issue by reliably transmitting 225 the final offset of all streams, that consist of more than a single 226 stream frame. The retransmit of the stream end can be achieved by 227 sending an empty stream frame with the final offset and the FIN bit 228 set or by using an RST_STREAM frame. For unidirectional streams that 229 only consist of a single stream frame, retransmission of the final 230 offset is not necessary - See Section 4.2 for details. 232 5. Application Interface Considerations 234 5.1. Retransmissions within Unreliable Streams 236 While unreliable streams suggest just disabling retransmissions for 237 these streams, applications may choose to apply arbitrary 238 retransmission strategies for unreliable streams, e.g., retransmit 239 stream data as long it will likely be delivered on-time with respect 240 to an application provided deadline, or only retransmit certain byte 241 ranges. 243 A QUIC implementation that implements retransmissions on a per-packet 244 basis, therefore, may retransmit unreliable stream data even if not 245 requested by the application. 247 5.2. Presentation of Unreliable Streams 249 The presentation of unreliable streams is application specific. The 250 anticipated use cases include the following. 252 o Data being delivered annotated with its offset as it is received. 254 o Data being delivered after a deadline with an annotated list of 255 holes. 257 o Data being delivered as concatenation of the stream fragments 258 received. This can be useful if the application's framing is 259 aligned with the QUIC stream frames. 261 5.3. Prioritization of Unreliable Streams 263 Prioritization of unreliable streams uses the same priority mechanism 264 as reliable streams. 266 Applications that want UDP-like behavior, and thus want to avoid data 267 sent over unreliable streams queued in send buffers, must ensure 268 that: 270 o The flow control windows are large enough to send at any given 271 point in time 273 o The data rate sent in all frames stays below the one permitted by 274 the congestion window. 276 o The priority of unreliable streams is high enough to transmit 277 data, even if there are retransmissions outstanding on other 278 streams. 280 To enable writing portable applications, guidelines how 281 prioritization should be handled in a QUIC implementation and how it 282 is exposed to the application are required. 284 6. Security Considerations 286 Unreliable Streams open a few additional risks of information 287 disclosure. 289 o An active, on path attacker can drop selected frames and see 290 whether the transmission timings change to see whether unreliable 291 streams are used. 293 o Using streams as a message as described in Section 4.2 will most 294 likely result in packets which sizes resemble the size of the 295 individual message contained. If not mitigated, this can disclose 296 the individual message length. 298 7. IANA Considerations 300 TBD 302 8. Acknowledgements 304 This work has been supported in part by Leibniz Prize project funds 305 of DFG - German Research Foundation: Gottfried Wilhelm Leibniz-Preis 306 2011 (FKZ FE 570/4-1) and received funding from the European Union's 307 Horizon 2020 research and innovation programme 2014-2018 under grant 308 agreement No. 644866, Scalable and Secure Infrastructures for Cloud 309 Operations (SSICLOPS). 311 9. Informative References 313 [I-D.draft-ietf-quic-applicability-01] 314 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 315 Transport Protocol", draft-ietf-quic-applicability-01 316 (work in progress), October 2017. 318 [I-D.draft-ietf-quic-recovery-06] 319 Iyengar, J. and I. Swett, "QUIC Loss Detection and 320 Congestion Control", draft-ietf-quic-recovery-06 (work in 321 progress), September 2017. 323 [I-D.draft-ietf-quic-transport-07] 324 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 325 and Secure Transport", draft-ietf-quic-transport-07 (work 326 in progress), October 2017. 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 Appendix A. Implemenation Proposal 335 This proposal realizes unreliable streams by modifying 336 [I-D.draft-ietf-quic-transport-07] with the addition of uni- 337 directional streams (https://github.com/quicwg/base-drafts/pull/872) 338 and variable-length integer encoding (https://github.com/quicwg/base- 339 drafts/pull/877) to support unreliable streams. It modifies the 340 Stream ID to signal whether a stream is reliable in analogy to the 341 way unidirectional streams are signaled. In addition, it addresses 342 the Stream Close concerns raised in Section 4.8. 344 A.1. Stream Identifiers 346 Streams are identified by a variable-length integer, referred to as 347 the Stream ID. The least significant three bits of the Stream ID are 348 used to identify the type of stream (unidirectional or 349 bidirectional), (unreliable or reliable) and the initiator of the 350 stream. 352 The second least significant bit (0x2) of the Stream ID 353 differentiates between unidirectional streams and bidirectional 354 streams. Unidirectional streams always have this bit set to 1 and 355 bidirectional streams have this bit set to 0. 357 The third least significant bit (0x4) of the Stream ID differentiates 358 between unreliable and reliable streams. Unreliable streams always 359 have this bit set to 1 and reliable streams have this bit set to 0. 361 The three type bits from a Stream ID, therefore, identify streams as 362 summarized in Appendix A.2. 364 +----------+----------------------------------------------+ 365 | Low Bits | Stream Type | 366 +----------+----------------------------------------------+ 367 | 0x0 | Client-Initiated, Bidirectional , Reliable | 368 | | | 369 | 0x1 | Server-Initiated, Bidirectional , Reliable | 370 | | | 371 | 0x2 | Client-Initiated, Unidirectional, Reliable | 372 | | | 373 | 0x3 | Server-Initiated, Unidirectional, Reliable | 374 | | | 375 | 0x4 | Client-Initiated, Bidirectional , Unreliable | 376 | | | 377 | 0x5 | Server-Initiated, Bidirectional , Unreliable | 378 | | | 379 | 0x6 | Client-Initiated, Unidirectional, Unreliable | 380 | | | 381 | 0x7 | Server-Initiated, Unidirectional, Unreliable | 382 +----------+----------------------------------------------+ 384 A.2. Stream Close 386 Streams MUST be explicitly closed. This can either be done by 387 setting the FIN bit on the frame carrying the final offset of the 388 stream or by using an RST_STREAM frame indicating the final offset. 390 For unreliable streams transmitted using more than one stream frame, 391 the stream close has to be transmitted reliably to prevent zombie 392 stream state. If the packet containing the FIN flagged stream frame 393 is lost, and the data in this stream is not to be retransmitted, the 394 sender can (re-)transmit the stream close by sending an empty FIN 395 flagged stream frame carrying the final offset. 397 Authors' Addresses 399 Philipp S. Tiesel 400 TU Berlin 401 Marchstr. 23 402 Berlin 403 Germany 405 Email: philipp@inet.tu-berlin.de 406 Mirko Palmer 407 TU Berlin 408 Marchstr. 23 409 Berlin 410 Germany 412 Email: mirko@inet.tu-berlin.de 414 Balakrishnan Chandrasekaran 415 TU Berlin 416 Marchstr. 23 417 Berlin 418 Germany 420 Email: balac@inet.tu-berlin.de 422 Anja Feldmann 423 TU Berlin 424 Marchstr. 23 425 Berlin 426 Germany 428 Email: anja@inet.tu-berlin.de 430 Joerg Ott 431 TU Munich 432 Boltzmannstrasse 3 433 Garching bei Muenchen 434 Germany 436 Email: ott@in.tum.de