<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.17 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-quic-datagram-10" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> version="3" consensus="true" number="9221">

  <!-- xml2rfc v2v3 conversion 3.11.1 -->

  <front>
    <title abbrev="QUIC Datagrams">An Unreliable Datagram Extension to QUIC</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-quic-datagram-10"/> name="RFC" value="9221"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <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>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <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>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, California 94043</city> View</city>
	  <region>CA</region>
	  <code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2022" month="February" day="04"/> month="March"/>
    <workgroup>QUIC</workgroup>
    <keyword>Internet-Draft</keyword>

    <keyword>quic</keyword>
    <keyword>datagram</keyword>
    <abstract>
      <t>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>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>
        Discussion of this document takes place on the
        QUIC Working Group mailing list (<eref target="mailto:quic@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/quic/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/quicwg/datagram"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The QUIC Transport Protocol transport protocol <xref target="RFC9000" format="default"/> 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>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"/> as a transport and have often added security
with DTLS <xref target="RFC6347" format="default"/>. 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>This document defines two new DATAGRAM QUIC frame types which that carry application
data without requiring retransmissions.</t>
      <section anchor="specification-of-requirements" numbered="true" toc="default">
        <name>Specification of Requirements</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    </section>
    <section anchor="motivation" numbered="true" toc="default">
      <name>Motivation</name>
      <t>Transmitting unreliable data over QUIC provides benefits over existing solutions:</t>
      <ul spacing="normal">
        <li>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>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>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>These features can be useful for optimizing audio/video streaming applications,
gaming applications, and other real-time network applications.</t>
      <t>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="default">
      <name>Transport Parameter</name>
      <t>Support for receiving the DATAGRAM frame types is advertised by means of a QUIC
Transport Parameter
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>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>An endpoint MUST NOT <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 MUST
NOT <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 MUST <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 MUST <bcp14>MUST</bcp14> terminate the connection with
an error of type PROTOCOL_VIOLATION.</t>
      <t>For most uses of DATAGRAM frames, it is RECOMMENDED <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>The max_datagram_frame_size transport parameter is a unidirectional limit and
indication of support of DATAGRAM frames. Application protocols that use
DATAGRAM frames MAY <bcp14>MAY</bcp14> choose to only negotiate and use them in a single direction.</t>
      <t>When clients use 0-RTT, they MAY <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 MUST <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 MUST <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 MUST <bcp14>MUST</bcp14> terminate the connection with error
PROTOCOL_VIOLATION.</t>
      <t>Application protocols that use datagrams MUST <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="default">
      <name>Datagram Frame Types</name>
      <t>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>DATAGRAM frames are structured as follows:</t>
      <figure anchor="datagram-format">
        <name>DATAGRAM Frame Format</name>

<artwork name="" type="" align="left" alt=""><![CDATA[ align="left">
DATAGRAM Frame {
  Type (i) = 0x30..0x31,
  [Length (i)],
  Datagram Data (..),
}
]]></artwork>
</artwork>
      </figure>
      <t>DATAGRAM frames contain the following fields:</t>
      <dl>
        <dt>
Length:  </dt>
        <dd>
          <t>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>
Datagram Data:  </dt>
        <dd>
          <t>The bytes of the datagram to be delivered.</t>
        </dd>
      </dl>
    </section>
    <section anchor="behavior-and-usage" numbered="true" toc="default">
      <name>Behavior and Usage</name>
      <t>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
SHOULD
<bcp14>SHOULD</bcp14> be sent as soon as possible (as determined by factors like congestion
control, described below) and MAY <bcp14>MAY</bcp14> be coalesced with other frames.</t>
      <t>When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD <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>Like STREAM frames, DATAGRAM frames contain application data and MUST <bcp14>MUST</bcp14> be
protected with either 0-RTT or 1-RTT keys.</t>
      <t>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="default">
        <name>Multiplexing Datagrams</name>
        <t>DATAGRAM frames belong to a QUIC connection as a whole, 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>Identifiers
        <t>Defining the identifiers used to multiplex different kinds of datagrams, datagrams or flows of
datagrams, are datagrams is the responsibility of the application protocol running over QUIC
to define. QUIC. The application defines the semantics of the Datagram Data field and
how it is parsed.</t>
        <t>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>QUIC implementations SHOULD <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="default">
        <name>Acknowledgement Handling</name>
        <t>Although DATAGRAM frames are not retransmitted upon loss detection, they are
ack-eliciting (<xref target="RFC9002" format="default"/>). Receivers SHOULD <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>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"/>.</t>
        <t>If a sender detects that a packet containing a specific DATAGRAM frame might
have been lost, the implementation MAY <bcp14>MAY</bcp14> notify the application that it believes
the datagram was lost.</t>
        <t>Similarly, if a packet containing a DATAGRAM frame is acknowledged, the
implementation MAY <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 which lost but, at a later point 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, 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="default">
        <name>Flow Control</name>
        <t>DATAGRAM frames do not provide any explicit flow control signaling, signaling and do not
contribute to any per-flow or connection-wide data limit.</t>
        <t>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 MAY <bcp14>MAY</bcp14> be dropped by
the receiver if the receiver cannot process them.</t>
      </section>
      <section anchor="congestion-control" numbered="true" toc="default">
        <name>Congestion Control</name>
        <t>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"/>. The sender
MUST
<bcp14>MUST</bcp14> either delay sending the frame until the controller allows it or drop the
frame without sending it (at which point it MAY <bcp14>MAY</bcp14> notify the application).
Implementations that use packet pacing (<xref section="7.7" sectionFormat="of" target="RFC9002" format="default"/>) can also
	delay the sending of DATAGRAM frames to maintain consistent packet pacing.</t>
        <t>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="default">
      <name>Security Considerations</name>
      <t>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"/> apply accordingly. All application data transmitted with the
DATAGRAM frame, like the STREAM frame, MUST <bcp14>MUST</bcp14> be protected either by 0-RTT or
1-RTT keys.</t>
      <t>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"/>.</t>
      <t>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="default">
      <name>IANA Considerations</name>
      <section anchor="quic-transport-parameter" numbered="true" toc="default">
        <name>QUIC Transport Parameter</name>
        <t>This document registers a new value in the QUIC "QUIC Transport Parameter Registry Parameters" registry
maintained at
<eref target="https://www.iana.org/assignments/quic/quic.xhtml#quic-transport"/>.</t>
        <dl> target="https://www.iana.org/assignments/quic" brackets="angle"/>.</t>
        <dl spacing="compact">
          <dt>
Value:  </dt>
          <dd>
            <t>0x20</t>
            0x20
          </dd>
          <dt>
Parameter Name:  </dt>
          <dd>
            <t>max_datagram_frame_size</t>
            max_datagram_frame_size
          </dd>
          <dt>
Status:  </dt>
          <dd>
            <t>permanent</t>
            permanent
          </dd>
          <dt>
Specification:  </dt>
          <dd>
            <t>This document</t>
           RFC 9221
          </dd>
        </dl>
      </section>
      <section anchor="quic-frame-types" numbered="true" toc="default">
        <name>QUIC Frame Types</name>
        <t>This document registers two new values in the QUIC "QUIC Frame Type Types" registry
maintained at
<eref target="https://www.iana.org/assignments/quic/quic.xhtml#quic-frame-types"/>.</t>
        <dl> target="https://www.iana.org/assignments/quic" brackets="angle"/>.</t>
        <dl spacing="compact">
          <dt>
Value:  </dt>
          <dd>
            <t>0x30 and 0x31 (if this document is approved)</t>
            0x30-0x31
          </dd>
          <dt>
Frame Name:  </dt>
          <dd>
            <t>DATAGRAM</t>
           DATAGRAM
          </dd>
          <dt>
Status:  </dt>
          <dd>
            <t>permanent</t>
            permanent
          </dd>
          <dt>
Specification:  </dt>
          <dd>
            <t>This document</t>
            RFC 9221
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9002.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="true" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The original proposal for this work came from Ian Swett.</t> <contact fullname="Ian Swett"/>.</t>
      <t>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.</t> <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>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC9001">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>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="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>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="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>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">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>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="RFC9002">
          <front>
            <title>QUIC Loss Detection and Congestion Control</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="I. Swett" initials="I." role="editor" surname="Swett">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>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>
        <name>Informative References</name>
        <reference anchor="RFC0768">
          <front>
            <title>User Datagram Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel">
              <organization/>
            </author>
            <date month="August" year="1980"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <reference anchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu">
              <organization/>
            </author>
            <date month="January" year="2012"/>
            <abstract>
              <t>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>
  </back>
  <!-- ##markdown-source:
H4sIAMak/WEAA81bW3Mbt5J+x6/A2g+RqiiachznRKnURseyE9WRL2vJzm6l
Ui5wBiSxGg64cxHNuJzfvl93AzOYIeVdn9qHfbBFzgXoe3/dDZ6cnKjGNYU9
0+elfldWtnBmXlh9YRqzrMxaP//Y2LJ2vtSN1//27vKZMvN5Ze/O+Ev3XK1y
n5VmjYXyyiyaE2ebxcl/tS47ycMjJ6czhc/2TGX4f+mr3Zmum1xtl7KWurNl
i7taLyvfbs70A7r6AN+b3QbrPvjNV7euXOpf6DZdXxtX4Drt8jPtN/XVkq6b
Klvh+qppNvXZo0f0GF1yd3YaH3tEFx7NK7+t7SNa4BG9uHTNqp2HJbfLR5F0
uleA6LpJlpVnpvLO1Pnu6Uf3SWC6atbFA6XcpjrTTdXWzePZ7IfZY3Vrd1tf
5Wf6smxsVdrm5IKWUKpuTJl/MIUvIYCdrdXGnenfG59NdO2rprKLGp92a/rw
h1KmbVa+IhGe4J/WrqzP9M1UvzFtseMroqIbv17vkqsQCAxgs4HiL8tsytdq
rG7B7+vShltvTHWrfzPySuYa6O9Zu7FV40o/0c9M4Ra+Kp3RP3w3O30iT/m2
bEjR70rX2FxfNyRF7Rf6fG0rlxl+yooimw0R9LOhzaaZXw/ZeD7V/3BlaU2V
MPIcawwu///gxN4KSffxcjHV17DH0vzpEmYuzJ3LhzeYnV+8X4Loq6tnA3ZO
n85m2HyzggFag4vM1nbA1Uui2rhSv3d2O+TsyezJt1/PWV4H8tiTfl7SVeZP
lb5amwY+Rub39sWzH2az0zOlTk5OtJmDZpPBnm9WrtaIFO3alo3O7cKV2MqU
2qZhBvxIdMFbZb2BoetN5WH1vqDbJs913W7ougI3urZlTnEBrqIrm1l3R9/a
PphF/wNTd7bSRhbPPHSUNdhzKmSuXZ4XVqmH5IaVz1u+SUQHcm46ct5Ecj59
+hfhdfb5MxEJDRJDoClrKzvR67ZoHGzgo81Vv6Emspm5tWsaorajlbTLlC40
GQ/Ezy8QC1Ohoq0RB+5M5Xxb6wXYshwga5ZcWJOf11tYBnS/MdmtbRAoSEDW
ZKvkLRV1sF1ZiL1i2fPLWAQEk/HgpisKPbegsiPa5rDhntZIvxoTjWBsSUMN
6CZGr2/ePj9/KRTUEPy1ByXJSyBzY+CIWYuYXexAj69B6so0urSwzpRJ7F6c
NG4tFE/UBmGQWBjLoTOF3RSqZRY3pm4m9Kke7q5X5s7qeeuKRuUO1tSAhnYD
Zt5dvIG2/xXann3/9G/QtiE99xZKwuWX/QKmTEYKatkM4ImKVKEvbq6uwxpP
v33y/efPU0mvbL1i8D5a9tA8emPeF3BvdaVnFfpNZ2NihokDMB0kAKZPzW0J
/TekwXoFk8JWdDOrdpvG4w0El4w5o8wCJcaNyTLgsmSLOW2kxvY7vc/Xm62H
Irf64vzm/Je3sATmOzXjLfZc6cxU1S5VjepM2rekemTWSjwnSKqm8EEbP3yo
rzc2c4tILbh7y89bIqUWj0bO1ZR0a/3g5bvrmwcT+atfvebPb5+DsLfPL+jz
9a/nV1fdh/jE9a+v313hvgqf+jefvX758vmrC3kZV/Xo0svz/3gg3vjg9Zub
y9evzq8eIDFA9I5xlEiMHAf2ALdzhApg3BSdYXXQdVa5Ob7gnb8/e6NPn4Q4
9Pj09AdYpnz52+n3Tz5/VnDsUjbzJWxZvkKZLFzkKFrEwL0zs3GNKShM1DAG
vy01jMmSPJFGENhNiIaH7VJskeMra7SzymBiIfbaj67mN2tftOxxlCM4LXcu
yM6+NRAB2IeF6TnsGr42sjGxyzKlYVH4LV4iyAgN12RTG4tdMzwWTX2+60wd
YRp/8N4KS+HirT1g60p31j63zdaSb/ekMK8pPUIDLC4hi9Gt7r1wqtk3iKrK
Is1YJpcAZpntgmmLX/WU4XG/RmTkEIjF/MaWxEOQDUWWJL8IKRfDq5Tm+hSC
+2sPEytbU2ZYtfB1TemT1LTTa5tha1evSRsSMnm1jh7hgYRj2H7A9HAF6M5n
iD6yC+HgW5gf8cQkcELrCOoDFKeLdv6fIDlWHMTCEtg7Bp7KF1PKwLCvVIui
qNGDvCHLqNMGyWZst2IgQqpdLEhed7QgZ8wFAomDQXBMo4SxANxCWK3jaxDn
opWtKPau3Z9MV5ujKCAn8MFC+Gqa6tTywEXxVY7kfYJDTYBgdTt4EvS8GxpZ
IkdRS+0DfZw43RpIRGJLqS/fBGCgmxYWUrB/KloFFUWLCIwwQBwZYMeqaU0B
kVMQsPpVoOXo/ZtXx9O+ZinMjrIvrwauVMRstV7C9yoYSWfcqQuNXM7miTsu
PFkWLs13KtFZSGtp4CeX61hKPGzCTNiPhnif9PurkccwIqPUF+xGsAtIY7Pn
u5GxwT7n0fpGmJJgddHhVDFBAjZJCqbQNgwUnfqUYwThmoCID6TXhykcNZQ/
oQbgqbAhUdyDYfbfmHHTZAshmfyOKp+apQzHx6KMPiVsHdhEH1G98tPafPwQ
Cf7Aa36o3Z+Q8Z0pWvvT7OPj2THpwap7nkzhfbe243KAMt4S33gpfVRZZD8C
kZwAldEEf0keJ4UtlxBneP5Yckf3eM2MY3u3btea92TOhqJQR67MijaPgurl
M9GyvvjkxuwKb/JjfgiobeOxLRFM8Jhf9kpEjhehwPmusQKELMEfFLdNMDO8
M+B4NgmoxwELZlx+MSODjXKPy4B4KtrUkAu2RZHXEjbSMJaHKGdfWjSuVd9v
IcT5gMdgVlaihOytfUAvg2xzXvbUR2zF1dqYdPhA4woqOVamjuvnRNNX2Q57
loGMypM/beWDNPI24lrVB5Yj6CHcIARt77ia6u+7hZ6dvL25IdYpfMKSx9yo
e7lhMVMiQwmzjHoIlniQGSZUjdlfVH6tCTkRhhnuH8ycH6z3DJpBXlwOFtNZ
QB+P7pxhig6JkVWFD0hNFO5JcElcEyGDlqqifLdgM9Fv3r6+ef3s9dWH95ev
r84J06I8RCbkIm7Cz6e0q/tpZ9Yg9bHsRJlgiotJuBck81XWsc+WHrGl/jds
KfXCE6ipG4FReHSk/wlRCQ4S1M+FnWVQJnzgraffffftd2BEfckyDjFCmTwo
NHo0dutcmot1k2V2Q3l+d1C+DMhR2QOcxHaIZLQQrr42YsOBnZTLkCWgQuGo
+IY3qUBpyNDR/PaFNk1rAN1DByYXglZjJ0MRpbOV5+6Al9qmtEsUKiQWxnjc
N7BrLnAi0u+IBKO/wUt0VjhOFPQ0e3wojmj5uiE82BsfWQXVFbZCxvzmq6xv
qi+8lD0CliXgyubROPZYBOEShDq0wSTL/lQHZqQ/6oiJtuVh6YUIE2Tywe6+
RqWDBILqHqDJFLEzJ7Lg9etAfcKLK/c8i8rI/nnFOqFnXtnttWXwduMYiILn
2ixRWlxSkg4LshLqPS18fWLAS64KMqqpxxk1TbEcS7s8cSjLTYqB2r9iQ8WC
me8Sc4mCSVJMPZazHsiZGc8V0/AjJSRE8kkq6v85oEk0Uwej2JfdLakkeBtp
3+gV1dckNBCeRdUrMwe/2T8jKFZ1fLZr6rpaAF3VCyOpeybjC31zmIqehQGS
GEhaua+mi5RDiTPgSIbb3UjsBcfRG0JHas9nKe3HeqvrQu717CgkDToXawPF
VVMOvrQyIrQt8mg04xDO/QCGqr5a69l8Njs9nc1m/86wpvOUWs0+fjvjWIgP
pwLGgWgNUlftliU3yMhOpQHYfHFrJVs72ffq+St+7Wj2cXZ6vI9ek25yZSVD
XAlS58VVkOuZZtXg/lxSZm3ZqGai4/QVXmReS/GaC2lBIYo+hKd4jpDX0Wwo
9AXWJIb+eM+Op7yjGu/Y6/+QnlGMtRl1AnIpljmwnyn1119/9c+LtXxSWoR7
5I71T6SP2XRKWpngxu9hW9z7g753lsaMHU2nxxP1mVf9dKYfdvPUBU9cNM9v
f3ow2vAF33zweZ/y0NUP9kM0U2Jilol4oQUfzrieOFhn6Zr7q7tYMYW7QdJD
8qM1KSmHpDAfC7jvTQ7MK9FPyH3JXbVnL4c2vt8gUtSjX/nGKg5+dr1pdlDF
1E4nmsqIwPvxqEllpDNBppFuy4IjP2N2415diJOGbg63R07gtx/qv9uVQf1R
sWG/owwYsAm1cJLIUTMjpl/s8DRrIhcYBkrjBayZYdNdnJn2Y3Tgury9cBWi
g7mjkTnFpSgf0RpXy6HbPQ9jHeoWe2o5Qpke2ZzeOuIutaQmaSsskC48MEvh
bm3SplOh3TJJmtpzC8EeM3EEwub0vClwG/c4qUlvrJsgiaiE6a7ISOoLTu0j
1hmiB0aCMjo9qf2Uo916bXNCllzMgA1PhWMdgD5LCm8hD2WAMEkTgRAwJaUe
SXIvuWT0Dbyz9tUOLFyRVAaTscleURnddn/ARoKiHD233HKDFURJWceiEswD
AzvlD7d2R3Ijkw+99pUr7FenyE1hMhYwg33luxJ30GzZq414R6kPQvt00Vah
20m98DzgJgZ4bb75ENou9xMS88HLsPVN2hakobY6ennz7rhPBJBMbOVHg0Fg
2hM4UrJvmMDKLNfcffpRcUZD5IUJHYIgdTelJPgBqWamlnxY2VQ+qgc9xBbV
uyQS4T4YuLiMDLRexjkyhdz+0M1ecCfnkS7NXlyQgeV25akPyk1X6v578uDa
Z2TcuQrF/S6ONC4vdIDDvBh3eKf6VwQ+eEysc+3Hjdic9D2SDrXUonGUk7vF
AmIopUSLGqjDqG5P/hAEj4wVihy8g3Be1cPWdOGX2KngkQuH2mTQX8mOPGxq
Xd1pXHVU6FtH8TR9DbK+7DfrcFw3xNdfenlCm0ZSVHLZBNUj1W0gFDd3hUOK
CeZ4EMhWbcnTnW6eRkFJMLiguEEUiKNVLjaAJBuX1V9KxhSVCMmL+uBINWei
y32CyJjrwVSaQxhP8SLkj9I5yLsvLY+EED9LGojD+WhawDhShnv3NnOD5am5
XbogjXtZCgmKgWbNYw5io/J02EGsUopuo7itpMt2Pbfc5hGiJS2DI09EykkF
5C63hnXVyIE0BmUP6EYoYVYZckiEMQho528u2f0GE01PTgbITY18PiSDSI2M
7xon5zbGts9+SPYSxmB8akPCAkc7nw4eQ4g4z25Lvy1svpQZz68UgMh/1HlB
Q/Plam+bGAEG5zrkuAMP8yiHZ13NtaPnFQDBCTJm5niMe9QdgHn8+TMqjLeS
d6tOMtFwkGUN48XzZ/8I26ujcECFISSFvzpGgzCLQAbAdh/43WPKmMGFbN+G
piVDe0TwGyPJmCz3sg80G8atBHwo63MtVVIPRTL9Qk6FqLCoeC9Aoa9gpnQY
pDS9oPOUYw52tLMrW9t1/MCvilrlhpMvZa5T9108E0dxa7dcccqB+JuUWrn/
Ta1CNuS+dEl0dCemAuSpJLjzXli+Mc0BYVKoYnNSfe3swWNJ0ISaA7XuUsFQ
4QE+bQV0BSHWLVtq7HxHboIWyAZZK2Pzo/b0nHKAcCu93ZyKAj+PLLN7yPY0
XEftCqLNyNTHhyI+fboOOe/p9PH0CR8AiUYqga4jXUz8fsrpycMZSpSl5MBQ
zwWpYhglGMbCzVAw7QVY6XaTyguHnFqrQbWwZahZU/2ZNNPd4h5CR/RRNExM
VSrcL5MWhLJH4ZgqhTRMUHfR0lA3DR79ITxyjos2uKqvsC6onEjxnfGMj4Zu
NIo91KEm1iVqNSE6i3jnbRO6DayvgvtngvmJrm54wgBn4KiXnO0ceXITEEnZ
QeCxRdGYcEwX2/CBYVqHScMEfBUCrw6QODqmCvWBTLaiJxGhcbSnly1QLdJf
0odMdTFecKCF4epyYPBm1dZB5JR+TBFRbWUZvqenyQL18lxgr4tQ/U5xHzAo
eecFnf14JnXcPiDNfWik8XEgDijAi+LPfFQmDtxlXzYREQnPOvmug9Klz423
N7Y6kTM2VQJuT7a0OtdDnEnCHKNy9W2CbyWo9fRwQEuJIFS514UXWSjTyT2E
6VAdxOqPQI6LvWOSkKmoT1r7tsokyyf1oYpTjxfp6QTXHF66Lx/FEg8VkR0o
l6RxKNW7csXglbNYbD0m8w7qTFR+s5HzFqmlhbTYfw9mlHC0Fmt41h/Budcm
kE0Lv+vLil6N39QHzvAUPP2s+cxIDbA5gSqSsqbLmcjMUV4y8hj5b2yGdBVm
6loygQ4V+j4BEUBCQyniETAuUVNxER5Kbsmy8WRyr7nBNvtr01QaGugtpDvw
GJeipquJITCcQGi+kGGOp+pyhFm7Hn/IIfgToFzMmt9Pvx/kzOPuOJESxmKu
CKh8bwDu6bcZAsEyKnmoWmiG+1EeHhFGm8jhVT4rFKGjiT3KveTpYyMSwTqS
g+jiqnCfTk7N7c4zHuKckWj3pNPAuDuk0rQTPSIqIj10xO2763DGl+ydBqpV
qH05AI1MkE4exkqNv8d34Uj8+wPy1DpWi03aPlRplg3A+UDvLzZDupWzAVVU
nn361B9ZJ3ESxMuQoGlCuoOn0fh43GQab84WOu6pcXOPNk9bWZPYnNJ9cyo4
CdwwtqbUoDX1hdmUHDU8YHCxH9kNTfujXlhiIR0uk/zogGemHDHCQSx+7Ues
YhMA+d30ae8Kpwwfb/qzW2M6ulgksJJXB5fkPHTKilMC8WSaUJfSkRmz4eeo
l0C2llQ0dIbiUDAPSZUn3D34QPgv1PA49CSxjcTx7ye7b5iEAyhKqs50mVxA
ncxT+45IWpsFT6cikn3k8vzV+Z5/IFuMf1bRn2Mbnh6v7JJiSEVJoB/MhtLx
vkVQmtFb1U7FYES4sFG//3EUf8O13W6nzpRGfhLGJTofEZefhNF/04/0o62H
/DuuTtYIquo9kcDdfjrpplS/7Sv6NQ/duKebCjCPiNfW/Ay8fm2o7MLV9NB6
mCMkQugFNhhA3ieoeNBeRoEDWfXvh+f/70TEXJ7wybGxkJJRpD6KU7iOcCpW
qGMD7H6slFDYCbIbQv7Tkku6I8lvAHzllo5QMYVfX5uiP5/HJ1wzooKPYV3C
ha+3tmn2ftiwMlTw3Dm7DWflyg2yBL+0JrzaIVgafwQtXD6/eSFtvcFvGicS
Wut2Tr/7ozZRutorl93qv5vyFoj+qs2QJmBy8MWJfts6/jGfn6iX9NuZEuz7
dU3u/95RE1m/N7WjAlPyw7MVcLH+zft8qv4blOpVNgI6AAA=

-->
</rfc>