draft-ietf-quic-datagram-03.txt   draft-ietf-quic-datagram-04.txt 
QUIC 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: 13 January 2022 D. Schinazi Expires: 12 March 2022 D. Schinazi
Google LLC Google LLC
12 July 2021 8 September 2021
An Unreliable Datagram Extension to QUIC An Unreliable Datagram Extension to QUIC
draft-ietf-quic-datagram-03 draft-ietf-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.
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 13 January 2022. This Internet-Draft will expire on 12 March 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 21 skipping to change at page 2, line 21
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. Multiplexing Datagrams . . . . . . . . . . . . . . . . . 6 5.1. Multiplexing Datagrams . . . . . . . . . . . . . . . . . 6
5.2. Acknowledgement Handling . . . . . . . . . . . . . . . . 6 5.2. Acknowledgement Handling . . . . . . . . . . . . . . . . 6
5.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Flow Control . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Congestion Control . . . . . . . . . . . . . . . . . . . 7 5.4. Congestion Control . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The QUIC Transport Protocol [RFC9000] provides a secure, multiplexed The QUIC Transport Protocol [RFC9000] provides a secure, multiplexed
connection for transmitting reliable streams of application data. connection for transmitting reliable streams of application data.
Reliability within QUIC is performed on a per-stream basis, so some Reliability within QUIC is performed on a per-stream basis, so some
frame types are not eligible for retransmission. frame types are not eligible for 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. In the past, these
build directly upon UDP [RFC0768] as a transport, and can add applications have built directly upon UDP [RFC0768] as a transport,
security with DTLS [RFC6347]. Extending QUIC to support transmitting and have often added security with DTLS [RFC6347]. Extending QUIC to
unreliable application data would provide another option for secure support transmitting unreliable application data provides another
datagrams, with the added benefit of sharing a cryptographic and option for secure datagrams, with the added benefit of sharing the
authentication context used for reliable streams. cryptographic and 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
application data without requiring retransmissions. application data without requiring retransmissions.
Note that DATAGRAM frames are only meant for unreliable
transmissions. Reliable transmission is already supported by QUIC
via STREAM frames.
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/
datagram (https://github.com/quicwg/datagram). datagram (https://github.com/quicwg/datagram).
1.1. Specification of Requirements 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 3, line 28 skipping to change at page 3, line 33
* 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 can 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 are subject to QUIC congestion control. Providing
allowing applications to be aware of whether a datagram was a single congestion control for both reliable and unreliable data
successfully received. can be more effective and efficient.
* QUIC datagrams are subject to QUIC congestion control, allowing
applications to avoid implementing their own.
These reductions in connection latency, and application insight into These features can be useful for optimizing audio/video streaming
the delivery of datagrams, can be useful for optimizing audio/video applications, gaming applications, and other real-time network
streaming applications, gaming applications, and other real-time applications.
network applications.
Unreliable QUIC datagrams can also be used to implement an IP packet Unreliable QUIC datagrams can also be used to implement an IP packet
tunnel over QUIC, such as for a Virtual Private Network (VPN). tunnel over QUIC, such as for a Virtual Private Network (VPN).
Internet-layer tunneling protocols generally require a reliable and Internet-layer tunneling protocols generally require a reliable and
authenticated handshake, followed by unreliable secure transmission authenticated handshake, followed by unreliable secure transmission
of IP packets. This can, for example, require a TLS connection for of IP packets. This can, for example, require a TLS connection for
the control data, and DTLS for tunneling IP packets. A single QUIC the control data, and DTLS for tunneling IP packets. A single QUIC
connection could support both parts with the use of unreliable connection could support both parts with the use of unreliable
datagrams. datagrams.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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 0b0011000X unreliable manner. The DATAGRAM frame type takes the form 0b0011000X
(or the values 0x30 and 0x31). The least significant bit of the (or the values 0x30 and 0x31). The least significant bit of the
DATAGRAM frame type is the LEN bit (0x01). It indicates that there 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 field 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 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. packet. If this bit is set to 1, the Length field is present.
The DATAGRAM frame is structured as follows: The DATAGRAM frame is structured as follows:
0 1 2 3 DATAGRAM Frame {
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 Type (i) = 0x30..0x31,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [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:
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 Data field in bytes. This field is present only when the
set. If the LEN bit is not set, the datagram data extends to the LEN bit is set to 1. When the LEN bit is set to 0, the Datagram
end of the QUIC packet. Note that empty (i.e., zero-length) Data field extends to the end of the QUIC packet. Note that empty
datagrams are allowed. (i.e., zero-length) datagrams are allowed.
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.
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 the
the Maximum Transmission Unit (MTU) of the path between endpoints. 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. Multiplexing Datagrams 5.1. Multiplexing Datagrams
DATAGRAM frames belong to a QUIC connection as a whole, and are not DATAGRAM frames belong to a QUIC connection as a whole, and are not
strongly associated with any stream ID at the QUIC layer. However, strongly associated with any stream ID at the QUIC layer. However,
it is expected that applications will want to differentiate between it is expected that applications will want to differentiate between
specific DATAGRAM frames by using identifiers, such as for logical specific DATAGRAM frames by using identifiers, such as for logical
skipping to change at page 6, line 42 skipping to change at page 6, line 40
QUIC implementations SHOULD present an API to applications to assign QUIC implementations SHOULD present an API to applications to assign
relative priorities to DATAGRAM frames with respect to each other and relative priorities to DATAGRAM frames with respect to each other and
to QUIC streams. to QUIC streams.
5.2. Acknowledgement Handling 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 ([RFC9002]). Receivers SHOULD support they are ack-eliciting ([RFC9002]). Receivers SHOULD support
delaying ACK frames (within the limits specified by max_ack_delay) in delaying ACK frames (within the limits specified by max_ack_delay) in
reponse to receiving packets that only contain DATAGRAM frames, since response to receiving packets that only contain DATAGRAM frames,
the timing of these acknowledgements is not used for loss recovery. since the sender takes no action if these packets are temporarily
unacknowledged. Receivers will continue to send ACK frames when
conditions indicate a packet might be lost, since the packet's
payload is unknown to the receiver, and when dictated by
max_ack_delay or other protocol components.
As with any ack-eliciting frame, when a sender suspects that a packet As with any ack-eliciting frame, when a sender suspects that a packet
containing only DATAGRAM frames has been lost, it MAY send probe containing only DATAGRAM frames has been lost, it sends probe packets
packets to elicit a faster acknowledgement as described in to elicit a faster acknowledgement as described in Section 6.2.4 of
Section 6.2.4 of [RFC9002]. [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. application that it believes the datagram was lost.
Similarly, if a packet containing a DATAGRAM frame is acknowledged, Similarly, if a packet containing a DATAGRAM frame is acknowledged,
the implementation MAY notify the sender application that the the implementation MAY notify the sender application that the
datagram was successfully transmitted and received. Due to datagram was successfully transmitted and received. Due to
reordering, this can include a DATAGRAM frame that was thought to be reordering, this can include a DATAGRAM frame that was thought to be
lost, but which at a later point was received and acknowledged. It lost, but which at a later point was received and acknowledged. It
is important to note that acknowledgement of a DATAGRAM frame only is important to note that acknowledgement of a DATAGRAM frame only
indicates that the transport-layer handling on the receiver processed indicates that the transport-layer handling on the receiver processed
the frame, and does not guarantee that the application on the the frame, and does not guarantee that the application on the
receiver successfully processed the data. Thus, this signal SHOULD receiver successfully processed the data. Thus, this signal cannot
NOT replace application-layer signals that indicate successful replace application-layer signals that indicate successful
processing. processing.
5.3. Flow Control 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 might 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 might not be able resources to process the frames. For example, it might not be able
skipping to change at page 7, line 37 skipping to change at page 7, line 41
if the receiver cannot process them. if the receiver cannot process them.
5.4. 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 might 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 [RFC9002]. The sender implementation MUST either delay sending it [RFC9002]. The sender implementation MUST either delay sending
the frame until the controller allows it or drop the frame without the frame until the controller allows it or drop the frame without
sending it (at which point it MAY notify the application). sending it (at which point it MAY notify the application).
Implementations that use packet pacing SHOULD support delaying the Implementations that use packet pacing (Section 7.7 of [RFC9002]) can
transmission of DATAGRAM frames for at least the time it takes to also delay the sending of DATAGRAM frames to maintain consistent
send the paced packets allowed by the congestion controller to avoid packet pacing.
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
protected either by 0-RTT or 1-RTT keys. protected either by 0-RTT or 1-RTT keys.
Application protocols that allow DATAGRAM frames to be sent in 0-RTT
require a profile that defines acceptable use of 0-RTT; see
Section 5.6 of [RFC9001].
The use of DATAGRAM frames might be detectable by an adversary on
path that is capable of dropping packets. Since DATAGRAM frames do
not use transport-level retransmission, connections that use DATAGRAM
frames might be distinguished from other frames using the different
response to loss.
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: A non-zero value indicates that the endpoint supports Specification: A non-zero value indicates that the endpoint supports
skipping to change at page 8, line 31 skipping to change at page 8, line 48
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. The original proposal for this work came from Ian Swett.
This document had reviews and input from many contributors in the
IETF QUIC Working Group, with substantive input from Nick Banks,
Lucas Pardue, Rui Paulo, Martin Thomson, Victor Vasiliev, and Chris
Wood.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>. May 2021, <https://www.rfc-editor.org/info/rfc9002>.
9.2. Informative References 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>.
 End of changes. 20 change blocks. 
49 lines changed or deleted 69 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/