QUIC Working Group P. Tiesel
Internet-Draft M. Palmer
Intended status: Informational B. Chandrasekaran
Expires: May 3, 2018 A. Feldmann
TU Berlin
J. Ott
TU Munich
October 30, 2017
Considerations for Unreliable Streams in QUIC
draft-tiesel-quic-unreliable-streams-01
Abstract
This memo outlines how to support unreliable streams as well as
partially-reliable streams within QUIC. The intention of this
document is to collect requirements and considerations, to frame the
design space, and to give an example how unreliable stream support
could be realized.
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 May 3, 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
Tiesel, et al. Expires May 3, 2018 [Page 1]
Internet-Draft QUIC Unreliable Streams October 2017
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Modes of Unreliable Transmission . . . . . . . . . . . . . . 3
4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 3
4.1. Unreliable Stream Support Negotiation . . . . . . . . . . 4
4.2. Stream as a Message . . . . . . . . . . . . . . . . . . . 4
4.3. Stream ID 0x0 . . . . . . . . . . . . . . . . . . . . . . 4
4.4. Congestion Control on Unreliable Streams . . . . . . . . 4
4.5. Flow Control on Unreliable Streams . . . . . . . . . . . 4
4.6. Stream Open . . . . . . . . . . . . . . . . . . . . . . . 5
4.7. Retransmission of Partially-Reliable Stream Data . . . . 5
4.8. Stream Close . . . . . . . . . . . . . . . . . . . . . . 5
5. Application Interface Considerations . . . . . . . . . . . . 5
5.1. Retransmissions within Unreliable Streams . . . . . . . . 5
5.2. Presentation of Unreliable Streams . . . . . . . . . . . 6
5.3. Prioritization of Unreliable Streams . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Implemenation Proposal . . . . . . . . . . . . . . . 8
A.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 8
A.2. Stream Close . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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
This memo describes how QUIC can provide reliable, partially-
reliable, and unreliable transmissions within the same connection.
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. For partial
reliable streams, the sender can decide which frames to retransmit.
This model allows applications to request the required kind of
reliability on a per-stream level and to mix of reliable and
Tiesel, et al. Expires May 3, 2018 [Page 2]
Internet-Draft QUIC Unreliable Streams October 2017
unreliable transmissions within the same stream. Still, some control
data or metadata often needs to be transmitted reliably.
This draft is based on [I-D.draft-ietf-quic-transport-07] with the
addition of uni-directional streams (https://github.com/quicwg/base-
drafts/pull/885) and variable-length integer encoding
(https://github.com/quicwg/base-drafts/pull/877). It gives a
comprehensive overview about considerations for adding support for
unreliable streams to QUIC in a way that each stream is either fully
reliable or unreliable (including partially-reliable). Our
implementation proposal in Appendix A needs minimal changes to the
wire format - the third least significant bit of the Stream ID is
repurposed to signal whether a stream is reliable or partial reliable
/ unreliable.
3. Modes of Unreliable Transmission
o Reliable transmission suggests that all application data is re-
transmitted if lost.
o Unreliable transmission suggests that no application data is re-
transmitted if lost.
o Partial reliable transmission suggests that some application data
is re-transmitted if lost.
In principle, the way [I-D.draft-ietf-quic-recovery-06] realizes
reliable transmission allows to realize all three levels of
reliability mentioned above without changing the wire format. The
combination of packet-based acknowledgments with stream-based
retransmits allows deciding on a per stream-frame or byte range base
whether or how a lost stream frame is retransmitted. For this memo,
we define unreliable streams as streams, for which some or all lost
stream frames are not re-transmitted. Thus, our definition covers
fully unreliable as well as partially-reliable transmission.
4. Protocol Considerations
For clear application semantic, the receiver must be able to know
whether to rely on the sender to retransmit lost stream data.
Therefore, an endpoint opening an unreliable stream MUST indicate
that lost stream data might not be retransmitted. The indication
must either be carried on each frame, that could be received first by
an endpoint, or the indication must be transmitted reliably and
acknowledged before the first frame of an unreliable stream is sent.
We anticipate two options to indicate whether a stream is unreliable:
Tiesel, et al. Expires May 3, 2018 [Page 3]
Internet-Draft QUIC Unreliable Streams October 2017
o Indicate unreliable streams within the Stream ID.
o Leave the signaling of unreliable streams completely to the
application layer.
The authors advocate for the former option. This approach does not
introduce complex interwinding between QUIC and the application.
4.1. Unreliable Stream Support Negotiation
Support of unreliable streams should be optional to reduce the
complexity of a minimal QUIC implementation. An endpoint signals its
willingness to receiving unreliable stream frames during the TLS
handshake using the transport parameter allow_unreliable_streams in
analogy to the omit_connection_id flag specified in
[I-D.draft-ietf-quic-transport-07]. An application that makes no use
of partial delivery of stream data, should not signal willingness to
allow unreliable streams.
4.2. Stream as a Message
Unreliable streams are particularly useful if QUIC streams are used
as a message abstraction. If the messages can be sent using a single
stream frame on a unidirectional stream, the state committed at the
sender-side and receiver-side can be minimized, and signaling of
stream close can be omitted. The loss of such a frame does not
introduce state at the perceived receiver, nor does it require the
sender to keep state for retransmission.
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.
It should be clarified that ACK and RST_STREAM Frames are 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.
Note: It is up to further discussion under which assumptions this
can be relaxed.
Tiesel, et al. Expires May 3, 2018 [Page 4]
Internet-Draft QUIC Unreliable Streams October 2017
4.6. Stream Open
A receiver may want to treat reliable and unreliable streams
differently, e.g., in the way state is represented or how the stream
data is presented to the application. Therefore, the receiver needs
to know upon the reception of the first stream frame whether the
respective stream is reliable or unreliable.
As the first frame sent may be lost or re-ordered, it is not
sufficient to mark the first stream frame. Instead, it is necessary
to either reliably transmit the fact whether a stream is reliable or
unreliable or to have all frames of the stream annotated.
4.7. Retransmission of Partially-Reliable Stream Data
Retransmissions of partially-reliable stream data SHOULD always
contain the same data, as was sent in the original transmission.
Note: It is up to further discussion under which assumptions this
can be relaxed.
4.8. Stream Close
As frames of unreliable streams may not be retransmitted, the loss of
a frame indicating the end of a stream may result in a "zombie"
stream state. A QUIC version with unreliable stream support MUST
ensure that either such a zombie state does not occur or include a
mechanism to clean up streams in such a zombie state, e.g., by using
a window of active unreliable stream ids.
The authors advocate for solving this issue by reliably transmitting
the final offset of all streams, that consist of more than a single
stream frame. The retransmit of the stream end can be achieved by
sending an empty stream frame with the final offset and the FIN bit
set or by using an RST_STREAM frame. For unidirectional streams that
only consist of a single stream frame, retransmission of the final
offset is not necessary - See Section 4.2 for details.
5. Application Interface Considerations
5.1. Retransmissions within Unreliable Streams
While unreliable streams suggest just disabling retransmissions for
these streams, applications may 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 May 3, 2018 [Page 5]
Internet-Draft QUIC Unreliable Streams October 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 the following.
o Data being delivered annotated with its offset as it is received.
o Data being delivered after a deadline with an annotated list of
holes.
o Data being delivered as concatenation of the stream fragments
received. This can be useful if the application's framing is
aligned with the QUIC stream frames.
5.3. Prioritization of Unreliable Streams
Prioritization of unreliable streams uses the same priority mechanism
as reliable streams.
Applications that want UDP-like behavior, and thus want to avoid data
sent over unreliable streams queued in send buffers, must ensure
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
Unreliable Streams open a few additional risks of information
disclosure.
Tiesel, et al. Expires May 3, 2018 [Page 6]
Internet-Draft QUIC Unreliable Streams October 2017
o An active, on path attacker can drop selected frames and see
whether the transmission timings change to see whether unreliable
streams are used.
o Using streams as a message as described in Section 4.2 will most
likely result in packets which sizes resemble the size of the
individual message contained. If not mitigated, this can disclose
the individual message length.
7. IANA Considerations
TBD
8. Acknowledgements
This work has been supported in part by Leibniz Prize project funds
of DFG - German Research Foundation: Gottfried Wilhelm Leibniz-Preis
2011 (FKZ FE 570/4-1) and received funding from the European Union's
Horizon 2020 research and innovation programme 2014-2018 under grant
agreement No. 644866, Scalable and Secure Infrastructures for Cloud
Operations (SSICLOPS).
9. Informative References
[I-D.draft-ietf-quic-applicability-01]
Kuehlewind, M. and B. Trammell, "Applicability of the QUIC
Transport Protocol", draft-ietf-quic-applicability-01
(work in progress), October 2017.
[I-D.draft-ietf-quic-recovery-06]
Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", draft-ietf-quic-recovery-06 (work in
progress), September 2017.
[I-D.draft-ietf-quic-transport-07]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-07 (work
in progress), October 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>.
Tiesel, et al. Expires May 3, 2018 [Page 7]
Internet-Draft QUIC Unreliable Streams October 2017
Appendix A. Implemenation Proposal
This proposal realizes unreliable streams by modifying
[I-D.draft-ietf-quic-transport-07] with the addition of uni-
directional streams (https://github.com/quicwg/base-drafts/pull/872)
and variable-length integer encoding (https://github.com/quicwg/base-
drafts/pull/877) to support unreliable streams. It modifies the
Stream ID to signal whether a stream is reliable in analogy to the
way unidirectional streams are signaled. In addition, it addresses
the Stream Close concerns raised in Section 4.8.
A.1. Stream Identifiers
Streams are identified by a variable-length integer, referred to as
the Stream ID. The least significant three bits of the Stream ID are
used to identify the type of stream (unidirectional or
bidirectional), (unreliable or reliable) and the initiator of the
stream.
The second least significant bit (0x2) of the Stream ID
differentiates between unidirectional streams and bidirectional
streams. Unidirectional streams always have this bit set to 1 and
bidirectional streams have this bit set to 0.
The third least significant bit (0x4) of the Stream ID differentiates
between unreliable and reliable streams. Unreliable streams always
have this bit set to 1 and reliable streams have this bit set to 0.
The three type bits from a Stream ID, therefore, identify streams as
summarized in Appendix A.2.
Tiesel, et al. Expires May 3, 2018 [Page 8]
Internet-Draft QUIC Unreliable Streams October 2017
+----------+----------------------------------------------+
| Low Bits | Stream Type |
+----------+----------------------------------------------+
| 0x0 | Client-Initiated, Bidirectional , Reliable |
| | |
| 0x1 | Server-Initiated, Bidirectional , Reliable |
| | |
| 0x2 | Client-Initiated, Unidirectional, Reliable |
| | |
| 0x3 | Server-Initiated, Unidirectional, Reliable |
| | |
| 0x4 | Client-Initiated, Bidirectional , Unreliable |
| | |
| 0x5 | Server-Initiated, Bidirectional , Unreliable |
| | |
| 0x6 | Client-Initiated, Unidirectional, Unreliable |
| | |
| 0x7 | Server-Initiated, Unidirectional, Unreliable |
+----------+----------------------------------------------+
A.2. Stream Close
Streams MUST be explicitly closed. This can either be done by
setting the FIN bit on the frame carrying the final offset of the
stream or by using an RST_STREAM frame indicating the final offset.
For unreliable streams transmitted using more than one stream frame,
the stream close has to be transmitted reliably to prevent zombie
stream state. If the packet containing the FIN flagged stream frame
is lost, and the data in this stream is not to be retransmitted, the
sender can (re-)transmit the stream close by sending an empty FIN
flagged stream frame carrying the final offset.
Authors' Addresses
Philipp S. Tiesel
TU Berlin
Marchstr. 23
Berlin
Germany
Email: philipp@inet.tu-berlin.de
Tiesel, et al. Expires May 3, 2018 [Page 9]
Internet-Draft QUIC Unreliable Streams October 2017
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
Boltzmannstrasse 3
Garching bei Muenchen
Germany
Email: ott@in.tum.de
Tiesel, et al. Expires May 3, 2018 [Page 10]