Partially Reliable Streams for QUIC
draft-lubashev-quic-partial-reliability-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Igor Lubashev | ||
| Last updated | 2018-05-29 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lubashev-quic-partial-reliability-02
QUIC I. Lubashev
Internet-Draft Akamai Technologies
Intended status: Informational May 29, 2018
Expires: November 30, 2018
Partially Reliable Streams for QUIC
draft-lubashev-quic-partial-reliability-02
Abstract
This memo introduces MIN_STREAM_DATA and EXPIRED_STREAM_DATA frames
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 MIN_STREAM_DATA frame allows a receiver to
express its disinterest in older parts of a stream. 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
Lubashev Expires November 30, 2018 [Page 1]
Internet-Draft quic-pr May 2018
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. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Stream-per-Message Alternative . . . . . . . . . . . . . 3
2.2. Partially Reliable Streams . . . . . . . . . . . . . . . 3
2.3. Exempt Stream Bytes . . . . . . . . . . . . . . . . . . . 4
2.4. Minimum retransmittable offset and current receive offset 4
3. New Frames . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MIN_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 4
3.2. EXPIRED_STREAM_DATA Frame . . . . . . . . . . . . . . . . 6
4. Flow Control Update . . . . . . . . . . . . . . . . . . . . . 7
4.1. Connection Flow Control . . . . . . . . . . . . . . . . . 7
4.2. Stream Final Offset . . . . . . . . . . . . . . . . . . . 8
5. QUIC Interface and Behavior . . . . . . . . . . . . . . . . . 8
5.1. Sender Interface and Behavior . . . . . . . . . . . . . . 8
5.2. Receiver Interface and Behavior . . . . . . . . . . . . . 9
6. Retransmission . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Retransmission of MIN_STREAM_DATA . . . . . . . . . . . . 9
6.2. Retransmission of EXPIRED_STREAM_DATA . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Since version 00 . . . . . . . . . . . . . . . . . . . . 10
9.2. Since version 01 . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. Normative References . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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
Lubashev Expires November 30, 2018 [Page 2]
Internet-Draft quic-pr May 2018
expire and lose their usefulness due to later events (time passing,
newer messages, etc).
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 Streams
The proposed single-stream mechanism keeps aplication messages
arriving in order on a single stream, while allowing the application
to control message expiration. In this proposal, both the sender and
the receiver are able to control expiration of messages in a stream.
A feature of the proposed protocol is that data is seen by the
receiver application at the same stream offsets used by the sender
application.
The key to partially reliabile streams is notifying the peer about
data that will not or should not be retransmitted and managing flow
control for the connection.
Lubashev Expires November 30, 2018 [Page 3]
Internet-Draft quic-pr May 2018
To facilitate flow control, this proposal introduces a new QUIC per-
stream value: Exempt Stream Bytes (Section 2.3).
2.3. Exempt Stream Bytes
Exempt Stream Bytes is the number of bytes sent on the stream that do
not count toward connection flow control limit. Initially, Exempt
Stream Bytes is 0 for all streams.
2.4. Minimum retransmittable offset and current receive offset
For fully reliable streams, the smallest unacknowledged data offset
is treated by the sender to be the minimum retransmittable offset.
Likewise, the current receive offset for a stream is the smallest
data offset that has not been received by the receiver. Note that
due to loss and reordering, the current 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 current
receive offset. The receiver can also advance its current receive
offset and notify the sender to advance its minimum retransmittable
offset.
3. New Frames
This introduces new MIN_STREAM_DATA (Section 3.1) and
EXPIRED_STREAM_DATA (Section 3.2) frames.
3.1. MIN_STREAM_DATA Frame
The MIN_STREAM_DATA frame (type=0x??) is used by a receiver to inform
a sender of the maximum amount of data that can be sent on a stream
(like MAX_STREAM_DATA frame) and to request an update to the minimum
retransmittable offset (Section 2.4) and Exempt Stream Bytes value
(Section 2.3) for this stream.
The MIN_STREAM_DATA frame includes MAX_STREAM_DATA frame
functionality solely for encoding efficiency, since any increase in
the minimum offset of the stream is likey to come with a
corresponding increase in stream flow control window.
The MIN_STREAM_DATA frame includes Minimum Stream Offset and Exempt
Stream Bytes fields in the same frame, since both affect connection
flow control. It would significantly complicate connection flow
control accounting, if both fields were not updated at the same time.
The frame is as follows:
Lubashev Expires November 30, 2018 [Page 4]
Internet-Draft quic-pr May 2018
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Stream Data (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Stream Offset (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exempt Stream Bytes (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the MIN_STREAM_DATA frame are as follows:
Stream ID: The stream ID of the stream that is affected encoded as a
variable-length integer.
Maximum Stream Data: A variable-length integer indicating the
maximum amount of data that can be sent on the identified stream,
in units of octets.
Minimum Stream Offset: A variable-length integer indicating the
minimum offset of the stream data that the receiver is expecting
to receive on the identified stream, in units of octets.
Exempt Stream Bytes: A variable-length integer indicating the amount
of data on the identified stream exempt from connection flow
control, in units of octets.
The semantics of Maximum Stream Data field is identical to that of
Maximum Stream Data field in MAX_STREAM_DATA frame.
Since Stream 0 MUST be reliable, Stream ID MUST NOT be 0.
Upon receipt of a MIN_STREAM_DATA frame, the sender advances the
maximum amount of data that can be sent on the stream, the minimum
retransmittable offset, and the Exempt Stream Bytes value to the
corresponding values of Maximum Stream Data, Minimum Stream Offset,
and Exempt Stream Bytes fields.
If the minimum retransmittable offset becomes larger than the current
send offset for a stream, the current send offset is advanced to the
minimum retransmittable offset.
The receiver MUST NOT reduce the maximum stream data value, minimum
retransmittable offset, and Exempt Stream Bytes value for the stream,
but loss and reordering can cause MIN_STREAM_DATA frames to be
received out of order. If Maximum Stream Data field does not advance
Lubashev Expires November 30, 2018 [Page 5]
Internet-Draft quic-pr May 2018
the maximum amount of data that can be sent on the stream, or Minimum
Stream Offset field does not advance the minimum retransmittable
offset, or Exempt Stream Bytes field does not advance Exempt Stream
Bytes value, the corresponding stream parameter is not updated.
A MIN_STREAM_DATA referencing a closed or a "half-closed (local)"
stream SHOULD be ignored.
An endpoint that receives a MIN_STREAM_DATA frame for a receive-only
stream MUST terminate the connection with error PROTOCOL_VIOLATION.
An endpoint that receives a MIN_STREAM_DATA frame for a send-only
stream it has not opened MUST terminate the connection with error
PROTOCOL_VIOLATION.
Note that an endpoint may legally receive a MIN_STREAM_DATA frame on
a bidirectional stream it has not opened.
An endpoint MUST terminate a connection with a MIN_STREAM_DATA_ERROR
error, if one of the three fields is advancing its stream parameter,
while another field is trying to retard its stream parameter. An
endpoint MUST terminate a connection with a MIN_STREAM_DATA_ERROR
error, if Maximum Stream Data field is smaller than Minimum Stream
Offset field or Minimum Stream Offset field is smaller than Exempt
Stream Bytes field.
3.2. 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.4)
for a stream.
Sending EXPIRED_STREAM_DATA frame does not change the stream's
current send offset.
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:
Lubashev Expires November 30, 2018 [Page 6]
Internet-Draft quic-pr May 2018
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 current receive offset for the stream to be 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 current receive offset for the stream MUST be ignored.
If the current receive offset becomes larger than the largest
received offset for the stream, the receiver MUST advance the
stream's Exempt Stream Bytes value by the difference between the
current and the largest received offsets. The largest received
offset is then set to match the current receive offset, and the
receiver SHOULD send a MIN_STREAM_DATA frame (Section 3.1).
Note that receipt of an EXPIRED_STREAM_DATA frame may cause the
current receive offset (and hence the largest received offset) to
exceed a previously advertised maximum stream data value for the
stream.
An endpoint that receives an EXPIRED_STREAM_DATA frame for a send-
only stream MUST terminate the connection with error
PROTOCOL_VIOLATION.
4. Flow Control Update
Flow control changes are designed to allow a sender that desires to
expire a large number of bytes that have never been transmitted to do
so efficiently and without closing down the connection flow control
window (thereby blocking other streams). That must be done in a way
that does not open up the connection flow control window, allowing a
different stream to use connection credits not designed for it.
4.1. Connection Flow Control
The connection flow control calculation is redefined to be the sum of
the current stream offsets (current send offset for the sender and
the largest received offset for the receiver) minus the sum of Exempt
Lubashev Expires November 30, 2018 [Page 7]
Internet-Draft quic-pr May 2018
Stream Bytes values (Section 2.3) for all streams, including closed
streams but excluding stream 0.
4.2. Stream Final Offset
If a STREAM-with-FIN or an RST_STREAM frame is received with the
final stream offset smaller than largest received offset for a
stream, it is only an error, if the final receive offset for the
stream is smaller than largest offset learned from a STREAM or
RST_STREAM frames. If the final stream offset is smaller than the
largest received offset, the final stream offset is advanced to be
the largest received offset.
5. QUIC Interface and Behavior
QUIC library interface needs to expose additional APIs to allow
applications to take advantage of partially reliable streams.
5.1. Sender Interface and Behavior
It is recommended that a QUIC library provides a way for a sender to
update the minimum retransmittable offset (Section 2.4) 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.
When an application instructs its QUIC transport to advance the
minimum retransmittable offset for a stream, and there there is any
unacknowledged data (including unsent data) at an offset smaller than
the new minimum retransmittable offset, the sender SHOULD transmit a
EXPIRED_STREAM_DATA frame (Section 3.2).
An application may decide to conditionally expire messages based on
the delivery status of prior messages. For example, an application
sending large messages may wish to ensure that its messages are
delivered at least at a given minimum rate before expiring a
partially-delivered message just because there is a newer message to
deliver. That is, if the rate of data the application wishes to
write exceeds the network's throughput, the application may want to
ensure that at least some messages are delivered in their entirety.
To support this use case, it is recommended that a QUIC library API
provides a way for the sender application to monitor the change in
minimum retransmittable offset due to receipt of ACKs.
Lubashev Expires November 30, 2018 [Page 8]
Internet-Draft quic-pr May 2018
5.2. Receiver Interface and Behavior
Upon receipt of an EXPIRED_STREAM_DATA frame (Section 3.2), the
receiver SHOULD assume that none of the data before the new current
receive offset (Section 2.4) will be retransmitted. A receiver
SHOULD discard any stream data received for an offset smaller than
the new current receive offset. 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 a
receiver application to obtain the length of a gap corresponding to
the expired data in addition to data octets that follow the gap.
It is recommended that a QUIC library API provide a way for a
receiver application to skip data octets past the current point in
the stream. Such a request from the application should be treated by
QUIC as a receipt of an EXPIRED_STREAM_DATA frame with the Minimum
Stream Offset field set of the offset to which the application wished
to skip. If the current receive offset is advanced as a result of
this application request, QUIC library SHOULD transmit a
MIN_STREAM_DATA frame.
6. Retransmission
Both MIN_STREAM_DATA (Section 3.1) and EXPIRED_STREAM_DATA
(Section 3.2) frames MUST be retransmitted if declared lost.
6.1. Retransmission of MIN_STREAM_DATA
The most recent MIN_STREAM_DATA frame MUST be retransmitted until the
receiver is certain that the sender is not going to transmit any
skipped data. I.e. the frame MUST be retransmitted until the stream
enters "half-closed (remote)" state, or all data between the largest
Minimum Stream Offset field in an acknowledged MIN_STREAM_DATA or
received EXPIRED_STREAM_DATA frames and the current receive offset
(Section 2.4) has been received.
6.2. Retransmission of EXPIRED_STREAM_DATA
The most recent EXPIRED_STREAM_DATA frame for a stream MUST be
retransmitted 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 or received MIN_STREAM_DATA frames
and the current minimum retransmittable offset (Section 2.4) has been
acknowledged.
Lubashev Expires November 30, 2018 [Page 9]
Internet-Draft quic-pr May 2018
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. (Section 5.2)
- Added Exempt Stream Bytes value and updated connection flow
control calculation to use Exempt Stream Bytes value.
(Section 2.3)
- Replaced the Min Stream Offset value with the existing values:
"min retransmittable offset" (for sender) and "current receive
offset" (for receiver). (Section 2.4)
- Changed MIN_STREAM_DATA frame to be a receiver-transmitted frame.
(Section 3.1)
- Addded sender-transmitted EXPIRED_STREAM_DATA frame.
(Section 3.2)
10. Acknowledgments
Many thanks to Mike Bishop and Ian Swett for their review and
feedback on flow control issues. Thus draft would not happen without
Subodh Iyengar's ideas for receiver-controlled MIN_STREAM_DATA.
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.
Lubashev Expires November 30, 2018 [Page 10]
Internet-Draft quic-pr May 2018
11. 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>.
Author's Address
Igor Lubashev
Akamai Technologies
EMail: igorlord@alum.mit.edu
Lubashev Expires November 30, 2018 [Page 11]