Skip to main content

Partially Reliable Streams for QUIC
draft-lubashev-quic-partial-reliability-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Igor Lubashev
Last updated 2017-12-18
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lubashev-quic-partial-reliability-00
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,
              <https://www.rfc-editor.org/info/rfc2119>.

Author's Address

   Igor Lubashev
   Akamai Technologies

   EMail: igorlord@alum.mit.edu

Lubashev                  Expires June 21, 2018                 [Page 6]