< draft-pauly-quic-datagram-02.txt   draft-pauly-quic-datagram-03.txt >
Network Working Group T. Pauly Network Working Group T. Pauly
Internet-Draft E. Kinnear Internet-Draft E. Kinnear
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: August 10, 2019 D. Schinazi Expires: January 7, 2020 D. Schinazi
Google LLC Google LLC
February 06, 2019 July 06, 2019
An Unreliable Datagram Extension to QUIC An Unreliable Datagram Extension to QUIC
draft-pauly-quic-datagram-02 draft-pauly-quic-datagram-03
Abstract Abstract
This document defines an extension to the QUIC transport protocol to This document defines an extension to the QUIC transport protocol to
add support for sending and receiving unreliable datagrams over a add support for sending and receiving unreliable datagrams over a
QUIC connection. QUIC connection.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 10, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . 2 1.1. Specification of Requirements . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 3 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 3
4. Datagram Frame Type . . . . . . . . . . . . . . . . . . . . . 4 4. Datagram Frame Type . . . . . . . . . . . . . . . . . . . . . 4
5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 4 5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 5
5.1. Datagram Identifiers . . . . . . . . . . . . . . . . . . 5 5.1. Flow Identifiers . . . . . . . . . . . . . . . . . . . . 5
5.2. Flow Control and Acknowledgements . . . . . . . . . . . . 5 5.2. Acknowledgement Handling . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.4. Congestion Control . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Informative References . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a
secure, multiplexed connection for transmitting reliable streams of secure, multiplexed connection for transmitting reliable streams of
application data. Reliability within QUIC is performed on a per- application data. Reliability within QUIC is performed on a per-
stream basis, so some frame types are not eligible for stream basis, so some frame types are not eligible for
retransmission. retransmission.
Some applications, particularly those that need to transmit real-time Some applications, particularly those that need to transmit real-time
skipping to change at page 3, line 40 skipping to change at page 3, line 45
connection could support both parts with the use of unreliable connection could support both parts with the use of unreliable
datagrams. datagrams.
3. Transport Parameter 3. Transport Parameter
Support for receiving the DATAGRAM frame types is advertised by means Support for receiving the DATAGRAM frame types is advertised by means
of a QUIC Transport Parameter (name=max_datagram_frame_size, of a QUIC Transport Parameter (name=max_datagram_frame_size,
value=0x0020). The max_datagram_frame_size transport parameter is an value=0x0020). The max_datagram_frame_size transport parameter is an
integer value (represented as a variable-length integer) that integer value (represented as a variable-length integer) that
represents the maximum size of a DATAGRAM frame (including the frame represents the maximum size of a DATAGRAM frame (including the frame
type, datagram ID, length and payload) the endpoint is willing to type, flow identifier, length and payload) the endpoint is willing to
receive, in bytes. An endpoint that includes this parameter supports receive, in bytes. An endpoint that includes this parameter supports
the DATAGRAM frame types and is willing to receive such frames on the DATAGRAM frame types and is willing to receive such frames on
this connection. Endpoints MUST NOT send DATAGRAM frames until they this connection. Endpoints MUST NOT send DATAGRAM frames until they
have sent and received the max_datagram_frame_size transport have sent and received the max_datagram_frame_size transport
parameter. Endpoints MUST NOT send DATAGRAM frames of size strictly parameter. Endpoints MUST NOT send DATAGRAM frames of size strictly
larger than the value of max_datagram_frame_size the endpoint has larger than the value of max_datagram_frame_size the endpoint has
received from its peer. An endpoint that receives a DATAGRAM frame received from its peer. An endpoint that receives a DATAGRAM frame
when it has not sent the max_datagram_frame_size transport parameter when it has not sent the max_datagram_frame_size transport parameter
MUST terminate the connection with error PROTOCOL_VIOLATION. An MUST terminate the connection with error PROTOCOL_VIOLATION. An
endpoint that receives a DATAGRAM frame that is strictly larger than endpoint that receives a DATAGRAM frame that is strictly larger than
skipping to change at page 4, line 15 skipping to change at page 4, line 20
4. Datagram Frame Type 4. Datagram Frame Type
DATAGRAM frames are used to transmit application data in an DATAGRAM frames are used to transmit application data in an
unreliable manner. The DATAGRAM frame type takes the form 0b001100XX unreliable manner. The DATAGRAM frame type takes the form 0b001100XX
(or the set of values from 0x30 to 0x33). The least significant bit (or the set of values from 0x30 to 0x33). The least significant bit
of the DATAGRAM frame type is the LEN bit (0x01). It indicates that of the DATAGRAM frame type is the LEN bit (0x01). It indicates that
there is a Length field present. If this bit is set to 0, the Length there is a Length field present. If this bit is set to 0, the Length
field is absent and the Datagram Data field extends to the end of the field is absent and the Datagram Data field extends to the end of the
packet. If this bit is set to 1, the Length field is present. The packet. If this bit is set to 1, the Length field is present. The
second least significant bit of the DATAGRAM frame type is the second least significant bit of the DATAGRAM frame type is the
DATAGRAM_ID bit (0x02). It indicates that there is a Datagram ID FLOW_ID bit (0x02). It indicates that there is a Flow ID field
field present. If this bit is set to 0, the Datagram ID field is present. If this bit is set to 0, the Flow ID field is absent and
absent and the Datagram ID is assumed to be zero. If this bit is set the Flow ID is assumed to be zero. If this bit is set to 1, the Flow
to 1, the Datagram ID field is present. ID field is present.
A DATAGRAM frame is shown below. The DATAGRAM frame is structured as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Datagram ID (i)] ... | [Flow ID (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] ... | [Length (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagram Data (*) ... | Datagram Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DATAGRAM Frame Format Figure 1: DATAGRAM Frame Format
The fields of a DATAGRAM frame are as follows: DATAGRAM frames contain the following fields:
Datagram ID: A variable-length integer indicating the datagram ID of Flow ID: A variable-length integer indicating the Flow ID of the
the datagram (see Section 5.1). datagram (see Section 5.1). This field is present when the
FLOW_ID bit is set, and is assumed to be zero otherwise.
Length: A variable-length integer specifying the length of the Length: A variable-length integer specifying the length of the
datagram in bytes. If the length is zero, the data extends to the datagram in bytes. This field is present only when the LEN bit is
set. If the LEN bit is not set, the datagram data extends to the
end of the QUIC packet. end of the QUIC packet.
Datagram Data: The bytes of the datagram to be delivered. Datagram Data: The bytes of the datagram to be delivered.
5. Behavior and Usage 5. Behavior and Usage
When an application sends an unreliable datagram over a QUIC When an application sends an unreliable datagram over a QUIC
connection, QUIC will generate a new DATAGRAM frame and send it in connection, QUIC will generate a new DATAGRAM frame and send it in
the first available packet. This frame SHOULD NOT be delayed, but the first available packet. This frame SHOULD be sent as soon as
MAY be coalesced with other STREAM or DATAGRAM frames. possible, and MAY be coalesced with other frames.
When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD
deliver the data to the application immediately. deliver the data to the application immediately, as long as it is
able to process the frame and can store the contents in memory.
DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys.
5.1. Datagram Identifiers 5.1. Flow Identifiers
Since several applications relying on datagrams have the need to Flow identifiers represent bidirectional flows of datagrams within a
identify which application-level flow a given datagram is a part of, single QUIC connection. These are effectively equivalent to UDP
DATAGRAM frames carry a datagram identifier. Applications that do ports, that allow basic demultiplexing of application data. Whenever
not have a need for the identifier can use the value zero on their one side of a connection receives a frame with a Flow ID was was not
DATAGRAM frames and use the DATAGRAM_ID bit to omit sending the previously known, it MAY represent this to the application as a new
identifier over the wire. If an application uses a mixture of flow of datagrams.
DATAGRAM frames with and without the DATAGRAM_ID bit set, the frames
without it are assumed to be part of the application-level flow with
Datagram ID zero.
5.2. Flow Control and Acknowledgements The primary role of the QUIC transport towards the flow identifier is
to provide a standard mechanism for demultiplexing application data
flows, which may be destined for different processing threads in the
application, akin to UDP sockets.
Although the DATAGRAM frame is not retransmitted upon loss detection, Beyond this, a sender SHOULD ensure that DATAGRAM frames within a
it does contribute to the maximum data for the overall connection. single flow are transmitted in order relative to one another. If
Packets that contain only DATAGRAM frames do need to be acknowledged, multiple DATAGRAM frames can packed into a single packet, the sender
but implementations SHOULD defer and batch acknowledgements since the SHOULD group them by Flow ID to promote fate-sharing within a
timing of these acknowledgements is not used for loss recovery. specific flow and improve the ability to process batches of datagram
messages efficiently on the receiver.
The DATAGRAM frame does not provide any explicit flow control Applications that do not have a need for the Flow ID can use the
signaling apart from the connection-level flow control. DATAGRAM value zero on their DATAGRAM frames and clear the FLOW_ID bit to omit
frames are flow controlled only when the maximum data for the sending the identifier over the wire. If an application uses a
connection is hit, at which point the BLOCKED frame is sent. mixture of DATAGRAM frames with and without the FLOW_ID bit set, the
frames without it are assumed to be part of the application-level
flow with Flow ID zero.
In cases in which a DATAGRAM frame is blocked due to connection-level 5.2. Acknowledgement Handling
flow control or congestion control, an implementation MAY drop the
frame without sending it. Although DATAGRAM frames are not retransmitted upon loss detection,
they are ack-eliciting ([I-D.ietf-quic-recovery]). Receivers SHOULD
support delaying ACK frames (within the limits specified by
max_ack_delay) in reponse to receiving packets that only contain
DATAGRAM frames, since the timing of these acknowledgements is not
used for loss recovery.
If a sender detects that a packet containing a specific DATAGRAM
frame has been lost, the implementation MAY notify the application
that the datagram was lost. Similarly, if a packet containing a
DATAGRAM frame is acknowledged, the implementation MAY notify the
application that the datagram was successfully transmitted and
received.
5.3. Flow Control
DATAGRAM frames do not provide any explicit flow control signaling,
and do not contribute to any per-flow or connection-wide data limit.
The risk associated with not providing flow control for DATAGRAM
frames is that a receiver may not be able to commit the necessary
resources to process the frames. For example, it may not be able to
store the frame contents in memory. However, since DATAGRAM frames
are inherently unreliable, they MAY be dropped by the receiver if the
receiver cannot process them.
5.4. Congestion Control
DATAGRAM frames are subject to a QUIC connection's congestion
control. Specifically, if a DATAGRAM frame is enqueued to be sent by
the application, but sending a packet with this frame is not allowed
by the congestion control window as specified in
[I-D.ietf-quic-recovery], the packet cannot be sent. The sender
implementation MUST either drop the frame without sending it (at
which point it MAY notify the application) or else delay sending the
frame until the window opens.
Implementations can optionally support allowing the application to
specify a sending expiration time, beyond which a congestion-
controlled DATAGRAM frame ought to be dropped without transmission.
6. Security Considerations 6. Security Considerations
The DATAGRAM frame shares the same security properties as the rest of The DATAGRAM frame shares the same security properties as the rest of
the data transmitted within a QUIC connection. All application data the data transmitted within a QUIC connection. All application data
transmitted with the DATAGRAM frame, like the STREAM frame, MUST be transmitted with the DATAGRAM frame, like the STREAM frame, MUST be
protected either by 0-RTT or 1-RTT keys. protected either by 0-RTT or 1-RTT keys.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 6, line 25 skipping to change at page 7, line 33
Value: 0x30 - 0x33 (if this document is approved) Value: 0x30 - 0x33 (if this document is approved)
Frame Name: DATAGRAM Frame Name: DATAGRAM
Specification: Unreliable application data Specification: Unreliable application data
8. Acknowledgments 8. Acknowledgments
Thanks to Ian Swett, who inspired this proposal. Thanks to Ian Swett, who inspired this proposal.
9. Informative References 9. References
9.1. Normative References
[I-D.ietf-quic-recovery]
Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", draft-ietf-quic-recovery-20 (work in
progress), April 2019.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-18 (work and Secure Transport", draft-ietf-quic-transport-20 (work
in progress), January 2019. in progress), April 2019.
9.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 26 change blocks. 
57 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/