rfc9002.original.xml   rfc9002.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.18 --> -ietf-quic-recovery-34" category="std" consensus="true" number="9002" obsoletes=
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> "" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="tr
<?rfc toc="yes"?> ue" symRefs="true" version="3">
<?rfc sortrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-quic-recovery-34" rel=
<?rfc symrefs="yes"?> "prev"/>
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-quic-recovery-34" category="std" obsoletes="" updates="" submissionType="I
ETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.5.0 -->
<front> <front>
<title abbrev="QUIC Loss Detection">QUIC Loss Detection and Congestion Contr ol</title> <title abbrev="QUIC Loss Detection">QUIC Loss Detection and Congestion Contr ol</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-recovery-34"/> <seriesInfo name="RFC" value="9002"/>
<author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor "> <author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor ">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<email>jri.ietf@gmail.com</email> <email>jri.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="I." surname="Swett" fullname="Ian Swett" role="editor"> <author initials="I." surname="Swett" fullname="Ian Swett" role="editor">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>ianswett@google.com</email> <email>ianswett@google.com</email>
</address> </address>
</author> </author>
<date year="2021" month="January" day="15"/> <date year="2021" month="May"/>
<area>Transport</area> <area>Transport</area>
<workgroup>QUIC</workgroup> <workgroup>QUIC</workgroup>
<keyword>bbr</keyword>
<keyword>delay-sensitive congestion control</keyword>
<keyword>fec</keyword>
<keyword>loss-tolerant congestion control</keyword>
<keyword>next generation</keyword>
<abstract> <abstract>
<t>This document describes loss detection and congestion control mechanism s for <t>This document describes loss detection and congestion control mechanism s for
QUIC.</t> QUIC.</t>
</abstract> </abstract>
<note>
<name>Note to Readers</name>
<t>Discussion of this draft takes place on the QUIC working group mailing
list
(<eref target="mailto:quic@ietf.org">quic@ietf.org</eref>), which is archived at
<eref target="https://mailarchive.ietf.org/arch/search/?email_list=quic"/>.</t>
<t>Working Group information can be found at <eref target="https://github.
com/quicwg"/>; source
code and issues list for this draft can be found at
<eref target="https://github.com/quicwg/base-drafts/labels/-recovery"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>QUIC is a secure general-purpose transport protocol, described in <t>QUIC is a secure, general-purpose transport protocol, described in
<xref target="QUIC-TRANSPORT" format="default"/>). This document describes loss <xref target="QUIC-TRANSPORT" format="default"/>. This document describes loss d
detection and congestion etection and congestion
control mechanisms for QUIC.</t> control mechanisms for QUIC.</t>
</section> </section>
<section anchor="conventions-and-definitions" numbered="true" toc="default"> <section anchor="conventions-and-definitions" numbered="true" toc="default">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as SHOULD</bcp14>",
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target= "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMEND
"RFC8174" format="default"/> when, and only when, they ED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this
appear in all capitals, as shown here.</t> document are to be interpreted as described in BCP 14 <xref target="RFC2119" for
mat="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
<t>Definitions of terms that are used in this document:</t> <t>Definitions of terms that are used in this document:</t>
<dl> <dl>
<dt> <dt>Ack-eliciting frames:</dt>
Ack-eliciting frames: </dt>
<dd> <dd>
<t>All frames other than ACK, PADDING, and CONNECTION_CLOSE are consid ered <t>All frames other than ACK, PADDING, and CONNECTION_CLOSE are consid ered
ack-eliciting.</t> ack-eliciting.</t>
</dd> </dd>
<dt> <dt>Ack-eliciting packets:</dt>
Ack-eliciting packets: </dt>
<dd> <dd>
<t>Packets that contain ack-eliciting frames elicit an ACK from the re ceiver <t>Packets that contain ack-eliciting frames elicit an ACK from the re ceiver
within the maximum acknowledgment delay and are called ack-eliciting packets.</t > within the maximum acknowledgment delay and are called ack-eliciting packets.</t >
</dd> </dd>
<dt> <dt>In-flight packets:</dt>
In-flight packets: </dt>
<dd> <dd>
<t>Packets are considered in-flight when they are ack-eliciting or con tain a <t>Packets are considered in flight when they are ack-eliciting or con tain a
PADDING frame, and they have been sent but are not acknowledged, declared PADDING frame, and they have been sent but are not acknowledged, declared
lost, or discarded along with old keys.</t> lost, or discarded along with old keys.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="design-of-the-quic-transmission-machinery" numbered="true" toc="default"> <section anchor="design-of-the-quic-transmission-machinery" numbered="true" toc="default">
<name>Design of the QUIC Transmission Machinery</name> <name>Design of the QUIC Transmission Machinery</name>
<t>All transmissions in QUIC are sent with a packet-level header, which in dicates <t>All transmissions in QUIC are sent with a packet-level header, which in dicates
the encryption level and includes a packet sequence number (referred to below as the encryption level and includes a packet sequence number (referred to below as
a packet number). The encryption level indicates the packet number space, as a packet number). The encryption level indicates the packet number space, as
described in Section 12.3 in <xref target="QUIC-TRANSPORT" format="default"/>. Packet numbers never repeat described in <xref section="12.3" sectionFormat="of" target="QUIC-TRANSPORT" for mat="default"/>. Packet numbers never repeat
within a packet number space for the lifetime of a connection. Packet numbers within a packet number space for the lifetime of a connection. Packet numbers
are sent in monotonically increasing order within a space, preventing ambiguity. are sent in monotonically increasing order within a space, preventing ambiguity.
It is permitted for some packet numbers to never be used, leaving intentional It is permitted for some packet numbers to never be used, leaving intentional
gaps.</t> gaps.</t>
<t>This design obviates the need for disambiguating between transmissions and <t>This design obviates the need for disambiguating between transmissions and
retransmissions; this eliminates significant complexity from QUIC's retransmissions; this eliminates significant complexity from QUIC's
interpretation of TCP loss detection mechanisms.</t> interpretation of TCP loss detection mechanisms.</t>
<t>QUIC packets can contain multiple frames of different types. The recove ry <t>QUIC packets can contain multiple frames of different types. The recove ry
mechanisms ensure that data and frames that need reliable delivery are mechanisms ensure that data and frames that need reliable delivery are
acknowledged or declared lost and sent in new packets as necessary. The types acknowledged or declared lost and sent in new packets as necessary. The types
of frames contained in a packet affect recovery and congestion control logic:</t > of frames contained in a packet affect recovery and congestion control logic:</t >
<ul spacing="normal"> <ul spacing="normal">
<li>All packets are acknowledged, though packets that contain no <li>All packets are acknowledged, though packets that contain no
ack-eliciting frames are only acknowledged along with ack-eliciting ack-eliciting frames are only acknowledged along with ack-eliciting
packets.</li> packets.</li>
<li>Long header packets that contain CRYPTO frames are critical to the <li>Long header packets that contain CRYPTO frames are critical to the
performance of the QUIC handshake and use shorter timers for performance of the QUIC handshake and use shorter timers for
acknowledgment.</li> acknowledgment.</li>
<li>Packets containing frames besides ACK or CONNECTION_CLOSE frames cou nt toward <li>Packets containing frames besides ACK or CONNECTION_CLOSE frames cou nt toward
congestion control limits and are considered in-flight.</li> congestion control limits and are considered to be in flight.</li>
<li>PADDING frames cause packets to contribute toward bytes in flight wi thout <li>PADDING frames cause packets to contribute toward bytes in flight wi thout
directly causing an acknowledgment to be sent.</li> directly causing an acknowledgment to be sent.</li>
</ul> </ul>
</section> </section>
<section anchor="relevant-differences-between-quic-and-tcp" numbered="true" toc="default"> <section anchor="relevant-differences-between-quic-and-tcp" numbered="true" toc="default">
<name>Relevant Differences Between QUIC and TCP</name> <name>Relevant Differences between QUIC and TCP</name>
<t>Readers familiar with TCP's loss detection and congestion control will find <t>Readers familiar with TCP's loss detection and congestion control will find
algorithms here that parallel well-known TCP ones. However, protocol differences algorithms here that parallel well-known TCP ones. However, protocol differences
between QUIC and TCP contribute to algorithmic differences. These protocol between QUIC and TCP contribute to algorithmic differences. These protocol
differences are briefly described below.</t> differences are briefly described below.</t>
<section anchor="separate-packet-number-spaces" numbered="true" toc="defau lt"> <section anchor="separate-packet-number-spaces" numbered="true" toc="defau lt">
<name>Separate Packet Number Spaces</name> <name>Separate Packet Number Spaces</name>
<t>QUIC uses separate packet number spaces for each encryption level, ex <t>QUIC uses separate packet number spaces for each encryption level,
cept 0-RTT except 0-RTT and all generations of 1-RTT keys use the same packet
and all generations of 1-RTT keys use the same packet number space. Separate number space. Separate packet number spaces ensures that the
packet number spaces ensures acknowledgment of packets sent with one level of acknowledgment of packets sent with one level of encryption will not
encryption will not cause spurious retransmission of packets sent with a cause spurious retransmission of packets sent with a different
different encryption level. Congestion control and round-trip time (RTT) encryption level. Congestion control and round-trip time (RTT)
measurement are unified across packet number spaces.</t> measurement are unified across packet number spaces.</t>
</section> </section>
<section anchor="monotonically-increasing-packet-numbers" numbered="true" toc="default"> <section anchor="monotonically-increasing-packet-numbers" numbered="true" toc="default">
<name>Monotonically Increasing Packet Numbers</name> <name>Monotonically Increasing Packet Numbers</name>
<t>TCP conflates transmission order at the sender with delivery order at the <t>TCP conflates transmission order at the sender with delivery order at the
receiver, resulting in the retransmission ambiguity problem receiver, resulting in the retransmission ambiguity problem
(<xref target="RETRANSMISSION" format="default"/>). QUIC separates transmission order from delivery order: <xref target="RETRANSMISSION" format="default"/>. QUIC separates transmission o rder from delivery order:
packet numbers indicate transmission order, and delivery order is determined by packet numbers indicate transmission order, and delivery order is determined by
the stream offsets in STREAM frames.</t> the stream offsets in STREAM frames.</t>
<t>QUIC's packet number is strictly increasing within a packet number sp ace, <t>QUIC's packet number is strictly increasing within a packet number sp ace
and directly encodes transmission order. A higher packet number signifies and directly encodes transmission order. A higher packet number signifies
that the packet was sent later, and a lower packet number signifies that that the packet was sent later, and a lower packet number signifies that
the packet was sent earlier. When a packet containing ack-eliciting the packet was sent earlier. When a packet containing ack-eliciting
frames is detected lost, QUIC includes necessary frames in a new packet frames is detected lost, QUIC includes necessary frames in a new packet
with a new packet number, removing ambiguity about which packet is with a new packet number, removing ambiguity about which packet is
acknowledged when an ACK is received. Consequently, more accurate RTT acknowledged when an ACK is received. Consequently, more accurate RTT
measurements can be made, spurious retransmissions are trivially detected, and measurements can be made, spurious retransmissions are trivially detected, and
mechanisms such as Fast Retransmit can be applied universally, based only on mechanisms such as Fast Retransmit can be applied universally, based only on
packet number.</t> packet number.</t>
<t>This design point significantly simplifies loss detection mechanisms for QUIC. <t>This design point significantly simplifies loss detection mechanisms for QUIC.
Most TCP mechanisms implicitly attempt to infer transmission ordering based on Most TCP mechanisms implicitly attempt to infer transmission ordering based on
TCP sequence numbers - a non-trivial task, especially when TCP timestamps are TCP sequence numbers -- a nontrivial task, especially when TCP timestamps are
not available.</t> not available.</t>
</section> </section>
<section anchor="clearer-loss-epoch" numbered="true" toc="default"> <section anchor="clearer-loss-epoch" numbered="true" toc="default">
<name>Clearer Loss Epoch</name> <name>Clearer Loss Epoch</name>
<t>QUIC starts a loss epoch when a packet is lost. The loss epoch ends w hen any <t>QUIC starts a loss epoch when a packet is lost. The loss epoch ends w hen any
packet sent after the start of the epoch is acknowledged. TCP waits for the gap packet sent after the start of the epoch is acknowledged. TCP waits for the gap
in the sequence number space to be filled, and so if a segment is lost multiple in the sequence number space to be filled, and so if a segment is lost multiple
times in a row, the loss epoch may not end for several round trips. Because both times in a row, the loss epoch may not end for several round trips. Because both
should reduce their congestion windows only once per epoch, QUIC will do it once should reduce their congestion windows only once per epoch, QUIC will do it once
for every round trip that experiences loss, while TCP may only do it once across for every round trip that experiences loss, while TCP may only do it once across
multiple round trips.</t> multiple round trips.</t>
</section> </section>
<section anchor="no-reneging" numbered="true" toc="default"> <section anchor="no-reneging" numbered="true" toc="default">
<name>No Reneging</name> <name>No Reneging</name>
<t>QUIC ACK frames contain information similar to that in TCP Selective <t>QUIC ACK frames contain information similar to that in TCP Selective
Acknowledgements (SACKs, <xref target="RFC2018" format="default"/>). However, QU Acknowledgments (SACKs) <xref target="RFC2018" format="default"/>. However, QUIC
IC does not allow a packet does not allow a packet
acknowledgement to be reneged, greatly simplifying implementations on both sides acknowledgment to be reneged, greatly simplifying implementations on both sides
and reducing memory pressure on the sender.</t> and reducing memory pressure on the sender.</t>
</section> </section>
<section anchor="more-ack-ranges" numbered="true" toc="default"> <section anchor="more-ack-ranges" numbered="true" toc="default">
<name>More ACK Ranges</name> <name>More ACK Ranges</name>
<t>QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges. In hi <t>QUIC supports many ACK ranges, as opposed to TCP's three SACK ranges.
gh loss In
environments, this speeds recovery, reduces spurious retransmits, and ensures high-loss environments, this speeds recovery, reduces spurious retransmits, and
forward progress without relying on timeouts.</t> ensures forward progress without relying on timeouts.</t>
</section> </section>
<section anchor="explicit-correction-for-delayed-acknowledgments" numbered ="true" toc="default"> <section anchor="explicit-correction-for-delayed-acknowledgments" numbered ="true" toc="default">
<name>Explicit Correction For Delayed Acknowledgments</name> <name>Explicit Correction for Delayed Acknowledgments</name>
<t>QUIC endpoints measure the delay incurred between when a packet is re ceived and <t>QUIC endpoints measure the delay incurred between when a packet is re ceived and
when the corresponding acknowledgment is sent, allowing a peer to maintain a when the corresponding acknowledgment is sent, allowing a peer to maintain a
more accurate round-trip time estimate; see Section 13.2 of <xref target="QUIC-T RANSPORT" format="default"/>.</t> more accurate RTT estimate; see <xref section="13.2" sectionFormat="of" target=" QUIC-TRANSPORT" format="default"/>.</t>
</section> </section>
<section anchor="probe-timeout-replaces-rto-and-tlp" numbered="true" toc=" default"> <section anchor="probe-timeout-replaces-rto-and-tlp" numbered="true" toc=" default">
<name>Probe Timeout Replaces RTO and TLP</name> <name>Probe Timeout Replaces RTO and TLP</name>
<t>QUIC uses a probe timeout (PTO; see <xref target="pto" format="defaul <t>QUIC uses a probe timeout (PTO; see <xref target="pto" format="defaul
t"/>), with a timer based on TCP's RTO t"/>), with a timer based on TCP's
computation; see <xref target="RFC6297" format="default"/>. QUIC's PTO includes retransmission timeout (RTO) computation; see <xref target="RFC6298" format="def
the peer's maximum expected ault"/>. QUIC's PTO includes
acknowledgment delay instead of using a fixed minimum timeout.</t> the peer's maximum expected acknowledgment delay instead of using a fixed
<t>Similar to the RACK-TLP loss detection algorithm for TCP minimum timeout.</t>
(<xref target="RACK" format="default"/>), QUIC does not collapse the congestion <t>Similar to the RACK-TLP loss detection algorithm for TCP <xref target
window ="RFC8985" format="default"/>, QUIC does
when the PTO expires, since a single packet loss at the tail does not indicate not collapse the congestion window when the PTO expires, since a single packet
persistent congestion. Instead, QUIC collapses the congestion window when loss at the tail does not indicate persistent congestion. Instead, QUIC
persistent congestion is declared; see <xref target="persistent-congestion" form collapses the congestion window when persistent congestion is declared; see
at="default"/>. In doing this, <xref target="persistent-congestion" format="default"/>. In doing this, QUIC avo
QUIC avoids unnecessary congestion window reductions, obviating the need for ids unnecessary congestion
correcting mechanisms such as F-RTO (<xref target="RFC5682" format="default"/>). window reductions, obviating the need for correcting mechanisms such as Forward
Since QUIC does not RTO-Recovery (F-RTO) <xref target="RFC5682" format="default"/>. Since QUIC does
collapse the congestion window on a PTO expiration, a QUIC sender is not not collapse the congestion
limited from sending more in-flight packets after a PTO expiration if it still window on a PTO expiration, a QUIC sender is not limited from sending more
has available congestion window. This occurs when a sender is in-flight packets after a PTO expiration if it still has available congestion
application-limited and the PTO timer expires. This is more aggressive than window. This occurs when a sender is application limited and the PTO timer
TCP's RTO mechanism when application-limited, but identical when not expires. This is more aggressive than TCP's RTO mechanism when application
application-limited.</t> limited, but identical when not application limited.</t>
<t>QUIC allows probe packets to temporarily exceed the congestion window whenever <t>QUIC allows probe packets to temporarily exceed the congestion window whenever
the timer expires.</t> the timer expires.</t>
</section> </section>
<section anchor="the-minimum-congestion-window-is-two-packets" numbered="t rue" toc="default"> <section anchor="the-minimum-congestion-window-is-two-packets" numbered="t rue" toc="default">
<name>The Minimum Congestion Window is Two Packets</name> <name>The Minimum Congestion Window Is Two Packets</name>
<t>TCP uses a minimum congestion window of one packet. However, loss of <t>TCP uses a minimum congestion window of one packet. However, loss of
that single packet means that the sender needs to waiting for a PTO that single
(<xref target="pto" format="default"/>) to recover, which can be much longer tha packet means that the sender needs to wait for a PTO to recover (<xref target="p
n a round-trip time. to" format="default"/>), which
Sending a single ack-eliciting packet also increases the chances of incurring can be much longer than an RTT. Sending a single ack-eliciting packet also
additional latency when a receiver delays its acknowledgment.</t> increases the chances of incurring additional latency when a receiver delays its
acknowledgment.</t>
<t>QUIC therefore recommends that the minimum congestion window be two <t>QUIC therefore recommends that the minimum congestion window be two
packets. While this increases network load, it is considered safe, since the packets. While this increases network load, it is considered safe since the
sender will still reduce its sending rate exponentially under persistent sender will still reduce its sending rate exponentially under persistent
congestion (<xref target="pto" format="default"/>).</t> congestion (<xref target="pto" format="default"/>).</t>
</section> </section>
<section anchor="handshake-packets-are-not-special" numbered="true" toc="d
efault">
<name>Handshake Packets Are Not Special</name>
<t>TCP treats the loss of SYN or SYN-ACK packet as persistent congestion
and
reduces the congestion window to one packet; see <xref target="RFC5681" format="
default"/>. QUIC treats loss
of a packet containing handshake data the same as other losses.</t>
</section>
</section> </section>
<section anchor="compute-rtt" numbered="true" toc="default"> <section anchor="compute-rtt" numbered="true" toc="default">
<name>Estimating the Round-Trip Time</name> <name>Estimating the Round-Trip Time</name>
<t>At a high level, an endpoint measures the time from when a packet was s ent to <t>At a high level, an endpoint measures the time from when a packet was s ent to
when it is acknowledged as a round-trip time (RTT) sample. The endpoint uses when it is acknowledged as an RTT sample. The endpoint uses RTT samples and
RTT samples and peer-reported host delays (see Section 13.2 of peer-reported host delays (see <xref section="13.2" sectionFormat="of" target="Q
<xref target="QUIC-TRANSPORT" format="default"/>) to generate a statistical desc UIC-TRANSPORT" format="default"/>) to generate a
ription of the network statistical description of the network path's RTT. An endpoint computes the
path's RTT. An endpoint computes the following three values for each path: following three values for each path: the minimum value over a period of time
the minimum value over a period of time (min_rtt), an (min_rtt), an exponentially weighted moving average (smoothed_rtt), and the mean
exponentially-weighted moving average (smoothed_rtt), and the mean deviation deviation (referred to as "variation" in the rest of this document) in the
(referred to as "variation" in the rest of this document) in the observed RTT observed RTT samples (rttvar).</t>
samples (rttvar).</t>
<section anchor="latest-rtt" numbered="true" toc="default"> <section anchor="latest-rtt" numbered="true" toc="default">
<name>Generating RTT samples</name> <name>Generating RTT Samples</name>
<t>An endpoint generates an RTT sample on receiving an ACK frame that me ets the <t>An endpoint generates an RTT sample on receiving an ACK frame that me ets the
following two conditions:</t> following two conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the largest acknowledged packet number is newly acknowledged, and< /li> <li>the largest acknowledged packet number is newly acknowledged, and< /li>
<li>at least one of the newly acknowledged packets was ack-eliciting.< /li> <li>at least one of the newly acknowledged packets was ack-eliciting.< /li>
</ul> </ul>
<t>The RTT sample, latest_rtt, is generated as the time elapsed since th e largest <t>The RTT sample, latest_rtt, is generated as the time elapsed since th e largest
acknowledged packet was sent:</t> acknowledged packet was sent:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
latest_rtt = ack_time - send_time_of_largest_acked latest_rtt = ack_time - send_time_of_largest_acked
]]></artwork> ]]></sourcecode>
<t>An RTT sample is generated using only the largest acknowledged packet in the <t>An RTT sample is generated using only the largest acknowledged packet in the
received ACK frame. This is because a peer reports acknowledgment delays for received ACK frame. This is because a peer reports acknowledgment delays for
only the largest acknowledged packet in an ACK frame. While the reported only the largest acknowledged packet in an ACK frame. While the reported
acknowledgment delay is not used by the RTT sample measurement, it is used to acknowledgment delay is not used by the RTT sample measurement, it is used to
adjust the RTT sample in subsequent computations of smoothed_rtt and rttvar adjust the RTT sample in subsequent computations of smoothed_rtt and rttvar
(<xref target="smoothed-rtt" format="default"/>).</t> (<xref target="smoothed-rtt" format="default"/>).</t>
<t>To avoid generating multiple RTT samples for a single packet, an ACK frame <t>To avoid generating multiple RTT samples for a single packet, an ACK frame
SHOULD NOT be used to update RTT estimates if it does not newly acknowledge the <bcp14>SHOULD NOT</bcp14> be used to update RTT estimates if it does not newly a cknowledge the
largest acknowledged packet.</t> largest acknowledged packet.</t>
<t>An RTT sample MUST NOT be generated on receiving an ACK frame that do es not <t>An RTT sample <bcp14>MUST NOT</bcp14> be generated on receiving an AC K frame that does not
newly acknowledge at least one ack-eliciting packet. A peer usually does not newly acknowledge at least one ack-eliciting packet. A peer usually does not
send an ACK frame when only non-ack-eliciting packets are received. Therefore send an ACK frame when only non-ack-eliciting packets are received. Therefore,
an ACK frame that contains acknowledgments for only non-ack-eliciting packets an ACK frame that contains acknowledgments for only non-ack-eliciting packets
could include an arbitrarily large ACK Delay value. Ignoring could include an arbitrarily large ACK Delay value. Ignoring
such ACK frames avoids complications in subsequent smoothed_rtt and rttvar such ACK frames avoids complications in subsequent smoothed_rtt and rttvar
computations.</t> computations.</t>
<t>A sender might generate multiple RTT samples per RTT when multiple AC K frames <t>A sender might generate multiple RTT samples per RTT when multiple AC K frames
are received within an RTT. As suggested in <xref target="RFC6298" format="defa ult"/>, doing so might result are received within an RTT. As suggested in <xref target="RFC6298" format="defa ult"/>, doing so might result
in inadequate history in smoothed_rtt and rttvar. Ensuring that RTT estimates in inadequate history in smoothed_rtt and rttvar. Ensuring that RTT estimates
retain sufficient history is an open research question.</t> retain sufficient history is an open research question.</t>
</section> </section>
<section anchor="min-rtt" numbered="true" toc="default"> <section anchor="min-rtt" numbered="true" toc="default">
<name>Estimating min_rtt</name> <name>Estimating min_rtt</name>
<t>min_rtt is the sender's estimate of the minimum RTT observed for a gi ven network <t>min_rtt is the sender's estimate of the minimum RTT observed for a gi ven network
path over a period of time. In this document, min_rtt is used by loss detection path over a period of time. In this document, min_rtt is used by loss detection
to reject implausibly small rtt samples.</t> to reject implausibly small RTT samples.</t>
<t>min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rt <t>min_rtt <bcp14>MUST</bcp14> be set to the latest_rtt on the first RTT
t MUST be sample. min_rtt <bcp14>MUST</bcp14> be
set to the lesser of min_rtt and latest_rtt (<xref target="latest-rtt" format="d efault"/>) on all other set to the lesser of min_rtt and latest_rtt (<xref target="latest-rtt" format="d efault"/>) on all other
samples.</t> samples.</t>
<t>An endpoint uses only locally observed times in computing the min_rtt and does <t>An endpoint uses only locally observed times in computing the min_rtt and does
not adjust for acknowledgment delays reported by the peer. Doing so allows the not adjust for acknowledgment delays reported by the peer. Doing so allows the
endpoint to set a lower bound for the smoothed_rtt based entirely on what it endpoint to set a lower bound for the smoothed_rtt based entirely on what it
observes (see <xref target="smoothed-rtt" format="default"/>), and limits potent observes (see <xref target="smoothed-rtt" format="default"/>) and limits potenti
ial underestimation due to al underestimation due to
erroneously-reported delays by the peer.</t> erroneously reported delays by the peer.</t>
<t>The RTT for a network path may change over time. If a path's actual R TT <t>The RTT for a network path may change over time. If a path's actual R TT
decreases, the min_rtt will adapt immediately on the first low sample. If the decreases, the min_rtt will adapt immediately on the first low sample. If the
path's actual RTT increases however, the min_rtt will not adapt to it, allowing path's actual RTT increases, however, the min_rtt will not adapt to it, allowing
future RTT samples that are smaller than the new RTT to be included in future RTT samples that are smaller than the new RTT to be included in
smoothed_rtt.</t> smoothed_rtt.</t>
<t>Endpoints SHOULD set the min_rtt to the newest RTT sample after persi <t>Endpoints <bcp14>SHOULD</bcp14> set the min_rtt to the newest RTT sam
stent ple after persistent
congestion is established. This is to allow a connection to reset its estimate congestion is established. This avoids repeatedly declaring persistent
of min_rtt and smoothed_rtt (<xref target="smoothed-rtt" format="default"/>) aft congestion when the RTT increases. This also allows a connection to reset
er a disruptive network event, its estimate of min_rtt and smoothed_rtt after a disruptive network event;
and because it is possible that an increase in path delay resulted in persistent see <xref target="smoothed-rtt" format="default"/>.</t>
congestion being incorrectly declared.</t> <t>Endpoints <bcp14>MAY</bcp14> reestablish the min_rtt at other times i
<t>Endpoints MAY re-establish the min_rtt at other times in the connecti n the connection, such as
on, such as
when traffic volume is low and an acknowledgment is received with a low when traffic volume is low and an acknowledgment is received with a low
acknowledgment delay. Implementations SHOULD NOT refresh the min_rtt acknowledgment delay. Implementations <bcp14>SHOULD NOT</bcp14> refresh the min_
value too often, since the actual minimum RTT of the path is not rtt
value too often since the actual minimum RTT of the path is not
frequently observable.</t> frequently observable.</t>
</section> </section>
<section anchor="smoothed-rtt" numbered="true" toc="default"> <section anchor="smoothed-rtt" numbered="true" toc="default">
<name>Estimating smoothed_rtt and rttvar</name> <name>Estimating smoothed_rtt and rttvar</name>
<t>smoothed_rtt is an exponentially-weighted moving average of an endpoi nt's RTT <t>smoothed_rtt is an exponentially weighted moving average of an endpoi nt's RTT
samples, and rttvar estimates the variation in the RTT samples using a mean samples, and rttvar estimates the variation in the RTT samples using a mean
variation.</t> variation.</t>
<t>The calculation of smoothed_rtt uses RTT samples after adjusting them for <t>The calculation of smoothed_rtt uses RTT samples after adjusting them for
acknowledgment delays. These delays are decoded from the ACK Delay field of acknowledgment delays. These delays are decoded from the ACK Delay field of
ACK frames as described in Section 19.3 of <xref target="QUIC-TRANSPORT" format= "default"/>.</t> ACK frames as described in <xref section="19.3" sectionFormat="of" target="QUIC- TRANSPORT" format="default"/>.</t>
<t>The peer might report acknowledgment delays that are larger than the peer's <t>The peer might report acknowledgment delays that are larger than the peer's
max_ack_delay during the handshake (Section 13.2.1 of <xref target="QUIC-TRANSPO max_ack_delay during the handshake (<xref section="13.2.1" sectionFormat="of" ta
RT" format="default"/>). To rget="QUIC-TRANSPORT" format="default"/>). To
account for this, the endpoint SHOULD ignore max_ack_delay until the handshake account for this, the endpoint <bcp14>SHOULD</bcp14> ignore max_ack_delay until
is confirmed, as defined in Section 4.1.2 of <xref target="QUIC-TLS" format="def the handshake
ault"/>. When they occur, is confirmed, as defined in <xref section="4.1.2" sectionFormat="of" target="QUI
C-TLS" format="default"/>. When they occur,
these large acknowledgment delays are likely to be non-repeating and limited to these large acknowledgment delays are likely to be non-repeating and limited to
the handshake. The endpoint can therefore use them without limiting them to the the handshake. The endpoint can therefore use them without limiting them to the
max_ack_delay, avoiding unnecessary inflation of the RTT estimate.</t> max_ack_delay, avoiding unnecessary inflation of the RTT estimate.</t>
<t>Note that a large acknowledgment delay can result in a substantially inflated <t>Note that a large acknowledgment delay can result in a substantially inflated
smoothed_rtt, if there is either an error in the peer's reporting of the smoothed_rtt if there is an error either in the peer's reporting of the
acknowledgment delay or in the endpoint's min_rtt estimate. Therefore, prior acknowledgment delay or in the endpoint's min_rtt estimate. Therefore, prior
to handshake confirmation, an endpoint MAY ignore RTT samples if adjusting to handshake confirmation, an endpoint <bcp14>MAY</bcp14> ignore RTT samples if adjusting
the RTT sample for acknowledgment delay causes the sample to be less than the the RTT sample for acknowledgment delay causes the sample to be less than the
min_rtt.</t> min_rtt.</t>
<t>After the handshake is confirmed, any acknowledgment delays reported by the <t>After the handshake is confirmed, any acknowledgment delays reported by the
peer that are greater than the peer's max_ack_delay are attributed to peer that are greater than the peer's max_ack_delay are attributed to
unintentional but potentially repeating delays, such as scheduler latency at the unintentional but potentially repeating delays, such as scheduler latency at the
peer or loss of previous acknowledgments. Excess delays could also be due to peer or loss of previous acknowledgments. Excess delays could also be due to
a non-compliant receiver. Therefore, these extra delays are considered a noncompliant receiver. Therefore, these extra delays are considered
effectively part of path delay and incorporated into the RTT estimate.</t> effectively part of path delay and incorporated into the RTT estimate.</t>
<t>Therefore, when adjusting an RTT sample using peer-reported acknowled gment <t>Therefore, when adjusting an RTT sample using peer-reported acknowled gment
delays, an endpoint:</t> delays, an endpoint:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>MAY ignore the acknowledgment delay for Initial packets, since the <li><bcp14>MAY</bcp14> ignore the acknowledgment delay for Initial pac
se kets, since these
acknowledgments are not delayed by the peer (Section 13.2.1 of acknowledgments are not delayed by the peer (<xref section="13.2.1" sectionForma
<xref target="QUIC-TRANSPORT" format="default"/>);</li> t="of" target="QUIC-TRANSPORT" format="default"/>);</li>
<li>SHOULD ignore the peer's max_ack_delay until the handshake is conf <li><bcp14>SHOULD</bcp14> ignore the peer's max_ack_delay until the ha
irmed;</li> ndshake is confirmed;</li>
<li>MUST use the lesser of the acknowledgment delay and the peer's max <li><bcp14>MUST</bcp14> use the lesser of the acknowledgment delay and
_ack_delay the peer's max_ack_delay
after the handshake is confirmed; and</li> after the handshake is confirmed; and</li>
<li>MUST NOT subtract the acknowledgment delay from the RTT sample if the <li><bcp14>MUST NOT</bcp14> subtract the acknowledgment delay from the RTT sample if the
resulting value is smaller than the min_rtt. This limits the underestimation resulting value is smaller than the min_rtt. This limits the underestimation
of the smoothed_rtt due to a misreporting peer.</li> of the smoothed_rtt due to a misreporting peer.</li>
</ul> </ul>
<t>Additionally, an endpoint might postpone the processing of acknowledg ments when <t>Additionally, an endpoint might postpone the processing of acknowledg ments when
the corresponding decryption keys are not immediately available. For example, a the corresponding decryption keys are not immediately available. For example, a
client might receive an acknowledgment for a 0-RTT packet that it cannot client might receive an acknowledgment for a 0-RTT packet that it cannot
decrypt because 1-RTT packet protection keys are not yet available to it. In decrypt because 1-RTT packet protection keys are not yet available to it. In
such cases, an endpoint SHOULD subtract such local delays from its RTT sample such cases, an endpoint <bcp14>SHOULD</bcp14> subtract such local delays from it s RTT sample
until the handshake is confirmed.</t> until the handshake is confirmed.</t>
<t>Similar to <xref target="RFC6298" format="default"/>, smoothed_rtt an d rttvar are computed as follows.</t> <t>Similar to <xref target="RFC6298" format="default"/>, smoothed_rtt an d rttvar are computed as follows.</t>
<t>An endpoint initializes the RTT estimator during connection establish ment and <t>An endpoint initializes the RTT estimator during connection establish ment and
when the estimator is reset during connection migration; see Section 9.4 of when the estimator is reset during connection migration; see <xref section="9.4"
<xref target="QUIC-TRANSPORT" format="default"/>. Before any RTT samples are ava sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>. Before any RTT s
ilable for a new path or when amples are available for a new path or when
the estimator is reset, the estimator is initialized using the initial RTT; see the estimator is reset, the estimator is initialized using the initial RTT; see
<xref target="pto-handshake" format="default"/>.</t> <xref target="pto-handshake" format="default"/>.</t>
<t>smoothed_rtt and rttvar are initialized as follows, where kInitialRtt contains <t>smoothed_rtt and rttvar are initialized as follows, where kInitialRtt contains
the initial RTT value:</t> the initial RTT value:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
smoothed_rtt = kInitialRtt smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2 rttvar = kInitialRtt / 2
]]></artwork> ]]></sourcecode>
<t>RTT samples for the network path are recorded in latest_rtt; see <t>RTT samples for the network path are recorded in latest_rtt; see
<xref target="latest-rtt" format="default"/>. On the first RTT sample after init ialization, the estimator is <xref target="latest-rtt" format="default"/>. On the first RTT sample after init ialization, the estimator is
reset using that sample. This ensures that the estimator retains no history of reset using that sample. This ensures that the estimator retains no history of
past samples.</t> past samples. Packets sent on other paths do not contribute RTT samples to the
current path, as described in <xref section="9.4" sectionFormat="of" target="QUI
C-TRANSPORT" format="default"/>.</t>
<t>On the first RTT sample after initialization, smoothed_rtt and rttvar are set as <t>On the first RTT sample after initialization, smoothed_rtt and rttvar are set as
follows:</t> follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
smoothed_rtt = latest_rtt smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2 rttvar = latest_rtt / 2
]]></artwork> ]]></sourcecode>
<t>On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: </t> <t>On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
ack_delay = decoded acknowledgment delay from ACK frame ack_delay = decoded acknowledgment delay from ACK frame
if (handshake confirmed): if (handshake confirmed):
ack_delay = min(ack_delay, max_ack_delay) ack_delay = min(ack_delay, max_ack_delay)
adjusted_rtt = latest_rtt adjusted_rtt = latest_rtt
if (min_rtt + ack_delay < latest_rtt): if (latest_rtt >= min_rtt + ack_delay):
adjusted_rtt = latest_rtt - ack_delay adjusted_rtt = latest_rtt - ack_delay
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt) rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="loss-detection" numbered="true" toc="default"> <section anchor="loss-detection" numbered="true" toc="default">
<name>Loss Detection</name> <name>Loss Detection</name>
<t>QUIC senders use acknowledgments to detect lost packets, and a probe <t>QUIC senders use acknowledgments to detect lost packets and a PTO to en
time out (see <xref target="pto" format="default"/>) to ensure acknowledgments a sure
re received. This section acknowledgments are received; see <xref target="pto" format="default"/>. This se
provides a description of these algorithms.</t> ction provides a description
of these algorithms.</t>
<t>If a packet is lost, the QUIC transport needs to recover from that loss , such <t>If a packet is lost, the QUIC transport needs to recover from that loss , such
as by retransmitting the data, sending an updated frame, or discarding the as by retransmitting the data, sending an updated frame, or discarding the
frame. For more information, see Section 13.3 of <xref target="QUIC-TRANSPORT" format="default"/>.</t> frame. For more information, see <xref section="13.3" sectionFormat="of" target ="QUIC-TRANSPORT" format="default"/>.</t>
<t>Loss detection is separate per packet number space, unlike RTT measurem ent and <t>Loss detection is separate per packet number space, unlike RTT measurem ent and
congestion control, because RTT and congestion control are properties of the congestion control, because RTT and congestion control are properties of the
path, whereas loss detection also relies upon key availability.</t> path, whereas loss detection also relies upon key availability.</t>
<section anchor="ack-loss-detection" numbered="true" toc="default"> <section anchor="ack-loss-detection" numbered="true" toc="default">
<name>Acknowledgment-Based Detection</name> <name>Acknowledgment-Based Detection</name>
<t>Acknowledgment-based loss detection implements the spirit of TCP's Fa st <t>Acknowledgment-based loss detection implements the spirit of TCP's Fa st
Retransmit (<xref target="RFC5681" format="default"/>), Early Retransmit (<xref Retransmit <xref target="RFC5681" format="default"/>, Early Retransmit <xref tar
target="RFC5827" format="default"/>), FACK (<xref target="FACK" format="default" get="RFC5827" format="default"/>, Forward Acknowledgment
/>), <xref target="FACK" format="default"/>, SACK loss recovery <xref target="RFC6675
SACK loss recovery (<xref target="RFC6675" format="default"/>), and RACK-TLP (<x " format="default"/>, and RACK-TLP <xref target="RFC8985" format="default"/>. Th
ref target="RACK" format="default"/>). This is
section provides an overview of how these algorithms are implemented in QUIC.</t > section provides an overview of how these algorithms are implemented in QUIC.</t >
<t>A packet is declared lost if it meets all the following conditions:</ t> <t>A packet is declared lost if it meets all of the following conditions :</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The packet is unacknowledged, in-flight, and was sent prior to an <li>The packet is unacknowledged, in flight, and was sent prior to an
acknowledged packet.</li> acknowledged packet.</li>
<li>The packet was sent kPacketThreshold packets before an acknowledge d packet <li>The packet was sent kPacketThreshold packets before an acknowledge d packet
(<xref target="packet-threshold" format="default"/>), or it was sent long enough in the past (<xref target="packet-threshold" format="default"/>), or it was sent long enough in the past
(<xref target="time-threshold" format="default"/>).</li> (<xref target="time-threshold" format="default"/>).</li>
</ul> </ul>
<t>The acknowledgment indicates that a packet sent later was delivered, and the <t>The acknowledgment indicates that a packet sent later was delivered, and the
packet and time thresholds provide some tolerance for packet reordering.</t> packet and time thresholds provide some tolerance for packet reordering.</t>
<t>Spuriously declaring packets as lost leads to unnecessary retransmiss ions and <t>Spuriously declaring packets as lost leads to unnecessary retransmiss ions and
may result in degraded performance due to the actions of the congestion may result in degraded performance due to the actions of the congestion
controller upon detecting loss. Implementations can detect spurious controller upon detecting loss. Implementations can detect spurious
retransmissions and increase the reordering threshold in packets or time to retransmissions and increase the packet or time reordering threshold to
reduce future spurious retransmissions and loss events. Implementations with reduce future spurious retransmissions and loss events. Implementations with
adaptive time thresholds MAY choose to start with smaller initial reordering adaptive time thresholds <bcp14>MAY</bcp14> choose to start with smaller initial reordering
thresholds to minimize recovery latency.</t> thresholds to minimize recovery latency.</t>
<section anchor="packet-threshold" numbered="true" toc="default"> <section anchor="packet-threshold" numbered="true" toc="default">
<name>Packet Threshold</name> <name>Packet Threshold</name>
<t>The RECOMMENDED initial value for the packet reordering threshold <t>The <bcp14>RECOMMENDED</bcp14> initial value for the packet reorder ing threshold
(kPacketThreshold) is 3, based on best practices for TCP loss detection (kPacketThreshold) is 3, based on best practices for TCP loss detection
(<xref target="RFC5681" format="default"/>, <xref target="RFC6675" format="defau <xref target="RFC5681" format="default"/> <xref target="RFC6675" format="default
lt"/>). In order to remain similar to TCP, "/>. In order to remain similar to TCP,
implementations SHOULD NOT use a packet threshold less than 3; see <xref target= implementations <bcp14>SHOULD NOT</bcp14> use a packet threshold less than 3; se
"RFC5681" format="default"/>.</t> e <xref target="RFC5681" format="default"/>.</t>
<t>Some networks may exhibit higher degrees of packet reordering, caus ing a sender <t>Some networks may exhibit higher degrees of packet reordering, caus ing a sender
to detect spurious losses. Additionally, packet reordering could be more common to detect spurious losses. Additionally, packet reordering could be more common
with QUIC than TCP, because network elements that could observe and reorder with QUIC than TCP because network elements that could observe and reorder TCP
TCP packets cannot do that for QUIC, because QUIC packet numbers are encrypted. packets cannot do that for QUIC and also because QUIC packet numbers are
Algorithms that increase the reordering threshold after spuriously detecting encrypted. Algorithms that increase the reordering threshold after spuriously
losses, such as RACK <xref target="RACK" format="default"/>, have proven to be u detecting losses, such as RACK <xref target="RFC8985" format="default"/>, have p
seful in TCP and are roven to be useful in TCP and
expected to be at least as useful in QUIC.</t> are expected to be at least as useful in QUIC.</t>
</section> </section>
<section anchor="time-threshold" numbered="true" toc="default"> <section anchor="time-threshold" numbered="true" toc="default">
<name>Time Threshold</name> <name>Time Threshold</name>
<t>Once a later packet within the same packet number space has been ac knowledged, <t>Once a later packet within the same packet number space has been ac knowledged,
an endpoint SHOULD declare an earlier packet lost if it was sent a threshold an endpoint <bcp14>SHOULD</bcp14> declare an earlier packet lost if it was sent a threshold
amount of time in the past. To avoid declaring packets as lost too early, this amount of time in the past. To avoid declaring packets as lost too early, this
time threshold MUST be set to at least the local timer granularity, as time threshold <bcp14>MUST</bcp14> be set to at least the local timer granularit y, as
indicated by the kGranularity constant. The time threshold is:</t> indicated by the kGranularity constant. The time threshold is:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity) max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)
]]></artwork> ]]></sourcecode>
<t>If packets sent prior to the largest acknowledged packet cannot yet be declared <t>If packets sent prior to the largest acknowledged packet cannot yet be declared
lost, then a timer SHOULD be set for the remaining time.</t> lost, then a timer <bcp14>SHOULD</bcp14> be set for the remaining time.</t>
<t>Using max(smoothed_rtt, latest_rtt) protects from the two following cases:</t> <t>Using max(smoothed_rtt, latest_rtt) protects from the two following cases:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the latest RTT sample is lower than the smoothed RTT, perhaps du e to <li>the latest RTT sample is lower than the smoothed RTT, perhaps du e to
reordering where the acknowledgment encountered a shorter path;</li> reordering where the acknowledgment encountered a shorter path;</li>
<li>the latest RTT sample is higher than the smoothed RTT, perhaps d ue to a <li>the latest RTT sample is higher than the smoothed RTT, perhaps d ue to a
sustained increase in the actual RTT, but the smoothed RTT has not yet caught sustained increase in the actual RTT, but the smoothed RTT has not yet caught
up.</li> up.</li>
</ul> </ul>
<t>The RECOMMENDED time threshold (kTimeThreshold), expressed as a rou <t>The <bcp14>RECOMMENDED</bcp14> time threshold (kTimeThreshold), exp
nd-trip time ressed as an RTT multiplier,
multiplier, is 9/8. The RECOMMENDED value of the timer granularity is 9/8. The <bcp14>RECOMMENDED</bcp14> value of the timer granularity (kGranular
(kGranularity) is 1ms.</t> ity) is 1
<dl> millisecond.</t>
<dt> <aside>
Note: </dt> <t>Note: TCP's RACK <xref target="RFC8985" format="default"/> specif
<dd> ies a slightly larger threshold, equivalent
<t>TCP's RACK (<xref target="RACK" format="default"/>) specifies a to 5/4, for a similar purpose. Experience with QUIC shows that 9/8 works well.</
slightly larger t>
threshold, equivalent to 5/4, for a similar purpose. Experience with QUIC shows </aside>
that 9/8 works well.</t> <t>Implementations <bcp14>MAY</bcp14> experiment with absolute thresho
</dd> lds, thresholds from
</dl> previous connections, adaptive thresholds, or the including of RTT variation.
<t>Implementations MAY experiment with absolute thresholds, thresholds Smaller thresholds reduce reordering resilience and increase spurious
from retransmissions, and larger thresholds increase loss detection delay.</t>
previous connections, adaptive thresholds, or including RTT variation. Smaller
thresholds reduce reordering resilience and increase spurious retransmissions,
and larger thresholds increase loss detection delay.</t>
</section> </section>
</section> </section>
<section anchor="pto" numbered="true" toc="default"> <section anchor="pto" numbered="true" toc="default">
<name>Probe Timeout</name> <name>Probe Timeout</name>
<t>A Probe Timeout (PTO) triggers sending one or two probe datagrams whe n <t>A Probe Timeout (PTO) triggers the sending of one or two probe datagr ams when
ack-eliciting packets are not acknowledged within the expected period of ack-eliciting packets are not acknowledged within the expected period of
time or the server may not have validated the client's address. A PTO enables time or the server may not have validated the client's address. A PTO enables
a connection to recover from loss of tail packets or acknowledgments.</t> a connection to recover from loss of tail packets or acknowledgments.</t>
<t>As with loss detection, the probe timeout is per packet number space. That is, a <t>As with loss detection, the PTO is per packet number space. That is, a
PTO value is computed per packet number space.</t> PTO value is computed per packet number space.</t>
<t>A PTO timer expiration event does not indicate packet loss and MUST N <t>A PTO timer expiration event does not indicate packet loss and <bcp14
OT cause >MUST NOT</bcp14> cause
prior unacknowledged packets to be marked as lost. When an acknowledgment prior unacknowledged packets to be marked as lost. When an acknowledgment is
is received that newly acknowledges packets, loss detection proceeds as received that newly acknowledges packets, loss detection proceeds as dictated
dictated by packet and time threshold mechanisms; see <xref target="ack-loss-det by the packet and time threshold mechanisms; see <xref target="ack-loss-detectio
ection" format="default"/>.</t> n" format="default"/>.</t>
<t>The PTO algorithm used in QUIC implements the reliability functions o <t>The PTO algorithm used in QUIC implements the reliability functions o
f f Tail Loss
Tail Loss Probe <xref target="RACK" format="default"/>, RTO <xref target="RFC568 Probe <xref target="RFC8985" format="default"/>, RTO <xref target="RFC5681" form
1" format="default"/>, and F-RTO algorithms for at="default"/>, and F-RTO algorithms for TCP
TCP <xref target="RFC5682" format="default"/>. The timeout computation is based <xref target="RFC5682" format="default"/>. The timeout computation is based on T
on TCP's retransmission CP's RTO period <xref target="RFC6298" format="default"/>.</t>
timeout period <xref target="RFC6298" format="default"/>.</t>
<section anchor="computing-pto" numbered="true" toc="default"> <section anchor="computing-pto" numbered="true" toc="default">
<name>Computing PTO</name> <name>Computing PTO</name>
<t>When an ack-eliciting packet is transmitted, the sender schedules a timer for <t>When an ack-eliciting packet is transmitted, the sender schedules a timer for
the PTO period as follows:</t> the PTO period as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay
]]></artwork> ]]></sourcecode>
<t>The PTO period is the amount of time that a sender ought to wait fo r an <t>The PTO period is the amount of time that a sender ought to wait fo r an
acknowledgment of a sent packet. This time period includes the estimated acknowledgment of a sent packet. This time period includes the estimated
network roundtrip-time (smoothed_rtt), the variation in the estimate (4*rttvar), network RTT (smoothed_rtt), the variation in the estimate (4*rttvar),
and max_ack_delay, to account for the maximum time by which a receiver might and max_ack_delay, to account for the maximum time by which a receiver might
delay sending an acknowledgment.</t> delay sending an acknowledgment.</t>
<t>When the PTO is armed for Initial or Handshake packet number spaces , the <t>When the PTO is armed for Initial or Handshake packet number spaces , the
max_ack_delay in the PTO period computation is set to 0, since the peer is max_ack_delay in the PTO period computation is set to 0, since the peer is
expected to not delay these packets intentionally; see 13.2.1 of expected to not delay these packets intentionally; see <xref section="13.2.1" se
<xref target="QUIC-TRANSPORT" format="default"/>.</t> ctionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
<t>The PTO period MUST be at least kGranularity, to avoid the timer ex <t>The PTO period <bcp14>MUST</bcp14> be at least kGranularity to avoi
piring d the timer expiring
immediately.</t> immediately.</t>
<t>When ack-eliciting packets in multiple packet number spaces are in flight, the <t>When ack-eliciting packets in multiple packet number spaces are in flight, the
timer MUST be set to the earlier value of the Initial and Handshake packet timer <bcp14>MUST</bcp14> be set to the earlier value of the Initial and Handsha ke packet
number spaces.</t> number spaces.</t>
<t>An endpoint MUST NOT set its PTO timer for the application data pac ket number <t>An endpoint <bcp14>MUST NOT</bcp14> set its PTO timer for the Appli cation Data packet number
space until the handshake is confirmed. Doing so prevents the endpoint from space until the handshake is confirmed. Doing so prevents the endpoint from
retransmitting information in packets when either the peer does not yet have the retransmitting information in packets when either the peer does not yet have the
keys to process them or the endpoint does not yet have the keys to process their keys to process them or the endpoint does not yet have the keys to process their
acknowledgments. For example, this can happen when a client sends 0-RTT packets acknowledgments. For example, this can happen when a client sends 0-RTT packets
to the server; it does so without knowing whether the server will be able to to the server; it does so without knowing whether the server will be able to
decrypt them. Similarly, this can happen when a server sends 1-RTT packets decrypt them. Similarly, this can happen when a server sends 1-RTT packets
before confirming that the client has verified the server's certificate and can before confirming that the client has verified the server's certificate and can
therefore read these 1-RTT packets.</t> therefore read these 1-RTT packets.</t>
<t>A sender SHOULD restart its PTO timer every time an ack-eliciting p <t>A sender <bcp14>SHOULD</bcp14> restart its PTO timer every time an
acket is sent ack-eliciting packet is
or acknowledged, or when Initial or Handshake keys are discarded (Section 4.9 of sent or acknowledged, or when Initial or Handshake keys are discarded
<xref target="QUIC-TLS" format="default"/>). This ensures the PTO is always set (<xref section="4.9" sectionFormat="of" target="QUIC-TLS" format="default"/>). T
based on the latest estimate his ensures the PTO is always set based on the
of the round-trip time and for the correct packet across packet number spaces.</ latest estimate of the RTT and for the correct packet across packet
t> number spaces.</t>
<t>When a PTO timer expires, the PTO backoff MUST be increased, result <t>When a PTO timer expires, the PTO backoff <bcp14>MUST</bcp14> be in
ing in the creased, resulting in the
PTO period being set to twice its current value. The PTO backoff factor is reset PTO period being set to twice its current value. The PTO backoff factor is reset
when an acknowledgment is received, except in the following case. A server when an acknowledgment is received, except in the following case. A server
might take longer to respond to packets during the handshake than otherwise. To might take longer to respond to packets during the handshake than otherwise. To
protect such a server from repeated client probes, the PTO backoff is not reset protect such a server from repeated client probes, the PTO backoff is not reset
at a client that is not yet certain that the server has finished validating the at a client that is not yet certain that the server has finished validating the
client's address. That is, a client does not reset the PTO backoff factor on client's address. That is, a client does not reset the PTO backoff factor on
receiving acknowledgments in Initial packets.</t> receiving acknowledgments in Initial packets.</t>
<t>This exponential reduction in the sender's rate is important becaus <t>This exponential reduction in the sender's rate is important becaus
e e consecutive
consecutive PTOs might be caused by loss of packets or acknowledgments due to PTOs might be caused by loss of packets or acknowledgments due to severe
severe congestion. Even when there are ack-eliciting packets in-flight in congestion. Even when there are ack-eliciting packets in flight in multiple
multiple packet number spaces, the exponential increase in probe timeout packet number spaces, the exponential increase in PTO occurs across all spaces
occurs across all spaces to prevent excess load on the network. For example, to prevent excess load on the network. For example, a timeout in the Initial
a timeout in the Initial packet number space doubles the length of the timeout packet number space doubles the length of the timeout in the Handshake packet
in the Handshake packet number space.</t> number space.</t>
<t>The total length of time over which consecutive PTOs expire is limi ted by the <t>The total length of time over which consecutive PTOs expire is limi ted by the
idle timeout.</t> idle timeout.</t>
<t>The PTO timer MUST NOT be set if a timer is set for time threshold <t>The PTO timer <bcp14>MUST NOT</bcp14> be set if a timer is set for time threshold
loss detection; see <xref target="time-threshold" format="default"/>. A timer t hat is set for time loss detection; see <xref target="time-threshold" format="default"/>. A timer t hat is set for time
threshold loss detection will expire earlier than the PTO timer threshold loss detection will expire earlier than the PTO timer
in most cases and is less likely to spuriously retransmit data.</t> in most cases and is less likely to spuriously retransmit data.</t>
</section> </section>
<section anchor="pto-handshake" numbered="true" toc="default"> <section anchor="pto-handshake" numbered="true" toc="default">
<name>Handshakes and New Paths</name> <name>Handshakes and New Paths</name>
<t>Resumed connections over the same network MAY use the previous conn ection's <t>Resumed connections over the same network <bcp14>MAY</bcp14> use th e previous connection's
final smoothed RTT value as the resumed connection's initial RTT. When no final smoothed RTT value as the resumed connection's initial RTT. When no
previous RTT is available, the initial RTT SHOULD be set to 333ms. This previous RTT is available, the initial RTT <bcp14>SHOULD</bcp14> be set to 333 m
results in handshakes starting with a PTO of 1 second, as recommended illiseconds.
for TCP's initial retransmission timeout; see Section 2 of <xref target="RFC6298 This results in handshakes starting with a PTO of 1 second, as recommended for
" format="default"/>.</t> TCP's initial RTO; see <xref section="2" sectionFormat="of" target="RFC6298" for
<t>A connection MAY use the delay between sending a PATH_CHALLENGE and mat="default"/>.</t>
receiving a <t>A connection <bcp14>MAY</bcp14> use the delay between sending a PAT
H_CHALLENGE and receiving a
PATH_RESPONSE to set the initial RTT (see kInitialRtt in PATH_RESPONSE to set the initial RTT (see kInitialRtt in
<xref target="constants-of-interest" format="default"/>) for a new path, but the delay SHOULD NOT be <xref target="constants-of-interest" format="default"/>) for a new path, but the delay <bcp14>SHOULD NOT</bcp14> be
considered an RTT sample.</t> considered an RTT sample.</t>
<t>Initial packets and Handshake packets could be never acknowledged, <t>When the Initial keys and Handshake keys are discarded (see
but they are <xref target="discarding-packets" format="default"/>), any Initial packets and H
removed from bytes in flight when the Initial and Handshake keys are discarded, andshake packets can
as described below in <xref target="discarding-packets" format="default"/>. When no longer be acknowledged, so they are removed from bytes in
Initial or Handshake keys are flight. When Initial or Handshake keys are discarded, the PTO and loss
discarded, the PTO and loss detection timers MUST be reset, because discarding detection timers <bcp14>MUST</bcp14> be reset, because discarding keys indicates
keys indicates forward progress and the loss detection timer might have been set forward progress and the loss detection timer might have been set for
for a now discarded packet number space.</t> a now-discarded packet number space.</t>
<section anchor="before-address-validation" numbered="true" toc="defau lt"> <section anchor="before-address-validation" numbered="true" toc="defau lt">
<name>Before Address Validation</name> <name>Before Address Validation</name>
<t>Until the server has validated the client's address on the path, the amount of <t>Until the server has validated the client's address on the path, the amount of
data it can send is limited to three times the amount of data received, data it can send is limited to three times the amount of data received,
as specified in Section 8.1 of <xref target="QUIC-TRANSPORT" format="default"/>. as specified in <xref section="8.1" sectionFormat="of" target="QUIC-TRANSPORT" f
If no additional data can be ormat="default"/>. If no additional data can be
sent, the server's PTO timer MUST NOT be armed until datagrams have been sent, the server's PTO timer <bcp14>MUST NOT</bcp14> be armed until datagrams ha
received from the client, because packets sent on PTO count against the ve been
anti-amplification limit. Note that the server could fail to validate the received from the client because packets sent on PTO count against the
client's address even if 0-RTT is accepted.</t> anti-amplification limit.</t>
<t>When the server receives a datagram from the client, the amplific
ation limit is
increased and the server resets the PTO timer. If the PTO timer is then set to
a time in the past, it is executed immediately. Doing so avoids sending new
1-RTT packets prior to packets critical to the completion of the handshake.
In particular, this can happen when 0-RTT is accepted but the server fails to
validate the client's address.</t>
<t>Since the server could be blocked until more datagrams are receiv ed from the <t>Since the server could be blocked until more datagrams are receiv ed from the
client, it is the client's responsibility to send packets to unblock the server client, it is the client's responsibility to send packets to unblock the server
until it is certain that the server has finished its address validation until it is certain that the server has finished its address validation (see
(see Section 8 of <xref target="QUIC-TRANSPORT" format="default"/>). That is, t <xref section="8" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>)
he client MUST set the . That is, the client <bcp14>MUST</bcp14> set the PTO timer
probe timer if the client has not received an acknowledgment for any of its if the client has not received an acknowledgment for any of its Handshake
Handshake packets and the handshake is not confirmed (see Section 4.1.2 of packets and the handshake is not confirmed (see <xref section="4.1.2" sectionFor
<xref target="QUIC-TLS" format="default"/>), even if there are no packets in fli mat="of" target="QUIC-TLS" format="default"/>),
ght. When the PTO fires, even if there are no packets in flight. When the PTO fires, the client <bcp14>MU
the client MUST send a Handshake packet if it has Handshake keys, otherwise it ST</bcp14>
MUST send an Initial packet in a UDP datagram with a payload of at least 1200 send a Handshake packet if it has Handshake keys, otherwise it <bcp14>MUST</bcp1
bytes.</t> 4> send an
Initial packet in a UDP datagram with a payload of at least 1200 bytes.</t>
</section> </section>
</section> </section>
<section anchor="speeding-up-handshake-completion" numbered="true" toc=" default"> <section anchor="speeding-up-handshake-completion" numbered="true" toc=" default">
<name>Speeding Up Handshake Completion</name> <name>Speeding up Handshake Completion</name>
<t>When a server receives an Initial packet containing duplicate CRYPT O data, <t>When a server receives an Initial packet containing duplicate CRYPT O data,
it can assume the client did not receive all of the server's CRYPTO data sent it can assume the client did not receive all of the server's CRYPTO data sent
in Initial packets, or the client's estimated RTT is too small. When a in Initial packets, or the client's estimated RTT is too small. When a
client receives Handshake or 1-RTT packets prior to obtaining Handshake keys, client receives Handshake or 1-RTT packets prior to obtaining Handshake keys,
it may assume some or all of the server's Initial packets were lost.</t> it may assume some or all of the server's Initial packets were lost.</t>
<t>To speed up handshake completion under these conditions, an endpoin t MAY, for a <t>To speed up handshake completion under these conditions, an endpoin t <bcp14>MAY</bcp14>, for a
limited number of times per connection, send a packet containing limited number of times per connection, send a packet containing
unacknowledged CRYPTO data earlier than the PTO expiry, subject to the address unacknowledged CRYPTO data earlier than the PTO expiry, subject to the address
validation limits in Section 8.1 of <xref target="QUIC-TRANSPORT" format="defaul t"/>. Doing so at most once validation limits in <xref section="8.1" sectionFormat="of" target="QUIC-TRANSPO RT" format="default"/>. Doing so at most once
for each connection is adequate to quickly recover from a single packet loss. for each connection is adequate to quickly recover from a single packet loss.
An endpoint that always retransmits packets in response to receiving packets An endpoint that always retransmits packets in response to receiving packets
that it cannot process risks creating an infinite exchange of packets.</t> that it cannot process risks creating an infinite exchange of packets.</t>
<t>Endpoints can also use coalesced packets (see Section 12.2 of <t>Endpoints can also use coalesced packets (see <xref section="12.2"
<xref target="QUIC-TRANSPORT" format="default"/>) to ensure that each datagram e sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>) to ensure that ea
licits at least one ch datagram elicits at least one
acknowledgment. For example, a client can coalesce an Initial packet acknowledgment. For example, a client can coalesce an Initial packet containing
containing PING and PADDING frames with a 0-RTT data packet and a server can PING and PADDING frames with a 0-RTT data packet, and a server can coalesce an
coalesce an Initial packet containing a PING frame with one or more packets in Initial packet containing a PING frame with one or more packets in its first
its first flight.</t> flight.</t>
</section> </section>
<section anchor="sending-probe-packets" numbered="true" toc="default"> <section anchor="sending-probe-packets" numbered="true" toc="default">
<name>Sending Probe Packets</name> <name>Sending Probe Packets</name>
<t>When a PTO timer expires, a sender MUST send at least one ack-elici <t>When a PTO timer expires, a sender <bcp14>MUST</bcp14> send at leas
ting packet t one ack-eliciting packet
in the packet number space as a probe. An endpoint MAY send up to two in the packet number space as a probe. An endpoint <bcp14>MAY</bcp14> send up t
full-sized datagrams containing ack-eliciting packets, to avoid an expensive o two
consecutive PTO expiration due to a single lost datagram, or transmit data full-sized datagrams containing ack-eliciting packets to avoid an expensive
from multiple packet number spaces. All probe packets sent on a PTO MUST be consecutive PTO expiration due to a single lost datagram or to transmit data
from multiple packet number spaces. All probe packets sent on a PTO <bcp14>MUST<
/bcp14> be
ack-eliciting.</t> ack-eliciting.</t>
<t>In addition to sending data in the packet number space for which th e timer <t>In addition to sending data in the packet number space for which th e timer
expired, the sender SHOULD send ack-eliciting packets from other packet expired, the sender <bcp14>SHOULD</bcp14> send ack-eliciting packets from other
number spaces with in-flight data, coalescing packets if possible. This is packet number
particularly valuable when the server has both Initial and Handshake data spaces with in-flight data, coalescing packets if possible. This is
in-flight or the client has both Handshake and Application Data in-flight, particularly valuable when the server has both Initial and Handshake data in
flight or when the client has both Handshake and Application Data in flight
because the peer might only have receive keys for one of the two packet number because the peer might only have receive keys for one of the two packet number
spaces.</t> spaces.</t>
<t>If the sender wants to elicit a faster acknowledgment on PTO, it ca n skip a <t>If the sender wants to elicit a faster acknowledgment on PTO, it ca n skip a
packet number to eliminate the acknowledgment delay.</t> packet number to eliminate the acknowledgment delay.</t>
<t>An endpoint SHOULD include new data in packets that are sent on PTO <t>An endpoint <bcp14>SHOULD</bcp14> include new data in packets that
expiration. are sent on PTO expiration.
Previously sent data MAY be sent if no new data can be sent. Implementations Previously sent data <bcp14>MAY</bcp14> be sent if no new data can be sent. Impl
MAY use alternative strategies for determining the content of probe packets, ementations
<bcp14>MAY</bcp14> use alternative strategies for determining the content of pro
be packets,
including sending new or retransmitted data based on the application's including sending new or retransmitted data based on the application's
priorities.</t> priorities.</t>
<t>It is possible the sender has no new or previously-sent data to sen d. <t>It is possible the sender has no new or previously sent data to sen d.
As an example, consider the following sequence of events: new application data As an example, consider the following sequence of events: new application data
is sent in a STREAM frame, deemed lost, then retransmitted in a new packet, is sent in a STREAM frame, deemed lost, then retransmitted in a new packet,
and then the original transmission is acknowledged. When there is no data to and then the original transmission is acknowledged. When there is no data to
send, the sender SHOULD send a PING or other ack-eliciting frame in a single send, the sender <bcp14>SHOULD</bcp14> send a PING or other ack-eliciting frame
packet, re-arming the PTO timer.</t> in a single
<t>Alternatively, instead of sending an ack-eliciting packet, the send packet, rearming the PTO timer.</t>
er MAY mark <t>Alternatively, instead of sending an ack-eliciting packet, the send
er <bcp14>MAY</bcp14> mark
any packets still in flight as lost. Doing so avoids sending an additional any packets still in flight as lost. Doing so avoids sending an additional
packet, but increases the risk that loss is declared too aggressively, resulting packet but increases the risk that loss is declared too aggressively, resulting
in an unnecessary rate reduction by the congestion controller.</t> in an unnecessary rate reduction by the congestion controller.</t>
<t>Consecutive PTO periods increase exponentially, and as a result, co nnection <t>Consecutive PTO periods increase exponentially, and as a result, co nnection
recovery latency increases exponentially as packets continue to be dropped in recovery latency increases exponentially as packets continue to be dropped in
the network. Sending two packets on PTO expiration increases resilience to the network. Sending two packets on PTO expiration increases resilience to
packet drops, thus reducing the probability of consecutive PTO events.</t> packet drops, thus reducing the probability of consecutive PTO events.</t>
<t>When the PTO timer expires multiple times and new data cannot be se nt, <t>When the PTO timer expires multiple times and new data cannot be se nt,
implementations must choose between sending the same payload every time implementations must choose between sending the same payload every time
or sending different payloads. Sending the same payload may be simpler or sending different payloads. Sending the same payload may be simpler
and ensures the highest priority frames arrive first. Sending different and ensures the highest priority frames arrive first. Sending different
payloads each time reduces the chances of spurious retransmission.</t> payloads each time reduces the chances of spurious retransmission.</t>
</section> </section>
</section> </section>
<section anchor="handling-retry-packets" numbered="true" toc="default"> <section anchor="handling-retry-packets" numbered="true" toc="default">
<name>Handling Retry Packets</name> <name>Handling Retry Packets</name>
<t>A Retry packet causes a client to send another Initial packet, effect ively <t>A Retry packet causes a client to send another Initial packet, effect ively
restarting the connection process. A Retry packet indicates that the Initial restarting the connection process. A Retry packet indicates that the Initial
was received, but not processed. A Retry packet cannot be treated as an packet was received but not processed. A Retry packet cannot be treated as an
acknowledgment, because it does not indicate that a packet was processed or acknowledgment because it does not indicate that a packet was processed or
specify the packet number.</t> specify the packet number.</t>
<t>Clients that receive a Retry packet reset congestion control and loss recovery <t>Clients that receive a Retry packet reset congestion control and loss recovery
state, including resetting any pending timers. Other connection state, in state, including resetting any pending timers. Other connection state, in
particular cryptographic handshake messages, is retained; see Section 17.2.5 of particular cryptographic handshake messages, is retained; see
<xref target="QUIC-TRANSPORT" format="default"/>.</t> <xref section="17.2.5" sectionFormat="of" target="QUIC-TRANSPORT" format="defaul
<t>The client MAY compute an RTT estimate to the server as the time peri t"/>.</t>
od from <t>The client <bcp14>MAY</bcp14> compute an RTT estimate to the server a
when the first Initial was sent to when a Retry or a Version Negotiation packet s the time period from
is received. The client MAY use this value in place of its default for the when the first Initial packet was sent to when a Retry or a Version Negotiation
initial RTT estimate.</t> packet is received. The client <bcp14>MAY</bcp14> use this value in place of it
s default for
the initial RTT estimate.</t>
</section> </section>
<section anchor="discarding-packets" numbered="true" toc="default"> <section anchor="discarding-packets" numbered="true" toc="default">
<name>Discarding Keys and Packet State</name> <name>Discarding Keys and Packet State</name>
<t>When Initial and Handshake packet protection keys are discarded <t>When Initial and Handshake packet protection keys are discarded
(see Section 4.9 of <xref target="QUIC-TLS" format="default"/>), all packets tha t were sent with those keys (see <xref section="4.9" sectionFormat="of" target="QUIC-TLS" format="default"/> ), all packets that were sent with those keys
can no longer be acknowledged because their acknowledgments cannot be processed. can no longer be acknowledged because their acknowledgments cannot be processed.
The sender MUST discard all recovery state associated with those packets The sender <bcp14>MUST</bcp14> discard all recovery state associated with those
and MUST remove them from the count of bytes in flight.</t> packets
and <bcp14>MUST</bcp14> remove them from the count of bytes in flight.</t>
<t>Endpoints stop sending and receiving Initial packets once they start exchanging <t>Endpoints stop sending and receiving Initial packets once they start exchanging
Handshake packets; see Section 17.2.2.1 of <xref target="QUIC-TRANSPORT" format= "default"/>. At this point, Handshake packets; see <xref section="17.2.2.1" sectionFormat="of" target="QUIC- TRANSPORT" format="default"/>. At this point,
recovery state for all in-flight Initial packets is discarded.</t> recovery state for all in-flight Initial packets is discarded.</t>
<t>When 0-RTT is rejected, recovery state for all in-flight 0-RTT packet s is <t>When 0-RTT is rejected, recovery state for all in-flight 0-RTT packet s is
discarded.</t> discarded.</t>
<t>If a server accepts 0-RTT, but does not buffer 0-RTT packets that arr ive <t>If a server accepts 0-RTT, but does not buffer 0-RTT packets that arr ive
before Initial packets, early 0-RTT packets will be declared lost, but that before Initial packets, early 0-RTT packets will be declared lost, but that
is expected to be infrequent.</t> is expected to be infrequent.</t>
<t>It is expected that keys are discarded after packets encrypted with t <t>It is expected that keys are discarded at some time after the packets
hem would encrypted with them are either acknowledged or declared lost. However,
be acknowledged or declared lost. However, Initial and Handshake secrets are Initial and Handshake secrets are discarded as soon as Handshake and
discarded as soon as handshake and 1-RTT keys are proven to be available to both 1-RTT keys are proven to be available to both client and server; see
client and server; see Section 4.9.1 of <xref target="QUIC-TLS" format="default" <xref section="4.9.1" sectionFormat="of" target="QUIC-TLS" format="default"/>.</
/>.</t> t>
</section> </section>
</section> </section>
<section anchor="congestion-control" numbered="true" toc="default"> <section anchor="congestion-control" numbered="true" toc="default">
<name>Congestion Control</name> <name>Congestion Control</name>
<t>This document specifies a sender-side congestion controller for QUIC si milar to <t>This document specifies a sender-side congestion controller for QUIC si milar to
TCP NewReno (<xref target="RFC6582" format="default"/>).</t> TCP NewReno <xref target="RFC6582" format="default"/>.</t>
<t>The signals QUIC provides for congestion control are generic and are de signed to <t>The signals QUIC provides for congestion control are generic and are de signed to
support different sender-side algorithms. A sender can unilaterally choose a support different sender-side algorithms. A sender can unilaterally choose a
different algorithm to use, such as Cubic (<xref target="RFC8312" format="defaul t"/>).</t> different algorithm to use, such as CUBIC <xref target="RFC8312" format="default "/>.</t>
<t>If a sender uses a different controller than that specified in this doc ument, <t>If a sender uses a different controller than that specified in this doc ument,
the chosen controller MUST conform to the congestion control guidelines the chosen controller <bcp14>MUST</bcp14> conform to the congestion control guid
specified in Section 3.1 of <xref target="RFC8085" format="default"/>.</t> elines
<t>Similar to TCP, packets containing only ACK frames do not count towards specified in <xref section="3.1" sectionFormat="of" target="RFC8085" format="def
bytes ault"/>.</t>
<t>Similar to TCP, packets containing only ACK frames do not count toward
bytes
in flight and are not congestion controlled. Unlike TCP, QUIC can detect the in flight and are not congestion controlled. Unlike TCP, QUIC can detect the
loss of these packets and MAY use that information to adjust the congestion loss of these packets and <bcp14>MAY</bcp14> use that information to adjust the congestion
controller or the rate of ACK-only packets being sent, but this document does controller or the rate of ACK-only packets being sent, but this document does
not describe a mechanism for doing so.</t> not describe a mechanism for doing so.</t>
<t>The congestion controller is per path, so packets sent on other paths d
o not
alter the current path's congestion controller, as described in
<xref section="9.4" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/
>.</t>
<t>The algorithm in this document specifies and uses the controller's cong estion <t>The algorithm in this document specifies and uses the controller's cong estion
window in bytes.</t> window in bytes.</t>
<t>An endpoint MUST NOT send a packet if it would cause bytes_in_flight (s ee <t>An endpoint <bcp14>MUST NOT</bcp14> send a packet if it would cause byt es_in_flight (see
<xref target="vars-of-interest" format="default"/>) to be larger than the conges tion window, unless the packet <xref target="vars-of-interest" format="default"/>) to be larger than the conges tion window, unless the packet
is sent on a PTO timer expiration (see <xref target="pto" format="default"/>) or when entering recovery is sent on a PTO timer expiration (see <xref target="pto" format="default"/>) or when entering recovery
(see <xref target="recovery-period" format="default"/>).</t> (see <xref target="recovery-period" format="default"/>).</t>
<section anchor="congestion-ecn" numbered="true" toc="default"> <section anchor="congestion-ecn" numbered="true" toc="default">
<name>Explicit Congestion Notification</name> <name>Explicit Congestion Notification</name>
<t>If a path has been validated to support ECN (<xref target="RFC3168" f <t>If a path has been validated to support Explicit Congestion Notificat
ormat="default"/>, <xref target="RFC8311" format="default"/>), QUIC ion (ECN)
treats a Congestion Experienced (CE) codepoint in the IP header as a signal of <xref target="RFC3168" format="default"/> <xref target="RFC8311" format="default
congestion. This document specifies an endpoint's response when the "/>, QUIC treats a Congestion Experienced (CE) codepoint
peer-reported ECN-CE count increases; see Section 13.4.2 of <xref target="QUIC-T in the IP header as a signal of congestion. This document specifies an
RANSPORT" format="default"/>.</t> endpoint's response when the peer-reported ECN-CE count increases; see <xref sec
tion="13.4.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
</section> </section>
<section anchor="initial-cwnd" numbered="true" toc="default"> <section anchor="initial-cwnd" numbered="true" toc="default">
<name>Initial and Minimum Congestion Window</name> <name>Initial and Minimum Congestion Window</name>
<t>QUIC begins every connection in slow start with the congestion window <t>QUIC begins every connection in slow start with the congestion window
set to set to an
an initial value. Endpoints SHOULD use an initial congestion window of 10 times initial value. Endpoints <bcp14>SHOULD</bcp14> use an initial congestion window
the maximum datagram size (max_datagram_size), while limiting the window of ten times
to the larger of 14720 bytes or twice the maximum datagram size. This follows the maximum datagram size (max_datagram_size), while limiting the window to the
the analysis and recommendations in <xref target="RFC6928" format="default"/>, i larger of 14,720 bytes or twice the maximum datagram size. This follows the
ncreasing the byte limit to analysis and recommendations in <xref target="RFC6928" format="default"/>, incre
asing the byte limit to
account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead
for TCP.</t> for TCP.</t>
<t>If the maximum datagram size changes during the connection, the initi al <t>If the maximum datagram size changes during the connection, the initi al
congestion window SHOULD be recalculated with the new size. If the maximum congestion window <bcp14>SHOULD</bcp14> be recalculated with the new size. If t he maximum
datagram size is decreased in order to complete the handshake, the datagram size is decreased in order to complete the handshake, the
congestion window SHOULD be set to the new initial congestion window.</t> congestion window <bcp14>SHOULD</bcp14> be set to the new initial congestion win dow.</t>
<t>Prior to validating the client's address, the server can be further l imited by <t>Prior to validating the client's address, the server can be further l imited by
the anti-amplification limit as specified in Section 8.1 of <xref target="QUIC-T RANSPORT" format="default"/>. the anti-amplification limit as specified in <xref section="8.1" sectionFormat=" of" target="QUIC-TRANSPORT" format="default"/>.
Though the anti-amplification limit can prevent the congestion window from Though the anti-amplification limit can prevent the congestion window from
being fully utilized and therefore slow down the increase in congestion window, being fully utilized and therefore slow down the increase in congestion window,
it does not directly affect the congestion window.</t> it does not directly affect the congestion window.</t>
<t>The minimum congestion window is the smallest value the congestion wi ndow can <t>The minimum congestion window is the smallest value the congestion wi ndow can
decrease to as a response to loss, increase in the peer-reported ECN-CE count, attain in response to loss, an increase in the peer-reported ECN-CE count,
or persistent congestion. The RECOMMENDED value is 2 * max_datagram_size.</t> or persistent congestion. The <bcp14>RECOMMENDED</bcp14> value is 2 * max_datag
ram_size.</t>
</section> </section>
<section anchor="congestion-control-states" numbered="true" toc="default"> <section anchor="congestion-control-states" numbered="true" toc="default">
<name>Congestion Control States</name> <name>Congestion Control States</name>
<t>The NewReno congestion controller described in this document has thre e <t>The NewReno congestion controller described in this document has thre e
distinct states, as shown in <xref target="fig-cc-fsm" format="default"/>.</t> distinct states, as shown in <xref target="fig-cc-fsm" format="default"/>.</t>
<figure anchor="fig-cc-fsm"> <figure anchor="fig-cc-fsm">
<name>Congestion Control States and Transitions</name> <name>Congestion Control States and Transitions</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
New Path or +------------+ New path or +------------+
persistent congestion | Slow | persistent congestion | Slow |
(O)---------------------->| Start | (O)---------------------->| Start |
+------------+ +------------+
| |
Loss or | Loss or |
ECN-CE increase | ECN-CE increase |
v v
+------------+ Loss or +------------+ +------------+ Loss or +------------+
| Congestion | ECN-CE increase | Recovery | | Congestion | ECN-CE increase | Recovery |
| Avoidance |------------------>| Period | | Avoidance |------------------>| Period |
skipping to change at line 749 skipping to change at line 741
<t>These states and the transitions between them are described in subseq uent <t>These states and the transitions between them are described in subseq uent
sections.</t> sections.</t>
<section anchor="slow-start" numbered="true" toc="default"> <section anchor="slow-start" numbered="true" toc="default">
<name>Slow Start</name> <name>Slow Start</name>
<t>A NewReno sender is in slow start any time the congestion window is below the <t>A NewReno sender is in slow start any time the congestion window is below the
slow start threshold. A sender begins in slow start because the slow start slow start threshold. A sender begins in slow start because the slow start
threshold is initialized to an infinite value.</t> threshold is initialized to an infinite value.</t>
<t>While a sender is in slow start, the congestion window increases by the number <t>While a sender is in slow start, the congestion window increases by the number
of bytes acknowledged when each acknowledgment is processed. This results in of bytes acknowledged when each acknowledgment is processed. This results in
exponential growth of the congestion window.</t> exponential growth of the congestion window.</t>
<t>The sender MUST exit slow start and enter a recovery period when a packet is <t>The sender <bcp14>MUST</bcp14> exit slow start and enter a recovery period when a packet is
lost or when the ECN-CE count reported by its peer increases.</t> lost or when the ECN-CE count reported by its peer increases.</t>
<t>A sender re-enters slow start any time the congestion window is les s than the <t>A sender reenters slow start any time the congestion window is less than the
slow start threshold, which only occurs after persistent congestion is slow start threshold, which only occurs after persistent congestion is
declared.</t> declared.</t>
</section> </section>
<section anchor="recovery-period" numbered="true" toc="default"> <section anchor="recovery-period" numbered="true" toc="default">
<name>Recovery</name> <name>Recovery</name>
<t>A NewReno sender enters a recovery period when it detects the loss of a packet <t>A NewReno sender enters a recovery period when it detects the loss of a packet
or the ECN-CE count reported by its peer increases. A sender that is already in or when the ECN-CE count reported by its peer increases. A sender that is
a recovery period stays in it and does not re-enter it.</t> already in a recovery period stays in it and does not reenter it.</t>
<t>On entering a recovery period, a sender MUST set the slow start thr <t>On entering a recovery period, a sender <bcp14>MUST</bcp14> set the
eshold to slow start threshold to
half the value of the congestion window when loss is detected. The congestion half the value of the congestion window when loss is detected. The congestion
window MUST be set to the reduced value of the slow start threshold before window <bcp14>MUST</bcp14> be set to the reduced value of the slow start thresho ld before
exiting the recovery period.</t> exiting the recovery period.</t>
<t>Implementations MAY reduce the congestion window immediately upon e ntering a <t>Implementations <bcp14>MAY</bcp14> reduce the congestion window imm ediately upon entering a
recovery period or use other mechanisms, such as Proportional Rate Reduction recovery period or use other mechanisms, such as Proportional Rate Reduction
(<xref target="PRR" format="default"/>), to reduce the congestion window more gr adually. If the <xref target="PRR" format="default"/>, to reduce the congestion window more grad ually. If the
congestion window is reduced immediately, a single packet can be sent prior to congestion window is reduced immediately, a single packet can be sent prior to
reduction. This speeds up loss recovery if the data in the lost packet is reduction. This speeds up loss recovery if the data in the lost packet is
retransmitted and is similar to TCP as described in Section 5 of <xref target="R FC6675" format="default"/>.</t> retransmitted and is similar to TCP as described in <xref section="5" sectionFor mat="of" target="RFC6675" format="default"/>.</t>
<t>The recovery period aims to limit congestion window reduction to on ce per round <t>The recovery period aims to limit congestion window reduction to on ce per round
trip. Therefore during a recovery period, the congestion window does not change trip. Therefore, during a recovery period, the congestion window does not change
in response to new losses or increases in the ECN-CE count.</t> in response to new losses or increases in the ECN-CE count.</t>
<t>A recovery period ends and the sender enters congestion avoidance w hen a packet <t>A recovery period ends and the sender enters congestion avoidance w hen a packet
sent during the recovery period is acknowledged. This is slightly different sent during the recovery period is acknowledged. This is slightly different
from TCP's definition of recovery, which ends when the lost segment that from TCP's definition of recovery, which ends when the lost segment that
started recovery is acknowledged (<xref target="RFC5681" format="default"/>).</t > started recovery is acknowledged <xref target="RFC5681" format="default"/>.</t>
</section> </section>
<section anchor="congestion-avoidance" numbered="true" toc="default"> <section anchor="congestion-avoidance" numbered="true" toc="default">
<name>Congestion Avoidance</name> <name>Congestion Avoidance</name>
<t>A NewReno sender is in congestion avoidance any time the congestion window is <t>A NewReno sender is in congestion avoidance any time the congestion window is
at or above the slow start threshold and not in a recovery period.</t> at or above the slow start threshold and not in a recovery period.</t>
<t>A sender in congestion avoidance uses an Additive Increase Multipli cative <t>A sender in congestion avoidance uses an Additive Increase Multipli cative
Decrease (AIMD) approach that MUST limit the increase to the congestion window Decrease (AIMD) approach that <bcp14>MUST</bcp14> limit the increase to the cong estion window
to at most one maximum datagram size for each congestion window that is to at most one maximum datagram size for each congestion window that is
acknowledged.</t> acknowledged.</t>
<t>The sender exits congestion avoidance and enters a recovery period when a <t>The sender exits congestion avoidance and enters a recovery period when a
packet is lost or when the ECN-CE count reported by its peer increases.</t> packet is lost or when the ECN-CE count reported by its peer increases.</t>
</section> </section>
</section> </section>
<section anchor="ignoring-loss-of-undecryptable-packets" numbered="true" t oc="default"> <section anchor="ignoring-loss-of-undecryptable-packets" numbered="true" t oc="default">
<name>Ignoring Loss of Undecryptable Packets</name> <name>Ignoring Loss of Undecryptable Packets</name>
<t>During the handshake, some packet protection keys might not be availa ble when <t>During the handshake, some packet protection keys might not be availa ble when
a packet arrives and the receiver can choose to drop the packet. In particular, a packet arrives, and the receiver can choose to drop the packet. In particular,
Handshake and 0-RTT packets cannot be processed until the Initial packets Handshake and 0-RTT packets cannot be processed until the Initial packets
arrive and 1-RTT packets cannot be processed until the handshake completes. arrive, and 1-RTT packets cannot be processed until the handshake completes.
Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might Endpoints <bcp14>MAY</bcp14> ignore the loss of Handshake, 0-RTT, and 1-RTT pack
ets that might
have arrived before the peer had packet protection keys to process those have arrived before the peer had packet protection keys to process those
packets. Endpoints MUST NOT ignore the loss of packets that were sent after packets. Endpoints <bcp14>MUST NOT</bcp14> ignore the loss of packets that were sent after
the earliest acknowledged packet in a given packet number space.</t> the earliest acknowledged packet in a given packet number space.</t>
</section> </section>
<section anchor="probe-timeout" numbered="true" toc="default"> <section anchor="probe-timeout" numbered="true" toc="default">
<name>Probe Timeout</name> <name>Probe Timeout</name>
<t>Probe packets MUST NOT be blocked by the congestion controller. A se nder MUST <t>Probe packets <bcp14>MUST NOT</bcp14> be blocked by the congestion co ntroller. A sender <bcp14>MUST</bcp14>
however count these packets as being additionally in flight, since these packets however count these packets as being additionally in flight, since these packets
add network load without establishing packet loss. Note that sending probe add network load without establishing packet loss. Note that sending probe
packets might cause the sender's bytes in flight to exceed the congestion window packets might cause the sender's bytes in flight to exceed the congestion window
until an acknowledgment is received that establishes loss or delivery of until an acknowledgment is received that establishes loss or delivery of
packets.</t> packets.</t>
</section> </section>
<section anchor="persistent-congestion" numbered="true" toc="default"> <section anchor="persistent-congestion" numbered="true" toc="default">
<name>Persistent Congestion</name> <name>Persistent Congestion</name>
<t>When a sender establishes loss of all packets sent over a long enough duration, <t>When a sender establishes loss of all packets sent over a long enough duration,
the network is considered to be experiencing persistent congestion.</t> the network is considered to be experiencing persistent congestion.</t>
<section anchor="pc-duration" numbered="true" toc="default"> <section anchor="pc-duration" numbered="true" toc="default">
<name>Duration</name> <name>Duration</name>
<t>The persistent congestion duration is computed as follows:</t> <t>The persistent congestion duration is computed as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
(smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) * (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
kPersistentCongestionThreshold kPersistentCongestionThreshold
]]></artwork> ]]></sourcecode>
<t>Unlike the PTO computation in <xref target="pto" format="default"/> , this duration includes the max_ack_delay <t>Unlike the PTO computation in <xref target="pto" format="default"/> , this duration includes the max_ack_delay
irrespective of the packet number spaces in which losses are established.</t> irrespective of the packet number spaces in which losses are established.</t>
<t>This duration allows a sender to send as many packets before establ ishing <t>This duration allows a sender to send as many packets before establ ishing
persistent congestion, including some in response to PTO expiration, as TCP does persistent congestion, including some in response to PTO expiration, as TCP does
with Tail Loss Probes (<xref target="RACK" format="default"/>) and a Retransmiss ion Timeout (<xref target="RFC5681" format="default"/>).</t> with Tail Loss Probes <xref target="RFC8985" format="default"/> and an RTO <xref target="RFC5681" format="default"/>.</t>
<t>Larger values of kPersistentCongestionThreshold cause the sender to become less <t>Larger values of kPersistentCongestionThreshold cause the sender to become less
responsive to persistent congestion in the network, which can result in responsive to persistent congestion in the network, which can result in
aggressive sending into a congested network. Too small a value can result in a aggressive sending into a congested network. Too small a value can result in a
sender declaring persistent congestion unnecessarily, resulting in reduced sender declaring persistent congestion unnecessarily, resulting in reduced
throughput for the sender.</t> throughput for the sender.</t>
<t>The RECOMMENDED value for kPersistentCongestionThreshold is 3, whic h results in <t>The <bcp14>RECOMMENDED</bcp14> value for kPersistentCongestionThres hold is 3, which results in
behavior that is approximately equivalent to a TCP sender declaring an RTO after behavior that is approximately equivalent to a TCP sender declaring an RTO after
two TLPs.</t> two TLPs.</t>
<t>This design does not use consecutive PTO events to establish persis tent <t>This design does not use consecutive PTO events to establish persis tent
congestion, since application patterns impact PTO expirations. For example, a congestion, since application patterns impact PTO expiration. For example, a
sender that sends small amounts of data with silence periods between them sender that sends small amounts of data with silence periods between them
restarts the PTO timer every time it sends, potentially preventing the PTO timer restarts the PTO timer every time it sends, potentially preventing the PTO timer
from expiring for a long period of time, even when no acknowledgments are being from expiring for a long period of time, even when no acknowledgments are being
received. The use of a duration enables a sender to establish persistent received. The use of a duration enables a sender to establish persistent
congestion without depending on PTO expiration.</t> congestion without depending on PTO expiration.</t>
</section> </section>
<section anchor="establishing-persistent-congestion" numbered="true" toc ="default"> <section anchor="establishing-persistent-congestion" numbered="true" toc ="default">
<name>Establishing Persistent Congestion</name> <name>Establishing Persistent Congestion</name>
<t>A sender establishes persistent congestion after the receipt of an <t>A sender establishes persistent congestion after the receipt of an
acknowledgment if two packets that are ack-eliciting are declared lost, and:</t> acknowledgment if two packets that are ack-eliciting are declared lost, and:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>across all packet number spaces, none of the packets sent betwee n the send <li>across all packet number spaces, none of the packets sent betwee n the send
times of these two packets are acknowledged;</li> times of these two packets are acknowledged;</li>
<li>the duration between the send times of these two packets exceeds the <li>the duration between the send times of these two packets exceeds the
persistent congestion duration (<xref target="pc-duration" format="default"/>); and</li> persistent congestion duration (<xref target="pc-duration" format="default"/>); and</li>
<li>a prior RTT sample existed when these two packets were sent.</li > <li>a prior RTT sample existed when these two packets were sent.</li >
</ul> </ul>
<t>These two packets MUST be ack-eliciting, since a receiver is requir <t>These two packets <bcp14>MUST</bcp14> be ack-eliciting, since a rec
ed to eiver is required to
acknowledge only ack-eliciting packets within its maximum ack delay; see Section acknowledge only ack-eliciting packets within its maximum acknowledgment delay;
13.2 of <xref target="QUIC-TRANSPORT" format="default"/>.</t> see <xref section="13.2" sectionFormat="of" target="QUIC-TRANSPORT" format="defa
<t>The persistent congestion period SHOULD NOT start until there is at ult"/>.</t>
least one <t>The persistent congestion period <bcp14>SHOULD NOT</bcp14> start un
til there is at least one
RTT sample. Before the first RTT sample, a sender arms its PTO timer based on RTT sample. Before the first RTT sample, a sender arms its PTO timer based on
the initial RTT (<xref target="pto-handshake" format="default"/>), which could b e substantially larger than the initial RTT (<xref target="pto-handshake" format="default"/>), which could b e substantially larger than
the actual RTT. Requiring a prior RTT sample prevents a sender from establishing the actual RTT. Requiring a prior RTT sample prevents a sender from establishing
persistent congestion with potentially too few probes.</t> persistent congestion with potentially too few probes.</t>
<t>Since network congestion is not affected by packet number spaces, p ersistent <t>Since network congestion is not affected by packet number spaces, p ersistent
congestion SHOULD consider packets sent across packet number spaces. A sender congestion <bcp14>SHOULD</bcp14> consider packets sent across packet number spac es. A sender
that does not have state for all packet number spaces or an implementation that that does not have state for all packet number spaces or an implementation that
cannot compare send times across packet number spaces MAY use state for just the cannot compare send times across packet number spaces <bcp14>MAY</bcp14> use sta te for just the
packet number space that was acknowledged. This might result in erroneously packet number space that was acknowledged. This might result in erroneously
declaring persistent congestion, but it will not lead to a failure to detect declaring persistent congestion, but it will not lead to a failure to detect
persistent congestion.</t> persistent congestion.</t>
<t>When persistent congestion is declared, the sender's congestion win dow MUST be <t>When persistent congestion is declared, the sender's congestion win dow <bcp14>MUST</bcp14> be
reduced to the minimum congestion window (kMinimumWindow), similar to a TCP reduced to the minimum congestion window (kMinimumWindow), similar to a TCP
sender's response on an RTO (<xref target="RFC5681" format="default"/>).</t> sender's response on an RTO <xref target="RFC5681" format="default"/>.</t>
</section> </section>
<section anchor="example" numbered="true" toc="default"> <section anchor="example" numbered="true" toc="default">
<name>Example</name> <name>Example</name>
<t>The following example illustrates how a sender might establish pers istent <t>The following example illustrates how a sender might establish pers istent
congestion. Assume:</t> congestion. Assume:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2 smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
kPersistentCongestionThreshold = 3 kPersistentCongestionThreshold = 3
]]></artwork> ]]></sourcecode>
<t>Consider the following sequence of events:</t> <t>Consider the following sequence of events:</t>
<table align="center"> <table align="center">
<thead> <thead>
<tr> <tr>
<th align="left">Time</th> <th align="left">Time</th>
<th align="left">Action</th> <th align="left">Action</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">t=0</td> <td align="left">t=0</td>
<td align="left">Send packet #1 (app data)</td> <td align="left">Send packet #1 (application data)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=1</td> <td align="left">t=1</td>
<td align="left">Send packet #2 (app data)</td> <td align="left">Send packet #2 (application data)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=1.2</td> <td align="left">t=1.2</td>
<td align="left">Recv acknowledgment of #1</td> <td align="left">Receive acknowledgment of #1</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=2</td> <td align="left">t=2</td>
<td align="left">Send packet #3 (app data)</td> <td align="left">Send packet #3 (application data)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=3</td> <td align="left">t=3</td>
<td align="left">Send packet #4 (app data)</td> <td align="left">Send packet #4 (application data)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=4</td> <td align="left">t=4</td>
<td align="left">Send packet #5 (app data)</td> <td align="left">Send packet #5 (application data)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=5</td> <td align="left">t=5</td>
<td align="left">Send packet #6 (app data)</td> <td align="left">Send packet #6 (application data)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=6</td> <td align="left">t=6</td>
<td align="left">Send packet #7 (app data)</td> <td align="left">Send packet #7 (application data)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=8</td> <td align="left">t=8</td>
<td align="left">Send packet #8 (PTO 1)</td> <td align="left">Send packet #8 (PTO 1)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=12</td> <td align="left">t=12</td>
<td align="left">Send packet #9 (PTO 2)</td> <td align="left">Send packet #9 (PTO 2)</td>
</tr> </tr>
<tr> <tr>
<td align="left">t=12.2</td> <td align="left">t=12.2</td>
<td align="left">Recv acknowledgment of #9</td> <td align="left">Receive acknowledgment of #9</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Packets 2 through 8 are declared lost when the acknowledgment for p acket 9 is <t>Packets 2 through 8 are declared lost when the acknowledgment for p acket 9 is
received at t = 12.2.</t> received at <tt>t = 12.2</tt>.</t>
<t>The congestion period is calculated as the time between the oldest and newest <t>The congestion period is calculated as the time between the oldest and newest
lost packets: 8 - 1 = 7. The persistent congestion duration is: 2 * 3 = 6. lost packets: <tt>8 - 1 = 7</tt>. The persistent congestion duration is <tt>2 * 3 = 6</tt>.
Because the threshold was reached and because none of the packets between the Because the threshold was reached and because none of the packets between the
oldest and the newest lost packets were acknowledged, the network is considered oldest and the newest lost packets were acknowledged, the network is considered
to have experienced persistent congestion.</t> to have experienced persistent congestion.</t>
<t>While this example shows PTO expiration, they are not required for persistent <t>While this example shows PTO expiration, they are not required for persistent
congestion to be established.</t> congestion to be established.</t>
</section> </section>
</section> </section>
<section anchor="pacing" numbered="true" toc="default"> <section anchor="pacing" numbered="true" toc="default">
<name>Pacing</name> <name>Pacing</name>
<t>A sender SHOULD pace sending of all in-flight packets based on input from the <t>A sender <bcp14>SHOULD</bcp14> pace sending of all in-flight packets based on input from the
congestion controller.</t> congestion controller.</t>
<t>Sending multiple packets into the network without any delay between t hem creates <t>Sending multiple packets into the network without any delay between t hem creates
a packet burst that might cause short-term congestion and losses. Senders MUST a packet burst that might cause short-term congestion and losses. Senders <bcp14
either use pacing or limit such bursts. Senders SHOULD limit bursts to the >MUST</bcp14>
either use pacing or limit such bursts. Senders <bcp14>SHOULD</bcp14> limit burs
ts to the
initial congestion window; see <xref target="initial-cwnd" format="default"/>. A sender with knowledge that initial congestion window; see <xref target="initial-cwnd" format="default"/>. A sender with knowledge that
the network path to the receiver can absorb larger bursts MAY use a higher the network path to the receiver can absorb larger bursts <bcp14>MAY</bcp14> use a higher
limit.</t> limit.</t>
<t>An implementation should take care to architect its congestion contro ller to <t>An implementation should take care to architect its congestion contro ller to
work well with a pacer. For instance, a pacer might wrap the congestion work well with a pacer. For instance, a pacer might wrap the congestion
controller and control the availability of the congestion window, or a pacer controller and control the availability of the congestion window, or a pacer
might pace out packets handed to it by the congestion controller.</t> might pace out packets handed to it by the congestion controller.</t>
<t>Timely delivery of ACK frames is important for efficient loss recover <t>Timely delivery of ACK frames is important for efficient loss recover
y. Packets y. To avoid
containing only ACK frames SHOULD therefore not be paced, to avoid delaying delaying their delivery to the peer, packets containing only ACK frames <bcp14>S
their delivery to the peer.</t> HOULD</bcp14>
therefore not be paced.</t>
<t>Endpoints can implement pacing as they choose. A perfectly paced send er spreads <t>Endpoints can implement pacing as they choose. A perfectly paced send er spreads
packets exactly evenly over time. For a window-based congestion controller, such packets exactly evenly over time. For a window-based congestion controller, such
as the one in this document, that rate can be computed by averaging the as the one in this document, that rate can be computed by averaging the
congestion window over the round-trip time. Expressed as a rate in units of congestion window over the RTT. Expressed as a rate in units of
bytes per time, where congestion_window is in bytes:</t> bytes per time, where congestion_window is in bytes:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
rate = N * congestion_window / smoothed_rtt rate = N * congestion_window / smoothed_rtt
]]></artwork> ]]></sourcecode>
<t>Or, expressed as an inter-packet interval in units of time:</t> <t>Or expressed as an inter-packet interval in units of time:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
interval = ( smoothed_rtt * packet_size / congestion_window ) / N interval = ( smoothed_rtt * packet_size / congestion_window ) / N
]]></artwork> ]]></sourcecode>
<t>Using a value for <tt>N</tt> that is small, but at least 1 (for examp le, 1.25) ensures <t>Using a value for <tt>N</tt> that is small, but at least 1 (for examp le, 1.25) ensures
that variations in round-trip time do not result in under-utilization of the that variations in RTT do not result in underutilization of the
congestion window.</t> congestion window.</t>
<t>Practical considerations, such as packetization, scheduling delays, a nd <t>Practical considerations, such as packetization, scheduling delays, a nd
computational efficiency, can cause a sender to deviate from this rate over time computational efficiency, can cause a sender to deviate from this rate over time
periods that are much shorter than a round-trip time.</t> periods that are much shorter than an RTT.</t>
<t>One possible implementation strategy for pacing uses a leaky bucket a lgorithm, <t>One possible implementation strategy for pacing uses a leaky bucket a lgorithm,
where the capacity of the "bucket" is limited to the maximum burst size and the where the capacity of the "bucket" is limited to the maximum burst size and the
rate the "bucket" fills is determined by the above function.</t> rate the "bucket" fills is determined by the above function.</t>
</section> </section>
<section anchor="under-utilizing-the-congestion-window" numbered="true" to <section anchor="underutilizing-the-congestion-window" numbered="true" toc
c="default"> ="default">
<name>Under-utilizing the Congestion Window</name> <name>Underutilizing the Congestion Window</name>
<t>When bytes in flight is smaller than the congestion window and sendin g is not <t>When bytes in flight is smaller than the congestion window and sendin g is not
pacing limited, the congestion window is under-utilized. When this occurs, pacing limited, the congestion window is underutilized. This can happen due to
the congestion window SHOULD NOT be increased in either slow start or insufficient application data or flow control limits. When this occurs,
congestion avoidance. This can happen due to insufficient application data the congestion window <bcp14>SHOULD NOT</bcp14> be increased in either slow star
or flow control limits.</t> t or
congestion avoidance.</t>
<t>A sender that paces packets (see <xref target="pacing" format="defaul t"/>) might delay sending packets <t>A sender that paces packets (see <xref target="pacing" format="defaul t"/>) might delay sending packets
and not fully utilize the congestion window due to this delay. A sender and not fully utilize the congestion window due to this delay. A sender
SHOULD NOT consider itself application limited if it would have fully <bcp14>SHOULD NOT</bcp14> consider itself application limited if it would have f ully
utilized the congestion window without pacing delay.</t> utilized the congestion window without pacing delay.</t>
<t>A sender MAY implement alternative mechanisms to update its congestio <t>A sender <bcp14>MAY</bcp14> implement alternative mechanisms to updat
n window e its congestion window
after periods of under-utilization, such as those proposed for TCP in after periods of underutilization, such as those proposed for TCP in
<xref target="RFC7661" format="default"/>.</t> <xref target="RFC7661" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="loss-and-congestion-signals" numbered="true" toc="default "> <section anchor="loss-and-congestion-signals" numbered="true" toc="default ">
<name>Loss and Congestion Signals</name> <name>Loss and Congestion Signals</name>
<t>Loss detection and congestion control fundamentally involve consumpti on of <t>Loss detection and congestion control fundamentally involve the consu mption of
signals, such as delay, loss, and ECN markings, from unauthenticated signals, such as delay, loss, and ECN markings, from unauthenticated
entities. An attacker can cause endpoints to reduce their sending rate by entities. An attacker can cause endpoints to reduce their sending rate by
manipulating these signals; by dropping packets, by altering path delay manipulating these signals: by dropping packets, by altering path delay
strategically, or by changing ECN codepoints.</t> strategically, or by changing ECN codepoints.</t>
</section> </section>
<section anchor="traffic-analysis" numbered="true" toc="default"> <section anchor="traffic-analysis" numbered="true" toc="default">
<name>Traffic Analysis</name> <name>Traffic Analysis</name>
<t>Packets that carry only ACK frames can be heuristically identified by observing <t>Packets that carry only ACK frames can be heuristically identified by observing
packet size. Acknowledgment patterns may expose information about link packet size. Acknowledgment patterns may expose information about link
characteristics or application behavior. To reduce leaked information, characteristics or application behavior. To reduce leaked information,
endpoints can bundle acknowledgments with other frames, or they can use PADDING endpoints can bundle acknowledgments with other frames, or they can use PADDING
frames at a potential cost to performance.</t> frames at a potential cost to performance.</t>
</section> </section>
<section anchor="misreporting-ecn-markings" numbered="true" toc="default"> <section anchor="misreporting-ecn-markings" numbered="true" toc="default">
<name>Misreporting ECN Markings</name> <name>Misreporting ECN Markings</name>
<t>A receiver can misreport ECN markings to alter the congestion respons e of a <t>A receiver can misreport ECN markings to alter the congestion respons e of a
sender. Suppressing reports of ECN-CE markings could cause a sender to sender. Suppressing reports of ECN-CE markings could cause a sender to
increase their send rate. This increase could result in congestion and loss.</t > increase their send rate. This increase could result in congestion and loss.</t >
<t>A sender can detect suppression of reports by marking occasional pack ets that it <t>A sender can detect suppression of reports by marking occasional pack ets that it
sends with an ECN-CE marking. If a packet sent with an ECN-CE marking is not sends with an ECN-CE marking. If a packet sent with an ECN-CE marking is not
reported as having been CE marked when the packet is acknowledged, then the reported as having been CE marked when the packet is acknowledged, then the
sender can disable ECN for that path by not setting ECT codepoints in subsequent sender can disable ECN for that path by not setting ECN-Capable Transport (ECT)
packets sent on that path <xref target="RFC3168" format="default"/>.</t> codepoints in subsequent packets sent on that path <xref target="RFC3168" format
="default"/>.</t>
<t>Reporting additional ECN-CE markings will cause a sender to reduce th eir sending <t>Reporting additional ECN-CE markings will cause a sender to reduce th eir sending
rate, which is similar in effect to advertising reduced connection flow control rate, which is similar in effect to advertising reduced connection flow control
limits and so no advantage is gained by doing so.</t> limits and so no advantage is gained by doing so.</t>
<t>Endpoints choose the congestion controller that they use. Congestion controllers <t>Endpoints choose the congestion controller that they use. Congestion controllers
respond to reports of ECN-CE by reducing their rate, but the response may vary. respond to reports of ECN-CE by reducing their rate, but the response may vary.
Markings can be treated as equivalent to loss (<xref target="RFC3168" format="de Markings can be treated as equivalent to loss <xref target="RFC3168" format="def
fault"/>), but other ault"/>, but other
responses can be specified, such as (<xref target="RFC8511" format="default"/>) responses can be specified, such as <xref target="RFC8511" format="default"/> or
or (<xref target="RFC8311" format="default"/>).</t> <xref target="RFC8311" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="QUIC-TRANSPORT"> <reference anchor="QUIC-TRANSPORT" target="https://www.rfc-editor.org/in fo/rfc9000">
<front> <front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author initials="J." surname="Iyengar" fullname="Jana Iyengar" role ="editor"> <author initials="J." surname="Iyengar" fullname="Jana Iyengar" role ="editor">
<organization>Fastly</organization> <organization>Fastly</organization>
</author> </author>
<author initials="M." surname="Thomson" fullname="Martin Thomson" ro le="editor"> <author initials="M." surname="Thomson" fullname="Martin Thomson" ro le="editor">
<organization>Mozilla</organization> <organization>Mozilla</organization>
</author> </author>
<date year="2021" month="January" day="15"/> <date year="2021" month="May"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34" <seriesInfo name="RFC" value="9000"/>
/> <seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference> </reference>
<reference anchor="QUIC-TLS"> <reference anchor="QUIC-TLS" target="https://www.rfc-editor.org/info/rfc 9001">
<front> <front>
<title>Using TLS to Secure QUIC</title> <title>Using TLS to Secure QUIC</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson" ro le="editor"> <author initials="M." surname="Thomson" fullname="Martin Thomson" ro le="editor">
<organization>Mozilla</organization> <organization>Mozilla</organization>
</author> </author>
<author initials="S." surname="Turner" fullname="Sean Turner" role=" editor"> <author initials="S." surname="Turner" fullname="Sean Turner" role=" editor">
<organization>sn3rd</organization> <organization>sn3rd</organization>
</author> </author>
<date year="2021" month="January" day="15"/> <date year="2021" month="May"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-tls-34"/> <seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert">
<organization/>
</author>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="G. Shepherd" initials="G." surname="Shepherd">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This documen
t provides guidelines on the use of UDP for the designers of applications, tunne
ls, and other protocols that use UDP. Congestion control guidelines are a prima
ry focus, but the document also provides guidance on other topics, including mes
sage sizes, reliability, checksums, middlebox traversal, the use of Explicit Con
gestion Notification (ECN), Differentiated Services Code Points (DSCPs), and por
ts.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference> </reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 119"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 119">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit le> <title>Key words for use in RFCs to Indicate Requirement Levels</tit le>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/> <organization/>
</author> </author>
<date year="1997" month="March"/> <date month="March" year="1997"/>
<abstract> <abstract>
<t>In many standards track documents several words are used to sig nify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF document s. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> <t>In many standards track documents several words are used to sig nify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF document s. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 174"> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 174">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle>
<author initials="B." surname="Leiba" fullname="B. Leiba"> <author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/> <organization/>
</author> </author>
<date year="2017" month="May"/> <date month="May" year="2017"/>
<abstract> <abstract>
<t>RFC 2119 specifies common key words that may be used in protoco l specifications. This document aims to reduce the ambiguity by clarifying tha t only UPPERCASE usage of the key words have the defined special meanings.</t> <t>RFC 2119 specifies common key words that may be used in protoco l specifications. This document aims to reduce the ambiguity by clarifying tha t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085">
<front>
<title>UDP Usage Guidelines</title>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This documen
t provides guidelines on the use of UDP for the designers of applications, tunne
ls, and other protocols that use UDP. Congestion control guidelines are a prima
ry focus, but the document also provides guidance on other topics, including mes
sage sizes, reliability, checksums, middlebox traversal, the use of Explicit Con
gestion Notification (ECN), Differentiated Services Code Points (DSCPs), and por
ts.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3 168"> <reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3 168">
<front> <front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP< /title> <title>The Addition of Explicit Congestion Notification (ECN) to IP< /title>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishn an"> <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishn an">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Floyd" fullname="S. Floyd"> <author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Black" fullname="D. Black"> <author fullname="D. Black" initials="D." surname="Black">
<organization/> <organization/>
</author> </author>
<date year="2001" month="September"/> <date month="September" year="2001"/>
<abstract> <abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congesti on Notification) to TCP and IP, including ECN's use of two bits in the IP header . [STANDARDS-TRACK]</t> <t>This memo specifies the incorporation of ECN (Explicit Congesti on Notification) to TCP and IP, including ECN's use of two bits in the IP header . [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="3168"/> <seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/> <seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="FACK"> <reference anchor="FACK">
<front> <front>
<title>Forward Acknowledgement: Refining TCP Congestion Control</tit le> <title>Forward acknowledgement: Refining TCP Congestion Control</tit le>
<author initials="M." surname="Mathis"> <author initials="M." surname="Mathis">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Mahdavi"> <author initials="J." surname="Mahdavi">
<organization/> <organization/>
</author> </author>
<date year="1996" month="August"/> <date year="1996" month="August"/>
</front> </front>
<seriesInfo name="ACM SIGCOMM" value=""/> <seriesInfo name="DOI" value="10.1145/248157.248181"/>
<refcontent>ACM SIGCOMM Computer Communication Review</refcontent>
</reference> </reference>
<reference anchor="RETRANSMISSION"> <reference anchor="RETRANSMISSION">
<front> <front>
<title>Improving Round-Trip Time Estimates in Reliable Transport Pro tocols</title> <title>Improving Round-Trip Time Estimates in Reliable Transport Pro tocols</title>
<author initials="P." surname="Karn"> <author initials="P." surname="Karn">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Partridge"> <author initials="C." surname="Partridge">
<organization/> <organization/>
</author> </author>
<date year="1995" month="January"/> <date year="1991" month="November"/>
</front> </front>
<seriesInfo name="ACM SIGCOMM CCR" value=""/> <seriesInfo name="DOI" value="10.1145/118544.118549"/>
<refcontent>ACM Transactions on Computer Systems</refcontent>
</reference>
<reference anchor="RFC3465" target="https://www.rfc-editor.org/info/rfc3
465">
<front>
<title>TCP Congestion Control with Appropriate Byte Counting (ABC)</
title>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization/>
</author>
<date month="February" year="2003"/>
<abstract>
<t>This document proposes a small modification to the way TCP incr
eases its congestion window. Rather than the traditional method of increasing t
he congestion window by a constant amount for each arriving acknowledgment, the
document suggests basing the increase on the number of previously unacknowledged
bytes each ACK covers. This change improves the performance of TCP, as well as
closes a security hole TCP receivers can use to induce the sender into increasi
ng the sending rate too rapidly. This memo defines an Experimental Protocol for
the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3465"/>
<seriesInfo name="DOI" value="10.17487/RFC3465"/>
</reference> </reference>
<reference anchor="RFC2018" target="https://www.rfc-editor.org/info/rfc2 018"> <reference anchor="RFC2018" target="https://www.rfc-editor.org/info/rfc2 018">
<front> <front>
<title>TCP Selective Acknowledgment Options</title> <title>TCP Selective Acknowledgment Options</title>
<author initials="M." surname="Mathis" fullname="M. Mathis"> <author fullname="M. Mathis" initials="M." surname="Mathis">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Mahdavi" fullname="J. Mahdavi"> <author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Floyd" fullname="S. Floyd"> <author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Romanow" fullname="A. Romanow"> <author fullname="A. Romanow" initials="A." surname="Romanow">
<organization/> <organization/>
</author> </author>
<date year="1996" month="October"/> <date month="October" year="1996"/>
<abstract> <abstract>
<t>This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]</t> <t>This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="2018"/> <seriesInfo name="RFC" value="2018"/>
<seriesInfo name="DOI" value="10.17487/RFC2018"/> <seriesInfo name="DOI" value="10.17487/RFC2018"/>
</reference> </reference>
<reference anchor="RFC6297" target="https://www.rfc-editor.org/info/rfc6 297"> <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6 298">
<front> <front>
<title>A Survey of Lower-than-Best-Effort Transport Protocols</title <title>Computing TCP's Retransmission Timer</title>
> <author fullname="V. Paxson" initials="V." surname="Paxson">
<author initials="M." surname="Welzl" fullname="M. Welzl">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Ros" fullname="D. Ros"> <author fullname="M. Allman" initials="M." surname="Allman">
<organization/> <organization/>
</author> </author>
<date year="2011" month="June"/> <author fullname="J. Chu" initials="J." surname="Chu">
<organization/>
</author>
<author fullname="M. Sargent" initials="M." surname="Sargent">
<organization/>
</author>
<date month="June" year="2011"/>
<abstract> <abstract>
<t>This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than s tandard TCP itself when they share a bottleneck with it. Such protocols could be used for delay-insensitive "background" traffic, as they provide what is someti mes called a "less than" (or "lower than") best-effort service. This document i s not an Internet Standards Track specification; it is published for informati onal purposes.</t> <t>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their r etransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 112 2 and upgrades the requirement of supporting the algorithm from a <bcp14>SHOULD< /bcp14> to a <bcp14>MUST</bcp14>. This document obsoletes RFC 2988. [STANDARD S-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6297"/> <seriesInfo name="RFC" value="6298"/>
<seriesInfo name="DOI" value="10.17487/RFC6297"/> <seriesInfo name="DOI" value="10.17487/RFC6298"/>
</reference> </reference>
<reference anchor="RACK" target="http://www.ietf.org/internet-drafts/dra ft-ietf-tcpm-rack-15.txt"> <reference anchor="RFC8985" target="https://www.rfc-editor.org/info/rfc8 985">
<front> <front>
<title>The RACK-TLP loss detection algorithm for TCP</title> <title>The RACK-TLP Loss Detection Algorithm for TCP</title>
<author initials="Y" surname="Cheng" fullname="Yuchung Cheng"> <author fullname="Y. Cheng" initials="Y." surname="Cheng">
<organization/> <organization/>
</author> </author>
<author initials="N" surname="Cardwell" fullname="Neal Cardwell"> <author fullname="N. Cardwell" initials="N." surname="Cardwell">
<organization/> <organization/>
</author> </author>
<author initials="N" surname="Dukkipati" fullname="Nandita Dukkipati "> <author fullname="N. Dukkipati" initials="N." surname="Dukkipati">
<organization/> <organization/>
</author> </author>
<author initials="P" surname="Jha" fullname="Priyaranjan Jha"> <author fullname="P. Jha" initials="P." surname="Jha">
<organization/> <organization/>
</author> </author>
<date month="December" day="22" year="2020"/> <date month="February" year="2021"/>
<abstract> <abstract>
<t>This document presents the RACK-TLP loss detection algorithm fo r TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgeme nts (SACK) and has two parts: RACK ("Recent ACKnowledgment") starts fast recover y quickly using time-based inferences derived from ACK feedback. TLP ("Tail Los s Probe") leverages RACK and sends a probe packet to trigger ACK feedback to avo id retransmission timeout (RTO) events. Compared to the widely used DUPACK thre shold approach, RACK-TLP detects losses more efficiently when there are applicat ion-limited flights of data, lost retransmissions, or data packet reordering eve nts. It is intended to be an alternative to the DUPACK threshold approach.</t> <t>This document presents the RACK-TLP loss detection algorithm fo r TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgmen ts (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely u sed duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losse s more efficiently when there are application-limited flights of data, lost retr ansmissions, or data packet reordering events. It is intended to be an alternati ve to the DupAck threshold approach.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-rack-15"/> <seriesInfo name="RFC" value="8985"/>
<seriesInfo name="DOI" value="10.17487/RFC8985"/>
</reference> </reference>
<reference anchor="RFC5682" target="https://www.rfc-editor.org/info/rfc5 682"> <reference anchor="RFC5682" target="https://www.rfc-editor.org/info/rfc5 682">
<front> <front>
<title>Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spur ious Retransmission Timeouts with TCP</title> <title>Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spur ious Retransmission Timeouts with TCP</title>
<author initials="P." surname="Sarolahti" fullname="P. Sarolahti"> <author fullname="P. Sarolahti" initials="P." surname="Sarolahti">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Kojo" fullname="M. Kojo"> <author fullname="M. Kojo" initials="M." surname="Kojo">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Yamamoto" fullname="K. Yamamoto"> <author fullname="K. Yamamoto" initials="K." surname="Yamamoto">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Hata" fullname="M. Hata"> <author fullname="M. Hata" initials="M." surname="Hata">
<organization/> <organization/>
</author> </author>
<date year="2009" month="September"/> <date month="September" year="2009"/>
<abstract> <abstract>
<t>The purpose of this document is to move the F-RTO (Forward RTO- Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in R FC 4138 remains with Experimental status. See Appendix B for the differences be tween this document and RFC 4138.</t> <t>The purpose of this document is to move the F-RTO (Forward RTO- Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in R FC 4138 remains with Experimental status. See Appendix B for the differences be tween this document and RFC 4138.</t>
<t>Spurious retransmission timeouts cause suboptimal TCP performan ce because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spur ious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that doe s not require any TCP options to operate. After retransmitting the first unackn owledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender m onitors the incoming acknowledgments to determine whether the timeout was spurio us. It then decides whether to send new segments or retransmit unacknowledged s egments. The algorithm effectively helps to avoid additional unnecessary retran smissions and thereby improves TCP performance in the case of a spurious timeout . [STANDARDS-TRACK]</t> <t>Spurious retransmission timeouts cause suboptimal TCP performan ce because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spur ious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that doe s not require any TCP options to operate. After retransmitting the first unackn owledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender m onitors the incoming acknowledgments to determine whether the timeout was spurio us. It then decides whether to send new segments or retransmit unacknowledged s egments. The algorithm effectively helps to avoid additional unnecessary retran smissions and thereby improves TCP performance in the case of a spurious timeout . [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5682"/> <seriesInfo name="RFC" value="5682"/>
<seriesInfo name="DOI" value="10.17487/RFC5682"/> <seriesInfo name="DOI" value="10.17487/RFC5682"/>
</reference> </reference>
<reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6
298">
<front>
<title>Computing TCP's Retransmission Timer</title>
<author initials="V." surname="Paxson" fullname="V. Paxson">
<organization/>
</author>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization/>
</author>
<author initials="J." surname="Chu" fullname="J. Chu">
<organization/>
</author>
<author initials="M." surname="Sargent" fullname="M. Sargent">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>This document defines the standard algorithm that Transmission
Control Protocol (TCP) senders are required to use to compute and manage their r
etransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 112
2 and upgrades the requirement of supporting the algorithm from a SHOULD to a MU
ST. This document obsoletes RFC 2988. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6298"/>
<seriesInfo name="DOI" value="10.17487/RFC6298"/>
</reference>
<reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc5 681"> <reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc5 681">
<front> <front>
<title>TCP Congestion Control</title> <title>TCP Congestion Control</title>
<author initials="M." surname="Allman" fullname="M. Allman"> <author fullname="M. Allman" initials="M." surname="Allman">
<organization/> <organization/>
</author> </author>
<author initials="V." surname="Paxson" fullname="V. Paxson"> <author fullname="V. Paxson" initials="V." surname="Paxson">
<organization/> <organization/>
</author> </author>
<author initials="E." surname="Blanton" fullname="E. Blanton"> <author fullname="E. Blanton" initials="E." surname="Blanton">
<organization/> <organization/>
</author> </author>
<date year="2009" month="September"/> <date month="September" year="2009"/>
<abstract> <abstract>
<t>This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recover y. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment gene ration methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t> <t>This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recover y. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment gene ration methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5681"/> <seriesInfo name="RFC" value="5681"/>
<seriesInfo name="DOI" value="10.17487/RFC5681"/> <seriesInfo name="DOI" value="10.17487/RFC5681"/>
</reference> </reference>
<reference anchor="RFC5827" target="https://www.rfc-editor.org/info/rfc5 827"> <reference anchor="RFC5827" target="https://www.rfc-editor.org/info/rfc5 827">
<front> <front>
<title>Early Retransmit for TCP and Stream Control Transmission Prot ocol (SCTP)</title> <title>Early Retransmit for TCP and Stream Control Transmission Prot ocol (SCTP)</title>
<author initials="M." surname="Allman" fullname="M. Allman"> <author fullname="M. Allman" initials="M." surname="Allman">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Avrachenkov" fullname="K. Avrachenkov "> <author fullname="K. Avrachenkov" initials="K." surname="Avrachenkov ">
<organization/> <organization/>
</author> </author>
<author initials="U." surname="Ayesta" fullname="U. Ayesta"> <author fullname="U. Ayesta" initials="U." surname="Ayesta">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Blanton" fullname="J. Blanton"> <author fullname="J. Blanton" initials="J." surname="Blanton">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Hurtig" fullname="P. Hurtig"> <author fullname="P. Hurtig" initials="P." surname="Hurtig">
<organization/> <organization/>
</author> </author>
<date year="2010" month="May"/> <date month="May" year="2010"/>
<abstract> <abstract>
<t>This document proposes a new mechanism for TCP and Stream Contr ol Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allo ws the transport to reduce, in certain special circumstances, the number of dupl icate acknowledgments required to trigger a fast retransmission. This allows th e transport to use fast retransmit to recover segment losses that would otherwis e require a lengthy retransmission timeout. [STANDARDS-TRACK]</t> <t>This document proposes a new mechanism for TCP and Stream Contr ol Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allo ws the transport to reduce, in certain special circumstances, the number of dupl icate acknowledgments required to trigger a fast retransmission. This allows th e transport to use fast retransmit to recover segment losses that would otherwis e require a lengthy retransmission timeout. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5827"/> <seriesInfo name="RFC" value="5827"/>
<seriesInfo name="DOI" value="10.17487/RFC5827"/> <seriesInfo name="DOI" value="10.17487/RFC5827"/>
</reference> </reference>
<reference anchor="RFC6675" target="https://www.rfc-editor.org/info/rfc6 675"> <reference anchor="RFC6675" target="https://www.rfc-editor.org/info/rfc6 675">
<front> <front>
<title>A Conservative Loss Recovery Algorithm Based on Selective Ack nowledgment (SACK) for TCP</title> <title>A Conservative Loss Recovery Algorithm Based on Selective Ack nowledgment (SACK) for TCP</title>
<author initials="E." surname="Blanton" fullname="E. Blanton"> <author fullname="E. Blanton" initials="E." surname="Blanton">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Allman" fullname="M. Allman"> <author fullname="M. Allman" initials="M." surname="Allman">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Wang" fullname="L. Wang"> <author fullname="L. Wang" initials="L." surname="Wang">
<organization/> <organization/>
</author> </author>
<author initials="I." surname="Jarvinen" fullname="I. Jarvinen"> <author fullname="I. Jarvinen" initials="I." surname="Jarvinen">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Kojo" fullname="M. Kojo"> <author fullname="M. Kojo" initials="M." surname="Kojo">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Nishida" fullname="Y. Nishida"> <author fullname="Y. Nishida" initials="Y." surname="Nishida">
<organization/> <organization/>
</author> </author>
<date year="2012" month="August"/> <date month="August" year="2012"/>
<abstract> <abstract>
<t>This document presents a conservative loss recovery algorithm f or TCP that is based on the use of the selective acknowledgment (SACK) TCP optio n. The algorithm presented in this document conforms to the spirit of the curre nt congestion control specification (RFC 5681), but allows TCP senders to recove r more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TR ACK]</t> <t>This document presents a conservative loss recovery algorithm f or TCP that is based on the use of the selective acknowledgment (SACK) TCP optio n. The algorithm presented in this document conforms to the spirit of the curre nt congestion control specification (RFC 5681), but allows TCP senders to recove r more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TR ACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6675"/> <seriesInfo name="RFC" value="6675"/>
<seriesInfo name="DOI" value="10.17487/RFC6675"/> <seriesInfo name="DOI" value="10.17487/RFC6675"/>
</reference> </reference>
<reference anchor="RFC6582" target="https://www.rfc-editor.org/info/rfc6 582"> <reference anchor="RFC6582" target="https://www.rfc-editor.org/info/rfc6 582">
<front> <front>
<title>The NewReno Modification to TCP's Fast Recovery Algorithm</ti tle> <title>The NewReno Modification to TCP's Fast Recovery Algorithm</ti tle>
<author initials="T." surname="Henderson" fullname="T. Henderson"> <author fullname="T. Henderson" initials="T." surname="Henderson">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Floyd" fullname="S. Floyd"> <author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Gurtov" fullname="A. Gurtov"> <author fullname="A. Gurtov" initials="A." surname="Gurtov">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Nishida" fullname="Y. Nishida"> <author fullname="Y. Nishida" initials="Y." surname="Nishida">
<organization/> <organization/>
</author> </author>
<date year="2012" month="April"/> <date month="April" year="2012"/>
<abstract> <abstract>
<t>RFC 5681 documents the following four intertwined TCP congestio n control algorithms: slow start, congestion avoidance, fast retransmit, and fas t recovery. RFC 5681 explicitly allows certain modifications of these algorithm s, including modifications that use the TCP Selective Acknowledgment (SACK) opti on (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) i n the absence of SACK. This document describes a specific algorithm for respond ing to partial acknowledgments, referred to as "NewReno". This response to part ial acknowledgments was first proposed by Janey Hoe. This document obsoletes RF C 3782. [STANDARDS-TRACK]</t> <t>RFC 5681 documents the following four intertwined TCP congestio n control algorithms: slow start, congestion avoidance, fast retransmit, and fas t recovery. RFC 5681 explicitly allows certain modifications of these algorithm s, including modifications that use the TCP Selective Acknowledgment (SACK) opti on (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) i n the absence of SACK. This document describes a specific algorithm for respond ing to partial acknowledgments, referred to as "NewReno". This response to part ial acknowledgments was first proposed by Janey Hoe. This document obsoletes RF C 3782. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6582"/> <seriesInfo name="RFC" value="6582"/>
<seriesInfo name="DOI" value="10.17487/RFC6582"/> <seriesInfo name="DOI" value="10.17487/RFC6582"/>
</reference> </reference>
<reference anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc8 312"> <reference anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc8 312">
<front> <front>
<title>CUBIC for Fast Long-Distance Networks</title> <title>CUBIC for Fast Long-Distance Networks</title>
<author initials="I." surname="Rhee" fullname="I. Rhee"> <author fullname="I. Rhee" initials="I." surname="Rhee">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Xu" fullname="L. Xu"> <author fullname="L. Xu" initials="L." surname="Xu">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Ha" fullname="S. Ha"> <author fullname="S. Ha" initials="S." surname="Ha">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Zimmermann" fullname="A. Zimmermann"> <author fullname="A. Zimmermann" initials="A." surname="Zimmermann">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Eggert" fullname="L. Eggert"> <author fullname="L. Eggert" initials="L." surname="Eggert">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Scheffenegger" fullname="R. Scheffene gger"> <author fullname="R. Scheffenegger" initials="R." surname="Scheffene gger">
<organization/> <organization/>
</author> </author>
<date year="2018" month="February"/> <date month="February" year="2018"/>
<abstract> <abstract>
<t>CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stabi lity under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementation s and to solicit community feedback through experimentation on the performance o f CUBIC.</t> <t>CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stabi lity under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementation s and to solicit community feedback through experimentation on the performance o f CUBIC.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8312"/> <seriesInfo name="RFC" value="8312"/>
<seriesInfo name="DOI" value="10.17487/RFC8312"/> <seriesInfo name="DOI" value="10.17487/RFC8312"/>
</reference> </reference>
<reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8 311"> <reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8 311">
<front> <front>
<title>Relaxing Restrictions on Explicit Congestion Notification (EC N) Experimentation</title> <title>Relaxing Restrictions on Explicit Congestion Notification (EC N) Experimentation</title>
<author initials="D." surname="Black" fullname="D. Black"> <author fullname="D. Black" initials="D." surname="Black">
<organization/> <organization/>
</author> </author>
<date year="2018" month="January"/> <date month="January" year="2018"/>
<abstract> <abstract>
<t>This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network con gestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimen tation towards benefits beyond just removal of loss. This memo summarizes the a nticipated areas of experimentation and updates RFC 3168 to enable experimentati on in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo make s related updates to the ECN specifications for RTP in RFC 6679 and for the Data gram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provide s the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.</t> <t>This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network con gestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimen tation towards benefits beyond just removal of loss. This memo summarizes the a nticipated areas of experimentation and updates RFC 3168 to enable experimentati on in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo make s related updates to the ECN specifications for RTP in RFC 6679 and for the Data gram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provide s the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8311"/> <seriesInfo name="RFC" value="8311"/>
<seriesInfo name="DOI" value="10.17487/RFC8311"/> <seriesInfo name="DOI" value="10.17487/RFC8311"/>
</reference> </reference>
<reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc6 928"> <reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc6 928">
<front> <front>
<title>Increasing TCP's Initial Window</title> <title>Increasing TCP's Initial Window</title>
<author initials="J." surname="Chu" fullname="J. Chu"> <author fullname="J. Chu" initials="J." surname="Chu">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Dukkipati" fullname="N. Dukkipati"> <author fullname="N. Dukkipati" initials="N." surname="Dukkipati">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Cheng" fullname="Y. Cheng"> <author fullname="Y. Cheng" initials="Y." surname="Cheng">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Mathis" fullname="M. Mathis"> <author fullname="M. Mathis" initials="M." surname="Mathis">
<organization/> <organization/>
</author> </author>
<date year="2013" month="April"/> <date month="April" year="2013"/>
<abstract> <abstract>
<t>This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advan tages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion c ollapse. The document closes with a discussion of usage and deployment for furt her experimental purposes recommended by the IETF TCP Maintenance and Minor Exte nsions (TCPM) working group.</t> <t>This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advan tages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion c ollapse. The document closes with a discussion of usage and deployment for furt her experimental purposes recommended by the IETF TCP Maintenance and Minor Exte nsions (TCPM) working group.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6928"/> <seriesInfo name="RFC" value="6928"/>
<seriesInfo name="DOI" value="10.17487/RFC6928"/> <seriesInfo name="DOI" value="10.17487/RFC6928"/>
</reference> </reference>
<reference anchor="PRR" target="https://www.rfc-editor.org/info/rfc6937" > <reference anchor="PRR" target="https://www.rfc-editor.org/info/rfc6937" >
<front> <front>
<title>Proportional Rate Reduction for TCP</title> <title>Proportional Rate Reduction for TCP</title>
<author initials="M." surname="Mathis" fullname="M. Mathis"> <author fullname="M. Mathis" initials="M." surname="Mathis">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Dukkipati" fullname="N. Dukkipati"> <author fullname="N. Dukkipati" initials="N." surname="Dukkipati">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Cheng" fullname="Y. Cheng"> <author fullname="Y. Cheng" initials="Y." surname="Cheng">
<organization/> <organization/>
</author> </author>
<date year="2013" month="May"/> <date month="May" year="2013"/>
<abstract> <abstract>
<t>This document describes an experimental Proportional Rate Reduc tion (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actu al window size at the end of recovery will be as close as possible to the ssthre sh, as determined by the congestion control algorithm.</t> <t>This document describes an experimental Proportional Rate Reduc tion (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actu al window size at the end of recovery will be as close as possible to the ssthre sh, as determined by the congestion control algorithm.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6937"/> <seriesInfo name="RFC" value="6937"/>
<seriesInfo name="DOI" value="10.17487/RFC6937"/> <seriesInfo name="DOI" value="10.17487/RFC6937"/>
</reference> </reference>
<reference anchor="RFC7661" target="https://www.rfc-editor.org/info/rfc7 661"> <reference anchor="RFC7661" target="https://www.rfc-editor.org/info/rfc7 661">
<front> <front>
<title>Updating TCP to Support Rate-Limited Traffic</title> <title>Updating TCP to Support Rate-Limited Traffic</title>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst"> <author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Sathiaseelan" fullname="A. Sathiaseel an"> <author fullname="A. Sathiaseelan" initials="A." surname="Sathiaseel an">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Secchi" fullname="R. Secchi"> <author fullname="R. Secchi" initials="R." surname="Secchi">
<organization/> <organization/>
</author> </author>
<date year="2015" month="October"/> <date month="October" year="2015"/>
<abstract> <abstract>
<t>This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is li mited by the application rather than the congestion window. It provides an expe rimental update to TCP that allows a TCP sender to restart quickly following a r ate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.</t> <t>This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is li mited by the application rather than the congestion window. It provides an expe rimental update to TCP that allows a TCP sender to restart quickly following a r ate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.</t>
<t>This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RF C 2861 sought to address important issues but failed to deliver a widely used so lution. This document therefore reclassifies the status of RFC 2861 from Experi mental to Historic. This document obsoletes RFC 2861.</t> <t>This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RF C 2861 sought to address important issues but failed to deliver a widely used so lution. This document therefore reclassifies the status of RFC 2861 from Experi mental to Historic. This document obsoletes RFC 2861.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7661"/> <seriesInfo name="RFC" value="7661"/>
<seriesInfo name="DOI" value="10.17487/RFC7661"/> <seriesInfo name="DOI" value="10.17487/RFC7661"/>
</reference> </reference>
<reference anchor="RFC8511" target="https://www.rfc-editor.org/info/rfc8 511"> <reference anchor="RFC8511" target="https://www.rfc-editor.org/info/rfc8 511">
<front> <front>
<title>TCP Alternative Backoff with ECN (ABE)</title> <title>TCP Alternative Backoff with ECN (ABE)</title>
<author initials="N." surname="Khademi" fullname="N. Khademi"> <author fullname="N. Khademi" initials="N." surname="Khademi">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Welzl" fullname="M. Welzl"> <author fullname="M. Welzl" initials="M." surname="Welzl">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Armitage" fullname="G. Armitage"> <author fullname="G. Armitage" initials="G." surname="Armitage">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst"> <author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/> <organization/>
</author> </author>
<date year="2018" month="December"/> <date month="December" year="2018"/>
<abstract> <abstract>
<t>Active Queue Management (AQM) mechanisms allow for burst tolera nce while enforcing short queues to minimise the time that packets spend enqueue d at a bottleneck. This can cause noticeable performance degradation for TCP co nnections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is the refore likely to be short. Feedback of this signal allows the TCP sender-side E CN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred pack et loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.</t> <t>Active Queue Management (AQM) mechanisms allow for burst tolera nce while enforcing short queues to minimise the time that packets spend enqueue d at a bottleneck. This can cause noticeable performance degradation for TCP co nnections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is the refore likely to be short. Feedback of this signal allows the TCP sender-side E CN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred pack et loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8511"/> <seriesInfo name="RFC" value="8511"/>
<seriesInfo name="DOI" value="10.17487/RFC8511"/> <seriesInfo name="DOI" value="10.17487/RFC8511"/>
</reference> </reference>
<reference anchor="RFC3465" target="https://www.rfc-editor.org/info/rfc3
465">
<front>
<title>TCP Congestion Control with Appropriate Byte Counting (ABC)</
title>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization/>
</author>
<date year="2003" month="February"/>
<abstract>
<t>This document proposes a small modification to the way TCP incr
eases its congestion window. Rather than the traditional method of increasing t
he congestion window by a constant amount for each arriving acknowledgment, the
document suggests basing the increase on the number of previously unacknowledged
bytes each ACK covers. This change improves the performance of TCP, as well as
closes a security hole TCP receivers can use to induce the sender into increasi
ng the sending rate too rapidly. This memo defines an Experimental Protocol for
the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3465"/>
<seriesInfo name="DOI" value="10.17487/RFC3465"/>
</reference>
</references> </references>
</references> </references>
<section anchor="loss-recovery-pseudocode" numbered="true" toc="default"> <section anchor="loss-recovery-pseudocode" numbered="true" toc="default">
<name>Loss Recovery Pseudocode</name> <name>Loss Recovery Pseudocode</name>
<t>We now describe an example implementation of the loss detection mechani sms <t>We now describe an example implementation of the loss detection mechani sms
described in <xref target="loss-detection" format="default"/>.</t> described in <xref target="loss-detection" format="default"/>.</t>
<t>The pseudocode segments in this section are licensed as Code Components ; see the <t>The pseudocode segments in this section are licensed as Code Components ; see the
copyright notice.</t> copyright notice.</t>
<section anchor="tracking-sent-packets" numbered="true" toc="default"> <section anchor="tracking-sent-packets" numbered="true" toc="default">
<name>Tracking Sent Packets</name> <name>Tracking Sent Packets</name>
<t>To correctly implement congestion control, a QUIC sender tracks every <t>To correctly implement congestion control, a QUIC sender tracks every
ack-eliciting packet until the packet is acknowledged or lost. ack-eliciting packet until the packet is acknowledged or lost.
It is expected that implementations will be able to access this information by It is expected that implementations will be able to access this information by
packet number and crypto context and store the per-packet fields packet number and crypto context and store the per-packet fields
(<xref target="sent-packets-fields" format="default"/>) for loss recovery and co ngestion control.</t> (<xref target="sent-packets-fields" format="default"/>) for loss recovery and co ngestion control.</t>
<t>After a packet is declared lost, the endpoint can still maintain stat e for it <t>After a packet is declared lost, the endpoint can still maintain stat e for it
for an amount of time to allow for packet reordering; see Section 13.3 of for an amount of time to allow for packet reordering; see <xref section="13.3" s
<xref target="QUIC-TRANSPORT" format="default"/>. This enables a sender to detec ectionFormat="of" target="QUIC-TRANSPORT" format="default"/>. This enables a sen
t spurious retransmissions.</t> der to detect spurious retransmissions.</t>
<t>Sent packets are tracked for each packet number space, and ACK <t>Sent packets are tracked for each packet number space, and ACK
processing only applies to a single space.</t> processing only applies to a single space.</t>
<section anchor="sent-packets-fields" numbered="true" toc="default"> <section anchor="sent-packets-fields" numbered="true" toc="default">
<name>Sent Packet Fields</name> <name>Sent Packet Fields</name>
<dl> <dl>
<dt> <dt>packet_number:</dt>
packet_number: </dt>
<dd> <dd>
<t>The packet number of the sent packet.</t> <t>The packet number of the sent packet.</t>
</dd> </dd>
<dt> <dt>ack_eliciting:</dt>
ack_eliciting: </dt>
<dd> <dd>
<t>A boolean that indicates whether a packet is ack-eliciting. <t>A Boolean that indicates whether a packet is ack-eliciting.
If true, it is expected that an acknowledgment will be received, If true, it is expected that an acknowledgment will be received,
though the peer could delay sending the ACK frame containing it though the peer could delay sending the ACK frame containing it
by up to the max_ack_delay.</t> by up to the max_ack_delay.</t>
</dd> </dd>
<dt> <dt>in_flight:</dt>
in_flight: </dt>
<dd> <dd>
<t>A boolean that indicates whether the packet counts towards byte s in <t>A Boolean that indicates whether the packet counts toward bytes in
flight.</t> flight.</t>
</dd> </dd>
<dt> <dt>sent_bytes:</dt>
sent_bytes: </dt>
<dd> <dd>
<t>The number of bytes sent in the packet, not including UDP or IP <t>The number of bytes sent in the packet, not including UDP or IP
overhead, but including QUIC framing overhead.</t> overhead, but including QUIC framing overhead.</t>
</dd> </dd>
<dt> <dt>time_sent:</dt>
time_sent: </dt>
<dd> <dd>
<t>The time the packet was sent.</t> <t>The time the packet was sent.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="constants-of-interest" numbered="true" toc="default"> <section anchor="constants-of-interest" numbered="true" toc="default">
<name>Constants of Interest</name> <name>Constants of Interest</name>
<t>Constants used in loss recovery are based on a combination of RFCs, p apers, and <t>Constants used in loss recovery are based on a combination of RFCs, p apers, and
common practice.</t> common practice.</t>
<dl> <dl>
<dt> <dt>kPacketThreshold:</dt>
kPacketThreshold: </dt>
<dd> <dd>
<t>Maximum reordering in packets before packet threshold loss detect ion <t>Maximum reordering in packets before packet threshold loss detect ion
considers a packet lost. The value recommended in <xref target="packet-threshold " format="default"/> is 3.</t> considers a packet lost. The value recommended in <xref target="packet-threshold " format="default"/> is 3.</t>
</dd> </dd>
<dt> <dt>kTimeThreshold:</dt>
kTimeThreshold: </dt>
<dd> <dd>
<t>Maximum reordering in time before time threshold loss detection <t>Maximum reordering in time before time threshold loss detection
considers a packet lost. Specified as an RTT multiplier. The value considers a packet lost. Specified as an RTT multiplier. The value
recommended in <xref target="time-threshold" format="default"/> is 9/8.</t> recommended in <xref target="time-threshold" format="default"/> is 9/8.</t>
</dd> </dd>
<dt> <dt>kGranularity:</dt>
kGranularity: </dt>
<dd> <dd>
<t>Timer granularity. This is a system-dependent value, and <xref ta rget="time-threshold" format="default"/> <t>Timer granularity. This is a system-dependent value, and <xref ta rget="time-threshold" format="default"/>
recommends a value of 1ms.</t> recommends a value of 1 ms.</t>
</dd> </dd>
<dt> <dt>kInitialRtt:</dt>
kInitialRtt: </dt>
<dd> <dd>
<t>The RTT used before an RTT sample is taken. The value recommended in <t>The RTT used before an RTT sample is taken. The value recommended in
<xref target="pto-handshake" format="default"/> is 333ms.</t> <xref target="pto-handshake" format="default"/> is 333 ms.</t>
</dd> </dd>
<dt> <dt>kPacketNumberSpace:</dt>
kPacketNumberSpace: </dt>
<dd> <dd>
<t>An enum to enumerate the three packet number spaces.</t> <t>An enum to enumerate the three packet number spaces:</t>
</dd> </dd>
</dl> </dl>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
enum kPacketNumberSpace { enum kPacketNumberSpace {
Initial, Initial,
Handshake, Handshake,
ApplicationData, ApplicationData,
} }
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="ld-vars-of-interest" numbered="true" toc="default"> <section anchor="ld-vars-of-interest" numbered="true" toc="default">
<name>Variables of interest</name> <name>Variables of Interest</name>
<t>Variables required to implement the congestion control mechanisms <t>Variables required to implement the congestion control mechanisms
are described in this section.</t> are described in this section.</t>
<dl> <dl>
<dt> <dt>latest_rtt:</dt>
latest_rtt: </dt>
<dd> <dd>
<t>The most recent RTT measurement made when receiving an ack for <t>The most recent RTT measurement made when receiving an acknowledg
a previously unacked packet.</t> ment for
a previously unacknowledged packet.</t>
</dd> </dd>
<dt> <dt>smoothed_rtt:</dt>
smoothed_rtt: </dt>
<dd> <dd>
<t>The smoothed RTT of the connection, computed as described in <t>The smoothed RTT of the connection, computed as described in
<xref target="smoothed-rtt" format="default"/>.</t> <xref target="smoothed-rtt" format="default"/>.</t>
</dd> </dd>
<dt> <dt>rttvar:</dt>
rttvar: </dt>
<dd> <dd>
<t>The RTT variation, computed as described in <xref target="smoothe d-rtt" format="default"/>.</t> <t>The RTT variation, computed as described in <xref target="smoothe d-rtt" format="default"/>.</t>
</dd> </dd>
<dt> <dt>min_rtt:</dt>
min_rtt: </dt>
<dd> <dd>
<t>The minimum RTT seen over a period of time, ignoring acknowledgme nt delay, as <t>The minimum RTT seen over a period of time, ignoring acknowledgme nt delay, as
described in <xref target="min-rtt" format="default"/>.</t> described in <xref target="min-rtt" format="default"/>.</t>
</dd> </dd>
<dt> <dt>first_rtt_sample:</dt>
first_rtt_sample: </dt>
<dd> <dd>
<t>The time that the first RTT sample was obtained.</t> <t>The time that the first RTT sample was obtained.</t>
</dd> </dd>
<dt> <dt>max_ack_delay:</dt>
max_ack_delay: </dt>
<dd> <dd>
<t>The maximum amount of time by which the receiver intends to delay <t>The maximum amount of time by which the receiver intends to delay
acknowledgments for packets in the Application Data packet number acknowledgments for packets in the Application Data packet number
space, as defined by the eponymous transport parameter (Section 18.2 space, as defined by the eponymous transport parameter (<xref section="18.2" sec
of <xref target="QUIC-TRANSPORT" format="default"/>). Note that the actual ack_d tionFormat="of" target="QUIC-TRANSPORT" format="default"/>). Note that the actua
elay in a received l ack_delay in a received
ACK frame may be larger due to late timers, reordering, or loss.</t> ACK frame may be larger due to late timers, reordering, or loss.</t>
</dd> </dd>
<dt> <dt>loss_detection_timer:</dt>
loss_detection_timer: </dt>
<dd> <dd>
<t>Multi-modal timer used for loss detection.</t> <t>Multi-modal timer used for loss detection.</t>
</dd> </dd>
<dt> <dt>pto_count:</dt>
pto_count: </dt>
<dd> <dd>
<t>The number of times a PTO has been sent without receiving an ack. </t> <t>The number of times a PTO has been sent without receiving an ackn owledgment.</t>
</dd> </dd>
<dt> <dt>time_of_last_ack_eliciting_packet[kPacketNumberSpace]:</dt>
time_of_last_ack_eliciting_packet[kPacketNumberSpace]: </dt>
<dd> <dd>
<t>The time the most recent ack-eliciting packet was sent.</t> <t>The time the most recent ack-eliciting packet was sent.</t>
</dd> </dd>
<dt> <dt>largest_acked_packet[kPacketNumberSpace]:</dt>
largest_acked_packet[kPacketNumberSpace]: </dt>
<dd> <dd>
<t>The largest packet number acknowledged in the packet number space so far.</t> <t>The largest packet number acknowledged in the packet number space so far.</t>
</dd> </dd>
<dt> <dt>loss_time[kPacketNumberSpace]:</dt>
loss_time[kPacketNumberSpace]: </dt>
<dd> <dd>
<t>The time at which the next packet in that packet number space can be <t>The time at which the next packet in that packet number space can be
considered lost based on exceeding the reordering window in time.</t> considered lost based on exceeding the reordering window in time.</t>
</dd> </dd>
<dt> <dt>sent_packets[kPacketNumberSpace]:</dt>
sent_packets[kPacketNumberSpace]: </dt>
<dd> <dd>
<t>An association of packet numbers in a packet number space to info rmation <t>An association of packet numbers in a packet number space to info rmation
about them. Described in detail above in <xref target="tracking-sent-packets" f ormat="default"/>.</t> about them. Described in detail above in <xref target="tracking-sent-packets" f ormat="default"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="initialization" numbered="true" toc="default"> <section anchor="initialization" numbered="true" toc="default">
<name>Initialization</name> <name>Initialization</name>
<t>At the beginning of the connection, initialize the loss detection var iables as <t>At the beginning of the connection, initialize the loss detection var iables as
follows:</t> follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
loss_detection_timer.reset() loss_detection_timer.reset()
pto_count = 0 pto_count = 0
latest_rtt = 0 latest_rtt = 0
smoothed_rtt = kInitialRtt smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2 rttvar = kInitialRtt / 2
min_rtt = 0 min_rtt = 0
first_rtt_sample = 0 first_rtt_sample = 0
for pn_space in [ Initial, Handshake, ApplicationData ]: for pn_space in [ Initial, Handshake, ApplicationData ]:
largest_acked_packet[pn_space] = infinite largest_acked_packet[pn_space] = infinite
time_of_last_ack_eliciting_packet[pn_space] = 0 time_of_last_ack_eliciting_packet[pn_space] = 0
loss_time[pn_space] = 0 loss_time[pn_space] = 0
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="on-sending-a-packet" numbered="true" toc="default"> <section anchor="on-sending-a-packet" numbered="true" toc="default">
<name>On Sending a Packet</name> <name>On Sending a Packet</name>
<t>After a packet is sent, information about the packet is stored. The parameters <t>After a packet is sent, information about the packet is stored. The parameters
to OnPacketSent are described in detail above in <xref target="sent-packets-fiel ds" format="default"/>.</t> to OnPacketSent are described in detail above in <xref target="sent-packets-fiel ds" format="default"/>.</t>
<t>Pseudocode for OnPacketSent follows:</t> <t>Pseudocode for OnPacketSent follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
OnPacketSent(packet_number, pn_space, ack_eliciting, OnPacketSent(packet_number, pn_space, ack_eliciting,
in_flight, sent_bytes): in_flight, sent_bytes):
sent_packets[pn_space][packet_number].packet_number = sent_packets[pn_space][packet_number].packet_number =
packet_number packet_number
sent_packets[pn_space][packet_number].time_sent = now() sent_packets[pn_space][packet_number].time_sent = now()
sent_packets[pn_space][packet_number].ack_eliciting = sent_packets[pn_space][packet_number].ack_eliciting =
ack_eliciting ack_eliciting
sent_packets[pn_space][packet_number].in_flight = in_flight sent_packets[pn_space][packet_number].in_flight = in_flight
sent_packets[pn_space][packet_number].sent_bytes = sent_bytes sent_packets[pn_space][packet_number].sent_bytes = sent_bytes
if (in_flight): if (in_flight):
if (ack_eliciting): if (ack_eliciting):
time_of_last_ack_eliciting_packet[pn_space] = now() time_of_last_ack_eliciting_packet[pn_space] = now()
OnPacketSentCC(sent_bytes) OnPacketSentCC(sent_bytes)
SetLossDetectionTimer() SetLossDetectionTimer()
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="on-receiving-a-datagram" numbered="true" toc="default"> <section anchor="on-receiving-a-datagram" numbered="true" toc="default">
<name>On Receiving a Datagram</name> <name>On Receiving a Datagram</name>
<t>When a server is blocked by anti-amplification limits, receiving <t>When a server is blocked by anti-amplification limits, receiving
a datagram unblocks it, even if none of the packets in the a datagram unblocks it, even if none of the packets in the
datagram are successfully processed. In such a case, the PTO datagram are successfully processed. In such a case, the PTO
timer will need to be re-armed.</t> timer will need to be rearmed.</t>
<t>Pseudocode for OnDatagramReceived follows:</t> <t>Pseudocode for OnDatagramReceived follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
OnDatagramReceived(datagram): OnDatagramReceived(datagram):
// If this datagram unblocks the server, arm the // If this datagram unblocks the server, arm the
// PTO timer to avoid deadlock. // PTO timer to avoid deadlock.
if (server was at anti-amplification limit): if (server was at anti-amplification limit):
SetLossDetectionTimer() SetLossDetectionTimer()
]]></artwork> if loss_detection_timer.timeout < now():
// Execute PTO if it would have expired
// while the amplification limit applied.
OnLossDetectionTimeout()
]]></sourcecode>
</section> </section>
<section anchor="on-receiving-an-acknowledgment" numbered="true" toc="defa ult"> <section anchor="on-receiving-an-acknowledgment" numbered="true" toc="defa ult">
<name>On Receiving an Acknowledgment</name> <name>On Receiving an Acknowledgment</name>
<t>When an ACK frame is received, it may newly acknowledge any number of packets.</t> <t>When an ACK frame is received, it may newly acknowledge any number of packets.</t>
<t>Pseudocode for OnAckReceived and UpdateRtt follow:</t> <t>Pseudocode for OnAckReceived and UpdateRtt follow:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
IncludesAckEliciting(packets): IncludesAckEliciting(packets):
for packet in packets: for packet in packets:
if (packet.ack_eliciting): if (packet.ack_eliciting):
return true return true
return false return false
OnAckReceived(ack, pn_space): OnAckReceived(ack, pn_space):
if (largest_acked_packet[pn_space] == infinite): if (largest_acked_packet[pn_space] == infinite):
largest_acked_packet[pn_space] = ack.largest_acked largest_acked_packet[pn_space] = ack.largest_acked
else: else:
skipping to change at line 1826 skipping to change at line 1782
// min_rtt ignores acknowledgment delay. // min_rtt ignores acknowledgment delay.
min_rtt = min(min_rtt, latest_rtt) min_rtt = min(min_rtt, latest_rtt)
// Limit ack_delay by max_ack_delay after handshake // Limit ack_delay by max_ack_delay after handshake
// confirmation. // confirmation.
if (handshake confirmed): if (handshake confirmed):
ack_delay = min(ack_delay, max_ack_delay) ack_delay = min(ack_delay, max_ack_delay)
// Adjust for acknowledgment delay if plausible. // Adjust for acknowledgment delay if plausible.
adjusted_rtt = latest_rtt adjusted_rtt = latest_rtt
if (latest_rtt > min_rtt + ack_delay): if (latest_rtt >= min_rtt + ack_delay):
adjusted_rtt = latest_rtt - ack_delay adjusted_rtt = latest_rtt - ack_delay
rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt) rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="setting-the-loss-detection-timer" numbered="true" toc="de fault"> <section anchor="setting-the-loss-detection-timer" numbered="true" toc="de fault">
<name>Setting the Loss Detection Timer</name> <name>Setting the Loss Detection Timer</name>
<t>QUIC loss detection uses a single timer for all timeout loss detectio n. The <t>QUIC loss detection uses a single timer for all timeout loss detectio n. The
duration of the timer is based on the timer's mode, which is set in the packet duration of the timer is based on the timer's mode, which is set in the packet
and timer events further below. The function SetLossDetectionTimer defined and timer events further below. The function SetLossDetectionTimer defined
below shows how the single timer is set.</t> below shows how the single timer is set.</t>
<t>This algorithm may result in the timer being set in the past, particu larly if <t>This algorithm may result in the timer being set in the past, particu larly if
timers wake up late. Timers set in the past fire immediately.</t> timers wake up late. Timers set in the past fire immediately.</t>
<t>Pseudocode for SetLossDetectionTimer follows (where the "^" operator represents <t>Pseudocode for SetLossDetectionTimer follows (where the "^" operator represents
exponentiation):</t> exponentiation):</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
GetLossTimeAndSpace(): GetLossTimeAndSpace():
time = loss_time[Initial] time = loss_time[Initial]
space = Initial space = Initial
for pn_space in [ Handshake, ApplicationData ]: for pn_space in [ Handshake, ApplicationData ]:
if (time == 0 || loss_time[pn_space] < time): if (time == 0 || loss_time[pn_space] < time):
time = loss_time[pn_space]; time = loss_time[pn_space];
space = pn_space space = pn_space
return time, space return time, space
GetPtoTimeAndSpace(): GetPtoTimeAndSpace():
duration = (smoothed_rtt + max(4 * rttvar, kGranularity)) duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
* (2 ^ pto_count) * (2 ^ pto_count)
// Arm PTO from now when there are no inflight packets. // Anti-deadlock PTO starts from the current time
if (no in-flight packets): if (no ack-eliciting packets in flight):
assert(!PeerCompletedAddressValidation()) assert(!PeerCompletedAddressValidation())
if (has handshake keys): if (has handshake keys):
return (now() + duration), Handshake return (now() + duration), Handshake
else: else:
return (now() + duration), Initial return (now() + duration), Initial
pto_timeout = infinite pto_timeout = infinite
pto_space = Initial pto_space = Initial
for space in [ Initial, Handshake, ApplicationData ]: for space in [ Initial, Handshake, ApplicationData ]:
if (no in-flight packets in space): if (no ack-eliciting packets in flight in space):
continue; continue;
if (space == ApplicationData): if (space == ApplicationData):
// Skip Application Data until handshake confirmed. // Skip Application Data until handshake confirmed.
if (handshake is not confirmed): if (handshake is not confirmed):
return pto_timeout, pto_space return pto_timeout, pto_space
// Include max_ack_delay and backoff for Application Data. // Include max_ack_delay and backoff for Application Data.
duration += max_ack_delay * (2 ^ pto_count) duration += max_ack_delay * (2 ^ pto_count)
t = time_of_last_ack_eliciting_packet[space] + duration t = time_of_last_ack_eliciting_packet[space] + duration
if (t < pto_timeout): if (t < pto_timeout):
skipping to change at line 1912 skipping to change at line 1868
if (no ack-eliciting packets in flight && if (no ack-eliciting packets in flight &&
PeerCompletedAddressValidation()): PeerCompletedAddressValidation()):
// There is nothing to detect lost, so no timer is set. // There is nothing to detect lost, so no timer is set.
// However, the client needs to arm the timer if the // However, the client needs to arm the timer if the
// server might be blocked by the anti-amplification limit. // server might be blocked by the anti-amplification limit.
loss_detection_timer.cancel() loss_detection_timer.cancel()
return return
timeout, _ = GetPtoTimeAndSpace() timeout, _ = GetPtoTimeAndSpace()
loss_detection_timer.update(timeout) loss_detection_timer.update(timeout)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="on-timeout" numbered="true" toc="default"> <section anchor="on-timeout" numbered="true" toc="default">
<name>On Timeout</name> <name>On Timeout</name>
<t>When the loss detection timer expires, the timer's mode determines th e action <t>When the loss detection timer expires, the timer's mode determines th e action
to be performed.</t> to be performed.</t>
<t>Pseudocode for OnLossDetectionTimeout follows:</t> <t>Pseudocode for OnLossDetectionTimeout follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
OnLossDetectionTimeout(): OnLossDetectionTimeout():
earliest_loss_time, pn_space = GetLossTimeAndSpace() earliest_loss_time, pn_space = GetLossTimeAndSpace()
if (earliest_loss_time != 0): if (earliest_loss_time != 0):
// Time threshold loss Detection // Time threshold loss Detection
lost_packets = DetectAndRemoveLostPackets(pn_space) lost_packets = DetectAndRemoveLostPackets(pn_space)
assert(!lost_packets.empty()) assert(!lost_packets.empty())
OnPacketsLost(lost_packets) OnPacketsLost(lost_packets)
SetLossDetectionTimer() SetLossDetectionTimer()
return return
if (bytes_in_flight > 0): if (no ack-eliciting packets in flight):
// PTO. Send new data if available, else retransmit old data.
// If neither is available, send a single PING frame.
_, pn_space = GetPtoTimeAndSpace()
SendOneOrTwoAckElicitingPackets(pn_space)
else:
assert(!PeerCompletedAddressValidation()) assert(!PeerCompletedAddressValidation())
// Client sends an anti-deadlock packet: Initial is padded // Client sends an anti-deadlock packet: Initial is padded
// to earn more anti-amplification credit, // to earn more anti-amplification credit,
// a Handshake packet proves address ownership. // a Handshake packet proves address ownership.
if (has Handshake keys): if (has Handshake keys):
SendOneAckElicitingHandshakePacket() SendOneAckElicitingHandshakePacket()
else: else:
SendOneAckElicitingPaddedInitialPacket() SendOneAckElicitingPaddedInitialPacket()
else:
// PTO. Send new data if available, else retransmit old data.
// If neither is available, send a single PING frame.
_, pn_space = GetPtoTimeAndSpace()
SendOneOrTwoAckElicitingPackets(pn_space)
pto_count++ pto_count++
SetLossDetectionTimer() SetLossDetectionTimer()
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="detecting-lost-packets" numbered="true" toc="default"> <section anchor="detecting-lost-packets" numbered="true" toc="default">
<name>Detecting Lost Packets</name> <name>Detecting Lost Packets</name>
<t>DetectAndRemoveLostPackets is called every time an ACK is received or the time <t>DetectAndRemoveLostPackets is called every time an ACK is received or the time
threshold loss detection timer expires. This function operates on the threshold loss detection timer expires. This function operates on the
sent_packets for that packet number space and returns a list of packets newly sent_packets for that packet number space and returns a list of packets newly
detected as lost.</t> detected as lost.</t>
<t>Pseudocode for DetectAndRemoveLostPackets follows:</t> <t>Pseudocode for DetectAndRemoveLostPackets follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
DetectAndRemoveLostPackets(pn_space): DetectAndRemoveLostPackets(pn_space):
assert(largest_acked_packet[pn_space] != infinite) assert(largest_acked_packet[pn_space] != infinite)
loss_time[pn_space] = 0 loss_time[pn_space] = 0
lost_packets = [] lost_packets = []
loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt) loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)
// Minimum time of kGranularity before packets are deemed lost. // Minimum time of kGranularity before packets are deemed lost.
loss_delay = max(loss_delay, kGranularity) loss_delay = max(loss_delay, kGranularity)
// Packets sent before this time are deemed lost. // Packets sent before this time are deemed lost.
skipping to change at line 1988 skipping to change at line 1944
unacked.packet_number + kPacketThreshold): unacked.packet_number + kPacketThreshold):
sent_packets[pn_space].remove(unacked.packet_number) sent_packets[pn_space].remove(unacked.packet_number)
lost_packets.insert(unacked) lost_packets.insert(unacked)
else: else:
if (loss_time[pn_space] == 0): if (loss_time[pn_space] == 0):
loss_time[pn_space] = unacked.time_sent + loss_delay loss_time[pn_space] = unacked.time_sent + loss_delay
else: else:
loss_time[pn_space] = min(loss_time[pn_space], loss_time[pn_space] = min(loss_time[pn_space],
unacked.time_sent + loss_delay) unacked.time_sent + loss_delay)
return lost_packets return lost_packets
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="upon-dropping-initial-or-handshake-keys" numbered="true" toc="default"> <section anchor="upon-dropping-initial-or-handshake-keys" numbered="true" toc="default">
<name>Upon Dropping Initial or Handshake Keys</name> <name>Upon Dropping Initial or Handshake Keys</name>
<t>When Initial or Handshake keys are discarded, packets from the space <t>When Initial or Handshake keys are discarded, packets from the space
are discarded and loss detection state is updated.</t> are discarded and loss detection state is updated.</t>
<t>Pseudocode for OnPacketNumberSpaceDiscarded follows:</t> <t>Pseudocode for OnPacketNumberSpaceDiscarded follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
OnPacketNumberSpaceDiscarded(pn_space): OnPacketNumberSpaceDiscarded(pn_space):
assert(pn_space != ApplicationData) assert(pn_space != ApplicationData)
RemoveFromBytesInFlight(sent_packets[pn_space]) RemoveFromBytesInFlight(sent_packets[pn_space])
sent_packets[pn_space].clear() sent_packets[pn_space].clear()
// Reset the loss detection and PTO timer // Reset the loss detection and PTO timer
time_of_last_ack_eliciting_packet[pn_space] = 0 time_of_last_ack_eliciting_packet[pn_space] = 0
loss_time[pn_space] = 0 loss_time[pn_space] = 0
pto_count = 0 pto_count = 0
SetLossDetectionTimer() SetLossDetectionTimer()
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="congestion-control-pseudocode" numbered="true" toc="default "> <section anchor="congestion-control-pseudocode" numbered="true" toc="default ">
<name>Congestion Control Pseudocode</name> <name>Congestion Control Pseudocode</name>
<t>We now describe an example implementation of the congestion controller described <t>We now describe an example implementation of the congestion controller described
in <xref target="congestion-control" format="default"/>.</t> in <xref target="congestion-control" format="default"/>.</t>
<t>The pseudocode segments in this section are licensed as Code Components ; see the <t>The pseudocode segments in this section are licensed as Code Components ; see the
copyright notice.</t> copyright notice.</t>
<section anchor="cc-consts-of-interest" numbered="true" toc="default"> <section anchor="cc-consts-of-interest" numbered="true" toc="default">
<name>Constants of interest</name> <name>Constants of Interest</name>
<t>Constants used in congestion control are based on a combination of RF Cs, papers, <t>Constants used in congestion control are based on a combination of RF Cs, papers,
and common practice.</t> and common practice.</t>
<dl> <dl>
<dt> <dt>kInitialWindow:</dt>
kInitialWindow: </dt>
<dd> <dd>
<t>Default limit on the initial bytes in flight as described in <xre f target="initial-cwnd" format="default"/>.</t> <t>Default limit on the initial bytes in flight as described in <xre f target="initial-cwnd" format="default"/>.</t>
</dd> </dd>
<dt> <dt>kMinimumWindow:</dt>
kMinimumWindow: </dt>
<dd> <dd>
<t>Minimum congestion window in bytes as described in <xref target=" initial-cwnd" format="default"/>.</t> <t>Minimum congestion window in bytes as described in <xref target=" initial-cwnd" format="default"/>.</t>
</dd> </dd>
<dt> <dt>kLossReductionFactor:</dt>
kLossReductionFactor: </dt>
<dd> <dd>
<t>Scaling factor applied to reduce the congestion window when a new loss event <t>Scaling factor applied to reduce the congestion window when a new loss event
is detected. <xref target="congestion-control" format="default"/> recommends a v alue is 0.5.</t> is detected. <xref target="congestion-control" format="default"/> recommends a v alue of 0.5.</t>
</dd> </dd>
<dt> <dt>kPersistentCongestionThreshold:</dt>
kPersistentCongestionThreshold: </dt>
<dd> <dd>
<t>Period of time for persistent congestion to be established, speci fied as a PTO <t>Period of time for persistent congestion to be established, speci fied as a PTO
multiplier. <xref target="persistent-congestion" format="default"/> recommends a value of 3.</t> multiplier. <xref target="persistent-congestion" format="default"/> recommends a value of 3.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="vars-of-interest" numbered="true" toc="default"> <section anchor="vars-of-interest" numbered="true" toc="default">
<name>Variables of interest</name> <name>Variables of Interest</name>
<t>Variables required to implement the congestion control mechanisms <t>Variables required to implement the congestion control mechanisms
are described in this section.</t> are described in this section.</t>
<dl> <dl>
<dt> <dt>max_datagram_size:</dt>
max_datagram_size: </dt>
<dd> <dd>
<t>The sender's current maximum payload size. Does not include UDP o r IP <t>The sender's current maximum payload size. This does not include UDP or IP
overhead. The max datagram size is used for congestion window overhead. The max datagram size is used for congestion window
computations. An endpoint sets the value of this variable based on its Path computations. An endpoint sets the value of this variable based on its Path
Maximum Transmission Unit (PMTU; see Section 14.2 of <xref target="QUIC-TRANSPOR T" format="default"/>), with Maximum Transmission Unit (PMTU; see <xref section="14.2" sectionFormat="of" tar get="QUIC-TRANSPORT" format="default"/>), with
a minimum value of 1200 bytes.</t> a minimum value of 1200 bytes.</t>
</dd> </dd>
<dt> <dt>ecn_ce_counters[kPacketNumberSpace]:</dt>
ecn_ce_counters[kPacketNumberSpace]: </dt>
<dd> <dd>
<t>The highest value reported for the ECN-CE counter in the packet n umber space <t>The highest value reported for the ECN-CE counter in the packet n umber space
by the peer in an ACK frame. This value is used to detect increases in the by the peer in an ACK frame. This value is used to detect increases in the
reported ECN-CE counter.</t> reported ECN-CE counter.</t>
</dd> </dd>
<dt> <dt>bytes_in_flight:</dt>
bytes_in_flight: </dt>
<dd> <dd>
<t>The sum of the size in bytes of all sent packets that contain at least one <t>The sum of the size in bytes of all sent packets that contain at least one
ack-eliciting or PADDING frame, and have not been acknowledged or declared ack-eliciting or PADDING frame and have not been acknowledged or declared
lost. The size does not include IP or UDP overhead, but does include the QUIC lost. The size does not include IP or UDP overhead, but does include the QUIC
header and AEAD overhead. Packets only containing ACK frames do not count header and Authenticated Encryption with Associated Data (AEAD) overhead.
towards bytes_in_flight to ensure congestion control does not impede Packets only containing ACK frames do not count toward bytes_in_flight to
congestion feedback.</t> ensure congestion control does not impede congestion feedback.</t>
</dd> </dd>
<dt> <dt>congestion_window:</dt>
congestion_window: </dt>
<dd> <dd>
<t>Maximum number of bytes allowed to be in flight.</t> <t>Maximum number of bytes allowed to be in flight.</t>
</dd> </dd>
<dt> <dt>congestion_recovery_start_time:</dt>
congestion_recovery_start_time: </dt>
<dd> <dd>
<t>The time the current recovery period started due to the detection of loss <t>The time the current recovery period started due to the detection of loss
or ECN. When a packet sent after this time is acknowledged, QUIC exits or ECN. When a packet sent after this time is acknowledged, QUIC exits
congestion recovery.</t> congestion recovery.</t>
</dd> </dd>
<dt> <dt>ssthresh:</dt>
ssthresh: </dt>
<dd> <dd>
<t>Slow start threshold in bytes. When the congestion window is bel ow ssthresh, <t>Slow start threshold in bytes. When the congestion window is bel ow ssthresh,
the mode is slow start and the window grows by the number of bytes the mode is slow start and the window grows by the number of bytes
acknowledged.</t> acknowledged.</t>
</dd> </dd>
</dl> </dl>
<t>The congestion control pseudocode also accesses some of the variables from the <t>The congestion control pseudocode also accesses some of the variables from the
loss recovery pseudocode.</t> loss recovery pseudocode.</t>
</section> </section>
<section anchor="initialization-1" numbered="true" toc="default"> <section anchor="initialization-1" numbered="true" toc="default">
<name>Initialization</name> <name>Initialization</name>
<t>At the beginning of the connection, initialize the congestion control <t>At the beginning of the connection, initialize the congestion control
variables as follows:</t> variables as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
congestion_window = kInitialWindow congestion_window = kInitialWindow
bytes_in_flight = 0 bytes_in_flight = 0
congestion_recovery_start_time = 0 congestion_recovery_start_time = 0
ssthresh = infinite ssthresh = infinite
for pn_space in [ Initial, Handshake, ApplicationData ]: for pn_space in [ Initial, Handshake, ApplicationData ]:
ecn_ce_counters[pn_space] = 0 ecn_ce_counters[pn_space] = 0
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="on-packet-sent" numbered="true" toc="default"> <section anchor="on-packet-sent" numbered="true" toc="default">
<name>On Packet Sent</name> <name>On Packet Sent</name>
<t>Whenever a packet is sent, and it contains non-ACK frames, the packet <t>Whenever a packet is sent and it contains non-ACK frames, the packet
increases bytes_in_flight.</t> increases bytes_in_flight.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
OnPacketSentCC(sent_bytes): OnPacketSentCC(sent_bytes):
bytes_in_flight += sent_bytes bytes_in_flight += sent_bytes
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="on-packet-acknowledgment" numbered="true" toc="default"> <section anchor="on-packet-acknowledgment" numbered="true" toc="default">
<name>On Packet Acknowledgment</name> <name>On Packet Acknowledgment</name>
<t>Invoked from loss detection's OnAckReceived and is supplied with the <t>This is invoked from loss detection's OnAckReceived and is supplied w ith the
newly acked_packets from sent_packets.</t> newly acked_packets from sent_packets.</t>
<t>In congestion avoidance, implementers that use an integer representat ion <t>In congestion avoidance, implementers that use an integer representat ion
for congestion_window should be careful with division, and can use for congestion_window should be careful with division and can use
the alternative approach suggested in Section 2.1 of <xref target="RFC3465" form the alternative approach suggested in <xref section="2.1" sectionFormat="of" tar
at="default"/>.</t> get="RFC3465" format="default"/>.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
InCongestionRecovery(sent_time): InCongestionRecovery(sent_time):
return sent_time <= congestion_recovery_start_time return sent_time <= congestion_recovery_start_time
OnPacketsAcked(acked_packets): OnPacketsAcked(acked_packets):
for acked_packet in acked_packets: for acked_packet in acked_packets:
OnPacketAcked(acked_packet) OnPacketAcked(acked_packet)
OnPacketAcked(acked_packet): OnPacketAcked(acked_packet):
if (!acked_packet.in_flight): if (!acked_packet.in_flight):
return; return;
skipping to change at line 2154 skipping to change at line 2100
if (InCongestionRecovery(acked_packet.time_sent)): if (InCongestionRecovery(acked_packet.time_sent)):
return return
if (congestion_window < ssthresh): if (congestion_window < ssthresh):
// Slow start. // Slow start.
congestion_window += acked_packet.sent_bytes congestion_window += acked_packet.sent_bytes
else: else:
// Congestion avoidance. // Congestion avoidance.
congestion_window += congestion_window +=
max_datagram_size * acked_packet.sent_bytes max_datagram_size * acked_packet.sent_bytes
/ congestion_window / congestion_window
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="on-new-congestion-event" numbered="true" toc="default"> <section anchor="on-new-congestion-event" numbered="true" toc="default">
<name>On New Congestion Event</name> <name>On New Congestion Event</name>
<t>Invoked from ProcessECN and OnPacketsLost when a new congestion event is <t>This is invoked from ProcessECN and OnPacketsLost when a new congesti on event is
detected. If not already in recovery, this starts a recovery period and detected. If not already in recovery, this starts a recovery period and
reduces the slow start threshold and congestion window immediately.</t> reduces the slow start threshold and congestion window immediately.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
OnCongestionEvent(sent_time): OnCongestionEvent(sent_time):
// No reaction if already in a recovery period. // No reaction if already in a recovery period.
if (InCongestionRecovery(sent_time)): if (InCongestionRecovery(sent_time)):
return return
// Enter recovery period. // Enter recovery period.
congestion_recovery_start_time = now() congestion_recovery_start_time = now()
ssthresh = congestion_window * kLossReductionFactor ssthresh = congestion_window * kLossReductionFactor
congestion_window = max(ssthresh, kMinimumWindow) congestion_window = max(ssthresh, kMinimumWindow)
// A packet can be sent to speed up loss recovery. // A packet can be sent to speed up loss recovery.
MaybeSendOnePacket() MaybeSendOnePacket()
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="process-ecn-information" numbered="true" toc="default"> <section anchor="process-ecn-information" numbered="true" toc="default">
<name>Process ECN Information</name> <name>Process ECN Information</name>
<t>Invoked when an ACK frame with an ECN section is received from the pe <t>This is invoked when an ACK frame with an ECN section is received fro
er.</t> m the peer.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
ProcessECN(ack, pn_space): ProcessECN(ack, pn_space):
// If the ECN-CE counter reported by the peer has increased, // If the ECN-CE counter reported by the peer has increased,
// this could be a new congestion event. // this could be a new congestion event.
if (ack.ce_counter > ecn_ce_counters[pn_space]): if (ack.ce_counter > ecn_ce_counters[pn_space]):
ecn_ce_counters[pn_space] = ack.ce_counter ecn_ce_counters[pn_space] = ack.ce_counter
sent_time = sent_packets[ack.largest_acked].time_sent sent_time = sent_packets[ack.largest_acked].time_sent
OnCongestionEvent(sent_time) OnCongestionEvent(sent_time)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="on-packets-lost" numbered="true" toc="default"> <section anchor="on-packets-lost" numbered="true" toc="default">
<name>On Packets Lost</name> <name>On Packets Lost</name>
<t>Invoked when DetectAndRemoveLostPackets deems packets lost.</t> <t>This is invoked when DetectAndRemoveLostPackets deems packets lost.</
<artwork name="" type="" align="left" alt=""><![CDATA[ t>
<sourcecode type="pseudocode"><![CDATA[
OnPacketsLost(lost_packets): OnPacketsLost(lost_packets):
sent_time_of_last_loss = 0 sent_time_of_last_loss = 0
// Remove lost packets from bytes_in_flight. // Remove lost packets from bytes_in_flight.
for lost_packet in lost_packets: for lost_packet in lost_packets:
if lost_packet.in_flight: if lost_packet.in_flight:
bytes_in_flight -= lost_packet.sent_bytes bytes_in_flight -= lost_packet.sent_bytes
sent_time_of_last_loss = sent_time_of_last_loss =
max(sent_time_of_last_loss, lost_packet.time_sent) max(sent_time_of_last_loss, lost_packet.time_sent)
// Congestion event if in-flight packets were lost // Congestion event if in-flight packets were lost
if (sent_time_of_last_loss != 0): if (sent_time_of_last_loss != 0):
skipping to change at line 2216 skipping to change at line 2162
// Only consider packets sent after getting an RTT sample. // Only consider packets sent after getting an RTT sample.
if (first_rtt_sample == 0): if (first_rtt_sample == 0):
return return
pc_lost = [] pc_lost = []
for lost in lost_packets: for lost in lost_packets:
if lost.time_sent > first_rtt_sample: if lost.time_sent > first_rtt_sample:
pc_lost.insert(lost) pc_lost.insert(lost)
if (InPersistentCongestion(pc_lost)): if (InPersistentCongestion(pc_lost)):
congestion_window = kMinimumWindow congestion_window = kMinimumWindow
congestion_recovery_start_time = 0 congestion_recovery_start_time = 0
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="removing-discarded-packets-from-bytes-in-flight" numbered ="true" toc="default"> <section anchor="removing-discarded-packets-from-bytes-in-flight" numbered ="true" toc="default">
<name>Removing Discarded Packets From Bytes In Flight</name> <name>Removing Discarded Packets from Bytes in Flight</name>
<t>When Initial or Handshake keys are discarded, packets sent in that sp ace no <t>When Initial or Handshake keys are discarded, packets sent in that sp ace no
longer count toward bytes in flight.</t> longer count toward bytes in flight.</t>
<t>Pseudocode for RemoveFromBytesInFlight follows:</t> <t>Pseudocode for RemoveFromBytesInFlight follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
RemoveFromBytesInFlight(discarded_packets): RemoveFromBytesInFlight(discarded_packets):
// Remove any unacknowledged packets from flight. // Remove any unacknowledged packets from flight.
foreach packet in discarded_packets: foreach packet in discarded_packets:
if packet.in_flight if packet.in_flight
bytes_in_flight -= size bytes_in_flight -= size
]]></artwork> ]]></sourcecode>
</section>
</section>
<section anchor="change-log" numbered="true" toc="default">
<name>Change Log</name>
<ul empty="true" spacing="normal">
<li>
<strong>RFC Editor's Note:</strong> Please remove this section prior
to
publication of a final version of this document.</li>
</ul>
<t>Issue and pull request numbers are listed with a leading octothorp.</t>
<section anchor="since-draft-ietf-quic-recovery-32" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-32</name>
<ul spacing="normal">
<li>Clarifications to definition of persistent congestion (#4413, #441
4, #4421,
#4429, #4437)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-31" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-31</name>
<ul spacing="normal">
<li>Limit the number of Initial packets sent in response to unauthenti
cated
packets (#4183, #4188)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-30" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-30</name>
<t>Editorial changes only.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-29" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-29</name>
<ul spacing="normal">
<li>Allow caching of packets that can't be decrypted, by allowing the
reported
acknowledgment delay to exceed max_ack_delay prior to confirming the
handshake (#3821, #3980, #4035, #3874)</li>
<li>Persistent congestion cannot include packets sent before the first
RTT
sample for the path (#3875, #3889)</li>
<li>Recommend reset of min_rtt in persistent congestion (#3927, #3975)
</li>
<li>Persistent congestion is independent of packet number space (#3939
, #3961)</li>
<li>Only limit bursts to the initial window without information about
the path
(#3892, #3936)</li>
<li>Add normative requirements for increasing and reducing the congest
ion
window (#3944, #3978, #3997, #3998)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-28" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-28</name>
<ul spacing="normal">
<li>Refactored pseudocode to correct PTO calculation (#3564, #3674, #3
681)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-27" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-27</name>
<ul spacing="normal">
<li>Added recommendations for speeding up handshake under some loss co
nditions
(#3078, #3080)</li>
<li>PTO count is reset when handshake progress is made (#3272, #3415)<
/li>
<li>PTO count is not reset by a client when the server might be awaiti
ng
address validation (#3546, #3551)</li>
<li>Recommend repairing losses immediately after entering the recovery
period
(#3335, #3443)</li>
<li>Clarified what loss conditions can be ignored during the handshake
(#3456,
#3450)</li>
<li>Allow, but don't recommend, using RTT from previous connection to
seed RTT
(#3464, #3496)</li>
<li>Recommend use of adaptive loss detection thresholds (#3571, #3572)
</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-26" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-26</name>
<t>No changes.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-25" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-25</name>
<t>No significant changes.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-24" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-24</name>
<ul spacing="normal">
<li>Require congestion control of some sort (#3247, #3244, #3248)</li>
<li>Set a minimum reordering threshold (#3256, #3240)</li>
<li>PTO is specific to a packet number space (#3067, #3074, #3066)</li
>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-23" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-23</name>
<ul spacing="normal">
<li>Define under-utilizing the congestion window (#2630, #2686, #2675)
</li>
<li>PTO MUST send data if possible (#3056, #3057)</li>
<li>Connection Close is not ack-eliciting (#3097, #3098)</li>
<li>MUST limit bursts to the initial congestion window (#3160)</li>
<li>Define the current max_datagram_size for congestion control
(#3041, #3167)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-22" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-22</name>
<ul spacing="normal">
<li>PTO should always send an ack-eliciting packet (#2895)</li>
<li>Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886)
</li>
<li>Move ACK generation text to transport draft (#1860, #2916)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-21" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-21</name>
<ul spacing="normal">
<li>No changes</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-20" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-20</name>
<ul spacing="normal">
<li>Path validation can be used as initial RTT value (#2644, #2687)</l
i>
<li>max_ack_delay transport parameter defaults to 0 (#2638, #2646)</li
>
<li>ACK delay only measures intentional delays induced by the implemen
tation
(#2596, #2786)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-19" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-19</name>
<ul spacing="normal">
<li>Change kPersistentThreshold from an exponent to a multiplier (#255
7)</li>
<li>Send a PING if the PTO timer fires and there's nothing to send (#2
624)</li>
<li>Set loss delay to at least kGranularity (#2617)</li>
<li>Merge application limited and sending after idle sections. Always
limit
burst size instead of requiring resetting CWND to initial CWND after
idle (#2605)</li>
<li>Rewrite RTT estimation, allow RTT samples where a newly acked pack
et is
ack-eliciting but the largest_acked is not (#2592)</li>
<li>Don't arm the handshake timer if there is no handshake data (#2590
)</li>
<li>Clarify that the time threshold loss alarm takes precedence over t
he
crypto handshake timer (#2590, #2620)</li>
<li>Change initial RTT to 500ms to align with RFC6298 (#2184)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-18" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-18</name>
<ul spacing="normal">
<li>Change IW byte limit to 14720 from 14600 (#2494)</li>
<li>Update PTO calculation to match RFC6298 (#2480, #2489, #2490)</li>
<li>Improve loss detection's description of multiple packet number spa
ces and
pseudocode (#2485, #2451, #2417)</li>
<li>Declare persistent congestion even if non-probe packets are sent a
nd don't
make persistent congestion more aggressive than RTO verified was (#2365,
#2244)</li>
<li>Move pseudocode to the appendices (#2408)</li>
<li>What to send on multiple PTOs (#2380)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-17" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-17</name>
<ul spacing="normal">
<li>After Probe Timeout discard in-flight packets or send another (#22
12, #1965)</li>
<li>Endpoints discard initial keys as soon as handshake keys are avail
able (#1951,
#2045)</li>
<li>0-RTT state is discarded when 0-RTT is rejected (#2300)</li>
<li>Loss detection timer is cancelled when ack-eliciting frames are in
flight
(#2117, #2093)</li>
<li>Packets are declared lost if they are in flight (#2104)</li>
<li>After becoming idle, either pace packets or reset the congestion c
ontroller
(#2138, 2187)</li>
<li>Process ECN counts before marking packets lost (#2142)</li>
<li>Mark packets lost before resetting crypto_count and pto_count (#22
08, #2209)</li>
<li>Congestion and loss recovery state are discarded when keys are dis
carded
(#2327)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-16" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-16</name>
<ul spacing="normal">
<li>Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP an
d min crypto
timeouts; eliminate timeout validation (#2114, #2166, #2168, #1017)</li>
<li>Redefine how congestion avoidance in terms of when the period star
ts (#1928,
#1930)</li>
<li>Document what needs to be tracked for packets that are in flight (
#765, #1724,
#1939)</li>
<li>Integrate both time and packet thresholds into loss detection (#19
69, #1212,
#934, #1974)</li>
<li>Reduce congestion window after idle, unless pacing is used (#2007,
#2023)</li>
<li>Disable RTT calculation for packets that don't elicit acknowledgme
nt (#2060,
#2078)</li>
<li>Limit ack_delay by max_ack_delay (#2060, #2099)</li>
<li>Initial keys are discarded once Handshake keys are available (#195
1, #2045)</li>
<li>Reorder ECN and loss detection in pseudocode (#2142)</li>
<li>Only cancel loss detection timer if ack-eliciting packets are in f
light
(#2093, #2117)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-14" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-14</name>
<ul spacing="normal">
<li>Used max_ack_delay from transport params (#1796, #1782)</li>
<li>Merge ACK and ACK_ECN (#1783)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-13" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-13</name>
<ul spacing="normal">
<li>Corrected the lack of ssthresh reduction in CongestionEvent pseudo
code (#1598)</li>
<li>Considerations for ECN spoofing (#1426, #1626)</li>
<li>Clarifications for PADDING and congestion control (#837, #838, #15
17, #1531,
#1540)</li>
<li>Reduce early retransmission timer to RTT/8 (#945, #1581)</li>
<li>Packets are declared lost after an RTO is verified (#935, #1582)</
li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-12" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-12</name>
<ul spacing="normal">
<li>Changes to manage separate packet number spaces and encryption lev
els (#1190,
#1242, #1413, #1450)</li>
<li>Added ECN feedback mechanisms and handling; new ACK_ECN frame (#80
4, #805,
#1372)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-11" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-11</name>
<t>No significant changes.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-10" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-10</name>
<ul spacing="normal">
<li>Improved text on ack generation (#1139, #1159)</li>
<li>Make references to TCP recovery mechanisms informational (#1195)</
li>
<li>Define time_of_last_sent_handshake_packet (#1171)</li>
<li>Added signal from TLS the data it includes needs to be sent in a R
etry packet
(#1061, #1199)</li>
<li>Minimum RTT (min_rtt) is initialized with an infinite value (#1169
)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-09" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-09</name>
<t>No significant changes.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-08" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-08</name>
<ul spacing="normal">
<li>Clarified pacing and RTO (#967, #977)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-07" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-07</name>
<ul spacing="normal">
<li>Include ACK delay in RTO(and TLP) computations (#981)</li>
<li>ACK delay in SRTT computation (#961)</li>
<li>Default RTT and Slow Start (#590)</li>
<li>Many editorial fixes.</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-06" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-06</name>
<t>No significant changes.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-05" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-05</name>
<ul spacing="normal">
<li>Add more congestion control text (#776)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-04" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-04</name>
<t>No significant changes.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-03" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-03</name>
<t>No significant changes.</t>
</section>
<section anchor="since-draft-ietf-quic-recovery-02" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-02</name>
<ul spacing="normal">
<li>Integrate F-RTO (#544, #409)</li>
<li>Add congestion control (#545, #395)</li>
<li>Require connection abort if a skipped packet was acknowledged (#41
5)</li>
<li>Simplify RTO calculations (#142, #417)</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-01" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-01</name>
<ul spacing="normal">
<li>Overview added to loss detection</li>
<li>Changes initial default RTT to 100ms</li>
<li>Added time-based loss detection and fixes early retransmit</li>
<li>Clarified loss recovery for handshake packets</li>
<li>Fixed references and made TCP references informative</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-recovery-00" numbered="true" toc="d
efault">
<name>Since draft-ietf-quic-recovery-00</name>
<ul spacing="normal">
<li>Improved description of constants and ACK behavior</li>
</ul>
</section>
<section anchor="since-draft-iyengar-quic-loss-recovery-01" numbered="true
" toc="default">
<name>Since draft-iyengar-quic-loss-recovery-01</name>
<ul spacing="normal">
<li>Adopted as base for draft-ietf-quic-recovery</li>
<li>Updated authors/editors list</li>
<li>Added table of contents</li>
</ul>
</section> </section>
</section> </section>
<section anchor="contributors" numbered="true" toc="default"> <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name> <name>Contributors</name>
<t>The IETF QUIC Working Group received an enormous amount of support from many <t>The IETF QUIC Working Group received an enormous amount of support from many
people. The following people provided substantive contributions to this people. The following people provided substantive contributions to this
document:</t> document:</t>
<ul spacing="normal"> <ul spacing="compact">
<li>Alessandro Ghedini</li>
<li>Benjamin Saunders</li>
<li>Gorry Fairhurst</li>
<li> <li>
<t> <contact asciiFullname="Kazu Yamamoto" fullname="山本和彦"/> <t><contact fullname="Alessandro Ghedini"/></t>
</t>
</li> </li>
<li> <li>
<t> <contact asciiFullname="Kazuho Oku" fullname="奥 一穂"/> <t><contact fullname="Benjamin Saunders"/></t>
</t>
</li> </li>
<li>Lars Eggert</li>
<li>Magnus Westerlund</li>
<li>Marten Seemann</li>
<li>Martin Duke</li>
<li>Martin Thomson</li>
<li> <li>
<t> <contact fullname="Mirja Kühlewind"/> <t><contact fullname="Gorry Fairhurst"/></t>
</t> </li>
<li>
<t><contact asciiFullname="Kazu Yamamoto" fullname="山本和彦"/></t>
</li>
<li>
<t><contact asciiFullname="Kazuho Oku" fullname="奥 一穂"/></t>
</li>
<li>
<t><contact fullname="Lars Eggert"/></t>
</li>
<li>
<t><contact fullname="Magnus Westerlund"/></t>
</li>
<li>
<t><contact fullname="Marten Seemann"/></t>
</li>
<li>
<t><contact fullname="Martin Duke"/></t>
</li>
<li>
<t><contact fullname="Martin Thomson"/></t>
</li>
<li>
<t><contact fullname="Mirja Kühlewind"/></t>
</li>
<li>
<t><contact fullname="Nick Banks"/></t>
</li>
<li>
<t><contact fullname="Praveen Balasubramanian"/></t>
</li> </li>
<li>Nick Banks</li>
<li>Praveen Balasubramanian</li>
</ul> </ul>
</section> </section>
<section numbered="false" anchor="acknowledgments" toc="default">
<name>Acknowledgments</name>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIALwHAWAAA8W9y3IcWZYgtvev8CLNJoHMCBCBFwFmsaZRJDMLXXyJQHZa
W6ma44jwALwY4R7t7gEkmpltY7PWSmsttBmZyUyb2WkhbaRfUUu/ofO+57p7
gMiuHomWVQAi3O/j3HPP+zEej5O2aBf5s/S/+eHsRfq6apr0Zd7m07aoyjQr
Z+mLqrzKG/oTfm3rapFkl5d1fjP4SjKrpmW2hPFmdTZvx0Xezsf/uC6m4zqf
Vjd5fTfeP0hmWQtP7O3uTca7k/HkMJnCB1dVffcsbdpZUqzqZ2lbr5t2b3f3
ZHcvyeo8e5Ze1FnZrKq6TW6r+tNVXa1XvIYkaVpY6sdsUZUw7l3eJKviWfqn
tpqO0gZeqPN5A7/dLfkXWOMyW62K8urPSZKt2+uqfpak4ySFf0XZPEv/dic9
u8vLq6ymz3hDf5uVWfRxVV89S7/LmnZxR3/ny6xYPEv/Uhc7uO2/ucK/d6bV
kr4FwMEg+axoqzqa7GwnPb/N29ZNdZaV7jOa5/uqulrkfp4CoIHP/M0VfTU8
UVJW9TJri5v8WQLfIrTGFx9O356/f/fh4hk9L+f/CL97lp6mP7x8P/591uSz
9M160RarRf4T/I6ocJ5P13UezuERvd87TPywyesib4pyXvEkaXpWtnld5u34
JSJGHz9aHRURBF+wg6F/Y/k5fEL3nNLQSfXPY2iONzvpxXW1bACr4zneZHVb
lL0vaZY31T8Vi0U2PI2dwOvzGPY/AKiuUvg4bSsFMz75bwvhRfMg2P7b73tw
mnOYZg3r7Z7geQ7Y3/mGpmjK/Xq2AbAIB4/o352++GMM4u+q+jarZ+np9FNZ
3S7y2VW+zEsA04d8XpQE/hfvB6jdoyGAGaDeZO110cQf/y1+fD3Lbgp3epOT
k6Px7nH36NLTF2/S87PvX7x78wbX/eEV3c43Z+fnZ+/exjs4W67q6gZX+qFa
l7PxRV2s0otimaevYMWw+byBBcB+FkV2uXD3NH1fV0ALq0Vzz2be76R/zOoy
/vDFTvoeDr0uAFrxZg4BFe/bTPrixYckGY/HaXbZwN2etklyAaBC4rtGwKez
vJnWxSUseoEsZBZxnWk4hymfQ7rMp9dZWTTLJoWzTvB67PAMZdXmH9/i/7XV
xw95NsvrJkleFs103TQ4RDVPW5obb0TaZp9g0tUim+YpfNle811LkasgdImz
pEhk8a9F0bTJ1p/wBv0N3qUdwMU/b+G3bfUs+nR7e5TeXhfT6xSmyurpNSAj
EM42+dOft67bdtU8e/IE35OvdvS9J/jBkyanH/+eqPtHnPU5jr4Ne/xRFvY9
LcxQHWEDV+UyB3gAPsBMqZvpqmiv15fIFZ7gOLdX298CL1zX0zyZVrOcoFw0
zRrhD5MhTD2QOiMn94385BLYxZjea54ssst80Twxfr8th7QsZjNgYMljpFN1
NVuzvJDQQRLEAJWI8F3lcPWzxXi1rldVk6fGGdKV4PHIkAf2UCafP8d87Zdf
tpGE/SuQLRlGtlSQ7TEShRsYDx5t6NWXRDzob8TvPP2U3yEizZr00Zsfzi8e
jfhn+vYd/f7hFQz14dVL/P38D6evX9sviTxx/od3P7x+GX4Lb+K1evX2Jb8M
n6bRR8mjN6d/D9/gqh69e38B5OP09SMkCG0ECZClkMnA2RbIL1Y1gAJOuEk8
SNPfv3j/f/yPk4P08+fffPjuxd5kcvLLL/LH8eTpAfxxe52XPFtVLu7kT7hL
dwmIVoDLOEq2WAAirYo2W4DYlTVpc13dlul1XucAzcQBj65oXgO42+uMF7lu
eCnR8oG4AwEfA4mbwotwJ+Y1MI0GPgbqA7Pxn2kFC0F0BiQGRjBK35++fHn2
9nte74t3b9++eoEA+vji9bvzVzQbHHxTAOHIkcNkfoqd7pQr+Dpvec73/Duv
GpEnw20PrDDlD1JeEXxYLYnywDXJgRggq7uFe1UwPVpmPxXL9RJHEmYlWLzI
7mgPtGQALx7d0OJg0WfleL4orq7bwQXHewY468N4kHSO9Eg8ONwE2yMsWKDK
O2TY0ovX2U0OCAbjNLjqyzUfKJBpt6F8hrd4CtSQQA7Xsh3hBDMg28CncWMg
zl8RVNJqMcOb1dAdfAns5kqIupBuYnXLgqn9mwzoK5CQOzg4QInWfUcMkt7A
BdHqaPxMYDRe5Df5AhAUeYhR83JWoILSJDhfXk7ruxXRDn6YCGk5XazhAtlA
MPY/ruFR2PV6eQm4uAWqR14jqOnyLapbvHP2OD8FZCu9GJrDlkBbjt5JG/gT
od+5wedC4CZ7O/v4d59IwmTv/UhNWsJkNaAk3F9Qshgds6HphFvkwDrmeYsi
CJxGhshR8rS9sRMDOIy5rAAXqrJADL5D4IF+1zCCAdxTm1m2BjSKiC48kC0v
i6t10d7tJGctco0VEI2iRRKGS2qqZQc8DcKb93XJNGUEMM1IjEICSLQ8WyRX
2Qqxi7mGINjlTWEwL3OZAvCTF5HRgi7z9hYxPcYywIkECKv/7FsmZHCZlkVJ
w+IkxRyAUCLpWKKiBRtj0oBn9VWTGIlmdg9ARiG1w8ICr9oRbioXnpi4Xtil
KHNGIuewlTngJJ5Je7fKmx3CPeXbiWOBedkgYyYiBxJgRjgv49CHBJ1aBU8g
U0jSiIIk/sbT/ZY7TzeeBlKsKPNbW3mGyDjNmyar73hdtMQEVi3zyr4Y2Q1J
M9jRtLVNbJIlF9VVMQV6+DUxjZWjiTGBAjl5fXVtD0RUvqy6nEKXhuMQU4z2
7shZ9BaMEoj21+lrfIoJ0PC8Lz78/fuLd34uuPQt3iVEdcBVHDCvSUhEAuTp
JBzorLkG+ZcAA7cBOXLdIq+ES1yzZJ122A4tS/mGrMLtFoSqAkkfsjU43x53
tfNaI6JVqITBFEOHAjejbQJ7G+BOvBTPdhDJcR8GqorHK4Dr5DJdenknupHy
uAIPFq0rswJQpYWjwlGIwJRdpsvCUsOAeIzqVX6DV/al3B7A0vT3QgWYtcAG
4Jomiagi6Txbgi6RMWHDr756qM5zW6BMA9Q/yRZXFRzzNdxGFJ8YJVZZjTIA
PJcvFmNcdUkEoirxNv+hukW6NzKx2S48LDm5HFhyDLrU5iym/lW6jwhyGTZx
39HJXYJGOAeYBn5EDA/B9xj4Eq4aJhD+8JbZyjmS+kboFxwokEd9cID/sFSe
A6Pv8cpRmv80zVdtujv+cHGREDYBEFmpMFlzgl+SSEG3AC8IkPXBuYCV6ZqT
waUwdWy6eAOzKFIGQQNORlh6NU/c0umgUUBibG5A9ymqdZPGTGR4zCwJhLwL
DVj8iz5aIVBqsiG0aEMgBr4FANkGop/hZkxTWCOHIiGzRoQd2j8f65uIpZ8F
lh4dMypJjGbzBbPWaHfE/QGv6TjyUmWBwFD8E4mKziOAUoPcjVi6SNXRwCY1
IM4Ch1omW58/x6YW0hn5MijiDa6OuHO8nmdJR+JQaW3gfZaSO/spmBKAIIPs
7PKO5MymBQgu4cTnDR43SnQXH16dvhGyJ6z+q+6ZwFjwZkE0zQlW9wlzI7ok
RgkBharZ4OYBQKfpNVBQY002DosyJCLL+ckDt5mgKp63bD8D6ne7eQyibcnQ
GKBWLgpax4+opdhuHFOKWauwiEJJrYgdIz5ok9pN1FCeQqAK8kgiSkL4RBaN
qLdkm1zAsewSeIvoDvJ00cRyEClZogoWjSqBM76trDrAUYxAUCaRZLomQoj0
zF3QRo00S2Azo000g0kyoAQIswsiygwIOgov5DVrWC9AGu3kwOVkDLMEgVa/
QEoAFAFQt8GxRukl+QlI1qnK+Bp0hOlVBbKsF3nhlaYAoZePfKNI68wvb1Bg
RPLhvqUR4LBR2AItYLkifl2UcxRpeghMArssmQhRR0tr0jGeclWOBV5pmzWf
gKM0q3zK4KOTw1eRaDZttlwRgBNSbm/Qugf0hUniC9AzalgHecherarptbA3
eK1GQYd3neM3ghEBXwhPWfJ1TwFNbBR57hTedDWyOUlxRDhgdJX6+LWiiURR
1DJhB7cZiluqyYEClAj17OqurPKxHDQv0OjA97gBSM/JbsccT1ZtqkZCMOLL
VFe3I9YYw26W2R3xvLwU7Q3FFQA6sSZEWVDJQLRilnhZtdcJSKvrBWoas/WU
uHZRe7HpFihvddsoQsIjIAjzZHLlic/OYN0tfZ+QGEGkOEzKslX+0wot2yTU
4JrJGoBWdUTA7I7nCCMJh0xMzfKbIHR4W8GtKvMrpEuMB2wI8tpMZNyF64HG
YpbqM1KRcPJzEECn6OhIOq6MJt06hyFhpZ8//3u02u1OjomtmSBIs84qpHiI
rguyQiiNy+LR5LxrXDIe+BWwEndp74jbotKKD6tgVdIxpaQQEFehk8JHl0An
a+S/QGjXtRnemcurCAGfI0w+ZHiielnWK7T9NgD08o6+runrUVqt0DxMBhWW
qffT8/D9DjrEiFvR8YGwdVPUVUmAGrEuDrc6nzWmLI4Er5oBUorv4H5E1kO8
Ic0C5Ikr3JKqFKgEE2hwf4D98JEc/6ufmFIBha9rIXPfAfa9RJte7v1StETZ
PYCHKCdsnwk/QY3tgMC+1mRRUlG+R0OUrxCpV8Me4Bq81awqkFKYYXqptWBW
O2LsoAfgEuWEhUvAUDH+xYypK0vm4o/6FsbKgyVqf2cP6dKAJYog9B5ks5wc
WgjIDzl5aBrgeu9YP3n93qsHGclyuUI53QKlmOf7/HnVVoD4I7XtkW5rhF+Q
BYZN0OqyZuTVV/HiHO2dPCXzmEhYqG6brEByCQDkq8astEgqkKUm2ZC5tiib
FhRB3LmomEBE0aUO4h69LjsAIJz7Gw/8HrB5DNvuKYuqlxHVRFVzCxcOTz8/
G78kv9K4na6W4xoWRICILz7obItsJWpPj3wGRMF9w95AMMToiYKoHP68Wpho
RisTiQ9QYxEmUSE4ATLaFA1a2txcdDsJLrI4XVMzvCjC7eGhWLpjo5IhgD04
Dg/ikQJJmFV4CEgARoxO2U1VABlYl0EM7M9PpIGo3EgMgzxKsAwmU7nYRO36
YtUYEXmLMezw6HiPSPM5QTU6nuT+40EMzsLREPLCbVXVpRSFAgcigwouDnUW
/IqWhje36PoGRH7oDoz8HUgWzL9YJNewCxNx+gsTl1uFREGFlLCghOTHKY06
1oWJx4Am5Usq6CZjwX9MaK6IyAIpI59OYjc4AFom7E8yIv8DMKSSbWT0HEJn
4Fm1nxLta4TAOMsSCphVndUFqkk/TfHgN2MrslzSYuKdEalDse6NXH+nn//I
b8O2L24rNbmxyiw0T2nGAFrMybjAq3U8n25oNWfFLL68wFJKMS46jbskpgi7
RfmQ7HyVIAaSGSat+LWwTfWSqC6C6I6WTvW/ZV3usJOcCyoaMRlyYcEhoHzJ
KqySheuM5DHYKzM/lKWy2axgIz7pmOX0TpFPDQRMiAGd2q6RRg8c3YX5HFEN
d7VckpxtgNkMdOQ/t1Wi9ltQS1FEJOEirLwE9lzVnwAqSO0K4rHOuNlk81zJ
K5o1zPABkipdPBV3C7b6EOiI7QJKwZEDXpNmsqbXAuVL3HLt4NDt+ljjRZSC
dcNJPj9mxpiP67b9JUlO4TBEkmILGxyrCiYql/ABEfcnchPLIqbBtxWzF4ZC
bB9v+rjCVik0zYGgac4xmRmvRIJmPP6aLcfImsd1jiIjjHmN6oic/taALDIU
OoC4LdZC4ncoHzRMO9iguVJfDFN/OlxAgfaaaNLFTnrqwCOQZPDMKxWq2usa
VnOTLdbelomDPEs8ytETKd4zksNAKiVBgmEDD32EE9rGA0kiZBjf5kjdUcgQ
6wRqVlfwTrOs0Dk+sxeZhCEpgO0RXwPdOPJWwsE8ugGiR189Cia2pg2BNeKe
39Zvq8smr1HyRJuFns8WzAkDbTMN/F4sshjP5A7x82OyDLaKew6Weip40u4d
5Ih81cWAb3oVX+Flzj4U1PYM/rfkJ2DKgZ7xMSunWY1XJkbMnoGtzG87zh02
psAgMB1o/QiZMg8o0n3ceArei26wAeJ42NwoZXDgeY1wcgUCXRi7czlJDLNA
RnQrydBW9DrCvv/5n/85CTOkz3E5H2nIMREb+v1jNf8o433EEWb0Gp6NO4Vo
bSzpko78JbgyxiSmq9jp0X1nKeBSjACii/D97lnc5aKjLPbQmT22kFmR6Xee
KgnZINOzjEshKpc8kYOEs9EpvV+zogrM6i/rpu2+AAtp1pdi90udVkKszl9Z
Nt3TNUJurF/RZSHqflGxPGsODxT51Cbh7xlz9UggGEXgSEL8kbrOkRqsVzOx
RZqa14iYaLJ/D+PphO85ip0uMmnMFM4csOoLF90k6P780b0cEjeAajNurZs1
20l1MLwF8WTEwQjD0FQ4GH9DRtdg1r1Q+SLpr1pMP11s5hO6fxZg8WgOE92U
fJf1ZdGKhErwptnIxsC8BBWvq7IiyYlUE2eEEkWIYhFEMm46uLkJFz3O4mGq
MLkkJcPY6SAmoo0O/yaw2hNhXYmHpXkySua16SmqWFeIWBwKYCr88S+/jETZ
A0GSF8KOooQMbdkM9oSLAhrTom0Kdzq8PZjmFRp+mHPDmUXYj5EeGYFpPocD
QjDZkMSqqlWOiMsRnikAklVgNgsFUUzYOXBA+E3Yn35WNE5EBzlDJ1ceo/IC
Lsx4L1/xKwBbGckpw/IEKccRNx+lbnqldbEtIiFF4C8Yc4HGQHSiX6KRcIk+
V3xTDnknbIWuNnnUWzV0OAYkdsF5UTetw5KdtPN64l8H3RA2BPvQh/Do3KBA
KZ1QASJexbGJFCaYhCV6YYMULrp+i4qdmgZXM2sz1qsY7SdH6sE+ASb4dBSD
3MpkVeEjSIR20peKt6KKIv20pcG2cffqRrskS7Pa8SMUZpsXSoVol8Rt35Il
uU1kMyIW9zgJS4YSkbGqWhYsWccQ3EMheLZGv0ACoiLQ1WrdgORp+5H9+W0F
4YZRUzUjQko0qqOCdyXyruDknLQIEq6zaQu0mUTKWS7a1SgCPSlN2SxbITou
8xnGb/G+A1Kh0dsUijO6PklvAqe+Xasm3ZuIzzcTn5OzmSbzdYu2Wk/lLK6V
7oZqxyIf0pMalUvEnAKb/VkC8F6ZMVhYM90Btyq5DzBgHt0ese4M64YFUZPs
clE018yrWOZqK/MQhLg+VvxxXkQMpUJJ5+pFONgXU8zYNCuaer1CX4ahAkX6
sUdahT6WoFZAd4rLhTDNrLQTwotICMSiGZN45gXDG77MOVJA7HXkE2XzYQTj
N6d/D4ONDTbxHW81xlhpgRiCBE4jtfuJNbXOkDekN9UCKCs7ym7ZF96LN/J2
ezFgw8ODcihcj44HxslsIHAALKJlJ6xOtlUFxLLFgO2gLwjuR4xkLp789lpN
ijCkOKeFHIq7s8PKNvBRYG0RKiQRhgu3fJgii/GmgVqz5q2UfOSnDEIq7sX0
WD0yf0XVPI/KcGJPCtUCHjBdLywOM1o48YrIEsEITrRf2AMZ6wdP0QKqhGIi
kQCMrGZqusV1BjFuXuQLZNqJl9yadDj492Rnf6PL5ULIsslGlGMxzKWMepFQ
6YgXu0KSZfYTaoYf+Q7OVFTKXcThlre97EyGl4WJG6AlTTlaUHNSmPYa/xMk
L1COpVh5NzW8VizimRO2twH1X5KmjrCaa+SoLupgZxJ7p16fo7/gR4uGJ7v2
CI0zjUBhA6gISsUn5DtM0VF855hqVluEr7JCGK10JzZwTRnGYpmUOLWluRpp
FMMuif2MoDFikR6f8d6NgqKvnBHLi7OAGJhKJSd+z05peUxt2cWPakKbqTmS
JwEF2t+UEWqKtCViOwWRULzHIEDUeiXFu8b4SGYEZtKDiwivOVqgVNr2lAYN
DMMhC7iJAK+Am4Ie6kxxYiByAUE0f8Ex7kFvd9LR5jfJehzb12iwIT7KCILy
q90olZNRHLWYjrDSDi6Xdw8TKxP24eotJmd+/xp37hLFQ7cSEErYui5dzDw5
Vkw2XNylAcl5EcYE02YKCLBGqUdN9BLDR8sCeImXgkL9yfPeUYZRA/sJ8Vf3
x5ov+QgAgiKHcuwO668YoqsOgPj8+QrnPwFT9nfWZQDlFEUOb8KmVhJN40QM
yfioanQGsaihHtv4IrlJ2R5uDCE2YDLjiU3XMQAShajDTbJaOvxkLj6Ad4iQ
Z5holVmsu+P8Td6L+G4sX2cm0QlOih8g5DDAACn/FtcX0+qNqDZAtiNUp7FI
9dNw3aD0bdy3GreHZsQ9f+F6fatGXTNGAYWjVNZ7QK382lv3mHylLkyV5TCM
tegqA3r7xfYpGhh+09G9YDzZeySK8E0gT2ETKKhoX6fmKsPgvciLw87gqmlR
+GKo1RVeOCHAXQQhf3zbiyZBvUzijym4WvHIa2MhTI4CYPKfxNCdJdMFWU9U
HqHLOyAhs/JI8d1qyuUAKWKZKKbKMkyFmPhnMW5dMDha413uQvhYpUObCJvJ
pqxsepipEqZI0bDrkx1FbIlGbMDzC9iQfAnT4zCQ2Jq1Saxm8kWOJnILsJ+j
a9EomAQU/yQ8yBErzMthmc2peqb5cDS4DyEKr5G2gvpg/304xtrF1ijVONk5
GPa8YawfSTrI1SJpGj+zg1HTwS2TZPjLcLG/rFF/uQEM6qbAR+RTnJeWm5DH
dGxnRBLzffD3w4YjIMIP334S+vuhDQbfpDMvUwXxyURTPffvJzJp9GH6JN1j
p0zXxu+clAwwsaZWNRsZnJ1MN+5tZTvpu2GLnJBP27bITl1wJ4wdCuisNdsL
0TfNnTBfe3iXraqodpo5FdBmhUb8YLH7dYu77/zIotaIi7AZPoUAqnAIzsxo
Z/Auspm7E9m8hPymWiCxM8yRFQQW+dyUws2cJzhvgOls9eTbfLb9jJm9jQn8
ZsvpCxGP3BZ31dD+cXwVs79xI/7WPcSTbRoCY62NG3cA/fTJcfp1DKtv0gl9
6MeTU/goh/4ca01EHm6cwz2/HY5t/8kBDCZ/4tjhTxmOj/JxtybS58coq47N
Av6LxqmSaZ7TibrMEgg5P8/x0SaDcTIEhRklnEWLgYw+hhFflezLIRHNe5go
cpON8lQnhNOR+yELuD5LJsM88Xkv7pyvMUfGWPEFiwuSwB+VdbJW4qOR/yUZ
WXxD3KxZxzFvdGTxK8BH2ZE40+zxkPotbyTqlEUhQaLWLDh61I0s3WzmeB0H
TxY+s6yfhMIZx+sSNXi6uVFGFPDAfpbeyMQMfH5DJh+eFhwLzNgWHMGkdmdh
EVk/JxCVG0yqRdPUiqUV5YPFgnKg0ewWBw5L6SaPr+g67OFs5y12FHQWYOHd
orOuirpoJQn5K04USVyiSIhtnJAH4VVWg7Q38MDx3lN6AIv04If4Ez9IKHyb
FmEJvPLO0dHTQ3NLWFyshr1awY9EbkAabkBJ3oSbIqcQuevqtncHmH3rXpkp
SsGPU3cx4sRl9nhzaAm6ktoovCcKLfmarDphoHUZh45YMCbvzmKlyE5BwnwZ
aWjeax6NbW9+4tDBi2s0AGPtBPVKX6qANTQcTIJxYvT7uNV3CerIyn0uF+Yo
5yXlRqvRBpGBBkBCFr0upsaumduVNCBLk89moWQxmk9S5TTlhC8NxweW7IlL
ba5Gj53rALQVaFaUAo1ykLxV55oJhIK2xPmbCyDy4Es2yyLPmO55E1ovxwpz
qcz7gECZ5SD9Irf2udiinYm93QqfRDGkWoMG1UK69nIhsRYRXA10WnWM/tNM
H7LMhW71AbVZsMekpQAXS4kyALIrhbdf1QLdKpH4Q3Fqbc4zK4WCkA+n6Tsn
0HCZkMOMInk7Z4eWjOl1RRV/KsliIv+H6sgqKoeVJ+51zE9A3wUI4IF6iLWJ
COVjTUUN1+Lz4x62i4syVNaxaVlnV5G6h05hK8lW9/5t47XfD+lymDOP9xtx
QJOZ+4UdkoigalaPUEJOb+H8UeLJSwpBCJojjDdKugk6zj0k4VSqPitIgi1y
36dE8BrwyuDNEn2iIZ9t/tN1cVm0mhiKeJ8zh+vBaBTS7EVeSoJoZHiFUMAQ
8Nha0Qc4mwAx5rhi/XcJMCOMkZjejHI9Ans2H2PgahR/g8OIP5xFcp6D4q5d
KQ2yh0kulmYlhsFd4Q3LJkTGIhnZqNifBpYjCV1fuo+sxjSeTAktSBhKwcSK
fDA1fjjiIjxID/NSzMywyvl6oWlkUmYh0eQVecgCpbLGvaD1rzB0Ha+tv0Id
eo/aDyWKMA1X1hRqG23Ks08xv4CqBkXsMRkwuQgrJmsMpwS7fBTlzcatMnc1
syU5ljSE1jEvdDxJ6NxmXoCeU5zxjjPIkpiGdUNbDJZkryTDEOcCAGco1zhF
e0eFe5QXmp310/fhCTJMo19F4p87cxaqKYLqtvUJTycczteoz23FDhinno2i
ebZZ4TnrlBgwKaT9QjSl3BC0ol3mobST6ROlZWLJKQqglKIyCSP8pyyBhIti
3rsDteU1wfCKkb1OEEOzHclgrcUZdYJWOYjGDLA6Fz41QuZ9na0adTCk/pre
SiGOnmiDGfRrrNyDurpVWEFZ/9t7VyIU9EFLoQJcDWi2WgMnBEM4bz69iG6a
7nB02fS4gICB9AnjrVc7ff7XwbcOjm1jvQ3K6twQwq8ZsQWG0MAmT54cs5vT
zyFh7iwK9e4IMFSPpzjKhFRXdFRSVTNJCBJ9QnWClNK2Kb8cjoFEbA2LrIPo
ABv4x3UBK5Ck18MnByOLjmV2KpUIdzCJU5KC08BosKidFD6AzaXMGbEiCyrX
HQaMQg5nFi9D/Y7LplpQyRWTZkZeMELUTswxFgysaEAwYcq9Si5RDCLS0PoQ
ypCm5yxMeclJxDuH2fBVseBtRnLjJtGP43UsNMBGthc7iiUHryQDWZ8gkbUV
qqedzzG7cxuzqa+ukLGqGYGi7Gu685yshVYGwJylOCg2x+Z2i9F5DmUs0QIk
xTojEXYoKNSWvU6MFtCnYHMGCfPkx8CAstkMrwYVzqDMuhJN2Fj3rRtS5Uwq
6gulfEonjnddogAllqk74B2p+8Zlx3KltOHyNhckiyA2JbhG802ZR2HTm3RM
ceoehxWQAtBPBY2TRstZcKyRCJUwq4nVY59+R6Uu6k9MaLg+wo9SSKPjLfUx
VFKgrBMRrnVTmlEXOcnvhaYurKhXTFvlyxvVTpftqSLzgMlFI24QYCGBV4tc
cj2S2N7C9dTI0gO6V2n6YnKBiEFmLb4kTurDnMhYa8D1cu6ps3hgKBIKgT4b
dcekC0QYF9BNCRhx8nR8/xN9Se6Ld1qJ1PjCImUxjzBxx9ZP/Cus9kzbchE2
y03UOILGZAncSStglel7NnT87nnXmoxyxcHXbPHtCEL8rfMVk2B0Ec8iEdkd
gVJsGbJcNJC0mkrJPKXshrFUXEGjVLOwen5pOJ3LJ59rfMEsUX2GOC4y3DHn
hXVyvNqhuDcLIDcgbDMV7wQQoaQRRWOF4qQ02eWd5H+6dEvy33LEgjf4xhvf
ESzQw6OayUuJWtdoBfj1D+bEGCo+NeoHPekO3Vl1kFnE810f/kiRDSDRe3XI
AiDEZKikyMXALO74yodQiI2hdm49qieYguDRj2FOikiQhoi4otrnHOkKwWEm
50s+DpYtY6dlqqZHhCPPNRCgr1pWJKfpISHWdE8p6ZYI847oEE8hccSBiSiO
ueRsrjgZbSFhhfGLrvQQRi8lRJsoUowlq46vwldgceYwcn1LwJrhi3E4lKJJ
DkAoUlBBW2kABX62VNnBph58NR14tegGjTadsAlK2UAT4DUWXrYqIBJL0VAq
s4+VaBI5VJZjvrXMLQCThhbifKLi2I5F7KHId8RdDpKwUAvcJdYzIIlZFeSB
dckwvK5JtC6xTsv5mcM4SFSktcDbXJMuLAo40hQdK3MWM8gFk1FIgGV1ZzO5
xNGUPlVJtFIMsUHTY4yXXCOIKN49bAvJeBJJasi/JEJhmKhZBEqoe7wVYlJP
PEXBiNTtnt88UM/FLcac4J0ybu1UTR+rT9JFJ9M6czkkEhlvIs+9xf+kFFuv
hsPIFncJL1bzuREWVQtm/cp9iaOSHKevVOi2kBR4KnoDuCDpbBedSeag+roA
kOR2UEL0UfZWMVIYR2w9wMRAxrKE45KwfYBVOKBsCAx+olsrtGIw/Jm0esoZ
uC0aikitErFeiA1PrwYpARxLCacomE/i/ABMJROV90qyh7zAFkan5MMFyWiH
Vu6BZsMrhWXYMflD1Rj1wPb1mKAr6DxGyDjQo7s+OQ4QEl3mZseTXZTd8EQt
HudyAUIFFj0nS4YjX25BxeCqGi1lapRFVwo2FSAVGVbVSGjZZc4aR0hoc4U1
+5qWWn+oPpl31WBU6o2SNqI2A0XTA0PWmitFmdzLmkeqhdreo1wXr9glUm5F
rih6IoW9t8b0CL2bhupPKFEQ0VG868pLkiwojGXE44fstbNqfbkQGrTIyysM
xgoWHFycDHKvCCfSUVu1WMAjDEMKNzEcLi/SPUmmMqnGSIZI52K2sBU40cvJ
NpJXTNLH3DQJEQzn5vgyo3GsIKqO1/VzkpLPQ+nd8+MlzscSK5zEUWU7KmiZ
DdCWnlDd9KZlk6a072B3Tcg2cJ6CINaQACV6mB0Fj/A2v03fZ+11w4YXF+6G
1YubNcrjzuAkiXlqxFf9A41aGpY7YKf6qkmAwMDpRgZIFiUzVXW7c31lgXqS
5/sj1+0JhjDK0nMVifjW+Hi62M4M4Nnf3182omAlzHqI+lwHqBDz14qpwtaw
XjDG1gCZp/QRqxEDOpi47txyO7VnBRPjGEjJNInU5FNvE/IgZRVEi7yZQpW+
P734w8cX2Dvk1dvvX4nnymhsQl9/eAVKyNvzV5oz2gURBRv5OEJqp6Ieh2Zc
zcdUgx7oHRpU49jLYFrmJUYFAxJX4iaKdqfWFBG1H9QgmuDf4/L9sVAlM3ON
eSrCqtlSvWLfqmUO6yt9AWyUROlU3KyBMstDgNJYFmk5QvcKd0kY2y61ecsD
IZAa7ComSQCrOhjD5KxhhACKXjFCDXwfGl9YoO/R0SZyrrDPIIYO0+rHSEUk
TveUpYL070RqwHY+P5hO5uSL+62jypMYpSKjSkK6nxShpUIMjt6TGoNldDgH
M7bG0Ism4eGJqjMgSvs63pSIRpnHZZW66lI0JJe5SrhGYqSBDDMZtmmwphqM
0wb9UPbEHFgMnnDukTcOlozzsEEmu8IAWU6kwbyrccb1dEVvJjjtpCGby50K
3605GhIBjHo+g0IfWXORUbISSWWbUFyWUHU1oEQDw8YvFxVWipGtk4s+7D+q
6KA7T3TnhdU7sLWwlN0UYg4lalZGxuF1STO6tUiovRTceoj4SwXCZNc3Aamj
ylHHGxMXg3DsNFbCBaG8SRDdaskK8YotC9FWsXMw66G8o+JnoCz36aXe+sgY
wvUexSAS18DSlMdYwRzZeQeBtqy8WUlaMaRpZL+bk86X9LdOMa49EZB99Ljt
mFyOgo6EZQrcGF0lgZMOf3j53vAq9PK5Y1l3Hixsk73d3YRYg0hC51j8FTnl
Dyu3hBfUh4VJ2Y+RwUJOphlYiCs/Pluz3SrXNh0U9poIBcsaFHP8uc+KmT93
rkoxjwmLG4ktDH19aaT2JbswZiVWOQlDFyiSSp0mmm1jGwtQgMEiM0kIAqgu
daedY8MtokdMtkgBeIiwA/vpcv9bRDNy51D5IqrKm65XUXqmnopUuWNTToiy
7OVsigfXSmAKFxPFgp1hUbY+o2nvQJOON8qfxaCsTnL8HYblXFJVFI32Y6qS
BKqiqV0PY0ahHkjLWkCoXp2xdqSSI9JnrWwDk2OHvk+kDjgP41AV153IRMt+
DLYouSLIngwISc7Ffylyp9kYo4QsM2jWRfMJiHFtydBob0WBFPVdrf4xd2aA
UI+BLhCGRK/p6DNQfabOPxiX99u7t7yf72dE8DMKwmp7E9WL6thfu1lrepW5
2RIvq08kEkck3mP3GqTWnU42Qr6Yz3qrN+cJKIfNMER00zxRLwSeSYpWafsR
jaYPR5lQHXhKobE2O0QiRdVgL6OVI91s8DPHlyPbXyq8lVgMVt/CkFmZZ1Su
O1nZNDyQCTIOVsl8vViMG0q/CnLGpsYQgW6ar4UrTwBmYGX1jrXB+7YtwVKu
EMWF6YxMh73endCFu9fcs8NNqKJisyrsMZi15lHWKRV4Vpp8qiIRMSESmjeD
dV6pVcUcTAmfYexttSoz5YYug0xNuBDKkN+HkS4YvjgHRJA3so3Nrb5LqPqX
YOp1gUU3MI8A7QXkczB9zklwVHV+WL+jQwhLiPhkeDc8j2+fOu/TSwamhugn
KpabE4j1KaoURWK9snJS0riGWwhtuq3iE0nMjH4296C/zSRvSNtGgqzetHmv
sADrAyNTkT4VK+B68aHzKNx1jpnRUCmZ2EWnadtSWQ41fsUqk7mtoJFTTMJF
2Unei6VmcceP0AB4cy+1EyBpWDa2VBCmTlvd2PFEDSLZAptcU6NnbHSDfeML
iaDWHjpqe8fLLx726HKBrGLhUXplcBGccxgiD3hVkS/FuSW/ajhepcB8Hjy/
bpUiO0uW7XWKlUFlHKAil3cHI3qIEAlzURtKxy9hDTpga+zXfEbDd72mifik
WFT2/YOw92a+tHY47TVVqPOb77TA4eCAVu8e7PuKbHqRravfZ+THYBknZUS3
S1UVNxMbZlx4d4i2ZP0ue1JyhGhwouUr63ycqePQmU4RtwPaoG/S1eSPAxR6
NC5aIyIhRiAlqIcZqaYazcHeZLFJTmjjwop+KjMr2OKpTHlU7hqFpdQS7KIc
JJTmQ1X0xZ3zpCVcHTHKVqEmDeY/kSDjfpbagmD1osP82B3novmiCk2SxUiR
n7SEkZNGk24mhtthXL06C7IlLqYo11odZVZXqxXXQ4s9FyqeBKLa9MmQm9BF
NbZas5tGJ4193YRmJa3Ez2n0FaBJTyK4kRi8SAmO5KHA9VnnQDh5YodysdC7
fqbGEqsGSjpM1/RrBnhVdIN3OqnqIAZYVzh5rvFA646xJBszt3cBvuSanbBR
AWOTGwkH5zal0n+yRpCQ9OiGt7kTnZsFbfKsaJsVQsJQ0n1DdKnEiSKHpobs
mFB4F6TRU/nAotClUr66QSs1HzApiaXlUepKvSTi+nf8o/QxgRLHGU3XyWJz
ZubkNvMuZrzdThEi4thbuqJEW+da4bkXMBYMg8VQiGWcTIdrsBmBniZsBL3r
i4Z47wlishMzSMRrZCfvUH6rmrOtfywWTs9HLhSZ3hW1DwZURCSjN0DjHZ2P
A7oN4ATBlIJNKpC1VyDAOhPBEkkdtQUizz6HxXf6zzzd2ds5vDdGSy1XmIrG
0a/qu7B4uSh4JqrBLWELFFRkQiqrVYp1rg6+xsMweMn+/ndYrhAW+ja/qloJ
11MlKWoS11kqi6NFo6G78Ba2zhFLIVY7yzApUaI7Eu//ccWK4I69DAnYfyTX
BeqofPDneBjp58cDLhChgfeFgw3WXDFXQ9IxS55067BtU2nNWPIkq1Fogtle
I6XEsROUI0HSkBCNy7inb+rk96Lv6Q93MFxUwgyv2MrCaU3G4Ahb0fxVTQu6
vG5ZahSxmGd2WFHMlDP8q++i48GKrCBNW62cIOFdfl27WiWm+TtJphQDC4oI
PePxwE3ZWKMP9NWW8Y3WNEo6MJiL3S8oXd2VoSSjh68s1LwLXE6Yg4O+MG4U
1oYaox/1bB5sJuyxkDg4JsZGOi/XyKo6Y4lyg7xNw9J6JldKBOu8p9FxUbK4
eiszusedhLui1JqapkSEJ3AVAxFiUs5V5rQMQ0U5rBGIbpiki/vd9ttASqxP
zPD1bbDObttxYlJFtwqtE02no7RrqysFD0L6YVRaibr5CQnjHuAci9ghBDEK
UklGLMnhWua8EP6DPUv0w7EwpV+0BaXUs47zgehCj1G9GpaELcfTZdVS0Pzb
/PZDDgRGSxMcci8n5iDY4TJbNJIOqlUIcKgNRSGoNjqwMm17zf0yudye9L5z
kpxftavikVoU45RE/4KSL0mwFhnSNwkO6QctWVNDEumL9SUsRTZ2vD+RjclV
oglEvAqjOYiJJTxrY2drXFScXURIFyNoE11ET1VVazHLIZBdrQssCVDmTTLo
0N1XlPkN7mD3+JCzluO86EjVEPsgGXBcSdVZJb6z0La8YcqcOF1PDk28bD0k
Qmb9A9cSoXm51VlI10d2bOk+UYw5sQrj7ZQsHOKS0f4YGkkMlw7QrEopEo8l
M2iLOoFGV5ZGnvxNsfrlGgdBZXG11xZZW0S51eoOhlPdA/e3jpvOW483WetX
jd+DtFYqylTddRtix73HRlJ+yfks/ULx5Y9F+VGOaotrW91kdS+qRapwdirb
9ro9UVkYicp2cllsqu3lQsXlfDQWGAuNSKqdiMvynP49ZmmS71/cPtKW9bZq
g7c/IoD5FGu8WO30kFrtIjEqba2ZvnrxFu883pj9ydFxqDUAFGBi/QMT0krw
7rslhITIWbr14tV2ihWqtNwcq0Pv0+s8m7GsnAl9RCHch1FuJNNRiWfzOKl0
ncQlM2Ef4xev5Mqa3t9rQnlwfxtKzwg392j7/FjE6PH0tpxpEahLbO/aiD7u
nXKgzVDd+VDVYhDFJFAtIb+YKztBDSg6xd/JGhqeG+wIN9ll2wP3lJK8HXN2
obck3cLkGf3oI360ra1ufYFhbQ7pE8HJnzo5eLq3KyIrpWIWEhAyOJ0cteRn
0bIywIe7pmhUmuXQutB9RLjsyR4hputpji/jvLxOAlsnU0krhxyP6Tm8WNdi
9sO4AVTxxJpGj+/txs9pcF+wzg+DkP2WUdy39y27mLukf0ohSBH2LjXGnShH
FiOGXBovIokXwdZBjqtHsFlpEHGe53FsCCf83Lccl/6Da9iIZwCd9xoeEMeP
9yK9fMSUmvvn65oU/xDFK1gxHM+U/vpILuBPVKno3mFxNRovPXw1Sa9nrom+
xrt03RZS7pEt45JrQhcdXijl4EPkdp+jJN6GMyukHUFGNqnhZQi73dySUDvF
EOo3kiaxYUvoSlakkU5vWeTX58Ju3eICm6nuCO2Pmxq+4rr7Sf+w3j0uVBFT
Iemh3pf0yRLRMBhUFB8W4KOS+LFMck2GmzonrQbwFZMwaFwK8MWM/pJpz7y4
Gk+n43mzJP6AmaBp959GUSP9o3/fjN2/b6IXhlvY/gzfnCPe4L+f7YWtd9vj
wX+/oxeImUQvbP53z5Lu+/floSkPGTa++UlBEMOihyyX/90knXVHM/K/7sZ+
9jjzc392/OyDGhZwLT+np+ieofpc6c8bYP2ebXv0wsCS4n+bYf0P9+02gsvP
D37ym/E9/7onfdpLPhZBtjsF+ybXsYyK2P/5Wfo4XAoQL9pF/vzRxntKxPEC
zfkcqfWIK2xhMYnwPZlQwzPm8CBThijF4SaH0qpa7s9i+vAK0bVAv4ASh9AU
ORbD0AotmR5DxJHaDi64XmDiXrM8Dqd1i9wXj+8jBcLHiS/dE1UNpkp/IR6K
BT+0jqEslm3axmjT8s3vJe4+CTgw+2JkGWKlBD00/Tw557Ig4S0kTvimo+lV
Xd2GFKBNjMvbUfOfsLe0P5AZK0acTM5XVKzq3d72VFfI1CmcMZL+ffsDiluj
9G4FiU/7xBY/OGfz61Aj7tkwhB7aGJm0bk3T6vRhituYJ64PEaKzkanPj7tq
4QB+yy42gA4FjZxLJbWaGVCFyq+JSMy/BogB/TXfKVtgoi06eZP+MgA8lLWA
S9EWaRL7yieA9dapdrIpx71B+iFmbed6BfijQnCdLRgdo8T14X7dzsnekvmV
c0v7lomB/Hj2aM7iaQYXxcbkBFFfpeTOHjdUDZIqPRsQ0pXXp5qRAYRJ9xwq
suFJZEUoXRKMgO/rivoGUNLDB2r2qaEDVJLw/YcPz0kj2+cyrhT/ec/iKNoQ
i2FSY80d7bk2eK0UkG5Do164qgsUssjkxMIbtBbyioq4rFedgrISd+9j5FxR
Zq5Y7uNgJNEurqy4seHSoUvsokKNQva6h5AVSwrvEuWjB4oQrIFB1yiaYMQy
5WwnmLPtWooqlx64LMPnYReP9dakE8uLyh4XF5RKUsJGij6ZJTra3Rol9itX
j2mTW0tmMldE2RMvdwxcjn6Ikbars/peIfSAPGucnEcdnzhQEg5IB1USTUs2
RkLo0OTM/8hrQ5c4nzkk6rDPuPSx1byx3ZqEuVEuGQTNF9kQZnyjV+xSvInD
NIcCTyqJAutTGyPjm5bBJv9SCnLeoCtMhOk3UtttSpFVyUvVJbdOz9683MZ4
tLqisA9kEEQ3xVbjNeO+sT/YmkK4+ybji4+B78BH2FLUAjsWQ5AMb0BLE0Y2
slSLs5Sq6X+FNIJmR+nKK+rNPP2hlNIa5DOzeJeXA8UFRpxvscHXzgGq4tYO
XjgukGYh5uTrDBfXivlQWLuV5cVwKWf/pp6xITpjlMRxtLFvdMC37kq4dNyr
iQQWBa/iw4bpJY0gfOOmjq4XkYpBfwiQFBdxf17uJU+ljSjOlxeoHN0MI7CC
2aaTiCq7VI0GLoIo5VaoDo6BZW4IgCCpkhugUErKPe3OpRvwptzOuOoeGvZ8
ULrPa9T0vntjCdMgIuK7ibRSVada7PBSl1Tmyv76AkWuYVVAktnMstApik0L
2FjvGlegRapnh3xIDaPgBgy6EL4uTnXTMhPdxGKMq/4JS8VtIF+MlPc3+OQU
FGu/Kj0AyE9Pdc+l54lmw+AJBeXBMZjPj4NSMQ5L+cVlsTHB6001j0Jr2JnF
7aF9lXfgyNx3wcdgSrElzfJmN1quHiHuOzVkCmT2+FKGxLVPxzrBL9qXckhF
0oei6oS9cm9b//pKb9vp12QJ+RSgHIBsNU+5Hpz4dTX0M6oxVqrHT8oghYX7
Sm5xkbmC+mhxMGJovTpQuKsoRWwRKY2qTLsOvhr1oHNKC2nDAQuJxPrdpfcI
EyHzVycZPAcf1EeMpyNBxhG4ZFFFmZl8yuTX6BQwbFB+0pqtnOv0IS6iYGVA
u3LWa/ZDkd5FyHz/yfWuNSPtFDeBGn2iecY3tJENinpUQkVlyKgbZhJis43K
UJPATAfKZyGS+UJTM+Fr1iA7rTUTWawrTD24shDzXUQh4XxApFmh+QlvNOBq
cJPR6AOlf0PJ+y+AlcvbMyCceegyB05J+pkaCFAg/IkiDoG4x3V3M0KS3k4p
/vKd8rhbUL9ev7f6QBwsEzQaTg0citQmam2tnAcbQyuL8VkUq6zFxAGqLYQ9
3mLU7pZis4My9tLowVJhgsYqE3Bjg2KRi2pHAfbe7KnByKHEV68QWSFTjKIm
nOLE6iVBsDakdQSlkgeReKtySw9K/vctl1sZ7DpEfDqpXe8h7k5L9iQjO1Lr
NqI7XzgBY9+zXMODB/KKiHu88gx+kCc6xcZzveGbE3pB0rZWXJezV6wTjQcu
28BSoOLMEWng7AMAgapRFXJXp2m48lPpssUipuyQg7YFfIrTCix0yK8sq+PQ
Pys8bsfTHe++0VjMIVRMNrmwbGDsIeP4+S/b0kfza8rlRGrgqp6DAka0UPWm
zsQm4+6o18B/a2U0PfTtFgcVhgQuoDUspHh1kI2zw7mNUhAa9TXVPOEbzpaL
YkoSLP75hS7bQxCTe+eq5rDibsoMJ01FqciujI5WYWmv+/3vnJ00q5dNp5ih
prT1GhBu9Zoebht707oecZdnFzTFbnurO78DPBxhzqap3sFbQU5bKNOnLwof
TDo9xcNcqDkmqpEsYUVJVEiNTOxc95v861FV584tHKZOclKWlBfdz/uKJJoa
xGnxxq5Ij4yDmwclPqr8kcYpQmyZEmVYIln8Rb5nPRZYGKbWYMJk4HlRN7NB
y5v2alVZBTt5lznlNyZfEFck5a3loGncxoLKdFaU7VosKEVf28MMI4MGj2/y
qBgZHsWqXN9WpCnWaoAWo9TmOIutTxIcxgFh2yNvIiZZJgkFClU4rkqVZ1Di
7RoMX7EcwTQjZHuKeJEClNac8tpQHzO7OXwGX+CtgIRUmmOos+Wv0pHS5+le
8gV58Hm6z0rSiwcnsCbJz9xbJvJ9n7L1JPJ9//xMnNv2y9A/eC5tn++yL/08
FAtKH0/SLRDxSA7bpvHgucnAc3tDzwGlh+c+5NObXir2HIeW5/YGxtsfGG9/
4LmDgecOBp47HHjucOC5o4Hnjgaeezrw3PHAc8fUjSGdbOt5IFz2+s+d8HN7
8XMAwM3wO8HnErF1pnupKCvpcV+mCqbWrF8nSZZwwu4cLakEFA4wE5eg6V49
Zkwliy0Iz2d3eXkJUJyMbJzQCb8mvq/nM1juOJ1gG1OJevqiNeMZxUDtwytH
O8nvXdxAMOJzOmGGBfBpYmtqNSAwurUmbq0Syod/+vWylJVF5fU2WnnQKE9s
K3eRv5tpc7GQ1DQlYtQspWchaKWSn/iDRVabR8FknhOLqSkyeiTc4Q3JC/V1
g19+6Zd3JoZm7UPmnYQiA6Am/RclKcpWoWxDyrSmvXbqfDSs9HtgqoaDhpe4
sCMFu1BlHGoQIih8ua6b1tmexYJBTYXGWO8g0mIkCRNFjnPpR0uGVylcLuXk
aOsSccleX5rFvSTA4if4S+GIycY4UK2LGsVF/+KiBEhwC6I3yS8eNBSpbg51
537ABjn1pcqashwrCCFtk7jUE2cLdCQlABYKr1S4eZqxVJHV0+uCcjA6HiCf
zlIlfGY5IInVFpuSYfs78o2iJDwlaZs+lyO6rbNVxybsMzOkQywFSRH9ci1d
N4YojDhFlKaRQtSEytR2Q5AN5XYWXfDU7k/yR1ZL/eTMzOyTX6JiyuRhm89B
P8rLNvam75hf6p5MGkGmECGr7htY/8xV4KHrUFBXR0zNtKUJSqBzpVcQyk5a
8ZpJtqY9IfZh/02Oq6UJFRubFcaqNGb2BwJFD6E4ggE7VOkWG5HRUWdyDNIo
dxCqoQMy8Ygy7+c+8UWmnBwJYjAz9iX29s3r7MqKb/cD+rX6bqd2O/Wlilpw
UUFsSgQjmxMXvqMQAjbxcOuyMMPHEIGheTciJ9JQz9O3wJ76jz+JmqpI7/O6
2xGspIYZ9djcUPDHDRW1tgXSsmRG+/55uhU3bflaMJ3ig2Hy/oK24dO3Yp6X
PpPBhvkf3v4HM0SSVY4VkFAiMN2ae2seyHqH21oEgTU3a6PCFdA6JfQlZSwo
Q1Ssbsxx4pkGHwyeLQXRUztQJq3EbXmmEJjDuw/d7LkZDpVbwKvDDcUT54iA
sfTiTu9G7MrNmGgGm9wsvylIDWQmV0g9dbsAiZonzdq1xPVoWzuKget1faNA
rjyUw+lSZK7cc6fCGu5BEgvhLD4BU1yzV1qzykZJ6LY3zfCNQCsf8cOPerVh
Q8gAc1FCG+0iXGs1JHt9DgqWBYBhGZng3uQAC23CxI64H9zhqrW1lyck+mnX
dagYeG++mSTGiveALAaJwEq2uTH2s4lQz1figa84FlHyMDclgIib11o1kG7P
UoSLMalqj8oWPCG2Adf8Q6qmAcdcGyfpVSsCXJjj2MocuUKij1AhFGQbhtJt
za9jge+XbeHBcfchn4CPVzRK4NgUJqW9mgkjsERWMOM4IJk1CJaaL+bRrhQb
fXYiCc80f2IJJBuCEkVUlDO3Ml2+GlHgf74wVojqowzfFdX27cg54qS2iFS6
4nCjejQr0B8pZoDhgY2I5+iyoZLh6JZ7enTETYITrB0ISIaX9EVEzOjmvNb+
b+66nHPedJK8jmtWi7DUTQOGqzjLiJ5wlMBNtbhh1896uRJKm0gudtiA9LTi
rBYcGTMfsaATwBc+IQq4LrM1nEfZckfWBH+jEl9YgDBrW8Sk2pHS3OSRKA6y
CHV4iNJc3iVLOJIVapZCLRrLFv8W6QzVOYpqE6JIsJA4ThKO2VGsZc+mXH4J
TuHyLtXSDrQlS8KUmIGLOsNbBzvgVLugYnMH5KxGCbAjtomAcp3DOTYtz5bC
SZYt517BpNw0mUy1zNslUa2TZWBONG4XjdgTpTMDdQU0B0b2KYFtIBvMeUq2
fLoLpQ5Fap+i0EaOQQTKRhwleSQlXgK2LLqGAqlOyHGwvGcto3vHafSwTKnQ
mWi1I6qto7ZngDP1BPYt3hngb4qGY770RN4IkknAZNBtlvpkhIskFC/UJeXw
P1gS5+ZtxLJL6xVJXJytgcPRXZYgNBt16vKjnQiQ+EbUgriEtVaLUb/nAYKA
M6B7egrlG9PrCjUCkxcJSCSrQ7aUNSy0RP61goJCZ1oetezsiuKJTV0OBWF6
DyoLtWA8ql5BlVMoNVqedM6oEBPct45I3L/bZ9FQWB0e47wyVgUrueQ+oVr8
6NWLC3dBOwktcRxO6Ubx+dk72J1D0ctVqO+eNxnW+xLfEJUieUidPS7eGdm+
pCNi0YEbbLMlaMaGcpfl7Jl3IuWNSYapuJL+DWiT2RU5ta4yFa9cHQGn2knA
4SYFNtVqW3d4S3c8IwkPaTTHjPfcvRWXd1HBNwAFg0B7WthVQ6oFgj/w3jd2
kZg2ujpdcSwDKclRSv02D0zURqNMApG1jNbAq7QIxyGl4CNh2oqS8pnNnp2+
Pe2x2IteqiOAn57MLF0qGY/H1KQJRyGea9km75t8DW8DioL0mnNXCKsCUQZ3
RCzSizDeaTkRJJEkipf//HlDe9SVTa4h2I2p0Y3KBFgvvJiCZsawf4FPY+V2
ykWShH9Ws1Z3tUa/FkqcgRtOiSCcI3iUE35+3MrnVJfTVbe6wPzSWnJzg8DV
R0y0A3HBGLlqOKBUAxhsReziVodJDZnpqDL6UGWgbs3ATms+qnpEoaZEwgO/
BVkkdvORkEWF1Wgr+U9SlKcNga2mvgOWLmYNJoJ4MI35Y+0RE6dcDMtwyCjm
nOwVNt8Jm6CYVi39QQVuqdgmNoqnbg7BgVlIE5Oy15G14gA47xcIra57xSH2
N9SH07Z7/ZgWZXAbemOzdTgY6cj+iIghEjTFrg94XVlABXkskZBhM62RQMQd
viwzxrVn8WidfkfHAsg9dFiJoMFHnvcZNlLvBR1a9f7QoTZBZP5oyIzvnaaX
VQWCmHCsUBZRO0hmMYb7MtZc2KBe59r5I8byfgCt4nlo75KibqI5/hSFzZJK
rAXilybg+to/Bea/Xt5pNfFuaCZs2OrIPGiz7kJPOe4rKiCEGlMairshaD+K
zY1PIICen9cavmHckSR0aBgmlrPAvrnvYWAtX2ElZeUZIk24d8IkeQjmx2vy
EafQ6S3lRPagVQvFyfJCu0PhAs+kjg7XnxnoGsU+YH5eu113yAOGlKnDBQMk
l5dYq1qYCnA8DMjI0BFkBq4leuzYXoZY/4mx3fzPuJE3Yvpxbe1d8WqJdZUN
bmrNBsBU9b4JGMyV0y4sq9C1A5PIX3rO94ajAElcKJrd3TI3rlNcjhzgE3cb
f/gSz61OBpthMfxGPFQFqg22BRikt4luezvcwsmTY9yEiw6gLVxQVNFV+DRk
ZQGBumvafDnmiL5c+3YydevP4lfSmPUWy8wskZK6TmWKrLgpbuXI0Ip6jVE1
DNAOy83nlfRinuiwqFOcYdZbupDnSGSJAGB043rJrSRAyjJbIvejGowBYuM2
vdYfNP2MVJD3htQs5KPAH64a/UvqJvMLW7jhKv4d2qOJI2Gtz3AVF7Nxr9BV
koSnXTick2iGxW0vw/Vy8b1cBlvkXrNorNfjoewtJNQlx6ctQY9c1zzfMptJ
+p/rW0fUntq6pxQ3ZjXkqROLZbMg3XS+AZ0uajEYfGlWi8dnDfiNwGQg0MjL
YxiQBFKOh/GYZg6AzUMNDQQkNwKKRBURoqLuKRkX3UjcQnPCsoGK/RhXD8vu
TA1D26wUFYjzfuTb0KHvUq+4GztI5J77/JBfPWKFtgONiIyFLesGH/lwqV/6
rGFhCS1Yac8UE4QzSzTtNWGIrhWMoWKSZHcGaz2oeuXdEmUxksTIurLKkOmj
uGntlSfHO3vILje084r7pklgY+a7zIcGc3hLTbCQStrirhYz8oJIBNU6Hjla
PxIJH+kD/vhohP0jPUycDEn2eFnNsNw+kdq1ml9jXgBjACn7SCJHX5SQsECK
vbB6cGYvQQtc9xaqbFDNPy4ywKRI6vvIx/Hf/qlPzf7cEyQ8FRhUhJyIQXDj
2eBuP2AWeaFDdiM16p5mKE2VzrNawY8r/vKWMBzS0LxEdcl8m+ai6E0knQMD
v9ZAJpN9OMw6ZD6bQBBKIopvjURGuS8bl3taWjlikaWiZTWMwoMBn5XXF/G6
koW2pRbv6UtPcWZYanshDjIWHAbV6F9EeDzTgifSL/KUrxcVUCklJqdLtEOR
lCETw41xNaCHcSbY0I3aoTLkW9vhqqTP013HuejPyO/83HdIFaYQf5g+SfeU
yNP7XdLLHyKRKz8yjAFWfzKW7xNQO+w+hbNM06FL8Scd688wupaNkbSAe+9s
9OIujq6o3/mGxAw8tXelVfbPRLUc0t65mmjftB8bOMisoGXMjS43GFn2ruTB
SYXtCRt9XBs0QaAvPViREOjRsDGK+K+2InV4ZGc1SiMojuJiSaYaUhc50eS2
8dD8LQ2Q/VM0y593oj/T5w8ujgX/olcfPKHpe3DGQCLhKjz0zQgMv26p0asP
njCUb30e4Pzgt8NxwOvhD3i/mKdbNh6dFX8WrVI+/7UXSkGaRmj34sWWww76
+jxv0fD6UukTqVHwqgr3cOk+BI5MMhCWPeg2psQ6VSEZe1OBQ5I6ZLAkCzUU
pG0qpoiEzp9DMaXMQkPRSUo3WJOFkb3prkzUWSlmbGpWbj2PE5ZeONw/t4xh
7tpDsmbv3uqmP1iz2M7t7T6wpQuk03vyhKvNoGWxt2M2a9VU/TyrOcCTXgmZ
Mi42LZvhWzuCPAJ7SopoNwJdMOjXHXTZcZ/qeZdOxCx8axHpvFnmt5zLZBGW
GGMa5D85yCEow4QGYNTLf6CIAeRrDG6B9pkkL8Pjr/QGCM1kgudMrMHWEm6X
aG7Dl6zO23Vdkh0wsb/m2aLJMZTIrRAvaaDN9D4O/iUOGVikTPlFlooScPQQ
vJbDeh72uhFHTK24/+FRf6rthFGRcea0nH2gjhGn+J16LGA3sxAHY9FZhAf8
diQDc3ldHKXhWGMKd/CUFJGb3o7W2dhe7llM51B4etCgKD0T9b6q11HY8DU0
8dTbNbCInXy5au+2tuXwGD8ESIyudJ+ph4R4okQtiBWBxs8rULq/TSXecffO
fWuUKbe2u0zds8reWaf/7t/J14MXbGCibUPhILTKEMR90vHQObrlmQhAb9l1
x1PcMRVXcfC9lCxBz7aX7bBpIwrTqLUxTHrG9d5Ldt1lUPi6izosj7YB+7p4
B7S0VbTzGIcr+I1/tYMzyo4bHGDLP4hv27eE1oNQF3h8oB5IQX1wVeGlowXF
31GL2WLO7wReQ7q3K8Nub4UyyQrO93leS0PqfHbK3/2dNRC2fcWKzGZ2kyTR
QcshK/3saywwmswQNJuAcfRFR03qfGuaksNTVJTwuwEFKQhO0e3WybkeTjNo
C0OIhUXCb1vy18jNLVTpNZeRNkMOhaD4/DYOiTODML815R7qkoLOIPO1hqTD
ugAsc8lyuBr7e9SpNyJ7POVuDuTBHNgeXbVFtuYGqaiP0/PDcGdmaAD/nQHm
mzQ+9XuGAQJiz+IS7ST3nxykX+uf36QT+jO7bOKaK+NoZNIvYkR5+uQY3uvk
IE7oQ/+mSUjnEjuDt4WCFQy52fkg5fc7lgGJKBYXKUt0mmfbSkWRjgWNlNLE
MrO0bSu9WjRxM1D6FG7tEgQpHzmTd3x13DlTqzeQtVNqnlN9WVGENbh4+Pqq
iTPhkrScRXXNxWnjDfIKtEBGaMuBImII3Aq70j4gbtHoeY967wIVY9MlMEPA
dqypSNFhF/xh52W827mv4NgXOYf3KLJ9uhVivR/9w6O0WqGDhbqzCr9pXOFZ
4SqEKt/zsDgacAuyhG0RqpPV7rmzc4jh5c9qRoYvtW+fiLGRneZL5hm+dTwL
kM30558HbSq/pYVEemW0KnvyW3lC16ZfBMmYHQT8Ie77fVv1t214/DwdLIpk
V7mT8rst03+dbu2l/xAYjFDQU1CWUEciAbLU8qmRcAcsP8qoM6mp6mfbKTEC
3bFut37zRa5n8L6O+k9hhbWuNrHF4tA3BoltZ2qjR4NAf+9LATkQGEo8IrMb
fjGMS/8ag99mcFHEoKk+/G8qLVO/tTdlJc+7o9tLcI7n2C2652bhmKQB3rYj
b8asT2oqdDmgg6eD2ChAKSxDpN4uF8YcV/izms8JiN116moMx7953hmhj730
Ch7bly06cmMDEoRbDtfYbcn2GyNG6z5VrOhc4Q1wSb50AcSwwen8IjwGkdKJ
mkGiJCcv7nBxpzfRwqqIYeDjkWqlijiiCX3bWEFFG/TGFqUFMel5qXroCg+6
5pVh+9euP6rrOIc6xM9W4H4ADTGealDAxeVrAcSPRlRH6UcA/SBnUEj03kl/
E2Rf2NDFfQEYjIeDngZOvBgYvyvlOotS8RCDEq7Jn7JxfokzZhseK9++q/rm
pU4xdn3RE7+FBmWDBXJCOpMpsA/UWHj92hM8GAk4ko5D/zhoOJZp5F3rWehU
rpILFFVqydM352LWoxcFxpwh1C9iuQnqvx5udq0F93rcObkfZZS2RB4Yq8r5
o6tU7OXdqPv0qCejhry2Rl3aSNfYCCspDMNW2N5tq9Z9P8rQQ5svpclX/xXu
pq1Cz+1fYUwI8sigReEBBoXNinj/jnWb1f3ObxFELc7MD93D4R0r5DsiGSaE
nbZYnoIeswtzBuRAkveQvoQ3pYmeKBDvz95+z/YbfvNj95iG0Jh7fr8r83f1
xW3lLVdDYA3i1q8T92AT3J5aquphgALeVrXLC1F6ZmWEsW8F8Cmy8bEFpkI8
LLka/cBNn9agrrQjfTwb7GFMFZKF+1W3JXDF62K1EwmkfxgWSAVIHj72JANK
oOkF0oGX3tOmZJf2YuKsQN98c48NyOiJfMP1pltXXnrj9ZDaKIvc95tXt4Sv
aStVJSl3eBPXjGmVdoVTFZg1PoxqszSbcIVdck0/coGN3Hi1KJe4aFyPGzHj
JtrfASOHOLi+S/HuAUJM9R5CTPAwBdm/4DP4jfNRJJu98j2S9qc/B3bCNqc4
zpTbazmj0CgyvagRSpsd0rliKVWnEsYBs9KPOM+X2ki4uwCazz7oqJdqV5ax
pLyhFLMrGkGswRlatFrPPormrMbuMFPCKhcF1WvAYFFu8BcHPUse7Zjtf/cF
J49dblW/EqUemChkldUbkWhQE8RgY1y79mSR0iSXueSeGcnG6LNnvrJmN8Y5
ZXWblIDG4tRqk3WoqI91GRgXJadrXWWrJt0cDrXTA0mIFvjt8+4JBDn9S+6w
33kPyDC0v+lt0eA7fHw77M0aPjw1YUTcuyjpGsoLfXpLptOhWxdEDpMEexez
D7BvPGLyq362TQOhwXjgm07YyeC/+9ewHZQvD5bAFH7A1jEvNQ9ZWSngbWBq
fwSmJhLo4Pf9buWh27J1umdFt9PTvOzxCM7uQWcKScWDoimjjAt9e2kjDgf6
DD06SKxN9PlN34iSYA85RL7vYEu/R+HtrPyORLetYVzdHGOzM12AXLIlpjX2
LQ3I9gieUMv33zLI6+EOJMGToaaMf1XO4HCKp4V+JRTqFR6y9u7/H+YMRjkv
LtB+Oh1T2suXc14GAut/ReJLwjl0vcQXuYNcbASDPl/m8wxt/Fy6q9ImpHxT
u2VI+pHrneJdMENU5ZLCkTe3HtVCJw8ZFzHM+kp9BzuqKNj5HERMqk9Nn0iu
2+yLPaakiZD2LmJHCypXvp3XMBINJZzAa7s7h5T/cV+dS1zw+yhmv1Ozzq+0
V7Nu5BrZZhKZjX5Ml6Hz+fNwW4fBRcMS9iXKdlNeyP8vSSG91q6WrGHlWNd1
zQkhnFWwyu6omweXk3ip5XKlecJgspt40WCETn+gognh8v3yJ6nv28A1Psww
2uRSfd11dSsaizd2RQKxunLWXsNoms114bsX/ADIn269f3PxQyfddGMnciy7
XNCAmSWLhFSovV1puA3Azaflx2nO5BtQ5d7YdSqUZy2BrQ6CtgHwLYu4G9QG
ITFJ1WImjYyi4DRR5uwiEfSDda/bUIxkkoFWwlTsrWMXMcQBcGheKp2xEh4p
6OiSVbXECcejxMW0045hE+Ag9T54J5ykRgV7uGRdXsbRRJU2KiAzQ8gLpEXN
umh7RlhLyBtlaNKD+hDuCbEBxsMnJDn79NXpS4/qqjpRPrBLZHXlW6QYGcES
5QWfgOosTZTCRqEqA5c8bGG5ymeSu6APzfN8hg4aOKZeITafgNlNZqVsbAv+
NGYUD6PJoR+pztRHLg/XSSpRqjHQaJKwyQo45U6OgmUgg0DKUSO+7aQ/Rp1F
Q0Mlp4v2CoBQtAE1D4thYnURk6Rp2PZBTG2oK5sibajNdW8XWh2Pk51ztugW
Tbd/Kn4lr2JD1k73VzuFJI121K+HqyjgZKts0WhNAcxJrpYWIxxSMKxSapzi
G0bZ+bfKAumvNfGZIB3pv18qMORvSKW27s1AWfh+jORMETkX7wz+KxI9OvT8
noQMpgGU7c8KWX4zmI5BDSyNAuJ9LseBTox8oIrvGRwBY6efLBEHtD8jnhAD
8Jso6H5g6aedOOez8qaisgiIRLH+A0JCP0wZt7gWAZFq/iDiuVDNj5HiGUe6
wmRR9SItXTcKog/6PIl5UP0crmKJGX0WhsLIGwsWil7BsIMVZ+drKSA7K26K
htCZBHquMsWdE1z9Nuub2KyvpFmQ6zG6tzMJXUb3D44OrTP9WRmEVC3nwqdk
cSei/9uHaNW5H8uTpBMaGQdFaty3/5REAv9UHIDZH2Y7TDLwpYYo/sZ/utPN
3+Cdfat69JIqNuLB93C5j6rj59F6XeYID/eyUk6udbB6lVOjyn/8lpb/G6xr
GCKJzxqgBO/q7+ARUadf8wPq/BBf0RdW4rSwXo9PmWgIPaJ9m92oE2fN7/d3
/VtjS8FdFZgdGxP7b31zH7SDhQx9PkPFJTeOKgaynr6BUYUb56OZ+sNF9Oot
qJVuKa9u+uQqxDPTzY5cg147dedFOiq3/VYN9WzODUqsj7ZrVctaFfeE6nck
xcIYrCFLYsumRrADCBNF6jGdD7ulzXaICNmnqRq9BoK7FQ+0mL0H/cLAQ5H9
r0gTGRjvi4zZEtsCe+6jzNfpkBkiGcIudmmYEJZ2un/wck+t6ovrUI3t9rAX
da8V9Q7pi3eXubj5zJtnqOcj789cQq6h3m0vM8jVvjPbl3fOmQ1WymnjXBtj
8X0KVU8/9E1tTRdED6jVjB0lEvteaOlBtAYOXgPFEdQngviT/m6zPCTocp+8
FA+WmCdBUCSyx2bdrIw/d5Ik7rsTA8JNQ37Vzknd41dEV1dI5hG3pJe5BoIM
LMc0MgYTjrEhNzDCqN/DJq4oFQVax8X9fOYucx/uON2caekAa/XP92jvpg2Y
t4Pu3eBDo2jkwLuSLu8QSjsfCKYkNxkOk2gY1uByXNDJPYgQvROni2zQ7lzR
PO28xm+FICstLrWhyQY9/U7sAEN9qUiXvZIA+qg6jl66+1I/TABYTT8SEom7
WXHlXiRxfqjf9TI+LG6SB1bnHP6u0T9n5ZD5dUveUI4xqNtF5Ln72CZdzq4x
3RqEV/Am6UVFj09KLh9Mc2Wnz7/WIRbqemG7SNIWyyrBpoyhSTLZbbqW+74n
bIM7qqMGb3Ja2doi2hLIB2aSkm+x21RaiElEQ3xFu6JMe2MbinRJyGYKglKc
nA76n7DWMSaCXCXJ79KvvwY1KH01K4B1g5pIjvOvv07T9wsSkNlJHDuDuBtd
W8Hbq/WlhRVT/0pQ4eEIMeDVPFSumiYqjk2z5kCT1XqxIKs5GlW1qAY7mrip
IbcMwa5mXOC2rdrrql6xDYS71M1quKDjIm/n439cF9OxouZ4fy9JxukLDJnQ
GCWpoENGBlncsKth6/HBwWR/lOKPA/qxN0FmjL+c0N/7T7cftIgJLoIzpmIr
Uqddu6Gy7wPcLaWd2tOwwMkxLXByfPywlewmCZ8xFV4mDGD754OguXeCGzml
QpBTwE+xMcU24qz8isJCZzkVw8SbSiW4pWkZF2VhoSfpljCSRK3QEzyORVeM
0zBmbfLhI5y3Hu8fwzmlj/dPjncRNrv7h/jX8dODbVj8+8GjlgaAaj6OjuNy
oEEkigxM5NXsT9WFce6nPNvxCc72Qf1LKdVLQWBZIt6mfnswyMneU9rA08PN
S6ZqpKEeXLcujRBCHGz/hAY7muBgxOMGOhKZd7NTNn9TGRJyq+B+T/Zo9P0j
HP0UO8nz8ze5usJCbSqRaZmFzqLCwb7LT2rdAWHggwMGxTH9OGHAnDwM3feO
EzoEdoMiuQ3kvrV6tNx4XPqVyQkcHtG0R0/5x/HkYfM9TRgI+Sy4FoXocAqL
VCYCJSZg7Jo76VD3bBRhABJci7phEO/y3nePdwkbqEv6upSEAMQqkorDeKu6
uuJ0hYaLw8EYe0/pmA4mh70xpNlKTs2OMo0Et+rd3Wjv7DbT6iMDGQwIuoMj
nOrwcNK9AauMG5kuuOO605hFviJzYSASkb7KsNjnywykdzvQdVIMsrYLPdUf
OeUVPRk2dkQuDg6PiKzDLwRhom/qVEJiZkc5SteEvCj8EcfWwnq+fjc1hufa
ebzmA8alg5OjGCDa7HmWrei6dGM71eDQEFSfEk07fLr3MEw8SpK3lVL4hxH3
Q3oFmykQr0Ry82teP+C7Rld+yAcCWyUcb7CQHKLkAd3lPb7gewfHCJ1zDPUz
Z60r3hXML/jq4RG/YzcCxRIOA5hyRd8NxHD3iCbd5Xu9e3T0MGju495eUvJo
1NqjT7wC6do72kf+s3d0fEQ/ntrVoy6pFDSuYejW4QeXyJvbPXxKKB4Q68WC
Wj5I993I54qvMWncPSE40hT3kfmhFe9PjgigslHvHexbAzuRAOo9Yop1QMg6
OXqYfLRHQhpCRuz92eI2u2skrr4crnUHAD4+IZD+APjKxpOgL1xIjRx2Z7ha
NHguB8d0IIf04/iYruUbFG/RAHSVl1IDPqUS3gg3q39IW4AxJsdHdLYnkwci
EEmA4UI+6J1dggrKFY7ACk1bSwCW7zvNsQK0wQNGPMKgWIQaquU442gnwpFd
xlyG0AEzdYAKv0yOcqk92nBBSlwUzM+ts1KNjxVjVhyoRrixd3hC1+Hp8cMg
NyGRU3QVF0cUIniJEFN0HEeh8f0P8T80KV+mc07UoAwNMRoEzMB860a9v3X+
VZRURaiIkNk7UDIl5FrkVQuJiOK98Y0JTf0mr6/ywbZGvj8Vs8EC26yIloXR
NHwb6Hn0uoQuXNg6EZs9UysQbRNOvJxuyosf377kKoSMJPQ3TYGWgdmCkWX3
kNnSLayYS7/glZYWMFL1PVg7Gul6lw1UnkErfDcaRPtAxLVahIgROuwRySFG
q1lngT37/DPNdHNfE/2kUXaDPHAX6o22A3lN2YKmgdcb5N+ArtxDWdoCot2a
i/h3V8Hz0MXY4+kYK/0dhNcOd3eX0noGWCnTINCtj/ZOjnGIyfHBwxD/2CH+
2Y+kzwtFh7EnB0/3dhn1JwdHu3RrD04IN6WOT1eohZfgTKfRWg5IQ4IfJ/SD
gXi2pBSdvuuYo9O0L1S3S2unOTp6UlIvb9N0hzTP4YR+8MV4yaE/G5QhV0tt
TJ3po9wJNs0hH0X0wag/kn8HR+KMpSuSjAsyZUgPcYC2yJDYL+Tx3v7RIYmD
eyCZGGeIFQfyNGNHtlmBe8Wt7RLb/ZEQT8gFTqowgtPgwVGIf8jpsyZB5OA9
7VsTBsUQNGCErWrlmNyNCabbm6DYPzk5ojseOsOEQRh12byG4Sio5nXrARCs
Ld8N2d/JIVtC9nYPaOTdMVEIjTQP8eikRvC3pK78hXOGEBK7hG2vhxKauOvd
NKc0KfbORERF+0jVLvKJuctkglLQ3u4J6QfvHa7Eba+ZotzFQ9AAu3ToDPlL
lNWplvyMMgQ5+Y9kSQf0esg0HUKwZWHIUuHyE857j5S0NhArg3ZZ8i4Mev2A
yKTLiJHv5L1A9Jl4SSQ62dfsL0SIXeLsACARLruNp4LaxacZpxfQWfRtsbxF
UDIfhttHiUltF6/f09R4EanLc0ijvHj3bZojwStxHfADHxrRL/oW/s77TSxb
uPFvaSWBSEMFJCH5aHJ0xD8QJJNdJkcfcq4RQ2VhhkJbyNKc10tyNYQeVy5o
rqEbsndMN2Ryss8ytTYSIk3V8qwv4zYmkSWti5tPj5B8Tp7uHejIdIjYO+KK
u+NVKO5yPqHxZKdGEoA7WiYu9QjJ/wRpBY57sn9ANIPtZR84XryvLgRRZaS1
u1bcYlGjVQHSu7t8HffoOr6U5l5IDTxr6u2c1W6+710LIY4KwjdTn6dEdb9Y
i0reIcIgMPN0L0LxCs94wPHQo3+B+n1gNTXVsIUOiNHSF/FBuczsbiI6N5zX
iREBgzUDBggfUDxC5skD7yBp6z80PRMre7ZjJYEQ+inJ7ZOnx3tBnEXNQPrr
fMTN42PH+w9bAKnUL9gCJxXcFrAMMhNotEGtIQW4246/MIbp5JD13riJF2EW
+fBXVTVnRRmATxs52jtyJqSpe0Gjlzc0zdx6fLyPWH1MStLkkDjO5HCfOeLk
kI0Scm9yqvwUNzMKVVHhIjxBQezkgG724fHkfq7Fd07kFowOV9EFhtiXIR5m
H5rsBemyYdmwxKZyTY4n3m4W6lIQlpHikgYD0tmCkGNywjdysndAAgf7TSZq
UCODKLX0k2hn31uVo8PL2YIaSWFYg6ITx2IAvHeRIh3vslw22X+gDWwy+asM
WhPSv0UanrExoOK+Gs5GgJsnA/sEUJBZ9Cdkx3NQV8opwxbbuxpbdTt3tvVs
wWA89PYX7wsn77iJZR/NCAIXfhJgzJ1Q+RJfvD7nqG2yMZlzo4mYjzqcMkDY
tr7TEFYkKZPdownti0mmJiwh8da6gNvshdCI4pnFzWgMr9kkJpOjkwcd2u7J
X3Vou8fO38eKqXob8M7APSED4MnTh5HJXRLDtbRSMISwMLKFw4Issh2lv+Ak
fJGj58+J64XnaC0TOW5KNsMHcEQK/TunoLOtx6LZvkHfcW6eu3nx00MBcvTX
wfNQPBqsPw2QQ7oXIJw8fZg9Z/fgr1vP/l/3+l4SSUzfjRkrDslidsBSMe52
kO4fEpnePxGmb5ZuNdBml8gykWunzacC9EMTwqjCtff7o+uWhjmnmlIgCX+I
9fWGWRU5dxFXH7I5MjK+u8FmwkBFqcRF2pP4HNlX7W/mEBBtC2jAMJKCVGjM
SVoDybSEiF0u10ZXMNYqkME6VxWzOnj+Oxho5ukmyffovWLqaZ8b0bzJHwaV
mIx3jBjWbU3lGGuOPDD4XV5eZTWPj7vqgv50Vq2kIgYCjPa6aV1mqIHH1xjP
0Dzh691Q3EMAP4mcvNKWijZK7nBbF5drfJ6TTs5eXXzHCTU/VqxCfl9X61UI
WUQLKbpm0VsV+g1h5D8iLXEMkAHuklVeYVATV9Os1GvPn1LxloIYzfqS4FZw
v3BejAZXYKxHorEezzhkAPQDgHBdpd9fowu0gA9/n5d/wTZ66XlGPhVEg+8r
bKL9XVbU12jmhE9+2/4O/6PEiykm206L4rv1YlGCbPD80R+zf1qnf58tYUdt
9Yg6wvMX//Jf/sv//T/8L//y3/93//K//0+Pnvzut09a+t+DBryu0nef1tFo
//k/p//X//of/5//+T/FY73O4LxeXV3ldUtE+qoE6P6IuQb1AvbEGjscW3qe
5wDdUj6APb9cf8rDXxfX1bKhu9lZXVjCm6L+S5b+8f/8364XOapg8ULeFiCW
/D4rPzVkXshuMMvu9xmIDutLkKJA4MhKRJw4WaRJPj9jCS+fPX9EZeIf/ZL8
v/WbQ5PPSAEA
</rfc> </rfc>
 End of changes. 367 change blocks. 
1738 lines changed or deleted 782 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/