Draft: draft-ietf-quic-datagram

Commentary: Purely editorial nits
The QUIC Transport Protocol RFC9000 provides a secure, multiplexed
connection for transmitting reliable streams of application data.
QUIC uses various frame types to transmit data within packets, and
each frame type defines whether or not the data it contains will be
retransmitted.  Streams of reliable application data are sent using
STREAM frames.
Some applications, particularly those that need to transmit real-time
data, prefer to transmit data unreliably.  In the past, these
applications have built directly upon UDP RFC0768 as a transport, and
have often added security with DTLS RFC6347.  Extending QUIC to
support transmitting unreliable application data provides another
option for secure datagrams, with the added benefit of sharing the
cryptographic and authentication context used for reliable streams.
This document defines two new DATAGRAM QUIC frame types, which carry
application data without requiring retransmissions.
The QUIC Transport Protocol RFC9000 provides a secure, multiplexed
connection for transmitting reliable streams of application data.
QUIC uses various frame types to transmit data within packets, and
each frame type defines whether the data it contains will be
retransmitted.  Streams of reliable application data are sent using
STREAM frames.
Some applications, particularly those that need to transmit real-time
data, prefer to transmit data unreliably.  In the past, these
applications have built directly upon UDP RFC0768 as a transport and
have often added security with DTLS RFC6347.  Extending QUIC to
support transmitting unreliable application data provides another
option for secure datagrams with the added benefit of sharing the
cryptographic and authentication context used for reliable streams.
This document defines two new DATAGRAM QUIC frame types which carry
application data without requiring retransmissions.
Applications that want to use both a reliable stream and an
unreliable flow to the same peer can benefit by sharing a single
handshake and authentication context between a reliable QUIC
stream and flow of unreliable QUIC datagrams.  This can reduce the
latency required for handshakes compared to opening both a TLS
connection and a DTLS connection.
Applications that want to use both a reliable stream and an
unreliable flow to the same peer can benefit by sharing a single
handshake and authentication context between a reliable QUIC
stream and a flow of unreliable QUIC datagrams.  This can reduce
the latency required for handshakes compared to opening both a TLS
connection and a DTLS connection.
Unreliable QUIC datagrams can also be used to implement an IP packet
tunnel over QUIC, such as for a Virtual Private Network (VPN).
Internet-layer tunneling protocols generally require a reliable and
authenticated handshake, followed by unreliable secure transmission
of IP packets.  This can, for example, require a TLS connection for
the control data, and DTLS for tunneling IP packets.  A single QUIC
connection could support both parts with the use of unreliable
datagrams in addition to reliable streams.
Unreliable QUIC datagrams can also be used to implement an IP packet
tunnel over QUIC, such as for a Virtual Private Network (VPN).
Internet-layer tunneling protocols generally require a reliable and
authenticated handshake followed by unreliable secure transmission of
IP packets.  This can, for example, require a TLS connection for the
control data and DTLS for tunneling IP packets.  A single QUIC
connection could support both parts with the use of unreliable
datagrams in addition to reliable streams.
Application protocols that use datagrams MUST define how they react
to the max_datagram_frame_size transport parameter being missing.  If
datagram support is integral to the application, the application
protocol can fail the handshake if the max_datagram_frame_size
transport parameter is not present.
Application protocols that use datagrams MUST define how they react
to the absence of the max_datagram_frame_size transport parameter.
If datagram support is integral to the application, the application
protocol can fail the handshake if the max_datagram_frame_size
transport parameter is not present.
DATAGRAM frames employ the QUIC connection's congestion controller.
As a result, a connection might be unable to send a DATAGRAM frame
generated by the application until the congestion controller allows
it RFC9002.  The sender implementation MUST either delay sending the
frame until the controller allows it or drop the frame without
sending it (at which point it MAY notify the application).
Implementations that use packet pacing (Section 7.7 of RFC9002) can
also delay the sending of DATAGRAM frames to maintain consistent
packet pacing.
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.
DATAGRAM frames employ the QUIC connection's congestion controller.
As a result, a connection might be unable to send a DATAGRAM frame
generated by the application until the congestion controller allows
it RFC9002.  The sender MUST either delay sending the frame until the
controller allows it or drop the frame without sending it (at which
point it MAY notify the application).  Implementations that use
packet pacing (Section 7.7 of RFC9002) can also delay the sending of
DATAGRAM frames to maintain consistent packet pacing.
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.