<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-quic-datagram-10" indexInclude="true" ipr="trust200902" number="9221" prepTime="2022-03-31T16:19:11" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-quic-datagram-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9221" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="QUIC Datagrams">An Unreliable Datagram Extension to QUIC</title>
    <seriesInfo name="RFC" value="9221" stream="IETF"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization showOnFrontPage="true">Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino</city>
          <region>CA</region>
          <code>95014</code>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="E." surname="Kinnear" fullname="Eric Kinnear">
      <organization showOnFrontPage="true">Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino</city>
          <region>CA</region>
          <code>95014</code>
          <country>United States of America</country>
        </postal>
        <email>ekinnear@apple.com</email>
      </address>
    </author>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization showOnFrontPage="true">Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <date month="03" year="2022"/>
    <workgroup>QUIC</workgroup>
    <keyword>quic</keyword>
    <keyword>datagram</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines an extension to the QUIC transport protocol to add support
for sending and receiving unreliable datagrams over a QUIC connection.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9221" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specification-of-requiremen">Specification of Requirements</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-motivation">Motivation</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-parameter">Transport Parameter</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-datagram-frame-types">Datagram Frame Types</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-behavior-and-usage">Behavior and Usage</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multiplexing-datagrams">Multiplexing Datagrams</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgement-handling">Acknowledgement Handling</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flow-control">Flow Control</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-congestion-control">Congestion Control</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-quic-transport-parameter">QUIC Transport Parameter</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-quic-frame-types">QUIC Frame Types</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The QUIC transport protocol <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-1-2">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 <xref target="RFC0768" format="default" sectionFormat="of" derivedContent="RFC0768"/> as a transport and have often added security
with DTLS <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-1-3">This document defines two new DATAGRAM QUIC frame types that carry application
data without requiring retransmissions.</t>
      <section anchor="specification-of-requirements" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-specification-of-requiremen">Specification of Requirements</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="motivation" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-motivation">Motivation</name>
      <t indent="0" pn="section-2-1">Transmitting unreliable data over QUIC provides benefits over existing solutions:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-2">
        <li pn="section-2-2.1">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.</li>
        <li pn="section-2-2.2">QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake. This
can allow loss recovery to occur more quickly for QUIC data.</li>
        <li pn="section-2-2.3">QUIC datagrams are subject to QUIC congestion control. Providing a single
congestion control for both reliable and unreliable data can be more effective
and efficient.</li>
      </ul>
      <t indent="0" pn="section-2-3">These features can be useful for optimizing audio/video streaming applications,
gaming applications, and other real-time network applications.</t>
      <t indent="0" pn="section-2-4">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.</t>
    </section>
    <section anchor="transport-parameter" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-transport-parameter">Transport Parameter</name>
      <t indent="0" pn="section-3-1">Support for receiving the DATAGRAM frame types is advertised by means of a QUIC
transport parameter (name=max_datagram_frame_size, value=0x20). The
max_datagram_frame_size transport parameter is an integer value (represented as
a variable-length integer) that represents the maximum size of a DATAGRAM frame
(including the frame type, length, and payload) the endpoint is willing to
receive, in bytes.</t>
      <t indent="0" pn="section-3-2">The default for this parameter is 0, which indicates that the endpoint does not
support DATAGRAM frames. A value greater than 0 indicates that the endpoint
supports the DATAGRAM frame types and is willing to receive such frames on this
connection.</t>
      <t indent="0" pn="section-3-3">An endpoint <bcp14>MUST NOT</bcp14> send DATAGRAM frames until it has received the
max_datagram_frame_size transport parameter with a non-zero value during the
handshake (or during a previous handshake if 0-RTT is used). An endpoint <bcp14>MUST NOT</bcp14> send DATAGRAM frames that are larger than the max_datagram_frame_size value
it has received from its peer. An endpoint that receives a DATAGRAM frame when
it has not indicated support via the transport parameter <bcp14>MUST</bcp14> terminate the
connection with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint that
receives a DATAGRAM frame that is larger than the value it sent in its
max_datagram_frame_size transport parameter <bcp14>MUST</bcp14> terminate the connection with
an error of type PROTOCOL_VIOLATION.</t>
      <t indent="0" pn="section-3-4">For most uses of DATAGRAM frames, it is <bcp14>RECOMMENDED</bcp14> 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.</t>
      <t indent="0" pn="section-3-5">The max_datagram_frame_size transport parameter is a unidirectional limit and
