< draft-ietf-quic-datagram-02.txt   draft-ietf-quic-datagram-03.txt >
Network Working Group T. Pauly QUIC T. Pauly
Internet-Draft E. Kinnear Internet-Draft E. Kinnear
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: 20 August 2021 D. Schinazi Expires: 13 January 2022 D. Schinazi
Google LLC Google LLC
16 February 2021 12 July 2021
An Unreliable Datagram Extension to QUIC An Unreliable Datagram Extension to QUIC
draft-ietf-quic-datagram-02 draft-ietf-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.
Discussion of this work is encouraged to happen on the QUIC IETF Discussion of this work is encouraged to happen on the QUIC IETF
mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub
repository which contains the draft: https://github.com/quicwg/ repository which contains the draft: https://github.com/quicwg/
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 20 August 2021. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 17 skipping to change at page 2, line 17
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 4 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 4
4. Datagram Frame Type . . . . . . . . . . . . . . . . . . . . . 5 4. Datagram Frame Type . . . . . . . . . . . . . . . . . . . . . 5
5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 5 5. Behavior and Usage . . . . . . . . . . . . . . . . . . . . . 5
5.1. Acknowledgement Handling . . . . . . . . . . . . . . . . 6 5.1. Multiplexing Datagrams . . . . . . . . . . . . . . . . . 6
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Acknowledgement Handling . . . . . . . . . . . . . . . . 6
5.3. Congestion Control . . . . . . . . . . . . . . . . . . . 7 5.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Congestion Control . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a The QUIC Transport Protocol [RFC9000] provides a secure, multiplexed
secure, multiplexed connection for transmitting reliable streams of connection for transmitting reliable streams of application data.
application data. Reliability within QUIC is performed on a per- Reliability within QUIC is performed on a per-stream basis, so some
stream basis, so some frame types are not eligible for 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
data, prefer to transmit data unreliably. These applications can data, prefer to transmit data unreliably. These applications can
build directly upon UDP [RFC0768] as a transport, and can add build directly upon UDP [RFC0768] as a transport, and can add
security with DTLS [RFC6347]. Extending QUIC to support transmitting security with DTLS [RFC6347]. Extending QUIC to support transmitting
unreliable application data would provide another option for secure unreliable application data would provide another option for secure
datagrams, with the added benefit of sharing a cryptographic and datagrams, with the added benefit of sharing a cryptographic and
authentication context used for reliable streams. authentication context used for reliable streams.
This document defines two new DATAGRAM QUIC frame types, which carry This document defines two new DATAGRAM QUIC frame types, which carry
skipping to change at page 3, line 26 skipping to change at page 3, line 26
existing solutions: existing solutions:
* Applications that open both a reliable TLS stream and an * Applications that open both a reliable TLS stream and an
unreliable DTLS flow to the same peer can benefit by sharing a unreliable DTLS flow to the same peer can benefit by sharing a
single handshake and authentication context between a reliable single handshake and authentication context between a reliable
QUIC stream and flow of unreliable QUIC datagrams. This can QUIC stream and flow of unreliable QUIC datagrams. This can
reduce the latency required for handshakes. reduce the latency required for handshakes.
* QUIC uses a more nuanced loss recovery mechanism than the DTLS * QUIC uses a more nuanced loss recovery mechanism than the DTLS
handshake, which has a basic packet loss retransmission timer. handshake, which has a basic packet loss retransmission timer.
This may allow loss recovery to occur more quickly for QUIC data. This can allow loss recovery to occur more quickly for QUIC data.
* QUIC datagrams, while unreliable, can support acknowledgements, * QUIC datagrams, while unreliable, can support acknowledgements,
allowing applications to be aware of whether a datagram was allowing applications to be aware of whether a datagram was
successfully received. successfully received.
* QUIC datagrams are subject to QUIC congestion control, allowing * QUIC datagrams are subject to QUIC congestion control, allowing
applications to avoid implementing their own. applications to avoid implementing their own.
These reductions in connection latency, and application insight into These reductions in connection latency, and application insight into
the delivery of datagrams, can be useful for optimizing audio/video the delivery of datagrams, can be useful for optimizing audio/video
skipping to change at page 4, line 13 skipping to change at page 4, line 13
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, length, and payload) the endpoint is willing to receive, in type, length, and payload) the endpoint is willing to receive, in
bytes. An endpoint that includes this parameter supports the bytes.
DATAGRAM frame types and is willing to receive such frames on this
connection. Endpoints MUST NOT send DATAGRAM frames until they have The default for this parameter is 0, which indicates that the
received the max_datagram_frame_size transport parameter. Endpoints endpoint does not support DATAGRAM frames. A value greater than 0
MUST NOT send DATAGRAM frames of size strictly larger than the value indicates that the endpoint supports the DATAGRAM frame types and is
of max_datagram_frame_size the endpoint has received from its peer. willing to receive such frames on this connection.
An endpoint that receives a DATAGRAM frame when it has not sent the
max_datagram_frame_size transport parameter MUST terminate the An endpoint MUST NOT send DATAGRAM frames until it has received the
connection with error PROTOCOL_VIOLATION. An endpoint that receives max_datagram_frame_size transport parameter with a non-zero value.
a DATAGRAM frame that is strictly larger than the value it sent in An endpoint MUST NOT send DATAGRAM frames that are larger than the
its max_datagram_frame_size transport parameter MUST terminate the max_datagram_frame_size value it has received from its peer. An
connection with error PROTOCOL_VIOLATION. Endpoints that wish to use endpoint that receives a DATAGRAM frame when it has not indicated
DATAGRAM frames need to ensure they send a max_datagram_frame_size support via the transport parameter MUST terminate the connection
value sufficient to allow their peer to use them. It is RECOMMENDED with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint
to send the value 65535 in the max_datagram_frame_size transport that receives a DATAGRAM frame that is larger than the value it sent
parameter as that indicates to the peer that this endpoint will in its max_datagram_frame_size transport parameter MUST terminate the
accept any DATAGRAM frame that fits inside a QUIC packet. connection with an error of type PROTOCOL_VIOLATION.
For most uses of DATAGRAM frames, it is RECOMMENDED to send a value
of 65535 in the max_datagram_frame_size transport parameter to
indicate that this endpoint will accept any DATAGRAM frame that fits
inside a QUIC packet.
The max_datagram_frame_size transport parameter is a unidirectional The max_datagram_frame_size transport parameter is a unidirectional
limit and indication of support of DATAGRAM frames. Application limit and indication of support of DATAGRAM frames. Application
protocols that use DATAGRAM frames MAY choose to only negotiate and protocols that use DATAGRAM frames MAY choose to only negotiate and
use them in a single direction. use them in a single direction.
When clients use 0-RTT, they MAY store the value of the server's When clients use 0-RTT, they MAY store the value of the server's
max_datagram_frame_size transport parameter. Doing so allows the max_datagram_frame_size transport parameter. Doing so allows the
client to send DATAGRAM frames in 0-RTT packets. When servers decide client to send DATAGRAM frames in 0-RTT packets. When servers decide
to accept 0-RTT data, they MUST send a max_datagram_frame_size to accept 0-RTT data, they MUST send a max_datagram_frame_size
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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.
Application protocols using datagrams are responsible for defining
the semantics of the Datagram Data field, and how it is parsed. If
the application protocol supports the coexistence of multiple
entities using datagrams inside a single QUIC connection, it may need
a mechanism to allow demultiplexing between them. For example, using
datagrams with HTTP/3 involves prepending a flow identifier to all
datagrams, see [I-D.schinazi-quic-h3-datagram].
Note that while the max_datagram_frame_size transport parameter Note that while the max_datagram_frame_size transport parameter
places a limit on the maximum size of DATAGRAM frames, that limit can places a limit on the maximum size of DATAGRAM frames, that limit can
be further reduced by the max_packet_size transport parameter, and by be further reduced by the max_packet_size transport parameter, and by
the Maximum Transmission Unit (MTU) of the path between endpoints. the Maximum Transmission Unit (MTU) of the path between endpoints.
DATAGRAM frames cannot be fragmented, therefore application protocols DATAGRAM frames cannot be fragmented, therefore application protocols
need to handle cases where the maximum datagram size is limited by need to handle cases where the maximum datagram size is limited by
other factors. other factors.
5.1. Acknowledgement Handling 5.1. Multiplexing Datagrams
DATAGRAM frames belong to a QUIC connection as a whole, and are not
strongly associated with any stream ID at the QUIC layer. However,
it is expected that applications will want to differentiate between
specific DATAGRAM frames by using identifiers, such as for logical
flows of datagrams or to distinguish between different kinds of
datagrams.
Identifiers used to multiplex different kinds of datagrams, or flows
of datagrams, are the responsibility of the application protocol
running over QUIC to define. The application defines the semantics
of the Datagram Data field and how it is parsed.
If the application needs to support the coexistence of multiple flows
of datagrams, one recommended pattern is to use a variable-length
integer at the beginning of the Datagram Data field.
QUIC implementations SHOULD present an API to applications to assign
relative priorities to DATAGRAM frames with respect to each other and
to QUIC streams.
5.2. 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 ([RFC9002]). Receivers SHOULD support
support delaying ACK frames (within the limits specified by delaying ACK frames (within the limits specified by max_ack_delay) in
max_ack_delay) in reponse to receiving packets that only contain reponse to receiving packets that only contain DATAGRAM frames, since
DATAGRAM frames, since the timing of these acknowledgements is not the timing of these acknowledgements is not used for loss recovery.
used for loss recovery.
As with any ack-eliciting frame, when a sender suspects that a packet
containing only DATAGRAM frames has been lost, it MAY send probe
packets to elicit a faster acknowledgement as described in
Section 6.2.4 of [RFC9002].
If a sender detects that a packet containing a specific DATAGRAM If a sender detects that a packet containing a specific DATAGRAM
frame might have been lost, the implementation MAY notify the frame might have been lost, the implementation MAY notify the
application that it believes the datagram was lost. Similarly, if a application that it believes the datagram was lost.
packet containing a DATAGRAM frame is acknowledged, the
implementation MAY notify the application that the datagram was
successfully transmitted and received. Note that, due to reordering,
a DATAGRAM frame that was thought to be lost could at a later point
be received and acknowledged.
5.2. Flow Control Similarly, if a packet containing a DATAGRAM frame is acknowledged,
the implementation MAY notify the sender application that the
datagram was successfully transmitted and received. Due to
reordering, this can include a DATAGRAM frame that was thought to be
lost, but which at a later point was received and acknowledged. It
is important to note that acknowledgement of a DATAGRAM frame only
indicates that the transport-layer handling on the receiver processed
the frame, and does not guarantee that the application on the
receiver successfully processed the data. Thus, this signal SHOULD
NOT replace application-layer signals that indicate successful
processing.
5.3. 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 might 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 might not be able
store the frame contents in memory. However, since DATAGRAM frames to store the frame contents in memory. However, since DATAGRAM
are inherently unreliable, they MAY be dropped by the receiver if the frames are inherently unreliable, they MAY be dropped by the receiver
receiver cannot process them. if the receiver cannot process them.
5.3. Congestion Control 5.4. Congestion Control
DATAGRAM frames employ the QUIC connection's congestion controller. DATAGRAM frames employ the QUIC connection's congestion controller.
As a result, a connection may be unable to send a DATAGRAM frame As a result, a connection might be unable to send a DATAGRAM frame
generated by the application until the congestion controller allows generated by the application until the congestion controller allows
it [I-D.ietf-quic-recovery]. The sender implementation MUST it [RFC9002]. The sender implementation MUST either delay sending
either delay sending the frame until the controller allows it or drop the frame until the controller allows it or drop the frame without
the frame without sending it (at which point it MAY notify the sending it (at which point it MAY notify the application).
application). Implementations that use packet pacing SHOULD support delaying the
transmission of DATAGRAM frames for at least the time it takes to
send the paced packets allowed by the congestion controller to avoid
dropping frames excessively.
Implementations can optionally support allowing the application to Implementations can optionally support allowing the application to
specify a sending expiration time, beyond which a congestion- specify a sending expiration time, beyond which a congestion-
controlled DATAGRAM frame ought to be dropped without transmission. 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
skipping to change at page 7, line 35 skipping to change at page 8, line 14
7. IANA Considerations 7. IANA Considerations
This document registers a new value in the QUIC Transport Parameter This document registers a new value in the QUIC Transport Parameter
Registry: Registry:
Value: 0x0020 (if this document is approved) Value: 0x0020 (if this document is approved)
Parameter Name: max_datagram_frame_size Parameter Name: max_datagram_frame_size
Specification: Indicates that the connection should enable support Specification: A non-zero value indicates that the endpoint supports
for unreliable DATAGRAM frames. An endpoint that advertises this receiving unreliable DATAGRAM frames. An endpoint that advertises
transport parameter can receive datagrams frames from the other this transport parameter can receive DATAGRAM frames from the
endpoint, up to and including the length in bytes provided in the other endpoint, up to and including the length in bytes provided
transport parameter. in the transport parameter. The default value is 0.
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 and 0x31 (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] [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Iyengar, J. and I. Swett, "QUIC Loss Detection and Multiplexed and Secure Transport", RFC 9000,
Congestion Control", Work in Progress, Internet-Draft, DOI 10.17487/RFC9000, May 2021,
draft-ietf-quic-recovery-34, 14 January 2021, <https://www.rfc-editor.org/info/rfc9000>.
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
recovery-34.txt>.
[I-D.ietf-quic-transport] [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
and Secure Transport", Work in Progress, Internet-Draft, May 2021, <https://www.rfc-editor.org/info/rfc9002>.
draft-ietf-quic-transport-34, 14 January 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-34.txt>.
9.2. Informative References 9.2. Informative References
[I-D.schinazi-quic-h3-datagram]
Schinazi, D., "Using QUIC Datagrams with HTTP/3", Work in
Progress, Internet-Draft, draft-schinazi-quic-h3-datagram-
05, 12 October 2020, <http://www.ietf.org/internet-drafts/
draft-schinazi-quic-h3-datagram-05.txt>.
[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. 23 change blocks. 
87 lines changed or deleted 109 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/