QUIC I. Lubashev Internet-Draft Akamai Technologies Intended status: Informational December 18, 2017 Expires: June 21, 2018 Partially Reliable Streams for QUIC draft-lubashev-quic-partial-reliability-00 Abstract This memo introduces a MIN_STREAM_DATA frame to enable partial reliability for QUIC streams. The MIN_STREAM_DATA frame allows a sender to give up on retransmitting older parts of a stream and to notify the receiver about this decision. The content of this draft is intended for merging into QUIC transport, recovery, and applicability drafts. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 21, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Lubashev Expires June 21, 2018 [Page 1] Internet-Draft quic-pr December 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Partially Reliabile Streams . . . . . . . . . . . . . . . . . 2 3.1. Min Stream Offset . . . . . . . . . . . . . . . . . . . . 3 3.2. MIN_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 3 4. Effect of MIN_STREAM_DATA on Flow Control . . . . . . . . . . 4 5. Sender Interface and Behavior . . . . . . . . . . . . . . . . 4 6. Receiver Interface and Behavior . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction Some applications, especially applications with real-time requirements, need a partially reliable transport. These applications typically communicate data in application-specific messages that are serialized over QUIC streams. Applications desire partially reliable transport when their messages expire and lose their usefulness due to later events (time passing, newer messages, etc). The content of this draft is intended for [I-D.ietf-quic-transport], [I-D.ietf-quic-recovery] and, [I-D.ietf-quic-applicability]. The key to partial reliablity is notifying the transport and the peer when data previously enqueued for transmission no longer needs to be transmitted. 3. Partially Reliabile Streams It is possible to provide partial reliablity without any changes to QUIC transport by using QUIC streams, encoding one message per QUIC stream. When the message expires, the sender can reset the stream, causing RST_STREAM frame to be transmitted, unless all data in the Lubashev Expires June 21, 2018 [Page 2] Internet-Draft quic-pr December 2017 stream has already been fully acknowledged. The problem with this approach is that messages transmitted by the application typically belong to a message stream, and applications may need to support multiple concurrent message streams. Hence, a message-per-stream approach requires each message to contain an extra header portion to associate the message with a logical application stream. In case of short messages, this approach introduces a significant overhead due to STREAM frames and message headers. It also places the burden on the application to reorder data arriving on multiple QUIC streams. An alternative is the proposed single-stream mechanism that keeps messages arriving in order on a single stream. 3.1. Min Stream Offset This proposal introduces a new QUIC stream variable "Min Stream Offset" that indicates the smallest retransmittable data offset. The receiver SHOULD NOT wait for any data at offsets smaller than Min Stream Offset to be retransmitted by the sender. Initially, Min Stream Offset is 0 for all streams. 3.2. MIN_STREAM_DATA Frame The MIN_STREAM_DATA frame (types 0x?? (type) and 0x?? (type+1)) is used in flow control to inform the peer of the minimum (re-)transmittable data offset on a stream. If the least significant bit is set, Unsent Bytes field is present in the frame. The frame is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sent Data (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unsent Bytes (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the MIN_STREAM_DATA frame are as follows: Stream ID: The stream ID of the stream that is affected encoded as a variable-length integer. Sent Data: A variable-length integer indicating the number of data octets written to the stream (since the beginning of the stream) that have expired and will not be retransmitted. Lubashev Expires June 21, 2018 [Page 3] Internet-Draft quic-pr December 2017 Unsent Bytes: A variable-length integer indicating the number of data octets past Sent Data that have expired but have never been sent and will not be transmitted. If Unsent Bytes field is absent, it is presumed to be 0. Since Stream 0 MUST be reliable, Stream ID MUST NOT be 0. If Unsent Bytes field is present in the frame, it MUST NOT be 0 (reserved for the future use). Min Stream Offset (Section 3.1) for Stream ID is determined by the formula: Min Stream Offset = Sent Data + Unsent Bytes The Min Stream Offset for a stream MUST NOT be reduced by the sender in a subsequent MIN_STREAM_DATA frame, but loss and reordering can cause MIN_STREAM_DATA frames to be received out of order. MIN_STREAM_DATA frames that do not increase the stream's Min Stream Offset MUST be ignored. 4. Effect of MIN_STREAM_DATA on Flow Control Specifying Unsent Bytes separately from Send Data in MIN_STREAM_DATA is done to avoid using stream and connection flow control credits to notify the other endpoint of bytes that will never be transmitted. The value of Sent Data field MUST be used in flow control accounting. A receipt of a MIN_STREAM_DATA frame MUST advance the stream and connection flow control credits, if the maximum data offset received on Stream ID is less than Sent Data. Also, a receipt of MIN_STREAM_DATA that advances Min Stream Offset for the stream beyond the stream's MAX_STREAM_DATA SHOULD be treated as a receipt of a STREAM_BLOCKED frame. 5. Sender Interface and Behavior It is recommended that a QUIC library API provides a way for a sender to update the minimum retransmittable offset for a stream. A typical sender would call an API function providing this functionality whenever any data previously enqueued for transmission expires, per application semantics. The sender would keep track of the message boundaries of such data. If all data between the current Min Stream Offset and the new Min Stream Offset has been acknowledged, no action is performed by the sender's QUIC implementation. Otherwise, if there is unacknowledged data, a MIN_STREAM_DATA frame is transmitted. Lubashev Expires June 21, 2018 [Page 4] Internet-Draft quic-pr December 2017 An application may decide to conditionally expire messages based on the delivery status of prior messages. For example, an application may wish to ensure that its large messages are delivered at least at a given minimum rate before expiring a partially-delivered message just because their is a newer message to deliver. That is, if the rate of data the application wishes to write exceeds the network's throughput, the application may want to ensure that at least some messages are delivered in their entirety. To support this use case, it is recommended that a QUIC library API provides a way for the sender to minitor the smallest unacknowledged stream offset greater than Min Stream Offset (Section 3.1). 6. Receiver Interface and Behavior A receiver of MIN_STREAM_DATA MUST use Sent Data for flow control accounting (see Section 4). The receiver SHOULD assume that none of the data up to Min Stream Offset (Section 3.1) will be retransmitted. When computing window updates for MAX_STREAM_DATA and MAX_DATA, the receiver SHOULD use the larger of "Min Stream Offset" and "the largest data offset" received for the stream. It is recommended that a QUIC library API provides a way for a receiver to obtain the length of a gap corresponding to the expired data instead of (or in addition to) data octets that follow the gap. A receiver MAY discard any stream data received for an offset smaller than Min Stream Offset. 7. IANA Considerations This document has no actions for IANA. 8. Security Considerations This document has no new security considerations. 9. Acknowledgments Many thanks to Mike Bishop for his feedback on flow control issues and proofreading this draft. Kudos to the QUIC working group for dilligently plowing through hard problems and making thousands of big and small decisions to make the Internet better for everyone. Lubashev Expires June 21, 2018 [Page 5] Internet-Draft quic-pr December 2017 10. Normative References [I-D.ietf-quic-applicability] Kuehlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", draft-ietf-quic-applicability-01 (work in progress), October 2017. [I-D.ietf-quic-recovery] Iyengar, J. and I. Swett, "QUIC Loss Detection and Congestion Control", draft-ietf-quic-recovery-08 (work in progress), December 2017. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-08 (work in progress), December 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Author's Address Igor Lubashev Akamai Technologies EMail: igorlord@alum.mit.edu Lubashev Expires June 21, 2018 [Page 6]