indication of support of DATAGRAM frames. Application protocols that use
DATAGRAM frames <bcp14>MAY</bcp14> choose to only negotiate and use them in a single direction.</t>
      <t indent="0" pn="section-3-6">When clients use 0-RTT, they <bcp14>MAY</bcp14> store the value of the server's
max_datagram_frame_size transport parameter. Doing so allows the client to send
DATAGRAM frames in 0-RTT packets. When servers decide to accept 0-RTT data,
they <bcp14>MUST</bcp14> send a max_datagram_frame_size transport parameter greater than or
equal to the value they sent to the client in the connection where they sent
them the NewSessionTicket message. If a client stores the value of the
max_datagram_frame_size transport parameter with their 0-RTT state, they <bcp14>MUST</bcp14>
validate that the new value of the max_datagram_frame_size transport parameter
sent by the server in the handshake is greater than or equal to the stored
value; if not, the client <bcp14>MUST</bcp14> terminate the connection with error
PROTOCOL_VIOLATION.</t>
      <t indent="0" pn="section-3-7">Application protocols that use datagrams <bcp14>MUST</bcp14> 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.</t>
    </section>
    <section anchor="datagram-frame-types" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-datagram-frame-types">Datagram Frame Types</name>
      <t indent="0" pn="section-4-1">DATAGRAM frames are used to transmit application data in an unreliable manner.
The Type field in the DATAGRAM frame takes the form 0b0011000X (or the values
0x30 and 0x31). The least significant bit of the Type field in the DATAGRAM
frame is the LEN bit (0x01), which indicates whether there 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 packet; if this bit is set to 1, the
Length field is present.</t>
      <t indent="0" pn="section-4-2">DATAGRAM frames are structured as follows:</t>
      <figure anchor="datagram-format" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-datagram-frame-format">DATAGRAM Frame Format</name>
        <artwork name="" type="" align="left" pn="section-4-3.1">
DATAGRAM Frame {
  Type (i) = 0x30..0x31,
  [Length (i)],
  Datagram Data (..),
}
</artwork>
      </figure>
      <t indent="0" pn="section-4-4">DATAGRAM frames contain the following fields:</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-4-5">
        <dt pn="section-4-5.1">
Length:  </dt>
        <dd pn="section-4-5.2">
          <t indent="0" pn="section-4-5.2.1">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.</t>
        </dd>
        <dt pn="section-4-5.3">
Datagram Data:  </dt>
        <dd pn="section-4-5.4">
          <t indent="0" pn="section-4-5.4.1">The bytes of the datagram to be delivered.</t>
        </dd>
      </dl>
    </section>
    <section anchor="behavior-and-usage" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-behavior-and-usage">Behavior and Usage</name>
      <t indent="0" pn="section-5-1">When an application sends a datagram over a QUIC connection, QUIC will generate
a new DATAGRAM frame and send it in the first available packet. This frame
<bcp14>SHOULD</bcp14> be sent as soon as possible (as determined by factors like congestion
control, described below) and <bcp14>MAY</bcp14> be coalesced with other frames.</t>
      <t indent="0" pn="section-5-2">When a QUIC endpoint receives a valid DATAGRAM frame, it <bcp14>SHOULD</bcp14> deliver the data
to the application immediately, as long as it is able to process the frame and
can store the contents in memory.</t>
      <t indent="0" pn="section-5-3">Like STREAM frames, DATAGRAM frames contain application data and <bcp14>MUST</bcp14> be
protected with either 0-RTT or 1-RTT keys.</t>
      <t indent="0" pn="section-5-4">Note that while the max_datagram_frame_size transport parameter places a limit
on the maximum size of DATAGRAM frames, that limit can be further reduced by the
max_udp_payload_size transport parameter and the Maximum Transmission Unit
(MTU) of the path between endpoints. DATAGRAM frames cannot be fragmented;
therefore, application protocols need to handle cases where the maximum
datagram size is limited by other factors.</t>
      <section anchor="multiplexing-datagrams" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-multiplexing-datagrams">Multiplexing Datagrams</name>
        <t indent="0" pn="section-5.1-1">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.</t>
        <t indent="0" pn="section-5.1-2">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.</t>
        <t indent="0" pn="section-5.1-3">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. This is a simple approach that allows a
