Considerations for Unreliable Streams in QUIC
draft-tiesel-quic-unreliable-streams-00

QUIC Working Group                                             P. Tiesel
Internet-Draft                                                 M. Palmer
Intended status: Informational                         B. Chandrasekaran
Expires: March 9, 2018                                       A. Feldmann
                                                               TU Berlin
                                                                  J. Ott
                                                               TU Munich
                                                      September 05, 2017

             Considerations for Unreliable Streams in QUIC
                draft-tiesel-quic-unreliable-streams-00

Abstract

   This memo outlines support for unreliable streams in QUIC.  This
   draft contains a collection of considerations and requirements for
   unreliable streams in QUIC based on [I-D.draft-ietf-quic-transport].
   It provides to alternatives demonstrating how unreliable streams can
   be realized.  The intention of this document is to collect
   considerations regarding unreliable streams in QUIC and to frame the
   design space.  All content of this memo is supposed to be merged into
   [I-D.draft-ietf-quic-transport], [I-D.draft-ietf-quic-recovery] and,
   [I-D.draft-ietf-quic-applicability] once unreliable streams get
   integrated with QUIC.

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 http://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 March 9, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Tiesel, et al.            Expires March 9, 2018                 [Page 1]
Internet-Draft           QUIC Unreliable Streams          September 2017

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Connection Level Considerations . . . . . . . . . . . . . . .   3
     3.1.  Unreliable Stream Support Negotiation . . . . . . . . . .   3
   4.  Stream Level Considerations . . . . . . . . . . . . . . . . .   3
     4.1.  Stream Open . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Stream Close  . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Stream ID 0x0 . . . . . . . . . . . . . . . . . . . . . .   4
     4.4.  Congestion Control on Unreliable Streams  . . . . . . . .   4
     4.5.  Flow Control on Unreliable Streams  . . . . . . . . . . .   4
   5.  Application Interface Considerations  . . . . . . . . . . . .   4
     5.1.  Retransmissions within Unreliable Streams . . . . . . . .   4
     5.2.  Presentation of Unreliable Streams  . . . . . . . . . . .   5
     5.3.  Prioritization of Unreliable Streams  . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Proposal with Application Layer Indicated
                Reliability  . . . . . . . . . . . . . . . . . . . .   6
     A.1.  Stream Close  . . . . . . . . . . . . . . . . . . . . . .   6
   Appendix B.  Proposal with Stream Frame Indicated Reliability . .   6
     B.1.  Stream Open . . . . . . . . . . . . . . . . . . . . . . .   7
     B.2.  Stream Close  . . . . . . . . . . . . . . . . . . . . . .   7
     B.3.  CLOSE_STREAM Frame  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Conventions and Definitions

   The words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and
   "MAY" are used in this document.  It's not shouting; when these words
   are capitalized, they have a special meaning as defined in [RFC2119].

Tiesel, et al.            Expires March 9, 2018                 [Page 2]
Internet-Draft           QUIC Unreliable Streams          September 2017

2.  Introduction

   There are many use cases for unreliable delivery of stream data,
   e.g., to meet deadlines for data delivery in the presence of short
   time congestion by avoiding head of line blocking.  Still, some
   control data or metadata often needs to be transmitted reliably.

   This memo describes how QUIC can provide reliable and unreliable
   transmission within the same connection.  This model allows
   applications to request reliable or unreliable transmission in QUIC
   on a per stream level.  For an unreliable stream, the QUIC
   implementation can decide which frames to retransmit.  Thus, it is
   possible to implement a mix of reliable and unreliable transmission
   within the same stream.

3.  Connection Level Considerations

3.1.  Unreliable Stream Support Negotiation

   Support of unreliable streams is optional to reduce the complexity of
   minimal QUIC implementations.  If the applications protocol makes no
   use of partial delivery of stream data, unreliable stream support
   should not be signaled on the connection.

   An endpoint signals its willingness to receiving unreliable stream
   frames during the TLS handshake using the transport parameter
   accept_unreliable_stream_frames (value TBD - used as flag the same
   way as omit_connection_id specified in [I-D.draft-ietf-quic-
   transport]).

4.  Stream Level Considerations

