Draft: draft-ietf-quic-datagram

Commentary: This PR contains all the diff that were made by the RFC editor and authors during RFC edition and AUTH48 . The diff between this PR 's txt representation and the RFC txt can be seen . 
 Would you like to change " and " to " - " here ? Current : 0x30 and 0x31 Perhaps : 0x30 - 0x31 The latter would match the IANA registry and would match how 0x12 - 0x13 ( for example ) appears in RFC 9000 ( ) . 
 Yes , we should change this to match the IANA registry 
 SGTM 
 For clarity , may this sentence be updated as follows ? Original : Identifiers used to multiplex different kinds of datagrams , or flows of datagrams , are the responsibility of the application protocol running over QUIC to define . Perhaps : Defining the identifiers used to multiplex different kinds of datagrams or flows of datagrams is the responsibility of the application protocol running over QUIC . 
 SGTM 
 Agreed , this looks fine to me . 
 Please review whether the " type " attribute should be set for the sourcecode element in the XML file . If the current list of preferred values for " type " ( ) does not contain an applicable type , then feel free to suggest a new one . Also , it is acceptable to leave the " type " attribute not set . 
 Looking at RFC 9000 , these are n't source code , but are artwork , and without a type : I 'd suggest matching that . 
 Matching RFC9000 SGTM 
 Please insert any keywords ( beyond those that appear in the title ) for use on 
 I propose " quic " and " datagram "
This document defines two new DATAGRAM QUIC frame types which carry
application data without requiring retransmissions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
This document defines two new DATAGRAM QUIC frame types that carry
application data without requiring retransmissions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.
A variable-length integer specifying the length of the Datagram
Data field in bytes.  This field is present only when the LEN bit
is set to 1.  When the LEN bit is set to 0, the Datagram Data
field extends to the end of the QUIC packet.  Note that empty
(i.e., zero-length) datagrams are allowed.
The bytes of the datagram to be delivered.
DATAGRAM frames belong to a QUIC connection as a whole, and are not
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.
DATAGRAM frames belong to a QUIC connection as a whole and are not
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.
Defining the identifiers used to multiplex different kinds of
datagrams or flows of datagrams is the responsibility of the
application protocol running over QUIC.  The application defines the
semantics of the Datagram Data field and how it is parsed.
As with any ack-eliciting frame, when a sender suspects that a packet
containing only DATAGRAM frames has been lost, it sends probe packets
to elicit a faster acknowledgement as described in Section 6.2.4 of
RFC9002.
As with any ack-eliciting frame, when a sender suspects that a packet
containing only DATAGRAM frames has been lost, it sends probe packets
to elicit a faster acknowledgement as described in RFC9002.
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 cannot
replace application-layer signals that indicate successful
processing.
DATAGRAM frames do not provide any explicit flow control signaling,
and do not contribute to any per-flow or connection-wide data limit.
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, 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 cannot replace
application-layer signals that indicate successful processing.
DATAGRAM frames do not provide any explicit flow control signaling
and do not contribute to any per-flow or connection-wide data limit.
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.
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 (RFC9002) can also delay the sending of DATAGRAM frames
to maintain consistent packet pacing.
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.
Application protocols that allow DATAGRAM frames to be sent in 0-RTT
require a profile that defines acceptable use of 0-RTT; see RFC9001.
This document registers a new value in the QUIC Transport Parameter
Registry maintained at <https://www.iana.org/assignments/quic/
quic.xhtml#quic-transport>.
This document registers two new values in the QUIC Frame Type
registry maintained at <https://www.iana.org/assignments/quic/
quic.xhtml#quic-frame-types>.
The original proposal for this work came from Ian Swett.
This document registers a new value in the "QUIC Transport
Parameters" registry maintained at
<<https://www.iana.org/assignments/quic>>.