large number of flows to be encoded using minimal space.</t>
        <t indent="0" pn="section-5.1-4">QUIC implementations <bcp14>SHOULD</bcp14> present an API to applications to assign relative
priorities to DATAGRAM frames with respect to each other and to QUIC streams.</t>
      </section>
      <section anchor="acknowledgement-handling" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-acknowledgement-handling">Acknowledgement Handling</name>
        <t indent="0" pn="section-5.2-1">Although DATAGRAM frames are not retransmitted upon loss detection, they are
ack-eliciting (<xref target="RFC9002" format="default" sectionFormat="of" derivedContent="RFC9002"/>). Receivers <bcp14>SHOULD</bcp14> support delaying ACK frames
(within the limits specified by max_ack_delay) in response to receiving packets
that only contain DATAGRAM frames, 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.</t>
        <t indent="0" pn="section-5.2-2">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 <xref section="6.2.4" sectionFormat="of" target="RFC9002" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9002#section-6.2.4" derivedContent="RFC9002"/>.</t>
        <t indent="0" pn="section-5.2-3">If a sender detects that a packet containing a specific DATAGRAM frame might
have been lost, the implementation <bcp14>MAY</bcp14> notify the application that it believes
the datagram was lost.</t>
        <t indent="0" pn="section-5.2-4">Similarly, if a packet containing a DATAGRAM frame is acknowledged, the
implementation <bcp14>MAY</bcp14> 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.</t>
      </section>
      <section anchor="flow-control" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-flow-control">Flow Control</name>
        <t indent="0" pn="section-5.3-1">DATAGRAM frames do not provide any explicit flow control signaling and do not
contribute to any per-flow or connection-wide data limit.</t>
        <t indent="0" pn="section-5.3-2">The risk associated with not providing flow control for DATAGRAM 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 to store the frame contents in memory.
However, since DATAGRAM frames are inherently unreliable, they <bcp14>MAY</bcp14> be dropped by
the receiver if the receiver cannot process them.</t>
      </section>
      <section anchor="congestion-control" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-congestion-control">Congestion Control</name>
        <t indent="0" pn="section-5.4-1">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 <xref target="RFC9002" format="default" sectionFormat="of" derivedContent="RFC9002"/>. The sender
