idnits 2.17.1 draft-lubashev-quic-partial-reliability-03.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 date (May 29, 2018) is 2152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 424 == 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-12 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-12 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC I. Lubashev 3 Internet-Draft Akamai Technologies 4 Intended status: Informational May 29, 2018 5 Expires: November 30, 2018 7 Partially Reliable Message Streams for QUIC 8 draft-lubashev-quic-partial-reliability-03 10 Abstract 12 This memo introduces a new EXPIRED_STREAM_DATA frame to enable 13 partial reliability for QUIC streams. The EXPIRED_STREAM_DATA frame 14 allows a sender to give up on retransmitting older parts of a stream 15 and to notify the receiver about this decision. The content of this 16 draft is intended for merging into QUIC transport, recovery, and 17 applicability drafts as a negotiable extension and/or QUIC Version 2 18 transport feature. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 30, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.1. Stream-per-Message Alternative . . . . . . . . . . . . . 3 57 2.2. Partially Reliable Message Streams . . . . . . . . . . . 3 58 2.3. Minimum retransmittable offset and smallest receive 59 offset . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. EXPIRED_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 4 61 4. Sender Interface and Behavior . . . . . . . . . . . . . . . . 5 62 4.1. Communicating Message Boundary . . . . . . . . . . . . . 5 63 4.2. Translating Application Offsets to QUIC Offsets . . . . . 5 64 4.3. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 5 65 4.3.1. Coalescing Minimum Retransmittable Offset Updates . . 6 66 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Receiver Interface and Behavior . . . . . . . . . . . . . . . 7 68 6. Retransmission of EXPIRED_STREAM_DATA . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Since version 00 . . . . . . . . . . . . . . . . . . . . 8 73 9.2. Since version 01 . . . . . . . . . . . . . . . . . . . . 8 74 9.3. Since version 02 . . . . . . . . . . . . . . . . . . . . 8 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Notational Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 Some applications, especially applications with near real-time 90 requirements, need transport that supports partially reliable streams 91 - streams that deliver bytes in order but allow for applicaiton- 92 controlled gaps. These applications communicate using application- 93 specific messages that are serialized over QUIC streams. 94 Applications desire partially reliable streams when their messages 95 expire and lose their usefulness due to later events (time passing, 96 newer messages, etc). 98 Examples of applications that can benefit from partially reliable 99 streams are real time video (all prior data is to be expired when a 100 new key frame is available) and data replication (expire previous 101 updates, when a new update overwrites the data). 103 The content of this draft is intended for [I-D.ietf-quic-transport], 104 [I-D.ietf-quic-recovery] and, [I-D.ietf-quic-applicability] as a QUIC 105 extension and/or QUIC Version 2. 107 2.1. Stream-per-Message Alternative 109 It is possible to avoid the need for partially reliable streams by 110 encoding one message per QUIC stream. When a message expires, the 111 sender can reset the stream, causing RST_STREAM frame to be 112 transmitted, unless all data in the stream has already been fully 113 acknowledged. Likewise, the receiver can send STOP_SENDING frame to 114 indicate its disinterest in the message. The problem with this 115 approach is that messages transmitted by the application typically 116 belong to a message stream, and applications may need to support 117 multiple concurrent message streams. Hence, a message-per-stream 118 approach requires each message to contain an extra header portion to 119 associate the message with a logical application stream. In case of 120 short messages, this approach introduces a significant overhead due 121 to STREAM frames and message headers. It also places the burden on 122 the application to reorder data arriving on multiple QUIC streams. 123 Furthermore, splitting each application stream into multiple QUIC 124 streams renders QUIC's per-stream flow control ineffective and 125 requires an application to build its own. 127 2.2. Partially Reliable Message Streams 129 The proposed single-stream mechanism keeps aplication messages 130 arriving in order on a single stream, while allowing the application 131 to control message expiration. 133 The key to partially reliabile message streams is notifying the 134 receiver about data that will not be retransmitted and ensuring that 135 the receiver can identify the beginning of each new message. 137 It is important to note that the proposed protocol does not guarantee 138 that data is read by the receiver application at the stream offsets 139 written to by the sender application. 141 2.3. Minimum retransmittable offset and smallest receive offset 143 For fully reliable streams, the smallest unacknowledged data offset 144 is treated by the sender to be the minimum retransmittable offset. 145 Likewise, the smallest receive offset for a stream is the smallest 146 data offset that has not been received by the receiver. Due to loss 147 and reordering, the smallest receive offset may be smaller than the 148 largest received offset. 150 Partially reliable streams allow the sender to advance its minimum 151 retransmittable offset and notify the receiver to advance its 152 smallest receive offset. 154 3. EXPIRED_STREAM_DATA Frame 156 The EXPIRED_STREAM_DATA frame (type=0x??) is used by a sender to 157 inform a receiver of the minimum retransmittable offset (Section 2.3) 158 for a stream. 160 An endpoint that receives an EXPIRED_STREAM_DATA frame for a send- 161 only stream MUST terminate the connection with error 162 PROTOCOL_VIOLATION. 164 The frame is as follows: 166 0 1 2 3 167 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Stream ID (i) ... 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Minimum Stream Offset (i) ... 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 The fields in the EXPIRED_STREAM_DATA frame are as follows: 176 Stream ID: The stream ID of the stream that is affected encoded as a 177 variable-length integer. 179 Minimum Stream Offset: A variable-length integer indicating the 180 minimum offset of the stream data that will sent (or re- 181 transmitted) on the identified stream, in units of octets. 183 Since Stream 0 MUST be reliable, Stream ID MUST NOT be 0. 185 Upon receipt of an EXPIRED_STREAM_DATA frame, the receiver advances 186 the smallest receive offset for the stream (Section 2.3) to be the 187 Minimum Stream Offset value. 189 The sender MUST NOT reduce the minimum retransmittable offset for a 190 stream, but loss and reordering can cause EXPIRED_STREAM_DATA frames 191 to be received out of order. EXPIRED_STREAM_DATA frames that do not 192 advance the smallest receive offset for the stream MUST be ignored. 194 It is possible for the smallest receive offset to become larger than 195 the largest received offset a the stream. Receipt of an 196 EXPIRED_STREAM_DATA does not advance the largest received offset for 197 the stream. 199 4. Sender Interface and Behavior 201 QUIC library interface needs provide a way for a sender to expire 202 data previously written to the transport by updating the minimum 203 retransmittable offset (Section 2.3) for a stream. A typical sender 204 would call this API function whenever data previously enqueued for 205 transmission expires, per application semantics. The sender would 206 keep track of the message boundaries and request expiration of data 207 on a message boundary. 209 4.1. Communicating Message Boundary 211 To allow a sender application to expire stream data written to the 212 transport but never sent to the receiver, the sender transport needs 213 to create a gap between data previously sent on the stream and data 214 to be sent after the expiration point. The gap ensures that the 215 receiver does not deliver subsequent octets to the application until 216 the receipt of the EXPIRED_STREAM_DATA frame, in case packets 217 containing the EXPIRED_STREAM_DATA frame and subsequent STREAM frame 218 are reordered. 220 To avoid complicated connection flow control accounting (see version 221 02 of this draft [1]), a single octet gap is used for communicating 222 the message boundary. Sender's EXPIRED_STREAM_DATA frame extends the 223 minimum stream offset past that gap. Upon receipt of the 224 EXPIRED_STREAM_DATA frame, the receiver is able to notify the 225 application of a gap, which allows the application to identify the 226 beginning of a new message. 228 4.2. Translating Application Offsets to QUIC Offsets 230 Since the QUIC library and the application need to communicate data 231 offsets (for example, for the purpose of updating the minimum 232 retransmittable stream offset), the QUIC library needs to translate 233 appliction offsets to QUIC offsets. Depending on the richness of the 234 APIs exposed to the application, keeping a single difference between 235 the current application and QUIC offsets is likely to be sufficient. 237 4.3. Sender Behavior 239 This section discusses sender behavior in terms of QUIC offsets, and 240 the translation from applicatoin offsets (see Section 4.2) is 241 implicit. 243 When an application instructs its QUIC transport to advance the 244 minimum retransmittable offset for a stream, and there is any 245 unacknowledged data (including unsent data) at an offset smaller than 246 the new minimum retransmittable offset, the sender SHOULD transmit an 247 EXPIRED_STREAM_DATA frame (Section 3), except as provided for in 248 Section 4.3.1. 250 - When the new minimum retransmittable offset is less than or equal 251 to the current send offset, the Minimum Stream Offset field in the 252 EXPIRED_STREAM_DATA frame is set to the new minimum 253 retransmittable offset. 255 - When the new minimum retransmittable offset is larger the current 256 send offset, the Minimum Stream Offset field in the 257 EXPIRED_STREAM_DATA frame is set to the current send offset plus 258 1, and stream data starting at the new minimum retransmittable 259 offset is henceforth sent starting at the current send offset plus 260 1 (which becomes the new minimum retransmittable offset). Hence, 261 it may be possible for a minimum retransmittable offset to become 262 larger than the current send offset for a stream. 264 4.3.1. Coalescing Minimum Retransmittable Offset Updates 266 When an application instructs its QUIC transport to advance the 267 minimum retransmittable offset for a stream, but the current send 268 offset is not larger than the minimum retransmittable offset 269 specified in the _previous_ call to this API function, the current 270 stream offset is not advanced and an EXPIRED_STREAM_DATA frame is not 271 sent. Stream data starting at the requested minimum retransmittable 272 offset is henceforth sent starting at the previous minimum 273 retransmittable offset (which remains the minimum retransmittable 274 offset for the stream). 276 Note that the coalescing rule does not apply (the EXPIRED_STREAM_DATA 277 frame _is_ sent) if the very first message has expired before any of 278 its octets have been transmitted. This allows the receiver to always 279 ascertain the location of any gaps in messages it is receiving. 281 4.3.2. Example 283 For example, an application wrote four 10-octet messages (A, B, C, D) 284 to the transport, and the current send offset (the next offset to be 285 sent) is 12. In this example, the upper-case indicates bytes to be 286 sent, while the lower-case indicates bytes already sent. 288 0 1 s 2 3 289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |a a a a a a a a a a b b B B B B B B B B C C C C C C C C C C D D ... 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 When the application desires to expire messages A and B, it requests 295 the minimum retransmittable offset to be 20. The transport then 296 sends an EXPIRED_STREAM_DATA frame with Minimum Stream Offset field 297 set to 13, and the subsequent STREAM frame would send message C 298 starting at stream offset 13. 300 0 1 s m 2 3 301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |a a a a a a a a a a b b C C C C C C C C C C D D D D D D D D D D 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 However, if the application requestes to expire octets corresponding 307 to message C before any subsequent STREAM frames could be sent, no 308 new EXPIRED_STREAM_DATA frame is sent, and the subsequent STREAM 309 frame would send message D starting at stream offset 13. 311 0 1 s m 2 3 312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |a a a a a a a a a a b b D D D D D D D D D D 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 5. Receiver Interface and Behavior 319 Upon receipt of an EXPIRED_STREAM_DATA frame (Section 3), the 320 receiver SHOULD assume that none of the data before the new smallest 321 receive offset (Section 2.3) will be retransmitted. A receiver 322 SHOULD discard any stream data received for an offset smaller than 323 the new smallest receive offset, possibly advancing the largest 324 received offset for the stream. Discarding such data ensures that 325 when the application observes a gap in the data stream, what follows 326 the gap is a beginning of a new message. 328 It is recommended that a QUIC library API provides a way for the 329 receiver application to learn of the presence of a gap in the data 330 stream, indicating that the data that follows the gap is a beginning 331 of a new message. 333 6. Retransmission of EXPIRED_STREAM_DATA 335 The most recent EXPIRED_STREAM_DATA frame (Section 3) for a stream 336 MUST be retransmitted if it is declared lost, until the sender is 337 certain that the receiver is not expecting retransmission of any 338 expired data. I.e. the frame MUST be retransmitted until the stream 339 enters "half-closed (local)" state, or all data between the largest 340 Minimum Stream Offset field in an acknowledged EXPIRED_STREAM_DATA 341 frame and the current minimum retransmittable offset (Section 2.3) 342 has been acknowledged. 344 7. IANA Considerations 346 This document has no actions for IANA. 348 8. Security Considerations 350 This document has no new security considerations. 352 9. Change Log 354 9.1. Since version 00 356 - Fixed flow control to disallow other streams to use connection 357 credits designated for skipping expired bytes. 359 9.2. Since version 01 361 - Added an ability by the receiver as well as the sender to control 362 partial reliability of QUIC streams. 364 - Added Exempt Stream Bytes value and updated connection flow 365 control calculation to use Exempt Stream Bytes value. 367 - Replaced the Min Stream Offset value with the existing values: 368 "min retransmittable offset" (for sender) and "smallest receive 369 offset" (for receiver). (Section 2.3) 371 - Changed MIN_STREAM_DATA frame to be a receiver-transmitted frame. 373 - Added sender-transmitted EXPIRED_STREAM_DATA frame. (Section 3) 375 9.3. Since version 02 377 - Significantly simplifed the proposal by treating the stream as a 378 message stream, allowing for data offsets not to be preserved 379 between the sender and the receiver. 381 - Reverted to sender-only transport-level control of message 382 expiration. 384 - Removed the need for Exempt Stream Bytes and changes to connection 385 flow control accounting. 387 - Removed MIN_STREAM_DATA frame. 389 10. Acknowledgments 391 Many thanks to Mike Bishop, Ian Swett, and Subodh Iyengar for their 392 reviews, feedback, and ideas. Thus draft would not happen without 393 their input. Kudos to the QUIC working group for a mountain of 394 feedback on this draft and for diligently plowing through hard 395 problems, making thousands of big and small decisions, to make the 396 Internet better for everyone. 398 11. References 400 11.1. Normative References 402 [I-D.ietf-quic-applicability] 403 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 404 Transport Protocol", draft-ietf-quic-applicability-01 405 (work in progress), October 2017. 407 [I-D.ietf-quic-recovery] 408 Iyengar, J. and I. Swett, "QUIC Loss Detection and 409 Congestion Control", draft-ietf-quic-recovery-12 (work in 410 progress), May 2018. 412 [I-D.ietf-quic-transport] 413 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 414 and Secure Transport", draft-ietf-quic-transport-12 (work 415 in progress), May 2018. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 11.2. URIs 424 [1] https://tools.ietf.org/html/draft-lubashev-quic-partial- 425 reliability-02 427 Author's Address 429 Igor Lubashev 430 Akamai Technologies 432 EMail: igorlord@alum.mit.edu