idnits 2.17.1 draft-lubashev-quic-partial-reliability-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 date (January 19, 2018) is 2281 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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-08 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 January 19, 2018 5 Expires: July 23, 2018 7 Partially Reliable Streams for QUIC 8 draft-lubashev-quic-partial-reliability-01 10 Abstract 12 This memo introduces a MIN_STREAM_DATA frame to enable partial 13 reliability for QUIC streams. The MIN_STREAM_DATA frame allows a 14 sender to give up on retransmitting older parts of a stream and to 15 notify the receiver about this decision. The content of this draft 16 is intended for merging into QUIC transport, recovery, and 17 applicability drafts. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 23, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Partially Reliable Streams . . . . . . . . . . . . . . . . . 3 56 3.1. Min Stream Offset . . . . . . . . . . . . . . . . . . . . 3 57 3.2. MIN_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 3 58 4. Effect of MIN_STREAM_DATA on Flow Control . . . . . . . . . . 4 59 4.1. Sender Flow Control . . . . . . . . . . . . . . . . . . . 5 60 4.2. Receiver Flow Control . . . . . . . . . . . . . . . . . . 6 61 5. Sender Interface and Behavior . . . . . . . . . . . . . . . . 6 62 6. Receiver Interface and Behavior . . . . . . . . . . . . . . . 7 63 7. Retransmission of MIN_STREAM_DATA . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Notational Conventions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Introduction 78 Some applications, especially applications with real-time 79 requirements, need a partially reliable transport. These 80 applications typically communicate data in application-specific 81 messages that are serialized over QUIC streams. Applications desire 82 partially reliable transport, when their messages expire and lose 83 their usefulness due to later events (time passing, newer messages, 84 etc). 86 The content of this draft is intended for [I-D.ietf-quic-transport], 87 [I-D.ietf-quic-recovery] and, [I-D.ietf-quic-applicability]. 89 The key to partial reliability is notifying the peer about data that 90 will not be retransmitted and managing flow control for the 91 connection. 93 3. Partially Reliable Streams 95 It is possible to provide partial reliability without any changes to 96 QUIC transport by using QUIC streams, encoding one message per QUIC 97 stream. When the message expires, the sender can reset the stream, 98 causing RST_STREAM frame to be transmitted, unless all data in the 99 stream has already been fully acknowledged. The problem with this 100 approach is that messages transmitted by the application typically 101 belong to a message stream, and applications may need to support 102 multiple concurrent message streams. Hence, a message-per-stream 103 approach requires each message to contain an extra header portion to 104 associate the message with a logical application stream. In case of 105 short messages, this approach introduces a significant overhead due 106 to STREAM frames and message headers. It also places the burden on 107 the application to reorder data arriving on multiple QUIC streams. 108 Furthermore, splitting each application stream into multiple QUIC 109 streams renders QUIC per-stream flow control ineffective and requires 110 an application to build its own. 112 An alternative is the proposed single-stream mechanism that keeps 113 messages arriving in order on a single stream. 115 3.1. Min Stream Offset 117 This proposal introduces a new QUIC stream variable "Min Stream 118 Offset" that indicates the smallest retransmittable data offset. The 119 receiver SHOULD NOT wait for any data at offsets smaller than Min 120 Stream Offset to be retransmitted by the sender. Initially, Min 121 Stream Offset is 0 for all streams. 123 3.2. MIN_STREAM_DATA Frame 125 The MIN_STREAM_DATA frame (types 0x?? (type) and 0x?? (type+1)) is 126 used in flow control to inform the peer of the minimum 127 (re-)transmittable data offset on a stream. If the least significant 128 bit is set, Unsent Bytes field is present in the frame. 130 The frame is as follows: 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Stream ID (i) ... 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Sent Data (i) ... 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Unsent Bytes (i) ... 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 The fields in the MIN_STREAM_DATA frame are as follows: 143 Stream ID: The stream ID of the stream that is affected encoded as a 144 variable-length integer. 146 Sent Data: A variable-length integer indicating the number of data 147 octets written to the stream (since the beginning of the stream) 148 that have expired and will not be retransmitted. 150 Unsent Bytes: A variable-length integer indicating the number of 151 data octets past Sent Data that have expired but have never been 152 sent and will not be transmitted. If Unsent Bytes field is 153 absent, it is presumed to be 0. 155 Since Stream 0 MUST be reliable, Stream ID MUST NOT be 0. If Unsent 156 Bytes field is present in the frame, it MUST NOT be 0 (reserved for 157 the future use). 159 If Unsent Bytes field is present in the frame, it implies that all 160 data previously sent to the receiver on the stream has expired. 161 Hence, Sent Data is implicitly the Largest Sent Data on the stream. 163 Min Stream Offset (Section 3.1) for Stream ID is determined by the 164 formula: 166 Min Stream Offset = Sent Data + Unsent Bytes 168 The Min Stream Offset for a stream MUST NOT be reduced by the sender 169 in a subsequent MIN_STREAM_DATA frame, but loss and reordering can 170 cause MIN_STREAM_DATA frames to be received out of order. 171 MIN_STREAM_DATA frames that do not increase the stream's Min Stream 172 Offset MUST be ignored. 174 The sender MUST NOT send a STREAM frame with an Offset smaller then 175 Min Stream Offset for the stream. 177 The value of the Largest Received Offset of the stream is immediately 178 advanced upon receipt, if it is smaller than Sent Data. 180 4. Effect of MIN_STREAM_DATA on Flow Control 182 Specifying Unsent Bytes separately from Send Data in MIN_STREAM_DATA 183 frame avoids consuming stream and connection flow control credits for 184 Unsent Bytes. Flow control credits protect receiver buffers, but 185 Unsent Bytes correspond to bytes that will not need buffering. A 186 sender that desires to expire a large number of bytes that have never 187 been transmitted can do so in a single frame and without closing down 188 the connection flow control window, because Unsent Bytes do not 189 require flow control credits. 191 Flow control accounting is the most complex part of the proposal. 192 The flow control has two goals: 194 1. Allow the sender to notify the receiver about Unsent Bytes past 195 Sent Data, requesting that the receiver advance its stream and 196 connection flow control windows to accommodate skipping Unsent 197 Bytes. That needs to be done without blocking the rest of the 198 streams for an rtt (until the sender receives a corresponding 199 MAX_DATA frame). 201 2. Ensure that the connection flow control credits designated for 202 skipping Unsent Bytes (that do not need buffering on the 203 receiver) cannot be used to send stream data on other streams. 205 4.1. Sender Flow Control 207 When an ACK frame is received for a packet containing a 208 MIN_STREAM_OFFSET frame and the Current Sent Data of the stream is 209 smaller than Min Stream Offset of the acknowledged MIN_STREAM_OFFSET 210 frame, the Current Sent Data is advanced to the Min Stream Offset. 211 (Note that this can only happen, when Unsent Bytes is non-zero in the 212 acknowledged MIN_STREAM_OFFSET frame.) 214 If the Current Sent Data for at least one stream was advanced due to 215 the receipt of a packet containing an ACK frame, and, after 216 processing that entire packet, the sum of the Current Sent Data on 217 all streams - including streams in terminal states but excluding 218 stream 0 - exceeds MAX_DATA, the sender MUST terminate a connection 219 with a QUIC_FLOW_CONTROL_SENT_TOO_MUCH_DATA error. 221 It is possible that the Current Sent Data for at least one stream 222 will be advanced past MAX_STREAM_DATA for that stream. In that case, 223 no data octets can be sent on that stream until a MAX_STREAM_DATA 224 frame advancing the maximum offset is received. Note that this does 225 not prohibit using the Current Sent Data beyond MAX_STREAM_DATA in an 226 RST_STREAM frame, a MIN_STREAM_DATA frame, or a STREAM frame with no 227 data and FIN bit set. 229 It is possible that Current Sent Data will be advanced due to an ACK 230 frame on a closed stream, if it was closed via RST_STREAM. 232 4.2. Receiver Flow Control 234 A stream whose Largest Received Offset smaller than the current Min 235 Stream Offset is called a "Tail Gap" stream. 237 When an ACK frame is sent acknowledging a packet containing a 238 MIN_STREAM_DATA frame for a "Tail Gap" stream: 240 - The stream's Largest Received Offset is saved as the stream's 241 "Last Sent Data". (It will be the Sent Data of the last processed 242 MIN_STREAM_DATA frame for the stream.). 244 - The stream's Largest Received Offset MUST be advanced to Min 245 Stream Offset, and MAX_DATA MUST be advanced by at least the same 246 amount. 248 - A stream whose Largest Received Offset was last updated due to 249 this rule is called a "Gap-ACKed" stream. 251 - A MIN_STREAM_DATA frame with Sent Data equal to Last Sent Data for 252 a "Gap-ACKed" stream is called a "Gap-ACKed" MIN_STREAM_DATA 253 frame. (There can be multiple "Gap-ACKed" MIN_STREAM_DATA frames 254 for a "Gap-ACKed" stream in case MIN_STREAM_DATA frame was 255 received multiple times with the same Sent Data.) 257 - A packet containing a "Gap-ACKed" MIN_STREAM_DATA frame is called 258 a "Gap-ACKed" packet, unless an acknowledgment of that packet has 259 been acknowledged by the sender. 261 A MAX_DATA frame MUST be sent in the same packet as an ACK frame 262 acknowledging a "Gap-ACKed" packet. 264 If a MAX_DATA frame is sent, the same packet MUST contain ACK frames 265 acknowledging all "Gap-ACKed" packets. 267 5. Sender Interface and Behavior 269 It is recommended that a QUIC library API provides a way for a sender 270 to update the minimum retransmittable offset for a stream. A typical 271 sender would call this API function whenever data previously enqueued 272 for transmission expires, per application semantics. The sender 273 would keep track of the message boundaries and request expiration of 274 data on a message boundary. 276 If all data between the current Min Stream Offset and the new Min 277 Stream Offset has been acknowledged, no action is performed by the 278 sender's QUIC transport. Otherwise, if there is unacknowledged data, 279 a MIN_STREAM_DATA frame is transmitted. 281 An application may decide to conditionally expire messages based on 282 the delivery status of prior messages. For example, an application 283 may wish to ensure that its large messages are delivered at least at 284 a given minimum rate before expiring a partially-delivered message 285 just because there is a newer message to deliver. That is, if the 286 rate of data the application wishes to write exceeds the network's 287 throughput, the application may want to ensure that at least some 288 messages are delivered in their entirety. To support this use case, 289 it is recommended that a QUIC library API provides a way for the 290 sender to monitor the smallest unacknowledged stream offset greater 291 than Min Stream Offset (Section 3.1). 293 6. Receiver Interface and Behavior 295 The receiver SHOULD assume that none of the data up to Min Stream 296 Offset (Section 3.1) will be retransmitted. 298 It is recommended that a QUIC library API provides a way for a 299 receiver application to obtain the length of a gap corresponding to 300 the expired data in addition to data octets that follow the gap. 302 A receiver MAY discard any stream data received for an offset smaller 303 than Min Stream Offset. 305 7. Retransmission of MIN_STREAM_DATA 307 The most recent MIN_STREAM_DATA frame for a stream MUST be 308 retransmitted until the sender is certain that the receiver is not 309 expecting retransmission of any expired data. I.e. the frame MUST be 310 retransmitted until either the stream enters "half-closed (local)" 311 state or all data between the largest acknowledged Min Stream Offset 312 and the current Min Stream Offset has been acknowledged. Note that 313 the later condition includes the trivial case of receiving an 314 acknowledgment for the latest MIN_STREAM_DATA frame. 316 8. IANA Considerations 318 This document has no actions for IANA. 320 9. Security Considerations 322 This document has no new security considerations. 324 10. Acknowledgments 326 Many thanks to Mike Bishop and Ian Swett for their feedback on flow 327 control issues. Kudos to the QUIC working group for a mountain of 328 feedback on this draft and for diligently plowing through hard 329 problems, making thousands of big and small decisions, to make the 330 Internet better for everyone. 332 11. Normative References 334 [I-D.ietf-quic-applicability] 335 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 336 Transport Protocol", draft-ietf-quic-applicability-01 337 (work in progress), October 2017. 339 [I-D.ietf-quic-recovery] 340 Iyengar, J. and I. Swett, "QUIC Loss Detection and 341 Congestion Control", draft-ietf-quic-recovery-08 (work in 342 progress), December 2017. 344 [I-D.ietf-quic-transport] 345 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 346 and Secure Transport", draft-ietf-quic-transport-08 (work 347 in progress), December 2017. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 Author's Address 356 Igor Lubashev 357 Akamai Technologies 359 EMail: igorlord@alum.mit.edu