4.1.  Stream Open

   In addition to the stream open specified in [I-D.draft-ietf-quic-
   transport], an endpoint opening a stream MUST indicate whether the
   stream is reliable, and therefore the receiver can rely on the sender
   retransmitting lost stream data.

   We anticipate two options how to indicate whether a stream is
   reliable or not:

   o  Leave it completely to the application layer.

   o  Indicate it in the stream frame header.  This can be realized by
      repurposing the 'F' (FIN) bit as 'R' (RELIABLE) bit and signal the
      stream close using CLOSE_STREAM / RST_STREAM frames.

Tiesel, et al.            Expires March 9, 2018                 [Page 3]
Internet-Draft           QUIC Unreliable Streams          September 2017

   See Appendix A for a proposal specifying the former and Appendix B
   for a proposal specifying the latter.

   The authors advocate for explicitly signaling unreliable streams in
   the stream frame header, as it does not introduce additional
   interwinding between QUIC and the application.  This reduces the
   complexity of applications where only some streams should be
   transmitted unreliably.

4.2.  Stream Close

   As frames of unreliable streams may not be retransmitted, the loss of
   a frame indicating the end of a stream may introduce zombie streams.

   A QUIC version with unreliable stream support MUST make sure that
   either such a zombie state does not occur (as the proposals in
   Appendix A and Appendix B do) or include a mechanism to clean up
   zombie streams, e.g. by using a window of active unreliable stream
   ids.

4.3.  Stream ID 0x0

   Data of stream 0x0 MUST be transmitted reliably as TLS expects
   reliable transmission.

4.4.  Congestion Control on Unreliable Streams

   Unreliable streams are subject to regular congestion control.
   CLOSE_STREAM Frames are, like ACK and RST_STREAM frames not subject
   to congestion control.

4.5.  Flow Control on Unreliable Streams

   Unreliable streams are subject to regular flow control on connection
   and stream level.

5.  Application Interface Considerations

5.1.  Retransmissions within Unreliable Streams

   While unreliable streams suggest just disabling retransmissions for
   these streams, applications my choose to apply arbitrary
   retransmission strategies for unreliable streams, e.g., retransmit
   stream data as long it will likely be delivered on-time with respect
   to an application provided deadline or only retransmit certain byte
   ranges.

Tiesel, et al.            Expires March 9, 2018                 [Page 4]
Internet-Draft           QUIC Unreliable Streams          September 2017

   A QUIC implementation that implements retransmissions on a per-packet
   basis, therefore, may retransmit unreliable stream data even if not
   requested by the application.

5.2.  Presentation of Unreliable Streams

   The presentation of unreliable streams is application specific.

   The anticipated use cases include:

   o  Data being delivered annotated with its offset as it is received.

   o  Data being delivered after a deadline, e.g., with an annotated
      list of holes and byte ranges of lost data filled with zeros.

5.3.  Prioritization of Unreliable Streams

   Unreliable streams are not prioritized in any special way.

   Applications that need UDP like behavior must make sure that:

   o  The flow control windows are large enough to send at any given
      point in time

   o  The data rate sent in all frames stays below the one permitted by
      the congestion window.

   o  The priority of unreliable streams is high enough to transmit
      data, even if there are retransmissions outstanding on other
      streams.

   To enable writing portable applications, guidelines how
   prioritization should be handled in a QUIC implementation and how it
   is exposed to the application are required.

6.  Security Considerations

   TBD

7.  IANA Considerations

   TBD

8.  Informative References

Tiesel, et al.            Expires March 9, 2018                 [Page 5]
Internet-Draft           QUIC Unreliable Streams          September 2017

   [I-D.draft-ietf-quic-applicability-00]
              Kuehlewind, M. and B. Trammell, "Applicability of the QUIC
              Transport Protocol", draft-ietf-quic-applicability-00
              (work in progress), July 2017.

   [I-D.draft-ietf-quic-recovery-04]
              Iyengar, J. and I. Swett, "QUIC Loss Detection and
              Congestion Control", draft-ietf-quic-recovery-04 (work in
              progress), June 2017.

   [I-D.draft-ietf-quic-transport-04]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-04 (work
              in progress), June 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>.

Appendix A.  Proposal with Application Layer Indicated Reliability

   This implementation proposal lets the decision and indication of
   unreliable transmission completely to the application.  In this
   proposal, the state space and error handling for applications can
   become quite complex when control messages at the start of a stream
   are transmitted unreliably.  The advantage of this implementation
   proposal requiring only minimal changes to [I-D.draft-ietf-quic-
   transport] and [I-D.draft-ietf-quic-recovery].

