Internet DRAFT - draft-lubashev-quic-partial-reliability
draft-lubashev-quic-partial-reliability
QUIC I. Lubashev
Internet-Draft Akamai Technologies
Intended status: Informational May 29, 2018
Expires: November 30, 2018
Partially Reliable Message Streams for QUIC
draft-lubashev-quic-partial-reliability-03
Abstract
This memo introduces a new EXPIRED_STREAM_DATA frame to enable
partial reliability for QUIC streams. The EXPIRED_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 as a negotiable extension and/or QUIC Version 2
transport feature.
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 November 30, 2018.
Copyright Notice
Copyright (c) 2018 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 November 30, 2018 [Page 1]
Internet-Draft quic-pr May 2018
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
2.1. Stream-per-Message Alternative . . . . . . . . . . . . . 3
2.2. Partially Reliable Message Streams . . . . . . . . . . . 3
2.3. Minimum retransmittable offset and smallest receive
offset . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. EXPIRED_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 4
4. Sender Interface and Behavior . . . . . . . . . . . . . . . . 5
4.1. Communicating Message Boundary . . . . . . . . . . . . . 5
4.2. Translating Application Offsets to QUIC Offsets . . . . . 5
4.3. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 5
4.3.1. Coalescing Minimum Retransmittable Offset Updates . . 6
4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 6
5. Receiver Interface and Behavior . . . . . . . . . . . . . . . 7
6. Retransmission of EXPIRED_STREAM_DATA . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Since version 00 . . . . . . . . . . . . . . . . . . . . 8
9.2. Since version 01 . . . . . . . . . . . . . . . . . . . . 8
9.3. Since version 02 . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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 near real-time
requirements, need transport that supports partially reliable streams
- streams that deliver bytes in order but allow for applicaiton-
controlled gaps. These applications communicate using application-
specific messages that are serialized over QUIC streams.
Applications desire partially reliable streams when their messages
expire and lose their usefulness due to later events (time passing,
newer messages, etc).
Lubashev Expires November 30, 2018 [Page 2]
Internet-Draft quic-pr May 2018
Examples of applications that can benefit from partially reliable
streams are real time video (all prior data is to be expired when a
new key frame is available) and data replication (expire previous
updates, when a new update overwrites the data).
The content of this draft is intended for [I-D.ietf-quic-transport],
[I-D.ietf-quic-recovery] and, [I-D.ietf-quic-applicability] as a QUIC
extension and/or QUIC Version 2.
2.1. Stream-per-Message Alternative
It is possible to avoid the need for partially reliable streams by
encoding one message per QUIC stream. When a message expires, the
sender can reset the stream, causing RST_STREAM frame to be
transmitted, unless all data in the stream has already been fully
acknowledged. Likewise, the receiver can send STOP_SENDING frame to
indicate its disinterest in the message. 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.
Furthermore, splitting each application stream into multiple QUIC
streams renders QUIC's per-stream flow control ineffective and
requires an application to build its own.
2.2. Partially Reliable Message Streams
The proposed single-stream mechanism keeps aplication messages
arriving in order on a single stream, while allowing the application
to control message expiration.
The key to partially reliabile message streams is notifying the
receiver about data that will not be retransmitted and ensuring that
the receiver can identify the beginning of each new message.
It is important to note that the proposed protocol does not guarantee
that data is read by the receiver application at the stream offsets
written to by the sender application.
2.3. Minimum retransmittable offset and smallest receive offset
For fully reliable streams, the smallest unacknowledged data offset
is treated by the sender to be the minimum retransmittable offset.
Likewise, the smallest receive offset for a stream is the smallest
Lubashev Expires November 30, 2018 [Page 3]
Internet-Draft quic-pr May 2018
data offset that has not been received by the receiver. Due to loss
and reordering, the smallest receive offset may be smaller than the
largest received offset.
Partially reliable streams allow the sender to advance its minimum
retransmittable offset and notify the receiver to advance its
smallest receive offset.
3. EXPIRED_STREAM_DATA Frame
The EXPIRED_STREAM_DATA frame (type=0x??) is used by a sender to
inform a receiver of the minimum retransmittable offset (Section 2.3)
for a stream.
An endpoint that receives an EXPIRED_STREAM_DATA frame for a send-
only stream MUST terminate the connection with error
PROTOCOL_VIOLATION.
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Stream Offset (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the EXPIRED_STREAM_DATA frame are as follows:
Stream ID: The stream ID of the stream that is affected encoded as a
variable-length integer.
Minimum Stream Offset: A variable-length integer indicating the
minimum offset of the stream data that will sent (or re-
transmitted) on the identified stream, in units of octets.
Since Stream 0 MUST be reliable, Stream ID MUST NOT be 0.
Upon receipt of an EXPIRED_STREAM_DATA frame, the receiver advances
the smallest receive offset for the stream (Section 2.3) to be the
Minimum Stream Offset value.
The sender MUST NOT reduce the minimum retransmittable offset for a
stream, but loss and reordering can cause EXPIRED_STREAM_DATA frames
to be received out of order. EXPIRED_STREAM_DATA frames that do not
advance the smallest receive offset for the stream MUST be ignored.
Lubashev Expires November 30, 2018 [Page 4]
Internet-Draft quic-pr May 2018
It is possible for the smallest receive offset to become larger than
the largest received offset a the stream. Receipt of an
EXPIRED_STREAM_DATA does not advance the largest received offset for
the stream.
4. Sender Interface and Behavior
QUIC library interface needs provide a way for a sender to expire
data previously written to the transport by updating the minimum
retransmittable offset (Section 2.3) for a stream. A typical sender
would call this API function whenever data previously enqueued for
transmission expires, per application semantics. The sender would
keep track of the message boundaries and request expiration of data
on a message boundary.
4.1. Communicating Message Boundary
To allow a sender application to expire stream data written to the
transport but never sent to the receiver, the sender transport needs
to create a gap between data previously sent on the stream and data
to be sent after the expiration point. The gap ensures that the
receiver does not deliver subsequent octets to the application until
the receipt of the EXPIRED_STREAM_DATA frame, in case packets
containing the EXPIRED_STREAM_DATA frame and subsequent STREAM frame
are reordered.
To avoid complicated connection flow control accounting (see version
02 of this draft [1]), a single octet gap is used for communicating
the message boundary. Sender's EXPIRED_STREAM_DATA frame extends the
minimum stream offset past that gap. Upon receipt of the
EXPIRED_STREAM_DATA frame, the receiver is able to notify the
application of a gap, which allows the application to identify the
beginning of a new message.
4.2. Translating Application Offsets to QUIC Offsets
Since the QUIC library and the application need to communicate data
offsets (for example, for the purpose of updating the minimum
retransmittable stream offset), the QUIC library needs to translate
appliction offsets to QUIC offsets. Depending on the richness of the
APIs exposed to the application, keeping a single difference between
the current application and QUIC offsets is likely to be sufficient.
4.3. Sender Behavior
This section discusses sender behavior in terms of QUIC offsets, and
the translation from applicatoin offsets (see Section 4.2) is
implicit.
Lubashev Expires November 30, 2018 [Page 5]
Internet-Draft quic-pr May 2018
When an application instructs its QUIC transport to advance the
minimum retransmittable offset for a stream, and there is any
unacknowledged data (including unsent data) at an offset smaller than
the new minimum retransmittable offset, the sender SHOULD transmit an
EXPIRED_STREAM_DATA frame (Section 3), except as provided for in
Section 4.3.1.
- When the new minimum retransmittable offset is less than or equal
to the current send offset, the Minimum Stream Offset field in the
EXPIRED_STREAM_DATA frame is set to the new minimum
retransmittable offset.
- When the new minimum retransmittable offset is larger the current
send offset, the Minimum Stream Offset field in the
EXPIRED_STREAM_DATA frame is set to the current send offset plus
1, and stream data starting at the new minimum retransmittable
offset is henceforth sent starting at the current send offset plus
1 (which becomes the new minimum retransmittable offset). Hence,
it may be possible for a minimum retransmittable offset to become
larger than the current send offset for a stream.
4.3.1. Coalescing Minimum Retransmittable Offset Updates
When an application instructs its QUIC transport to advance the
minimum retransmittable offset for a stream, but the current send
offset is not larger than the minimum retransmittable offset
specified in the _previous_ call to this API function, the current
stream offset is not advanced and an EXPIRED_STREAM_DATA frame is not
sent. Stream data starting at the requested minimum retransmittable
offset is henceforth sent starting at the previous minimum
retransmittable offset (which remains the minimum retransmittable
offset for the stream).
Note that the coalescing rule does not apply (the EXPIRED_STREAM_DATA
frame _is_ sent) if the very first message has expired before any of
its octets have been transmitted. This allows the receiver to always
ascertain the location of any gaps in messages it is receiving.
4.3.2. Example
For example, an application wrote four 10-octet messages (A, B, C, D)
to the transport, and the current send offset (the next offset to be
sent) is 12. In this example, the upper-case indicates bytes to be
sent, while the lower-case indicates bytes already sent.
Lubashev Expires November 30, 2018 [Page 6]
Internet-Draft quic-pr May 2018
0 1 s 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a a a a a a a a a a b b B B B B B B B B C C C C C C C C C C D D ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the application desires to expire messages A and B, it requests
the minimum retransmittable offset to be 20. The transport then
sends an EXPIRED_STREAM_DATA frame with Minimum Stream Offset field
set to 13, and the subsequent STREAM frame would send message C
starting at stream offset 13.
0 1 s m 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a a a a a a a a a a b b C C C C C C C C C C D D D D D D D D D D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
However, if the application requestes to expire octets corresponding
to message C before any subsequent STREAM frames could be sent, no
new EXPIRED_STREAM_DATA frame is sent, and the subsequent STREAM
frame would send message D starting at stream offset 13.
0 1 s m 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a a a a a a a a a a b b D D D D D D D D D D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Receiver Interface and Behavior
Upon receipt of an EXPIRED_STREAM_DATA frame (Section 3), the
receiver SHOULD assume that none of the data before the new smallest
receive offset (Section 2.3) will be retransmitted. A receiver
SHOULD discard any stream data received for an offset smaller than
the new smallest receive offset, possibly advancing the largest
received offset for the stream. Discarding such data ensures that
when the application observes a gap in the data stream, what follows
the gap is a beginning of a new message.
It is recommended that a QUIC library API provides a way for the
receiver application to learn of the presence of a gap in the data
stream, indicating that the data that follows the gap is a beginning
of a new message.
Lubashev Expires November 30, 2018 [Page 7]
Internet-Draft quic-pr May 2018
6. Retransmission of EXPIRED_STREAM_DATA
The most recent EXPIRED_STREAM_DATA frame (Section 3) for a stream
MUST be retransmitted if it is declared lost, until the sender is
certain that the receiver is not expecting retransmission of any
expired data. I.e. the frame MUST be retransmitted until the stream
enters "half-closed (local)" state, or all data between the largest
Minimum Stream Offset field in an acknowledged EXPIRED_STREAM_DATA
frame and the current minimum retransmittable offset (Section 2.3)
has been acknowledged.
7. IANA Considerations
This document has no actions for IANA.
8. Security Considerations
This document has no new security considerations.
9. Change Log
9.1. Since version 00
- Fixed flow control to disallow other streams to use connection
credits designated for skipping expired bytes.
9.2. Since version 01
- Added an ability by the receiver as well as the sender to control
partial reliability of QUIC streams.
- Added Exempt Stream Bytes value and updated connection flow
control calculation to use Exempt Stream Bytes value.
- Replaced the Min Stream Offset value with the existing values:
"min retransmittable offset" (for sender) and "smallest receive
offset" (for receiver). (Section 2.3)
- Changed MIN_STREAM_DATA frame to be a receiver-transmitted frame.
- Added sender-transmitted EXPIRED_STREAM_DATA frame. (Section 3)
9.3. Since version 02
- Significantly simplifed the proposal by treating the stream as a
message stream, allowing for data offsets not to be preserved
between the sender and the receiver.
Lubashev Expires November 30, 2018 [Page 8]
Internet-Draft quic-pr May 2018
- Reverted to sender-only transport-level control of message
expiration.
- Removed the need for Exempt Stream Bytes and changes to connection
flow control accounting.
- Removed MIN_STREAM_DATA frame.
10. Acknowledgments
Many thanks to Mike Bishop, Ian Swett, and Subodh Iyengar for their
reviews, feedback, and ideas. Thus draft would not happen without
their input. Kudos to the QUIC working group for a mountain of
feedback on this draft and for diligently plowing through hard
problems, making thousands of big and small decisions, to make the
Internet better for everyone.
11. References
11.1. 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-12 (work in
progress), May 2018.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-12 (work
in progress), May 2018.
[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>.
11.2. URIs
[1] https://tools.ietf.org/html/draft-lubashev-quic-partial-
reliability-02
Lubashev Expires November 30, 2018 [Page 9]
Internet-Draft quic-pr May 2018
Author's Address
Igor Lubashev
Akamai Technologies
EMail: igorlord@alum.mit.edu
Lubashev Expires November 30, 2018 [Page 10]
