< draft-pauly-quic-datagram-03.txt   draft-pauly-quic-datagram-04.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: January 7, 2020 D. Schinazi Expires: April 24, 2020 D. Schinazi
Google LLC Google LLC
July 06, 2019 October 22, 2019
An Unreliable Datagram Extension to QUIC An Unreliable Datagram Extension to QUIC
draft-pauly-quic-datagram-03 draft-pauly-quic-datagram-04
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 January 7, 2020. This Internet-Draft will expire on April 24, 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 5 5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 4
5.1. Flow Identifiers . . . . . . . . . . . . . . . . . . . . 5 5.1. Acknowledgement Handling . . . . . . . . . . . . . . . . 5
5.2. Acknowledgement Handling . . . . . . . . . . . . . . . . 5 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Congestion Control . . . . . . . . . . . . . . . . . . . 5
5.4. Congestion Control . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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 45 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, flow identifier, length and payload) the endpoint is willing to type, length, and payload) the endpoint is willing to receive, in
receive, in bytes. An endpoint that includes this parameter supports bytes. An endpoint that includes this parameter supports the
the DATAGRAM frame types and is willing to receive such frames on DATAGRAM frame types and is willing to receive such frames on this
this connection. Endpoints MUST NOT send DATAGRAM frames until they connection. Endpoints MUST NOT send DATAGRAM frames until they have
have sent and received the max_datagram_frame_size transport sent and received the max_datagram_frame_size transport parameter.
parameter. Endpoints MUST NOT send DATAGRAM frames of size strictly Endpoints MUST NOT send DATAGRAM frames of size strictly larger than
larger than the value of max_datagram_frame_size the endpoint has the value of max_datagram_frame_size the endpoint has received from
received from its peer. An endpoint that receives a DATAGRAM frame its peer. An endpoint that receives a DATAGRAM frame when it has not
when it has not sent the max_datagram_frame_size transport parameter sent the max_datagram_frame_size transport parameter MUST terminate
MUST terminate the connection with error PROTOCOL_VIOLATION. An the connection with error PROTOCOL_VIOLATION. An endpoint that
endpoint that receives a DATAGRAM frame that is strictly larger than receives a DATAGRAM frame that is strictly larger than the value it
the value it sent in its max_datagram_frame_size transport parameter sent in its max_datagram_frame_size transport parameter MUST
MUST terminate the connection with error PROTOCOL_VIOLATION. terminate the connection with error PROTOCOL_VIOLATION.
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 0b0011000X
(or the set of values from 0x30 to 0x33). The least significant bit (or the values 0x30 and 0x31). The least significant bit of the
of the DATAGRAM frame type is the LEN bit (0x01). It indicates that DATAGRAM frame type is the LEN bit (0x01). It indicates that there
there is a Length field present. If this bit is set to 0, the Length is a Length field present. If this bit is set to 0, the Length field
field is absent and the Datagram Data field extends to the end of the 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.
second least significant bit of the DATAGRAM frame type is the
FLOW_ID bit (0x02). It indicates that there is a Flow ID field
present. If this bit is set to 0, the Flow ID field is absent and
the Flow ID is assumed to be zero. If this bit is set to 1, the Flow
ID field is present.
The DATAGRAM frame is structured as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Flow ID (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] ... | [Length (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagram Data (*) ... | Datagram Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DATAGRAM Frame Format Figure 1: DATAGRAM Frame Format
DATAGRAM frames contain the following fields: DATAGRAM frames contain the following fields:
Flow ID: A variable-length integer indicating the Flow ID of the
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. This field is present only when the LEN bit is 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 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 be sent as soon as the first available packet. This frame SHOULD be sent as soon as
possible, and MAY be coalesced with other 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, as long as it is deliver the data to the application immediately, as long as it is
able to process the frame and can store the contents in memory. 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. Flow Identifiers Application protocols using datagrams might need to differentiate
categories or flows of datagrams being transmitted over a single QUIC
Flow identifiers represent bidirectional flows of datagrams within a connection. Each application protocol is expected to define its own
single QUIC connection. These are effectively equivalent to UDP mechanism for adding flow identifiers or similar mechanisms to the
ports, that allow basic demultiplexing of application data. Whenever datagram payloads being sent over the QUIC connection. For example,
one side of a connection receives a frame with a Flow ID was was not the use of datagrams with HTTP/3 is defined in
previously known, it MAY represent this to the application as a new [I-D.schinazi-quic-h3-datagram].
flow of datagrams.
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.
Beyond this, a sender SHOULD ensure that DATAGRAM frames within a
single flow are transmitted in order relative to one another. If
multiple DATAGRAM frames can packed into a single packet, the sender
SHOULD group them by Flow ID to promote fate-sharing within a
specific flow and improve the ability to process batches of datagram
messages efficiently on the receiver.
Applications that do not have a need for the Flow ID can use the
value zero on their DATAGRAM frames and clear the FLOW_ID bit to omit
sending the identifier over the wire. If an application uses a
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.
5.2. Acknowledgement Handling 5.1. Acknowledgement Handling
Although DATAGRAM frames are not retransmitted upon loss detection, Although DATAGRAM frames are not retransmitted upon loss detection,
they are ack-eliciting ([I-D.ietf-quic-recovery]). Receivers SHOULD they are ack-eliciting ([I-D.ietf-quic-recovery]). Receivers SHOULD
support delaying ACK frames (within the limits specified by support delaying ACK frames (within the limits specified by
max_ack_delay) in reponse to receiving packets that only contain max_ack_delay) in reponse to receiving packets that only contain
DATAGRAM frames, since the timing of these acknowledgements is not DATAGRAM frames, since the timing of these acknowledgements is not
used for loss recovery. used for loss recovery.
If a sender detects that a packet containing a specific DATAGRAM If a sender detects that a packet containing a specific DATAGRAM
frame has been lost, the implementation MAY notify the application frame has been lost, the implementation MAY notify the application
that the datagram was lost. Similarly, if a packet containing a that the datagram was lost. Similarly, if a packet containing a
DATAGRAM frame is acknowledged, the implementation MAY notify the DATAGRAM frame is acknowledged, the implementation MAY notify the
application that the datagram was successfully transmitted and application that the datagram was successfully transmitted and
received. received.
5.3. Flow Control 5.2. Flow Control
DATAGRAM frames do not provide any explicit flow control signaling, DATAGRAM frames do not provide any explicit flow control signaling,
and do not contribute to any per-flow or connection-wide data limit. and do not contribute to any per-flow or connection-wide data limit.
The risk associated with not providing flow control for DATAGRAM The risk associated with not providing flow control for DATAGRAM
frames is that a receiver may not be able to commit the necessary 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 resources to process the frames. For example, it may not be able to
store the frame contents in memory. However, since DATAGRAM frames store the frame contents in memory. However, since DATAGRAM frames
are inherently unreliable, they MAY be dropped by the receiver if the are inherently unreliable, they MAY be dropped by the receiver if the
receiver cannot process them. receiver cannot process them.
5.4. Congestion Control 5.3. Congestion Control
DATAGRAM frames are subject to a QUIC connection's congestion DATAGRAM frames are subject to a QUIC connection's congestion
control. Specifically, if a DATAGRAM frame is enqueued to be sent by control. Specifically, if a DATAGRAM frame is enqueued to be sent by
the application, but sending a packet with this frame is not allowed the application, but sending a packet with this frame is not allowed
by the congestion control window as specified in by the congestion control window as specified in
[I-D.ietf-quic-recovery], the packet cannot be sent. The sender [I-D.ietf-quic-recovery], the packet cannot be sent. The sender
implementation MUST either drop the frame without sending it (at implementation MUST either drop the frame without sending it (at
which point it MAY notify the application) or else delay sending the which point it MAY notify the application) or else delay sending the
frame until the window opens. frame until the window opens.
skipping to change at page 7, line 23 skipping to change at page 6, line 34
Specification: Indicates that the connection should enable support Specification: Indicates that the connection should enable support
for unreliable DATAGRAM frames. An endpoint that advertises this for unreliable DATAGRAM frames. An endpoint that advertises this
transport parameter can receive datagrams frames from the other transport parameter can receive datagrams frames from the other
endpoint, up to and including the length in bytes provided in the endpoint, up to and including the length in bytes provided in the
transport parameter. transport parameter.
This document also registers a new value in the QUIC Frame Type This document also registers a new value in the QUIC Frame Type
registry: registry:
Value: 0x30 - 0x33 (if this document is approved) Value: 0x30 and 0x31 (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. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-quic-recovery] [I-D.ietf-quic-recovery]
Iyengar, J. and I. Swett, "QUIC Loss Detection and Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", draft-ietf-quic-recovery-20 (work in Congestion Control", draft-ietf-quic-recovery-23 (work in
progress), April 2019. progress), September 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-20 (work and Secure Transport", draft-ietf-quic-transport-23 (work
in progress), April 2019. in progress), September 2019.
9.2. Informative References 9.2. Informative References
[I-D.schinazi-quic-h3-datagram]
Schinazi, D., "Using QUIC Datagrams with HTTP/3", draft-
schinazi-quic-h3-datagram-01 (work in progress), October
2019.
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 End of changes. 19 change blocks. 
79 lines changed or deleted 52 lines changed or added

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