A.1.  Stream Close

   As frames of unreliable streams may not be retransmitted, the loss of
   an unreliable stream frame carrying a FIN bit may lead to zombie
   streams.  To prevent zombie streams, STREAM frames carrying the FIN
   bit MUST be retransmitted if lost regardless whether a stream is
   reliable or not.

Appendix B.  Proposal with Stream Frame Indicated Reliability

   This implementation proposal repurposes the 'F' (FIN) bit of the
   'type' field from [I-D.draft-ietf-quic-transport] as 'R'(RELIABLE)
   bit and indicates the stream close using CLOSE_STREAM / RST_STREAM
   frames.

Tiesel, et al.            Expires March 9, 2018                 [Page 6]
Internet-Draft           QUIC Unreliable Streams          September 2017

B.1.  Stream Open

   o  The sender opening an reliable stream must set 'R' bit of the type
      byte for a STREAM frame to 1.

   o  The sender opening an unreliable stream must set 'R' bit of the
      type byte for a STREAM frame to 0.

   When receiving a STREAM frame having the 'R' bit not set, a client
   that has not advertised support for unreliable streams in the
   handshake MUST answer with a RST_STREAM frame indicating a
   STREAM_STATE_ERROR.

   All frames of a stream MUST have the R bit to the same value.

B.2.  Stream Close

   Streams MUST be explicitly closed with a CLOSE_STREAM frame
   indicating the stream ID and final offset of the stream to prevent
   zombie streams.  (Alternative implementation option: RST_STREAM frame
   with error code NO_ERROR indicating the final offset).

   o  Once an endpoint has completed sending all stream data, it sends a
      CLOSE_STREAM frame.  The stream state becomes "half-closed
      (local).

   o  A stream in state 'open' for which a CLOSE_STREAM frame is
      received, transitions to "half-closed (remote)" state.  An
      endpoint could continue receiving frames for the stream if not all
      data advertised in 'Final Offset' was received.

   This reduces the code paths that cause state transitions from open to
   half-closed and eases state keeping for unreliable streams by having
   reliable signaling of closing unreliable stream.  It comes with the
   caveat of increasing the minimal on-wire data of a stream by at least
   four bytes.

B.3.  CLOSE_STREAM Frame

   The CLOSE_STREAM frame indicates the final offset of a stream and
   therefore replaces the F bit.

   It uses a type value between 0x80 and 0x9f.  The type byte for a
   CLOSE_STREAM frame contains embedded flags, and is formatted as
   "100RSSOO".  These bits are parsed as follows:

   o  The R bit is set to 1 for reliable streams and to 0 otherwise.

Tiesel, et al.            Expires March 9, 2018                 [Page 7]
Internet-Draft           QUIC Unreliable Streams          September 2017

   o  The "SS" bits encode the length of the Stream ID header field.
      The values 00, 01, 02, and 03 indicate lengths of 8, 16, 24, and
      32 bits long respectively.

   o  The "OO" bits encode the length of the Offset header field.  The
      values 00, 01, 02, and 03 indicate lengths of 0, 16, 32, and 64
      bits long respectively.

   A CLOSE_STREAM frame is shown below.

       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 (8/16/24/32)                   ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Final Offset (0/16/32/64)                   ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CLOSE_STREAM frames must be retransmitted if lost.

Authors' Addresses

   Philipp S. Tiesel
   TU Berlin
   Marchstr. 23
   Berlin
   Germany

   Email: philipp@inet.tu-berlin.de

   Mirko Palmer
   TU Berlin
   Marchstr. 23
   Berlin
   Germany

   Email: mirko@inet.tu-berlin.de

   Balakrishnan Chandrasekaran
   TU Berlin
   Marchstr. 23
   Berlin
   Germany

   Email: balac@inet.tu-berlin.de

Tiesel, et al.            Expires March 9, 2018                 [Page 8]
Internet-Draft           QUIC Unreliable Streams          September 2017

   Anja Feldmann
   TU Berlin
   Marchstr. 23
   Berlin
   Germany

   Email: anja@inet.tu-berlin.de

   Joerg Ott
   TU Munich
   Boltzmannstrasse 3
   Garching bei Muenchen
   Germany

   Email: ott@in.tum.de

Tiesel, et al.            Expires March 9, 2018                 [Page 9]