<bcp14>MUST</bcp14> either delay sending the frame until the controller allows it or drop the
frame without sending it (at which point it <bcp14>MAY</bcp14> notify the application).
Implementations that use packet pacing (<xref section="7.7" sectionFormat="of" target="RFC9002" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9002#section-7.7" derivedContent="RFC9002"/>) can also
	delay the sending of DATAGRAM frames to maintain consistent packet pacing.</t>
        <t indent="0" pn="section-5.4-2">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.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">The DATAGRAM frame shares the same security properties as the rest of the data
transmitted within a QUIC connection, and the security considerations of
<xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/> apply accordingly. All application data transmitted with the
DATAGRAM frame, like the STREAM frame, <bcp14>MUST</bcp14> be protected either by 0-RTT or
1-RTT keys.</t>
      <t indent="0" pn="section-6-2">Application protocols that allow DATAGRAM frames to be sent in 0-RTT require a
profile that defines acceptable use of 0-RTT; see <xref section="5.6" sectionFormat="of" target="RFC9001" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9001#section-5.6" derivedContent="RFC9001"/>.</t>
      <t indent="0" pn="section-6-3">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 connections due to their different response to packet loss.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="quic-transport-parameter" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-quic-transport-parameter">QUIC Transport Parameter</name>
        <t indent="0" pn="section-7.1-1">This document registers a new value in the "QUIC Transport Parameters" registry
maintained at
<eref target="https://www.iana.org/assignments/quic" brackets="angle"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-7.1-2">
          <dt pn="section-7.1-2.1">
Value:  </dt>
          <dd pn="section-7.1-2.2">
            0x20
          </dd>
          <dt pn="section-7.1-2.3">
Parameter Name:  </dt>
          <dd pn="section-7.1-2.4">
            max_datagram_frame_size
          </dd>
          <dt pn="section-7.1-2.5">
Status:  </dt>
          <dd pn="section-7.1-2.6">
            permanent
          </dd>
          <dt pn="section-7.1-2.7">
Specification:  </dt>
          <dd pn="section-7.1-2.8">
           RFC 9221
          </dd>
        </dl>
      </section>
      <section anchor="quic-frame-types" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-quic-frame-types">QUIC Frame Types</name>
        <t indent="0" pn="section-7.2-1">This document registers two new values in the "QUIC Frame Types" registry
maintained at
<eref target="https://www.iana.org/assignments/quic" brackets="angle"/>.</t>
        <dl spacing="compact" indent="3" newline="false" pn="section-7.2-2">
          <dt pn="section-7.2-2.1">
Value:  </dt>
          <dd pn="section-7.2-2.2">
            0x30-0x31
          </dd>
          <dt pn="section-7.2-2.3">
Frame Name:  </dt>
          <dd pn="section-7.2-2.4">
           DATAGRAM
          </dd>
          <dt pn="section-7.2-2.5">
Status:  </dt>
          <dd pn="section-7.2-2.6">
            permanent
          </dd>
          <dt pn="section-7.2-2.7">
Specification:  </dt>
          <dd pn="section-7.2-2.8">
            RFC 9221
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author initials="J." surname="Iyengar" fullname="J. Iyengar" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC9001" target="https://www.rfc-editor.org/info/rfc9001" quoteTitle="true" derivedAnchor="RFC9001">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Turner" fullname="S. Turner" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9001"/>
          <seriesInfo name="DOI" value="10.17487/RFC9001"/>
        </reference>
        <reference anchor="RFC9002" target="https://www.rfc-editor.org/info/rfc9002" quoteTitle="true" derivedAnchor="RFC9002">
          <front>
            <title>QUIC Loss Detection and Congestion Control</title>
            <author initials="J." surname="Iyengar" fullname="J. Iyengar" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I." surname="Swett" fullname="I. Swett" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">This document describes loss detection and congestion control mechanisms for QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9002"/>
          <seriesInfo name="DOI" value="10.17487/RFC9002"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc768" quoteTitle="true" derivedAnchor="RFC0768">
          <front>
            <title>User Datagram Protocol</title>
            <author initials="J." surname="Postel" fullname="J. Postel">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1980" month="August"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="January"/>
            <abstract>
              <t indent="0">This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The original proposal for this work came from <contact fullname="Ian Swett"/>.</t>
      <t indent="0" pn="section-appendix.a-2">This document had reviews and input from many contributors in the IETF QUIC
Working Group, with substantive input from <contact fullname="Nick Banks"/>, <contact fullname="Lucas Pardue"/>, <contact fullname="Rui Paulo"/>,
<contact fullname="Martin Thomson"/>, <contact fullname="Victor Vasiliev"/>, and <contact fullname="Chris Wood"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="T." surname="Pauly" fullname="Tommy Pauly">
        <organization showOnFrontPage="true">Apple Inc.</organization>
        <address>
          <postal>
            <street>One Apple Park Way</street>
            <city>Cupertino</city>
            <region>CA</region>
            <code>95014</code>
            <country>United States of America</country>
          </postal>
          <email>tpauly@apple.com</email>
        </address>
      </author>
      <author initials="E." surname="Kinnear" fullname="Eric Kinnear">
        <organization showOnFrontPage="true">Apple Inc.</organization>
        <address>
          <postal>
            <street>One Apple Park Way</street>
            <city>Cupertino</city>
            <region>CA</region>
            <code>95014</code>
            <country>United States of America</country>
          </postal>
          <email>ekinnear@apple.com</email>
        </address>
      </author>
      <author initials="D." surname="Schinazi" fullname="David Schinazi">
        <organization showOnFrontPage="true">Google LLC</organization>
        <address>
          <postal>
            <street>1600 Amphitheatre Parkway</street>
            <city>Mountain View</city>
            <region>CA</region>
            <code>94043</code>
            <country>United States of America</country>
          </postal>
          <email>dschinazi.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
