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

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:

• Leave it completely to the application layer.
• 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.

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:

• Data being delivered annotated with its offset as it is received.
• 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:

• The flow control windows are large enough to send at any given point in time
• The data rate sent in all frames stays below the one permitted by the congestion window.
• 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

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

• The sender opening an reliable stream must set ‘R’ bit of the type byte for a STREAM frame to 1.
• 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).

• Once an endpoint has completed sending all stream data, it sends a CLOSE_STREAM frame. The stream state becomes “half-closed (local).
• 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:

• The R bit is set to 1 for reliable streams and to 0 otherwise.
• 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.
• 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