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


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 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 March 9, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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].

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:

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.

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:

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:

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


7. IANA Considerations


8. Informative References

[I-D.draft-ietf-quic-applicability-00] Kuehlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", Internet-Draft draft-ietf-quic-applicability-00, July 2017.
[I-D.draft-ietf-quic-recovery-04] Iyengar, J. and I. Swett, "QUIC Loss Detection and Congestion Control", Internet-Draft draft-ietf-quic-recovery-04, June 2017.
[I-D.draft-ietf-quic-transport-04] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Internet-Draft draft-ietf-quic-transport-04, 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.

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.

B.1. Stream Open

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).

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.


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:

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
Anja Feldmann TU Berlin Marchstr. 23 Berlin, Germany EMail: anja@inet.tu-berlin.de
Joerg Ott TU Munich Boltzmannstraße 3 Garching bei München, Germany EMail: ott@in.tum.de