<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.18 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?> version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-quic-recovery-34" category="std" consensus="true" number="9002" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <link href="https://datatracker.ietf.org/doc/draft-ietf-quic-recovery-34" rel="prev"/>
  <front>
    <title abbrev="QUIC Loss Detection">QUIC Loss Detection and Congestion Control</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-quic-recovery-34"/> name="RFC" value="9002"/>
    <author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor">
      <organization>Fastly</organization>
      <address>
        <email>jri.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="I." surname="Swett" fullname="Ian Swett" role="editor">
      <organization>Google</organization>
      <address>
        <email>ianswett@google.com</email>
      </address>
    </author>
    <date year="2021" month="January" day="15"/> month="May"/>
    <area>Transport</area>
    <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>
      <t>This document describes loss detection and congestion control mechanisms for
QUIC.</t>
    </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>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>QUIC is a secure secure, general-purpose transport protocol, described in
<xref target="QUIC-TRANSPORT" format="default"/>). format="default"/>. This document describes loss detection and congestion
control mechanisms for QUIC.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this
document are to be interpreted as described in BCP&nbsp;14 BCP 14 <xref target="RFC2119" format="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>
      <dl>
        <dt>
Ack-eliciting frames:  </dt>
        <dt>Ack-eliciting frames:</dt>
        <dd>
          <t>All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered
ack-eliciting.</t>
        </dd>
        <dt>
Ack-eliciting packets:  </dt>
        <dt>Ack-eliciting packets:</dt>
        <dd>
          <t>Packets that contain ack-eliciting frames elicit an ACK from the receiver
within the maximum acknowledgment delay and are called ack-eliciting packets.</t>
        </dd>
        <dt>
In-flight packets:  </dt>
        <dt>In-flight packets:</dt>
        <dd>
          <t>Packets are considered in-flight in flight when they are ack-eliciting or contain a
PADDING frame, and they have been sent but are not acknowledged, declared
lost, or discarded along with old keys.</t>
        </dd>
      </dl>
    </section>
    <section anchor="design-of-the-quic-transmission-machinery" numbered="true" toc="default">
      <name>Design of the QUIC Transmission Machinery</name>
      <t>All transmissions in QUIC are sent with a packet-level header, which indicates
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
described in Section 12.3 in <xref section="12.3" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.  Packet numbers never repeat
within a packet number space for the lifetime of a connection.  Packet numbers
are sent in monotonically increasing order within a space, preventing ambiguity.
It is permitted for some packet numbers to never be used, leaving intentional
gaps.</t>
      <t>This design obviates the need for disambiguating between transmissions and
retransmissions; this eliminates significant complexity from QUIC's
interpretation of TCP loss detection mechanisms.</t>
      <t>QUIC packets can contain multiple frames of different types. The recovery
mechanisms ensure that data and frames that need reliable delivery are
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>
      <ul spacing="normal">
        <li>All packets are acknowledged, though packets that contain no
ack-eliciting frames are only acknowledged along with ack-eliciting
packets.</li>
        <li>Long header packets that contain CRYPTO frames are critical to the
performance of the QUIC handshake and use shorter timers for
acknowledgment.</li>
        <li>Packets containing frames besides ACK or CONNECTION_CLOSE frames count toward
congestion control limits and are considered in-flight.</li> to be in flight.</li>
        <li>PADDING frames cause packets to contribute toward bytes in flight without
directly causing an acknowledgment to be sent.</li>
      </ul>
    </section>
    <section anchor="relevant-differences-between-quic-and-tcp" numbered="true" toc="default">
      <name>Relevant Differences Between between QUIC and TCP</name>
      <t>Readers familiar with TCP's loss detection and congestion control will find
algorithms here that parallel well-known TCP ones. However, protocol differences
between QUIC and TCP contribute to algorithmic differences. These protocol
differences are briefly described below.</t>
      <section anchor="separate-packet-number-spaces" numbered="true" toc="default">
        <name>Separate Packet Number Spaces</name>
        <t>QUIC uses separate packet number spaces for each encryption level,
except 0-RTT and all generations of 1-RTT keys use the same packet
number space.  Separate packet number spaces ensures that the
acknowledgment of packets sent with one level of encryption will not
cause spurious retransmission of packets sent with a different
encryption level.  Congestion control and round-trip time (RTT)
measurement are unified across packet number spaces.</t>
      </section>
      <section anchor="monotonically-increasing-packet-numbers" numbered="true" toc="default">
        <name>Monotonically Increasing Packet Numbers</name>
        <t>TCP conflates transmission order at the sender with delivery order at the
receiver, resulting in the retransmission ambiguity problem
(<xref
<xref target="RETRANSMISSION" format="default"/>). format="default"/>.  QUIC separates transmission order from delivery order:
packet numbers indicate transmission order, and delivery order is determined by
the stream offsets in STREAM frames.</t>
        <t>QUIC's packet number is strictly increasing within a packet number space, space
and directly encodes transmission order.  A higher packet number signifies
that the packet was sent later, and a lower packet number signifies that
the packet was sent earlier.  When a packet containing ack-eliciting
frames is detected lost, QUIC includes necessary frames in a new packet
with a new packet number, removing ambiguity about which packet is
acknowledged when an ACK is received.  Consequently, more accurate RTT
measurements can be made, spurious retransmissions are trivially detected, and
mechanisms such as Fast Retransmit can be applied universally, based only on
packet number.</t>
        <t>This design point significantly simplifies loss detection mechanisms for QUIC.
Most TCP mechanisms implicitly attempt to infer transmission ordering based on
TCP sequence numbers - -- a non-trivial nontrivial task, especially when TCP timestamps are
not available.</t>
      </section>
      <section anchor="clearer-loss-epoch" numbered="true" toc="default">
        <name>Clearer Loss Epoch</name>
        <t>QUIC starts a loss epoch when a packet is lost. The loss epoch ends when any
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
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
for every round trip that experiences loss, while TCP may only do it once across
multiple round trips.</t>
      </section>
      <section anchor="no-reneging" numbered="true" toc="default">
        <name>No Reneging</name>
        <t>QUIC ACK frames contain information similar to that in TCP Selective
Acknowledgements (SACKs,
Acknowledgments (SACKs) <xref target="RFC2018" format="default"/>). format="default"/>. However, QUIC does not allow a packet
acknowledgement
acknowledgment to be reneged, greatly simplifying implementations on both sides
and reducing memory pressure on the sender.</t>
      </section>
      <section anchor="more-ack-ranges" numbered="true" toc="default">
        <name>More ACK Ranges</name>
        <t>QUIC supports many ACK ranges, as opposed to TCP's 3 three SACK ranges.  In high loss
high-loss environments, this speeds recovery, reduces spurious retransmits, and
ensures forward progress without relying on timeouts.</t>
      </section>
      <section anchor="explicit-correction-for-delayed-acknowledgments" numbered="true" toc="default">
        <name>Explicit Correction For for Delayed Acknowledgments</name>
        <t>QUIC endpoints measure the delay incurred between when a packet is received and
when the corresponding acknowledgment is sent, allowing a peer to maintain a
more accurate round-trip time RTT estimate; see Section 13.2 of <xref section="13.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
      </section>
      <section anchor="probe-timeout-replaces-rto-and-tlp" numbered="true" toc="default">
        <name>Probe Timeout Replaces RTO and TLP</name>
        <t>QUIC uses a probe timeout (PTO; see <xref target="pto" format="default"/>), with a timer based on TCP's RTO
retransmission timeout (RTO) computation; see <xref target="RFC6297" target="RFC6298" format="default"/>.  QUIC's PTO includes
the peer's maximum expected acknowledgment delay instead of using a fixed
minimum timeout.</t>
        <t>Similar to the RACK-TLP loss detection algorithm for TCP
(<xref target="RACK" format="default"/>), <xref target="RFC8985" format="default"/>, QUIC does
not collapse the congestion window when the PTO expires, since a single packet
loss at the tail does not indicate persistent congestion.  Instead, QUIC
collapses the congestion window when persistent congestion is declared; see
<xref target="persistent-congestion" format="default"/>. In doing this, QUIC avoids unnecessary congestion
window reductions, obviating the need for correcting mechanisms such as F-RTO (<xref Forward
RTO-Recovery (F-RTO) <xref target="RFC5682" format="default"/>). format="default"/>. Since QUIC does not collapse the congestion
window on a PTO expiration, a QUIC sender is not limited from sending more
in-flight packets after a PTO expiration if it still has available congestion
window. This occurs when a sender is
application-limited application limited and the PTO timer
expires. This is more aggressive than TCP's RTO mechanism when application-limited, application
limited, but identical when not
application-limited.</t> application limited.</t>
        <t>QUIC allows probe packets to temporarily exceed the congestion window whenever
the timer expires.</t>
      </section>
      <section anchor="the-minimum-congestion-window-is-two-packets" numbered="true" toc="default">
        <name>The Minimum Congestion Window is Is Two Packets</name>
        <t>TCP uses a minimum congestion window of one packet. However, loss of that single
packet means that the sender needs to waiting wait for a PTO to recover (<xref target="pto" format="default"/>) to recover, format="default"/>), which
can be much longer than a round-trip time. an RTT.  Sending a single ack-eliciting packet also
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
packets. While this increases network load, it is considered safe, safe since the
sender will still reduce its sending rate exponentially under persistent
congestion (<xref target="pto" format="default"/>).</t>
      </section>
      <section anchor="handshake-packets-are-not-special" numbered="true" toc="default">
        <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 anchor="compute-rtt" numbered="true" toc="default">
      <name>Estimating the Round-Trip Time</name>
      <t>At a high level, an endpoint measures the time from when a packet was sent to
when it is acknowledged as a round-trip time (RTT) an RTT sample. The endpoint uses RTT samples and
peer-reported host delays (see Section 13.2 of <xref section="13.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>) to generate a
statistical description of the network path's RTT. An endpoint computes the
following three values for each path: the minimum value over a period of time
(min_rtt), an
exponentially-weighted exponentially weighted moving average (smoothed_rtt), and the mean
deviation (referred to as "variation" in the rest of this document) in the
observed RTT samples (rttvar).</t>
      <section anchor="latest-rtt" numbered="true" toc="default">
        <name>Generating RTT samples</name> Samples</name>
        <t>An endpoint generates an RTT sample on receiving an ACK frame that meets the
following two conditions:</t>
        <ul spacing="normal">
          <li>the largest acknowledged packet number is newly acknowledged, and</li>
          <li>at least one of the newly acknowledged packets was ack-eliciting.</li>
        </ul>
        <t>The RTT sample, latest_rtt, is generated as the time elapsed since the largest
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
]]></artwork>
]]></sourcecode>
        <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
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
adjust the RTT sample in subsequent computations of smoothed_rtt and rttvar
(<xref target="smoothed-rtt" format="default"/>).</t>
        <t>To avoid generating multiple RTT samples for a single packet, an ACK frame
SHOULD NOT
<bcp14>SHOULD NOT</bcp14> be used to update RTT estimates if it does not newly acknowledge the
largest acknowledged packet.</t>
        <t>An RTT sample MUST NOT <bcp14>MUST NOT</bcp14> be generated on receiving an ACK frame that 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 Therefore,
an ACK frame that contains acknowledgments for only non-ack-eliciting packets
could include an arbitrarily large ACK Delay value.  Ignoring
such ACK frames avoids complications in subsequent smoothed_rtt and rttvar
computations.</t>
        <t>A sender might generate multiple RTT samples per RTT when multiple ACK frames
are received within an RTT.  As suggested in <xref target="RFC6298" format="default"/>, doing so might result
in inadequate history in smoothed_rtt and rttvar.  Ensuring that RTT estimates
retain sufficient history is an open research question.</t>
      </section>
      <section anchor="min-rtt" numbered="true" toc="default">
        <name>Estimating min_rtt</name>
        <t>min_rtt is the sender's estimate of the minimum RTT observed for a given network
path over a period of time. In this document, min_rtt is used by loss detection
to reject implausibly small rtt RTT samples.</t>
        <t>min_rtt MUST <bcp14>MUST</bcp14> be set to the latest_rtt on the first RTT sample. min_rtt MUST <bcp14>MUST</bcp14> be
set to the lesser of min_rtt and latest_rtt (<xref target="latest-rtt" format="default"/>) on all other
samples.</t>
        <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
endpoint to set a lower bound for the smoothed_rtt based entirely on what it
observes (see <xref target="smoothed-rtt" format="default"/>), format="default"/>) and limits potential underestimation due to
erroneously-reported
erroneously reported delays by the peer.</t>
        <t>The RTT for a network path may change over time. If a path's actual RTT
decreases, the min_rtt will adapt immediately on the first low sample.  If the
path's actual RTT increases 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
smoothed_rtt.</t>
        <t>Endpoints SHOULD <bcp14>SHOULD</bcp14> set the min_rtt to the newest RTT sample after persistent
congestion is established. This is to allow avoids repeatedly declaring persistent
congestion when the RTT increases. This also allows a connection to reset
its estimate of min_rtt and smoothed_rtt (<xref target="smoothed-rtt" format="default"/>) after a disruptive network event,
and because it is possible that an increase in path delay resulted in persistent
congestion being incorrectly declared.</t> event;
see <xref target="smoothed-rtt" format="default"/>.</t>
        <t>Endpoints MAY re-establish <bcp14>MAY</bcp14> reestablish the min_rtt at other times in the connection, such as
when traffic volume is low and an acknowledgment is received with a low
acknowledgment delay. Implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> refresh the min_rtt
value too often, often since the actual minimum RTT of the path is not
frequently observable.</t>
      </section>
      <section anchor="smoothed-rtt" numbered="true" toc="default">
        <name>Estimating smoothed_rtt and rttvar</name>
        <t>smoothed_rtt is an exponentially-weighted exponentially weighted moving average of an endpoint's RTT
samples, and rttvar estimates the variation in the RTT samples using a mean
variation.</t>
        <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
ACK frames as described in Section 19.3 of <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
max_ack_delay during the handshake (Section 13.2.1 of <xref (<xref section="13.2.1" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>). To
account for this, the endpoint SHOULD <bcp14>SHOULD</bcp14> ignore max_ack_delay until the handshake
is confirmed, as defined in Section 4.1.2 of <xref section="4.1.2" sectionFormat="of" target="QUIC-TLS" format="default"/>. When they occur,
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
max_ack_delay, avoiding unnecessary inflation of the RTT estimate.</t>
        <t>Note that a large acknowledgment delay can result in a substantially inflated
smoothed_rtt,
smoothed_rtt if there is either an error either in the peer's reporting of the
acknowledgment delay or in the endpoint's min_rtt estimate.  Therefore, prior
to handshake confirmation, an endpoint MAY <bcp14>MAY</bcp14> ignore RTT samples if adjusting
the RTT sample for acknowledgment delay causes the sample to be less than the
min_rtt.</t>
        <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
unintentional but potentially repeating delays, such as scheduler latency at the
peer or loss of previous acknowledgments.  Excess delays could also be due to
a non-compliant noncompliant receiver.  Therefore, these extra delays are considered
effectively part of path delay and incorporated into the RTT estimate.</t>
        <t>Therefore, when adjusting an RTT sample using peer-reported acknowledgment
delays, an endpoint:</t>
        <ul spacing="normal">
          <li>MAY
          <li><bcp14>MAY</bcp14> ignore the acknowledgment delay for Initial packets, since these
acknowledgments are not delayed by the peer (Section 13.2.1 of
<xref (<xref section="13.2.1" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>);</li>
          <li>SHOULD
          <li><bcp14>SHOULD</bcp14> ignore the peer's max_ack_delay until the handshake is confirmed;</li>
          <li>MUST
          <li><bcp14>MUST</bcp14> use the lesser of the acknowledgment delay and the peer's max_ack_delay
after the handshake is confirmed; and</li>
          <li>MUST NOT
          <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
of the smoothed_rtt due to a misreporting peer.</li>
        </ul>
        <t>Additionally, an endpoint might postpone the processing of acknowledgments when
the corresponding decryption keys are not immediately available. For example, a
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
such cases, an endpoint SHOULD <bcp14>SHOULD</bcp14> subtract such local delays from its RTT sample
until the handshake is confirmed.</t>
        <t>Similar to <xref target="RFC6298" format="default"/>, smoothed_rtt and rttvar are computed as follows.</t>
        <t>An endpoint initializes the RTT estimator during connection establishment and
when the estimator is reset during connection migration; see Section 9.4 of <xref section="9.4" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>. Before any RTT samples are available for a new path or when
the estimator is reset, the estimator is initialized using the initial RTT; see
<xref target="pto-handshake" format="default"/>.</t>
        <t>smoothed_rtt and rttvar are initialized as follows, where kInitialRtt contains
the initial RTT value:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2
]]></artwork>
]]></sourcecode>
        <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 initialization, the estimator is
reset using that sample. This ensures that the estimator retains no history of
past samples.</t> 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="QUIC-TRANSPORT" format="default"/>.</t>
        <t>On the first RTT sample after initialization, smoothed_rtt and rttvar are set as
follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2
]]></artwork>
]]></sourcecode>
        <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
if (handshake confirmed):
  ack_delay = min(ack_delay, max_ack_delay)
adjusted_rtt = latest_rtt
if (min_rtt (latest_rtt >= min_rtt + ack_delay < latest_rtt): ack_delay):
  adjusted_rtt = latest_rtt - ack_delay
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
]]></artwork>
]]></sourcecode>
      </section>
    </section>
    <section anchor="loss-detection" numbered="true" toc="default">
      <name>Loss Detection</name>
      <t>QUIC senders use acknowledgments to detect lost packets, packets and a probe
time out (see <xref target="pto" format="default"/>) PTO to ensure
acknowledgments are received. received; see <xref target="pto" format="default"/>. This section provides a description
of these algorithms.</t>
      <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
frame.  For more information, see Section 13.3 of <xref section="13.3" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
      <t>Loss detection is separate per packet number space, unlike RTT measurement and
congestion control, because RTT and congestion control are properties of the
path, whereas loss detection also relies upon key availability.</t>
      <section anchor="ack-loss-detection" numbered="true" toc="default">
        <name>Acknowledgment-Based Detection</name>
        <t>Acknowledgment-based loss detection implements the spirit of TCP's Fast
Retransmit (<xref <xref target="RFC5681" format="default"/>), format="default"/>, Early Retransmit (<xref <xref target="RFC5827" format="default"/>), FACK (<xref format="default"/>, Forward Acknowledgment
<xref target="FACK" format="default"/>), format="default"/>, SACK loss recovery (<xref <xref target="RFC6675" format="default"/>), format="default"/>, and RACK-TLP (<xref target="RACK" format="default"/>). <xref target="RFC8985" format="default"/>. This
section provides an overview of how these algorithms are implemented in QUIC.</t>
        <t>A packet is declared lost if it meets all of the following conditions:</t>
        <ul spacing="normal">
          <li>The packet is unacknowledged, in-flight, in flight, and was sent prior to an
acknowledged packet.</li>
          <li>The packet was sent kPacketThreshold packets before an acknowledged packet
(<xref target="packet-threshold" format="default"/>), or it was sent long enough in the past
(<xref target="time-threshold" format="default"/>).</li>
        </ul>
        <t>The acknowledgment indicates that a packet sent later was delivered, and the
packet and time thresholds provide some tolerance for packet reordering.</t>
        <t>Spuriously declaring packets as lost leads to unnecessary retransmissions and
may result in degraded performance due to the actions of the congestion
controller upon detecting loss.  Implementations can detect spurious
retransmissions and increase the reordering threshold in packets packet or time reordering threshold to
reduce future spurious retransmissions and loss events. Implementations with
adaptive time thresholds MAY <bcp14>MAY</bcp14> choose to start with smaller initial reordering
thresholds to minimize recovery latency.</t>
        <section anchor="packet-threshold" numbered="true" toc="default">
          <name>Packet Threshold</name>
          <t>The RECOMMENDED <bcp14>RECOMMENDED</bcp14> initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss detection
(<xref
<xref target="RFC5681" format="default"/>, format="default"/> <xref target="RFC6675" format="default"/>). format="default"/>.  In order to remain similar to TCP,
implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> use a packet threshold less than 3; see <xref target="RFC5681" format="default"/>.</t>
          <t>Some networks may exhibit higher degrees of packet reordering, causing a sender
to detect spurious losses. Additionally, packet reordering could be more common
with QUIC than TCP, TCP because network elements that could observe and reorder TCP
packets cannot do that for QUIC, QUIC and also because QUIC packet numbers are
encrypted.  Algorithms that increase the reordering threshold after spuriously
detecting losses, such as RACK <xref target="RACK" target="RFC8985" format="default"/>, have proven to be useful in TCP and
are expected to be at least as useful in QUIC.</t>
        </section>
        <section anchor="time-threshold" numbered="true" toc="default">
          <name>Time Threshold</name>
          <t>Once a later packet within the same packet number space has been acknowledged,
an endpoint SHOULD <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
time threshold MUST <bcp14>MUST</bcp14> be set to at least the local timer granularity, as
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)
]]></artwork>
]]></sourcecode>
          <t>If packets sent prior to the largest acknowledged packet cannot yet be declared
lost, then a timer SHOULD <bcp14>SHOULD</bcp14> be set for the remaining time.</t>
          <t>Using max(smoothed_rtt, latest_rtt) protects from the two following cases:</t>
          <ul spacing="normal">
            <li>the latest RTT sample is lower than the smoothed RTT, perhaps due to
reordering where the acknowledgment encountered a shorter path;</li>
            <li>the latest RTT sample is higher than the smoothed RTT, perhaps due to a
sustained increase in the actual RTT, but the smoothed RTT has not yet caught
up.</li>
          </ul>
          <t>The RECOMMENDED <bcp14>RECOMMENDED</bcp14> time threshold (kTimeThreshold), expressed as a round-trip time an RTT multiplier,
is 9/8. The RECOMMENDED <bcp14>RECOMMENDED</bcp14> value of the timer granularity (kGranularity) is 1ms.</t>
          <dl>
            <dt>
Note:  </dt>
            <dd>
              <t>TCP's 1
millisecond.</t>
          <aside>
            <t>Note: TCP's RACK (<xref target="RACK" format="default"/>) <xref target="RFC8985" format="default"/> specifies a slightly larger threshold, equivalent
to 5/4, for a similar purpose. Experience with QUIC shows that 9/8 works well.</t>
            </dd>
          </dl>
          </aside>
          <t>Implementations MAY <bcp14>MAY</bcp14> experiment with absolute thresholds, thresholds from
previous connections, adaptive thresholds, or the including of RTT variation.
Smaller thresholds reduce reordering resilience and increase spurious
retransmissions, and larger thresholds increase loss detection delay.</t>
        </section>
      </section>
      <section anchor="pto" numbered="true" toc="default">
        <name>Probe Timeout</name>
        <t>A Probe Timeout (PTO) triggers the sending of one or two probe datagrams when
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
a connection to recover from loss of tail packets or acknowledgments.</t>
        <t>As with loss detection, the probe timeout PTO is per packet number space. That is, a
PTO value is computed per packet number space.</t>
        <t>A PTO timer expiration event does not indicate packet loss and MUST NOT <bcp14>MUST NOT</bcp14> cause
prior unacknowledged packets to be marked as lost. When an acknowledgment is
received that newly acknowledges packets, loss detection proceeds as dictated
by the packet and time threshold mechanisms; see <xref target="ack-loss-detection" format="default"/>.</t>
        <t>The PTO algorithm used in QUIC implements the reliability functions of Tail Loss
Probe <xref target="RACK" target="RFC8985" format="default"/>, RTO <xref target="RFC5681" format="default"/>, and F-RTO algorithms for TCP
<xref target="RFC5682" format="default"/>. The timeout computation is based on TCP's retransmission
timeout RTO period <xref target="RFC6298" format="default"/>.</t>
        <section anchor="computing-pto" numbered="true" toc="default">
          <name>Computing PTO</name>
          <t>When an ack-eliciting packet is transmitted, the sender schedules a timer for
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
]]></artwork>
]]></sourcecode>
          <t>The PTO period is the amount of time that a sender ought to wait for an
acknowledgment of a sent packet.  This time period includes the estimated
network roundtrip-time 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
delay sending an acknowledgment.</t>
          <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
expected to not delay these packets intentionally; see 13.2.1 of <xref section="13.2.1" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
          <t>The PTO period MUST <bcp14>MUST</bcp14> be at least kGranularity, kGranularity to avoid the timer expiring
immediately.</t>
          <t>When ack-eliciting packets in multiple packet number spaces are in flight, the
timer MUST <bcp14>MUST</bcp14> be set to the earlier value of the Initial and Handshake packet
number spaces.</t>
          <t>An endpoint MUST NOT <bcp14>MUST NOT</bcp14> set its PTO timer for the application data Application Data packet number
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
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
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
before confirming that the client has verified the server's certificate and can
therefore read these 1-RTT packets.</t>
          <t>A sender SHOULD <bcp14>SHOULD</bcp14> restart its PTO timer every time an ack-eliciting packet is
sent or acknowledged, or when Initial or Handshake keys are discarded (Section 4.9 of
<xref
(<xref section="4.9" sectionFormat="of" target="QUIC-TLS" format="default"/>). This ensures the PTO is always set based on the
latest estimate of the round-trip time RTT and for the correct packet across packet
number spaces.</t>
          <t>When a PTO timer expires, the PTO backoff MUST <bcp14>MUST</bcp14> be increased, resulting in the
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
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
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
receiving acknowledgments in Initial packets.</t>
          <t>This exponential reduction in the sender's rate is important because consecutive
PTOs might be caused by loss of packets or acknowledgments due to severe
congestion.  Even when there are ack-eliciting packets in-flight in flight in multiple
packet number spaces, the exponential increase in probe timeout PTO occurs across all spaces
to prevent excess load on the network.  For example, a timeout in the Initial
packet number space doubles the length of the timeout in the Handshake packet
number space.</t>
          <t>The total length of time over which consecutive PTOs expire is limited by the
idle timeout.</t>
          <t>The PTO timer MUST NOT <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 that is set for time
threshold loss detection will expire earlier than the PTO timer
in most cases and is less likely to spuriously retransmit data.</t>
        </section>
        <section anchor="pto-handshake" numbered="true" toc="default">
          <name>Handshakes and New Paths</name>
          <t>Resumed connections over the same network MAY <bcp14>MAY</bcp14> use the previous connection's
final smoothed RTT value as the resumed connection's initial RTT.  When no
previous RTT is available, the initial RTT SHOULD <bcp14>SHOULD</bcp14> be set to 333ms. 333 milliseconds.
This results in handshakes starting with a PTO of 1 second, as recommended for
TCP's initial retransmission timeout; RTO; see Section 2 of <xref section="2" sectionFormat="of" target="RFC6298" format="default"/>.</t>
          <t>A connection MAY <bcp14>MAY</bcp14> use the delay between sending a PATH_CHALLENGE and receiving a
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 <bcp14>SHOULD NOT</bcp14> be
considered an RTT sample.</t>
          <t>Initial
          <t>When the Initial keys and Handshake keys are discarded (see
<xref target="discarding-packets" format="default"/>), any Initial packets and Handshake packets could can
no longer be never acknowledged, but so they are removed from bytes in flight when the Initial and Handshake keys are discarded,
as described below in <xref target="discarding-packets" format="default"/>.
flight. When Initial or Handshake keys are discarded, the PTO and loss
detection timers MUST <bcp14>MUST</bcp14> be reset, because discarding keys indicates
forward progress and the loss detection timer might have been set for
a now discarded now-discarded packet number space.</t>
          <section anchor="before-address-validation" numbered="true" toc="default">
            <name>Before Address Validation</name>
            <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,
as specified in Section 8.1 of <xref section="8.1" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>. If no additional data can be
sent, the server's PTO timer MUST NOT <bcp14>MUST NOT</bcp14> be armed until datagrams have been
received from the client, client because packets sent on PTO count against the
anti-amplification limit. Note that limit.</t>
            <t>When the server could fail receives a datagram from the client, the amplification limit is
increased and the server resets the PTO timer.  If the PTO timer is then set to validate
a time in the
client's address even if 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.</t> accepted but the server fails to
validate the client's address.</t>
            <t>Since the server could be blocked until more datagrams are received from the
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 (see Section 8 of
<xref section="8" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>). That is, the client MUST <bcp14>MUST</bcp14> set the
probe PTO timer
if the client has not received an acknowledgment for any of its Handshake
packets and the handshake is not confirmed (see Section 4.1.2 of <xref section="4.1.2" sectionFormat="of" target="QUIC-TLS" format="default"/>),
even if there are no packets in flight. When the PTO fires, the client MUST <bcp14>MUST</bcp14>
send a Handshake packet if it has Handshake keys, otherwise it
MUST <bcp14>MUST</bcp14> send an
Initial packet in a UDP datagram with a payload of at least 1200 bytes.</t>
          </section>
        </section>
        <section anchor="speeding-up-handshake-completion" numbered="true" toc="default">
          <name>Speeding Up up Handshake Completion</name>
          <t>When a server receives an Initial packet containing duplicate CRYPTO data,
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
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>
          <t>To speed up handshake completion under these conditions, an endpoint MAY, <bcp14>MAY</bcp14>, for a
limited number of times per connection, send a packet containing
unacknowledged CRYPTO data earlier than the PTO expiry, subject to the address
validation limits in Section 8.1 of <xref section="8.1" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>. Doing so at most once
for each connection is adequate to quickly recover from a single packet loss.
An endpoint that always retransmits packets in response to receiving packets
that it cannot process risks creating an infinite exchange of packets.</t>
          <t>Endpoints can also use coalesced packets (see Section 12.2 of <xref section="12.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>) to ensure that each datagram elicits at least one
acknowledgment. For example, a client can coalesce an Initial packet containing
PING and PADDING frames with a 0-RTT data packet packet, and a server can coalesce an
Initial packet containing a PING frame with one or more packets in its first
flight.</t>
        </section>
        <section anchor="sending-probe-packets" numbered="true" toc="default">
          <name>Sending Probe Packets</name>
          <t>When a PTO timer expires, a sender MUST <bcp14>MUST</bcp14> send at least one ack-eliciting packet
in the packet number space as a probe.  An endpoint MAY <bcp14>MAY</bcp14> send up to two
full-sized datagrams containing ack-eliciting packets, packets to avoid an expensive
consecutive PTO expiration due to a single lost datagram, datagram or to transmit data
from multiple packet number spaces. All probe packets sent on a PTO MUST <bcp14>MUST</bcp14> be
ack-eliciting.</t>
          <t>In addition to sending data in the packet number space for which the timer
expired, the sender SHOULD <bcp14>SHOULD</bcp14> send ack-eliciting packets from other packet number
spaces with in-flight data, coalescing packets if possible.  This is
particularly valuable when the server has both Initial and Handshake data
in-flight in
flight or when the client has both Handshake and Application Data in-flight, in flight
because the peer might only have receive keys for one of the two packet number
spaces.</t>
          <t>If the sender wants to elicit a faster acknowledgment on PTO, it can skip a
packet number to eliminate the acknowledgment delay.</t>
          <t>An endpoint SHOULD <bcp14>SHOULD</bcp14> include new data in packets that are sent on PTO expiration.
Previously sent data MAY <bcp14>MAY</bcp14> be sent if no new data can be sent. Implementations
MAY
<bcp14>MAY</bcp14> use alternative strategies for determining the content of probe packets,
including sending new or retransmitted data based on the application's
priorities.</t>
          <t>It is possible the sender has no new or previously-sent previously sent data to send.
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,
and then the original transmission is acknowledged.  When there is no data to
send, the sender SHOULD <bcp14>SHOULD</bcp14> send a PING or other ack-eliciting frame in a single
packet, re-arming rearming the PTO timer.</t>
          <t>Alternatively, instead of sending an ack-eliciting packet, the sender MAY <bcp14>MAY</bcp14> mark
any packets still in flight as lost.  Doing so avoids sending an additional
packet,
packet but increases the risk that loss is declared too aggressively, resulting
in an unnecessary rate reduction by the congestion controller.</t>
          <t>Consecutive PTO periods increase exponentially, and as a result, connection
recovery latency increases exponentially as packets continue to be dropped in
the network.  Sending two packets on PTO expiration increases resilience to
packet drops, thus reducing the probability of consecutive PTO events.</t>
          <t>When the PTO timer expires multiple times and new data cannot be sent,
implementations must choose between sending the same payload every time
or sending different payloads.  Sending the same payload may be simpler
and ensures the highest priority frames arrive first.  Sending different
payloads each time reduces the chances of spurious retransmission.</t>
        </section>
      </section>
      <section anchor="handling-retry-packets" numbered="true" toc="default">
        <name>Handling Retry Packets</name>
        <t>A Retry packet causes a client to send another Initial packet, effectively
restarting the connection process.  A Retry packet indicates that the Initial
packet was received, received but not processed.  A Retry packet cannot be treated as an
acknowledgment,
acknowledgment because it does not indicate that a packet was processed or
specify the packet number.</t>
        <t>Clients that receive a Retry packet reset congestion control and loss recovery
state, including resetting any pending timers.  Other connection state, in
particular cryptographic handshake messages, is retained; see Section 17.2.5 of
<xref section="17.2.5" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
        <t>The client MAY <bcp14>MAY</bcp14> compute an RTT estimate to the server as the time period from
when the first Initial packet was sent to when a Retry or a Version Negotiation
packet is received.  The client MAY <bcp14>MAY</bcp14> use this value in place of its default for
the initial RTT estimate.</t>
      </section>
      <section anchor="discarding-packets" numbered="true" toc="default">
        <name>Discarding Keys and Packet State</name>
        <t>When Initial and Handshake packet protection keys are discarded
(see Section 4.9 of <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.
The sender MUST <bcp14>MUST</bcp14> discard all recovery state associated with those packets
and MUST <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
Handshake packets; see Section 17.2.2.1 of <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>
        <t>When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
discarded.</t>
        <t>If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
before Initial packets, early 0-RTT packets will be declared lost, but that
is expected to be infrequent.</t>
        <t>It is expected that keys are discarded at some time after the packets
encrypted with them would
be are either acknowledged or declared lost. However,
Initial and Handshake secrets are discarded as soon as handshake Handshake and
1-RTT keys are proven to be available to both client and server; see Section 4.9.1 of
<xref section="4.9.1" sectionFormat="of" target="QUIC-TLS" format="default"/>.</t>
      </section>
    </section>
    <section anchor="congestion-control" numbered="true" toc="default">
      <name>Congestion Control</name>
      <t>This document specifies a sender-side congestion controller for QUIC similar to
TCP NewReno (<xref <xref target="RFC6582" format="default"/>).</t> format="default"/>.</t>
      <t>The signals QUIC provides for congestion control are generic and are designed to
support different sender-side algorithms. A sender can unilaterally choose a
different algorithm to use, such as Cubic (<xref CUBIC <xref target="RFC8312" format="default"/>).</t> format="default"/>.</t>
      <t>If a sender uses a different controller than that specified in this document,
the chosen controller MUST <bcp14>MUST</bcp14> conform to the congestion control guidelines
specified in Section 3.1 of <xref section="3.1" sectionFormat="of" target="RFC8085" format="default"/>.</t>
      <t>Similar to TCP, packets containing only ACK frames do not count towards toward bytes
in flight and are not congestion controlled.  Unlike TCP, QUIC can detect the
loss of these packets and MAY <bcp14>MAY</bcp14> use that information to adjust the congestion
controller or the rate of ACK-only packets being sent, but this document does
not describe a mechanism for doing so.</t>
      <t>The congestion controller is per path, so packets sent on other paths do 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 congestion
window in bytes.</t>
      <t>An endpoint MUST NOT <bcp14>MUST NOT</bcp14> send a packet if it would cause bytes_in_flight (see
<xref target="vars-of-interest" format="default"/>) to be larger than the congestion window, unless the packet
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>
      <section anchor="congestion-ecn" numbered="true" toc="default">
        <name>Explicit Congestion Notification</name>
        <t>If a path has been validated to support ECN (<xref Explicit Congestion Notification (ECN)
<xref target="RFC3168" format="default"/>, format="default"/> <xref target="RFC8311" format="default"/>), format="default"/>, QUIC treats a Congestion Experienced (CE) codepoint
in the IP header as a signal of congestion. This document specifies an
endpoint's response when the peer-reported ECN-CE count increases; see Section 13.4.2 of <xref section="13.4.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
      </section>
      <section anchor="initial-cwnd" numbered="true" toc="default">
        <name>Initial and Minimum Congestion Window</name>
        <t>QUIC begins every connection in slow start with the congestion window set to an
initial value.  Endpoints SHOULD <bcp14>SHOULD</bcp14> use an initial congestion window of 10 ten times
the maximum datagram size (max_datagram_size), while limiting the window to the
larger of 14720 14,720 bytes or twice the maximum datagram size. This follows the
analysis and recommendations in <xref target="RFC6928" format="default"/>, increasing the byte limit to
account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead
for TCP.</t>
        <t>If the maximum datagram size changes during the connection, the initial
congestion window SHOULD <bcp14>SHOULD</bcp14> be recalculated with the new size.  If the maximum
datagram size is decreased in order to complete the handshake, the
congestion window SHOULD <bcp14>SHOULD</bcp14> be set to the new initial congestion window.</t>
        <t>Prior to validating the client's address, the server can be further limited by
the anti-amplification limit as specified in Section 8.1 of <xref section="8.1" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.
Though the anti-amplification limit can prevent the congestion window from
being fully utilized and therefore slow down the increase in congestion window,
it does not directly affect the congestion window.</t>
        <t>The minimum congestion window is the smallest value the congestion window can
decrease to as a
attain in response to loss, an increase in the peer-reported ECN-CE count,
or persistent congestion.  The RECOMMENDED <bcp14>RECOMMENDED</bcp14> value is 2 * max_datagram_size.</t>
      </section>
      <section anchor="congestion-control-states" numbered="true" toc="default">
        <name>Congestion Control States</name>
        <t>The NewReno congestion controller described in this document has three
distinct states, as shown in <xref target="fig-cc-fsm" format="default"/>.</t>
        <figure anchor="fig-cc-fsm">
          <name>Congestion Control States and Transitions</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                 New Path path or      +------------+
            persistent congestion |   Slow     |
        (O)---------------------->|   Start    |
                                  +------------+
                                        |
                                Loss or |
                        ECN-CE increase |
                                        v
 +------------+     Loss or       +------------+
 | Congestion |  ECN-CE increase  |  Recovery  |
 | Avoidance  |------------------>|   Period   |
 +------------+                   +------------+
           ^                            |
           |                            |
           +----------------------------+
              Acknowledgment of packet
                sent during recovery
]]></artwork>
        </figure>
        <t>These states and the transitions between them are described in subsequent
sections.</t>
        <section anchor="slow-start" numbered="true" toc="default">
          <name>Slow Start</name>
          <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
threshold is initialized to an infinite value.</t>
          <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
exponential growth of the congestion window.</t>
          <t>The sender MUST <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>
          <t>A sender re-enters reenters slow start any time the congestion window is less than the
slow start threshold, which only occurs after persistent congestion is
declared.</t>
        </section>
        <section anchor="recovery-period" numbered="true" toc="default">
          <name>Recovery</name>
          <t>A NewReno sender enters a recovery period when it detects the loss of a packet
or when the ECN-CE count reported by its peer increases. A sender that is
already in a recovery period stays in it and does not re-enter reenter it.</t>
          <t>On entering a recovery period, a sender MUST <bcp14>MUST</bcp14> set the slow start threshold to
half the value of the congestion window when loss is detected. The congestion
window MUST <bcp14>MUST</bcp14> be set to the reduced value of the slow start threshold before
exiting the recovery period.</t>
          <t>Implementations MAY <bcp14>MAY</bcp14> reduce the congestion window immediately upon entering a
recovery period or use other mechanisms, such as Proportional Rate Reduction
(<xref
<xref target="PRR" format="default"/>), format="default"/>, to reduce the congestion window more gradually. If the
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
retransmitted and is similar to TCP as described in Section 5 of <xref section="5" sectionFormat="of" target="RFC6675" format="default"/>.</t>
          <t>The recovery period aims to limit congestion window reduction to once per round
trip. Therefore Therefore, during a recovery period, the congestion window does not change
in response to new losses or increases in the ECN-CE count.</t>
          <t>A recovery period ends and the sender enters congestion avoidance when a packet
sent during the recovery period is acknowledged. This is slightly different
from TCP's definition of recovery, which ends when the lost segment that
started recovery is acknowledged (<xref <xref target="RFC5681" format="default"/>).</t> format="default"/>.</t>
        </section>
        <section anchor="congestion-avoidance" numbered="true" toc="default">
          <name>Congestion Avoidance</name>
          <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>
          <t>A sender in congestion avoidance uses an Additive Increase Multiplicative
Decrease (AIMD) approach that MUST <bcp14>MUST</bcp14> limit the increase to the congestion window
to at most one maximum datagram size for each congestion window that is
acknowledged.</t>
          <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>
        </section>
      </section>
      <section anchor="ignoring-loss-of-undecryptable-packets" numbered="true" toc="default">
        <name>Ignoring Loss of Undecryptable Packets</name>
        <t>During the handshake, some packet protection keys might not be available when
a packet arrives arrives, and the receiver can choose to drop the packet. In particular,
Handshake and 0-RTT packets cannot be processed until the Initial packets
arrive
arrive, and 1-RTT packets cannot be processed until the handshake completes.
Endpoints MAY <bcp14>MAY</bcp14> ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might
have arrived before the peer had packet protection keys to process those
packets. Endpoints MUST NOT <bcp14>MUST NOT</bcp14> ignore the loss of packets that were sent after
the earliest acknowledged packet in a given packet number space.</t>
      </section>
      <section anchor="probe-timeout" numbered="true" toc="default">
        <name>Probe Timeout</name>
        <t>Probe packets MUST NOT <bcp14>MUST NOT</bcp14> be blocked by the congestion controller.  A sender MUST <bcp14>MUST</bcp14>
however count these packets as being additionally in flight, since these packets
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
until an acknowledgment is received that establishes loss or delivery of
packets.</t>
      </section>
      <section anchor="persistent-congestion" numbered="true" toc="default">
        <name>Persistent Congestion</name>
        <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>
        <section anchor="pc-duration" numbered="true" toc="default">
          <name>Duration</name>
          <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) *
    kPersistentCongestionThreshold
]]></artwork>
]]></sourcecode>
          <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>
          <t>This duration allows a sender to send as many packets before establishing
persistent congestion, including some in response to PTO expiration, as TCP does
with Tail Loss Probes (<xref target="RACK" format="default"/>) <xref target="RFC8985" format="default"/> and a Retransmission Timeout (<xref an RTO <xref target="RFC5681" format="default"/>).</t> format="default"/>.</t>
          <t>Larger values of kPersistentCongestionThreshold cause the sender to become less
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
sender declaring persistent congestion unnecessarily, resulting in reduced
throughput for the sender.</t>
          <t>The RECOMMENDED <bcp14>RECOMMENDED</bcp14> value for kPersistentCongestionThreshold is 3, which results in
behavior that is approximately equivalent to a TCP sender declaring an RTO after
two TLPs.</t>
          <t>This design does not use consecutive PTO events to establish persistent
congestion, since application patterns impact PTO expirations. expiration. For example, a
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
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
congestion without depending on PTO expiration.</t>
        </section>
        <section anchor="establishing-persistent-congestion" numbered="true" toc="default">
          <name>Establishing Persistent Congestion</name>
          <t>A sender establishes persistent congestion after the receipt of an
acknowledgment if two packets that are ack-eliciting are declared lost, and:</t>
          <ul spacing="normal">
            <li>across all packet number spaces, none of the packets sent between the send
times of these two packets are acknowledged;</li>
            <li>the duration between the send times of these two packets exceeds the
persistent congestion duration (<xref target="pc-duration" format="default"/>); and</li>
            <li>a prior RTT sample existed when these two packets were sent.</li>
          </ul>
          <t>These two packets MUST <bcp14>MUST</bcp14> be ack-eliciting, since a receiver is required to
acknowledge only ack-eliciting packets within its maximum ack acknowledgment delay;
see Section
13.2 of <xref section="13.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>.</t>
          <t>The persistent congestion period SHOULD NOT <bcp14>SHOULD NOT</bcp14> start until there is at least one
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 be substantially larger than
the actual RTT. Requiring a prior RTT sample prevents a sender from establishing
persistent congestion with potentially too few probes.</t>
          <t>Since network congestion is not affected by packet number spaces, persistent
congestion SHOULD <bcp14>SHOULD</bcp14> consider packets sent across packet number spaces. A sender
that does not have state for all packet number spaces or an implementation that
cannot compare send times across packet number spaces MAY <bcp14>MAY</bcp14> use state for just the
packet number space that was acknowledged. This might result in erroneously
declaring persistent congestion, but it will not lead to a failure to detect
persistent congestion.</t>
          <t>When persistent congestion is declared, the sender's congestion window MUST <bcp14>MUST</bcp14> be
reduced to the minimum congestion window (kMinimumWindow), similar to a TCP
sender's response on an RTO (<xref <xref target="RFC5681" format="default"/>).</t> format="default"/>.</t>
        </section>
        <section anchor="example" numbered="true" toc="default">
          <name>Example</name>
          <t>The following example illustrates how a sender might establish persistent
congestion. Assume:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          <sourcecode type="pseudocode"><![CDATA[
smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
kPersistentCongestionThreshold = 3
]]></artwork>
]]></sourcecode>
          <t>Consider the following sequence of events:</t>
          <table align="center">
            <thead>
              <tr>
                <th align="left">Time</th>
                <th align="left">Action</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">t=0</td>
                <td align="left">Send packet #1 (app (application data)</td>
              </tr>
              <tr>
                <td align="left">t=1</td>
                <td align="left">Send packet #2 (app (application data)</td>
              </tr>
              <tr>
                <td align="left">t=1.2</td>
                <td align="left">Recv align="left">Receive acknowledgment of #1</td>
              </tr>
              <tr>
                <td align="left">t=2</td>
                <td align="left">Send packet #3 (app (application data)</td>
              </tr>
              <tr>
                <td align="left">t=3</td>
                <td align="left">Send packet #4 (app (application data)</td>
              </tr>
              <tr>
                <td align="left">t=4</td>
                <td align="left">Send packet #5 (app (application data)</td>
              </tr>
              <tr>
                <td align="left">t=5</td>
                <td align="left">Send packet #6 (app (application data)</td>
              </tr>
              <tr>
                <td align="left">t=6</td>
                <td align="left">Send packet #7 (app (application data)</td>
              </tr>
              <tr>
                <td align="left">t=8</td>
                <td align="left">Send packet #8 (PTO 1)</td>
              </tr>
              <tr>
                <td align="left">t=12</td>
                <td align="left">Send packet #9 (PTO 2)</td>
              </tr>
              <tr>
                <td align="left">t=12.2</td>
                <td align="left">Recv align="left">Receive acknowledgment of #9</td>
              </tr>
            </tbody>
          </table>
          <t>Packets 2 through 8 are declared lost when the acknowledgment for packet 9 is
received at t <tt>t = 12.2.</t> 12.2</tt>.</t>
          <t>The congestion period is calculated as the time between the oldest and newest
lost packets: 8 <tt>8 - 1 = 7. 7</tt>.  The persistent congestion duration is: 2 is <tt>2 * 3 = 6. 6</tt>.
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
to have experienced persistent congestion.</t>
          <t>While this example shows PTO expiration, they are not required for persistent
congestion to be established.</t>
        </section>
      </section>
      <section anchor="pacing" numbered="true" toc="default">
        <name>Pacing</name>
        <t>A sender SHOULD <bcp14>SHOULD</bcp14> pace sending of all in-flight packets based on input from the
congestion controller.</t>
        <t>Sending multiple packets into the network without any delay between them creates
a packet burst that might cause short-term congestion and losses. Senders MUST <bcp14>MUST</bcp14>
either use pacing or limit such bursts. Senders SHOULD <bcp14>SHOULD</bcp14> limit bursts to the
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 <bcp14>MAY</bcp14> use a higher
limit.</t>
        <t>An implementation should take care to architect its congestion controller to
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
might pace out packets handed to it by the congestion controller.</t>
        <t>Timely delivery of ACK frames is important for efficient loss recovery. Packets To avoid
delaying their delivery to the peer, packets containing only ACK frames SHOULD <bcp14>SHOULD</bcp14>
therefore not be paced, to avoid delaying
their delivery to the peer.</t> paced.</t>
        <t>Endpoints can implement pacing as they choose. A perfectly paced sender spreads
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
congestion window over the round-trip time. RTT. Expressed as a rate in units of
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
]]></artwork>
        <t>Or,
]]></sourcecode>
        <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
]]></artwork>
]]></sourcecode>
        <t>Using a value for <tt>N</tt> that is small, but at least 1 (for example, 1.25) ensures
that variations in round-trip time RTT do not result in under-utilization underutilization of the
congestion window.</t>
        <t>Practical considerations, such as packetization, scheduling delays, and
computational efficiency, can cause a sender to deviate from this rate over time
periods that are much shorter than a round-trip time.</t> an RTT.</t>
        <t>One possible implementation strategy for pacing uses a leaky bucket algorithm,
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>
      </section>
      <section anchor="under-utilizing-the-congestion-window" anchor="underutilizing-the-congestion-window" numbered="true" toc="default">
        <name>Under-utilizing
        <name>Underutilizing the Congestion Window</name>
        <t>When bytes in flight is smaller than the congestion window and sending is not
pacing limited, the congestion window is under-utilized. underutilized. This can happen due to
insufficient application data or flow control limits. When this occurs,
the congestion window SHOULD NOT <bcp14>SHOULD NOT</bcp14> be increased in either slow start or
congestion avoidance. This can happen due to insufficient application data
or flow control limits.</t> avoidance.</t>
        <t>A sender that paces packets (see <xref target="pacing" format="default"/>) might delay sending packets
and not fully utilize the congestion window due to this delay. A sender
SHOULD NOT
<bcp14>SHOULD NOT</bcp14> consider itself application limited if it would have fully
utilized the congestion window without pacing delay.</t>
        <t>A sender MAY <bcp14>MAY</bcp14> implement alternative mechanisms to update its congestion window
after periods of under-utilization, underutilization, such as those proposed for TCP in
<xref target="RFC7661" format="default"/>.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="loss-and-congestion-signals" numbered="true" toc="default">
        <name>Loss and Congestion Signals</name>
        <t>Loss detection and congestion control fundamentally involve the consumption of
signals, such as delay, loss, and ECN markings, from unauthenticated
entities. An attacker can cause endpoints to reduce their sending rate by
manipulating these signals; signals: by dropping packets, by altering path delay
strategically, or by changing ECN codepoints.</t>
      </section>
      <section anchor="traffic-analysis" numbered="true" toc="default">
        <name>Traffic Analysis</name>
        <t>Packets that carry only ACK frames can be heuristically identified by observing
packet size.  Acknowledgment patterns may expose information about link
characteristics or application behavior.  To reduce leaked information,
endpoints can bundle acknowledgments with other frames, or they can use PADDING
frames at a potential cost to performance.</t>
      </section>
      <section anchor="misreporting-ecn-markings" numbered="true" toc="default">
        <name>Misreporting ECN Markings</name>
        <t>A receiver can misreport ECN markings to alter the congestion response of a
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>
        <t>A sender can detect suppression of reports by marking occasional packets that it
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
sender can disable ECN for that path by not setting ECT ECN-Capable Transport (ECT)
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 their sending
rate, which is similar in effect to advertising reduced connection flow control
limits and so no advantage is gained by doing so.</t>
        <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.
Markings can be treated as equivalent to loss (<xref <xref target="RFC3168" format="default"/>), format="default"/>, but other
responses can be specified, such as (<xref <xref target="RFC8511" format="default"/>) format="default"/> or (<xref <xref target="RFC8311" format="default"/>).</t>
      </section> format="default"/>.</t>
      </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="QUIC-TRANSPORT"> anchor="QUIC-TRANSPORT" target="https://www.rfc-editor.org/info/rfc9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor">
              <organization>Fastly</organization>
            </author>
            <author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
              <organization>Mozilla</organization>
            </author>
            <date year="2021" month="January" day="15"/> month="May"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34"/> name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="QUIC-TLS"> anchor="QUIC-TLS" target="https://www.rfc-editor.org/info/rfc9001">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
              <organization>Mozilla</organization>
            </author>
            <author initials="S." surname="Turner" fullname="Sean Turner" role="editor">
              <organization>sn3rd</organization>
            </author>
            <date year="2021" month="January" day="15"/> month="May"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-tls-34"/> name="RFC" value="9001"/>
          <seriesInfo name="DOI" value="10.17487/RFC9001"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085"> anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085">
          <front>
            <title>UDP Usage Guidelines</title>
            <author initials="L." surname="Eggert" fullname="L. Eggert"> Eggert" initials="L." surname="Eggert">
              <organization/>
            </author>
            <author initials="G." surname="Fairhurst" fullname="G. Fairhurst"> Fairhurst" initials="G." surname="Fairhurst">
              <organization/>
            </author>
            <author initials="G." surname="Shepherd" fullname="G. Shepherd"> Shepherd" initials="G." surname="Shepherd">
              <organization/>
            </author>
            <date year="2017" month="March"/> month="March" year="2017"/>
            <abstract>
              <t>The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.  This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP.  Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</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 Internet transport must employ mechanisms to prevent congestion collapse and to establish 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 protocols (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 multicast 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/rfc3168"> anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>The Addition of Explicit Congestion Notification (ECN)
            <title>Key words for use in RFCs to IP</title>
            <author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
              <organization/>
            </author> Indicate Requirement Levels</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/>
            </author>
            <author initials="D." surname="Black" fullname="D. Black"> Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date year="2001" month="September"/> month="March" year="1997"/>
            <abstract>
              <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification)
              <t>In many standards track documents several words are used to TCP and IP, including ECN's use of two bits signify the requirements in the IP header.  [STANDARDS-TRACK]</t> specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168">
          <front>
            <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
            <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan">
              <organization/>
            </author>
            <author fullname="S. Floyd" initials="S." surname="Floyd">
              <organization/>
            </author>
            <author fullname="D. Black" initials="D." surname="Black">
              <organization/>
            </author>
            <date month="September" year="2001"/>
            <abstract>
              <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3168"/>
          <seriesInfo name="DOI" value="10.17487/RFC3168"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="FACK">
          <front>
            <title>Forward Acknowledgement: acknowledgement: Refining TCP Congestion Control</title>
            <author initials="M." surname="Mathis">
              <organization/>
            </author>
            <author initials="J." surname="Mahdavi">
              <organization/>
            </author>
            <date year="1996" month="August"/>
          </front>
          <seriesInfo name="ACM SIGCOMM" value=""/> name="DOI" value="10.1145/248157.248181"/>
          <refcontent>ACM SIGCOMM Computer Communication Review</refcontent>
        </reference>
        <reference anchor="RETRANSMISSION">
          <front>
            <title>Improving Round-Trip Time Estimates in Reliable Transport Protocols</title>
            <author initials="P." surname="Karn">
              <organization/>
            </author>
            <author initials="C." surname="Partridge">
              <organization/>
            </author>
            <date year="1995" month="January"/> year="1991" month="November"/>
          </front>
          <seriesInfo name="ACM SIGCOMM CCR" value=""/> name="DOI" value="10.1145/118544.118549"/>
          <refcontent>ACM Transactions on Computer Systems</refcontent>
        </reference>
        <reference anchor="RFC2018" target="https://www.rfc-editor.org/info/rfc2018"> anchor="RFC3465" target="https://www.rfc-editor.org/info/rfc3465">
          <front>
            <title>TCP Selective Acknowledgment Options</title> Congestion Control with Appropriate Byte Counting (ABC)</title>
            <author initials="M." surname="Mathis" fullname="M. Mathis">
              <organization/>
            </author>
            <author initials="J." surname="Mahdavi" fullname="J. Mahdavi">
              <organization/>
            </author>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/>
            </author>
            <author initials="A." surname="Romanow" fullname="A. Romanow">
              <organization/>
            </author>
            <date year="1996" month="October"/>
            <abstract>
              <t>This memo proposes an implementation of SACK and discusses its performance and related issues.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2018"/>
          <seriesInfo name="DOI" value="10.17487/RFC2018"/>
        </reference>
        <reference anchor="RFC6297" target="https://www.rfc-editor.org/info/rfc6297">
          <front>
            <title>A Survey of Lower-than-Best-Effort Transport Protocols</title>
            <author Allman" initials="M." surname="Welzl" fullname="M. Welzl">
              <organization/>
            </author>
            <author initials="D." surname="Ros" fullname="D. Ros"> surname="Allman">
              <organization/>
            </author>
            <date year="2011" month="June"/> month="February" year="2003"/>
            <abstract>
              <t>This document provides proposes a survey of transport protocols that are designed small modification to have a smaller bandwidth and/or delay impact on standard the way TCP increases its congestion window.  Rather than standard TCP itself when they share the traditional method of increasing the congestion window by a bottleneck with it. Such protocols could be used constant amount for delay-insensitive "background" traffic, 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 they provide what is sometimes called well as closes a "less than" (or "lower than") best-effort service. security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This document is not memo defines an  Internet Standards Track specification; it is published Experimental Protocol for informational purposes.</t> the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3465"/>
          <seriesInfo name="DOI" value="10.17487/RFC3465"/>
        </reference>
        <reference anchor="RFC2018" target="https://www.rfc-editor.org/info/rfc2018">
          <front>
            <title>TCP Selective Acknowledgment Options</title>
            <author fullname="M. Mathis" initials="M." surname="Mathis">
              <organization/>
            </author>
            <author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
              <organization/>
            </author>
            <author fullname="S. Floyd" initials="S." surname="Floyd">
              <organization/>
            </author>
            <author fullname="A. Romanow" initials="A." surname="Romanow">
              <organization/>
            </author>
            <date month="October" year="1996"/>
            <abstract>
              <t>This memo proposes an implementation of SACK and discusses its performance and related issues.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2018"/>
          <seriesInfo name="DOI" value="10.17487/RFC2018"/>
        </reference>
        <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298">
          <front>
            <title>Computing TCP's Retransmission Timer</title>
            <author fullname="V. Paxson" initials="V." surname="Paxson">
              <organization/>
            </author>
            <author fullname="M. Allman" initials="M." surname="Allman">
              <organization/>
            </author>
            <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>
              <t>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a <bcp14>SHOULD</bcp14> to a <bcp14>MUST</bcp14>.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6297"/> value="6298"/>
          <seriesInfo name="DOI" value="10.17487/RFC6297"/> value="10.17487/RFC6298"/>
        </reference>
        <reference anchor="RACK" target="http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-15.txt"> anchor="RFC8985" target="https://www.rfc-editor.org/info/rfc8985">
          <front>
            <title>The RACK-TLP loss detection algorithm Loss Detection Algorithm for TCP</title>
            <author initials="Y" surname="Cheng" fullname="Yuchung Cheng"> fullname="Y. Cheng" initials="Y." surname="Cheng">
              <organization/>
            </author>
            <author initials="N" surname="Cardwell" fullname="Neal Cardwell"> fullname="N. Cardwell" initials="N." surname="Cardwell">
              <organization/>
            </author>
            <author initials="N" surname="Dukkipati" fullname="Nandita Dukkipati"> fullname="N. Dukkipati" initials="N." surname="Dukkipati">
              <organization/>
            </author>
            <author initials="P" surname="Jha" fullname="Priyaranjan Jha"> fullname="P. Jha" initials="P." surname="Jha">
              <organization/>
            </author>
            <date month="December" day="22" year="2020"/> month="February" year="2021"/>
            <abstract>
              <t>This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgements (SACK) acknowledgments (SACKs) and has two parts: RACK ("Recent ACKnowledgment") parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from ACK feedback.  TLP ("Tail acknowledgment (ACK) feedback, and Tail Loss Probe") Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used DUPACK duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DUPACK DupAck threshold approach.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-rack-15"/> name="RFC" value="8985"/>
          <seriesInfo name="DOI" value="10.17487/RFC8985"/>
        </reference>
        <reference anchor="RFC5682" target="https://www.rfc-editor.org/info/rfc5682">
          <front>
            <title>Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP</title>
            <author initials="P." surname="Sarolahti" fullname="P. Sarolahti"> Sarolahti" initials="P." surname="Sarolahti">
              <organization/>
            </author>
            <author initials="M." surname="Kojo" fullname="M. Kojo"> Kojo" initials="M." surname="Kojo">
              <organization/>
            </author>
            <author initials="K." surname="Yamamoto" fullname="K. Yamamoto"> Yamamoto" initials="K." surname="Yamamoto">
              <organization/>
            </author>
            <author initials="M." surname="Hata" fullname="M. Hata"> Hata" initials="M." surname="Hata">
              <organization/>
            </author>
            <date year="2009" month="September"/> month="September" year="2009"/>
            <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 RFC 4138 remains with Experimental status.  See Appendix B for the differences between this document and RFC 4138.</t>
              <t>Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data.  This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts.  F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate.  After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious.  It then decides whether to send new segments or retransmit unacknowledged segments.  The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5682"/>
          <seriesInfo name="DOI" value="10.17487/RFC5682"/>
        </reference>
        <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298">
          <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 retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  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/rfc5681">
          <front>
            <title>TCP Congestion Control</title>
            <author initials="M." surname="Allman" fullname="M. Allman"> Allman" initials="M." surname="Allman">
              <organization/>
            </author>
            <author initials="V." surname="Paxson" fullname="V. Paxson"> Paxson" initials="V." surname="Paxson">
              <organization/>
            </author>
            <author initials="E." surname="Blanton" fullname="E. Blanton"> Blanton" initials="E." surname="Blanton">
              <organization/>
            </author>
            <date year="2009" month="September"/> month="September" year="2009"/>
            <abstract>
              <t>This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.  This document obsoletes RFC 2581.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5681"/>
          <seriesInfo name="DOI" value="10.17487/RFC5681"/>
        </reference>
        <reference anchor="RFC5827" target="https://www.rfc-editor.org/info/rfc5827">
          <front>
            <title>Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)</title>
            <author initials="M." surname="Allman" fullname="M. Allman"> Allman" initials="M." surname="Allman">
              <organization/>
            </author>
            <author initials="K." surname="Avrachenkov" fullname="K. Avrachenkov"> Avrachenkov" initials="K." surname="Avrachenkov">
              <organization/>
            </author>
            <author initials="U." surname="Ayesta" fullname="U. Ayesta"> Ayesta" initials="U." surname="Ayesta">
              <organization/>
            </author>
            <author initials="J." surname="Blanton" fullname="J. Blanton"> Blanton" initials="J." surname="Blanton">
              <organization/>
            </author>
            <author initials="P." surname="Hurtig" fullname="P. Hurtig"> Hurtig" initials="P." surname="Hurtig">
              <organization/>
            </author>
            <date year="2010" month="May"/> month="May" year="2010"/>
            <abstract>
              <t>This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small.  The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission.  This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5827"/>
          <seriesInfo name="DOI" value="10.17487/RFC5827"/>
        </reference>
        <reference anchor="RFC6675" target="https://www.rfc-editor.org/info/rfc6675">
          <front>
            <title>A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP</title>
            <author initials="E." surname="Blanton" fullname="E. Blanton"> Blanton" initials="E." surname="Blanton">
              <organization/>
            </author>
            <author initials="M." surname="Allman" fullname="M. Allman"> Allman" initials="M." surname="Allman">
              <organization/>
            </author>
            <author initials="L." surname="Wang" fullname="L. Wang"> Wang" initials="L." surname="Wang">
              <organization/>
            </author>
            <author initials="I." surname="Jarvinen" fullname="I. Jarvinen"> Jarvinen" initials="I." surname="Jarvinen">
              <organization/>
            </author>
            <author initials="M." surname="Kojo" fullname="M. Kojo"> Kojo" initials="M." surname="Kojo">
              <organization/>
            </author>
            <author initials="Y." surname="Nishida" fullname="Y. Nishida"> Nishida" initials="Y." surname="Nishida">
              <organization/>
            </author>
            <date year="2012" month="August"/> month="August" year="2012"/>
            <abstract>
              <t>This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option.  The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6675"/>
          <seriesInfo name="DOI" value="10.17487/RFC6675"/>
        </reference>
        <reference anchor="RFC6582" target="https://www.rfc-editor.org/info/rfc6582">
          <front>
            <title>The NewReno Modification to TCP's Fast Recovery Algorithm</title>
            <author initials="T." surname="Henderson" fullname="T. Henderson"> Henderson" initials="T." surname="Henderson">
              <organization/>
            </author>
            <author initials="S." surname="Floyd" fullname="S. Floyd"> Floyd" initials="S." surname="Floyd">
              <organization/>
            </author>
            <author initials="A." surname="Gurtov" fullname="A. Gurtov"> Gurtov" initials="A." surname="Gurtov">
              <organization/>
            </author>
            <author initials="Y." surname="Nishida" fullname="Y. Nishida"> Nishida" initials="Y." surname="Nishida">
              <organization/>
            </author>
            <date year="2012" month="April"/> month="April" year="2012"/>
            <abstract>
              <t>RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK.  This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno".  This response to partial acknowledgments was first proposed by Janey Hoe.  This document obsoletes RFC 3782.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6582"/>
          <seriesInfo name="DOI" value="10.17487/RFC6582"/>
        </reference>
        <reference anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc8312">
          <front>
            <title>CUBIC for Fast Long-Distance Networks</title>
            <author initials="I." surname="Rhee" fullname="I. Rhee"> Rhee" initials="I." surname="Rhee">
              <organization/>
            </author>
            <author initials="L." surname="Xu" fullname="L. Xu"> Xu" initials="L." surname="Xu">
              <organization/>
            </author>
            <author initials="S." surname="Ha" fullname="S. Ha"> Ha" initials="S." surname="Ha">
              <organization/>
            </author>
            <author initials="A." surname="Zimmermann" fullname="A. Zimmermann"> Zimmermann" initials="A." surname="Zimmermann">
              <organization/>
            </author>
            <author initials="L." surname="Eggert" fullname="L. Eggert"> Eggert" initials="L." surname="Eggert">
              <organization/>
            </author>
            <author initials="R." surname="Scheffenegger" fullname="R. Scheffenegger"> Scheffenegger" initials="R." surname="Scheffenegger">
              <organization/>
            </author>
            <date year="2018" month="February"/> month="February" year="2018"/>
            <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 stability 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 implementations and to solicit community feedback through experimentation on the performance of CUBIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8312"/>
          <seriesInfo name="DOI" value="10.17487/RFC8312"/>
        </reference>
        <reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8311">
          <front>
            <title>Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation</title>
            <author initials="D." surname="Black" fullname="D. Black"> Black" initials="D." surname="Black">
              <organization/>
            </author>
            <date year="2018" month="January"/> month="January" year="2018"/>
            <abstract>
              <t>This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints.  It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss.  This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation 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 makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram 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 provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8311"/>
          <seriesInfo name="DOI" value="10.17487/RFC8311"/>
        </reference>
        <reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc6928">
          <front>
            <title>Increasing TCP's Initial Window</title>
            <author initials="J." surname="Chu" fullname="J. Chu"> Chu" initials="J." surname="Chu">
              <organization/>
            </author>
            <author initials="N." surname="Dukkipati" fullname="N. Dukkipati"> Dukkipati" initials="N." surname="Dukkipati">
              <organization/>
            </author>
            <author initials="Y." surname="Cheng" fullname="Y. Cheng"> Cheng" initials="Y." surname="Cheng">
              <organization/>
            </author>
            <author initials="M." surname="Mathis" fullname="M. Mathis"> Mathis" initials="M." surname="Mathis">
              <organization/>
            </author>
            <date year="2013" month="April"/> month="April" year="2013"/>
            <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 advantages 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 collapse.  The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6928"/>
          <seriesInfo name="DOI" value="10.17487/RFC6928"/>
        </reference>
        <reference anchor="PRR" target="https://www.rfc-editor.org/info/rfc6937">
          <front>
            <title>Proportional Rate Reduction for TCP</title>
            <author initials="M." surname="Mathis" fullname="M. Mathis"> Mathis" initials="M." surname="Mathis">
              <organization/>
            </author>
            <author initials="N." surname="Dukkipati" fullname="N. Dukkipati"> Dukkipati" initials="N." surname="Dukkipati">
              <organization/>
            </author>
            <author initials="Y." surname="Cheng" fullname="Y. Cheng"> Cheng" initials="Y." surname="Cheng">
              <organization/>
            </author>
            <date year="2013" month="May"/> month="May" year="2013"/>
            <abstract>
              <t>This document describes an experimental Proportional Rate Reduction (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 actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6937"/>
          <seriesInfo name="DOI" value="10.17487/RFC6937"/>
        </reference>
        <reference anchor="RFC7661" target="https://www.rfc-editor.org/info/rfc7661">
          <front>
            <title>Updating TCP to Support Rate-Limited Traffic</title>
            <author initials="G." surname="Fairhurst" fullname="G. Fairhurst"> Fairhurst" initials="G." surname="Fairhurst">
              <organization/>
            </author>
            <author initials="A." surname="Sathiaseelan" fullname="A. Sathiaseelan"> Sathiaseelan" initials="A." surname="Sathiaseelan">
              <organization/>
            </author>
            <author initials="R." surname="Secchi" fullname="R. Secchi"> Secchi" initials="R." surname="Secchi">
              <organization/>
            </author>
            <date year="2015" month="October"/> month="October" year="2015"/>
            <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 limited by the application rather than the congestion window.  It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-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 RFC 2861 sought to address important issues but failed to deliver a widely used solution.  This document therefore reclassifies the status of RFC 2861 from Experimental to Historic.  This document obsoletes RFC 2861.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7661"/>
          <seriesInfo name="DOI" value="10.17487/RFC7661"/>
        </reference>
        <reference anchor="RFC8511" target="https://www.rfc-editor.org/info/rfc8511">
          <front>
            <title>TCP Alternative Backoff with ECN (ABE)</title>
            <author initials="N." surname="Khademi" fullname="N. Khademi"> Khademi" initials="N." surname="Khademi">
              <organization/>
            </author>
            <author initials="M." surname="Welzl" fullname="M. Welzl"> Welzl" initials="M." surname="Welzl">
              <organization/>
            </author>
            <author initials="G." surname="Armitage" fullname="G. Armitage"> Armitage" initials="G." surname="Armitage">
              <organization/>
            </author>
            <author initials="G." surname="Fairhurst" fullname="G. Fairhurst"> Fairhurst" initials="G." surname="Fairhurst">
              <organization/>
            </author>
            <date year="2018" month="December"/> month="December" year="2018"/>
            <abstract>
              <t>Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck.  This can cause noticeable performance degradation for TCP connections 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 therefore likely to be short.  Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8511"/>
          <seriesInfo name="DOI" value="10.17487/RFC8511"/>
        </reference>
        <reference anchor="RFC3465" target="https://www.rfc-editor.org/info/rfc3465">
          <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 increases its congestion window.  Rather than the traditional method of increasing the 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 increasing 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>
    <section anchor="loss-recovery-pseudocode" numbered="true" toc="default">
      <name>Loss Recovery Pseudocode</name>
      <t>We now describe an example implementation
      </references>
    </references>
    <section anchor="loss-recovery-pseudocode" numbered="true" toc="default">
      <name>Loss Recovery Pseudocode</name>
      <t>We now describe an example implementation of the loss detection mechanisms
described in <xref target="loss-detection" format="default"/>.</t>
      <t>The pseudocode segments in this section are licensed as Code Components; see the
copyright notice.</t>
      <section anchor="tracking-sent-packets" numbered="true" toc="default">
        <name>Tracking Sent Packets</name>
        <t>To correctly implement congestion control, a QUIC sender tracks every
ack-eliciting packet until the packet is acknowledged or lost.
It is expected that implementations will be able to access this information by
packet number and crypto context and store the per-packet fields
(<xref target="sent-packets-fields" format="default"/>) for loss recovery and congestion control.</t>
        <t>After a packet is declared lost, the endpoint can still maintain state for it
for an amount of time to allow for packet reordering; see Section 13.3 of <xref section="13.3" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>. This enables a sender to detect spurious retransmissions.</t>
        <t>Sent packets are tracked for each packet number space, and ACK
processing only applies to a single space.</t>
        <section anchor="sent-packets-fields" numbered="true" toc="default">
          <name>Sent Packet Fields</name>
          <dl>
            <dt>
packet_number:  </dt>
            <dt>packet_number:</dt>
            <dd>
              <t>The packet number of the sent packet.</t>
            </dd>
            <dt>
ack_eliciting:  </dt>
            <dt>ack_eliciting:</dt>
            <dd>
              <t>A boolean Boolean that indicates whether a packet is ack-eliciting.
If true, it is expected that an acknowledgment will be received,
though the peer could delay sending the ACK frame containing it
by up to the max_ack_delay.</t>
            </dd>
            <dt>
in_flight:  </dt>
            <dt>in_flight:</dt>
            <dd>
              <t>A boolean Boolean that indicates whether the packet counts towards toward bytes in
flight.</t>
            </dd>
            <dt>
sent_bytes:  </dt>
            <dt>sent_bytes:</dt>
            <dd>
              <t>The number of bytes sent in the packet, not including UDP or IP
overhead, but including QUIC framing overhead.</t>
            </dd>
            <dt>
time_sent:  </dt>
            <dt>time_sent:</dt>
            <dd>
              <t>The time the packet was sent.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="constants-of-interest" numbered="true" toc="default">
        <name>Constants of Interest</name>
        <t>Constants used in loss recovery are based on a combination of RFCs, papers, and
common practice.</t>
        <dl>
          <dt>
kPacketThreshold:  </dt>
          <dt>kPacketThreshold:</dt>
          <dd>
            <t>Maximum reordering in packets before packet threshold loss detection
considers a packet lost. The value recommended in <xref target="packet-threshold" format="default"/> is 3.</t>
          </dd>
          <dt>
kTimeThreshold:  </dt>
          <dt>kTimeThreshold:</dt>
          <dd>
            <t>Maximum reordering in time before time threshold loss detection
considers a packet lost. Specified as an RTT multiplier. The value
recommended in <xref target="time-threshold" format="default"/> is 9/8.</t>
          </dd>
          <dt>
kGranularity:  </dt>
          <dt>kGranularity:</dt>
          <dd>
            <t>Timer granularity. This is a system-dependent value, and <xref target="time-threshold" format="default"/>
recommends a value of 1ms.</t> 1 ms.</t>
          </dd>
          <dt>
kInitialRtt:  </dt>
          <dt>kInitialRtt:</dt>
          <dd>
            <t>The RTT used before an RTT sample is taken. The value recommended in
<xref target="pto-handshake" format="default"/> is 333ms.</t> 333 ms.</t>
          </dd>
          <dt>
kPacketNumberSpace:  </dt>
          <dt>kPacketNumberSpace:</dt>
          <dd>
            <t>An enum to enumerate the three packet number spaces.</t> spaces:</t>
          </dd>
        </dl>
        <artwork name="" type="" align="left" alt=""><![CDATA[
enum kPacketNumberSpace {
  Initial,
  Handshake,
  ApplicationData,
}
]]></artwork>
      </section>
      <section anchor="ld-vars-of-interest" numbered="true" toc="default">
        <name>Variables of interest</name> Interest</name>
        <t>Variables required to implement the congestion control mechanisms
are described in this section.</t>
        <dl>
          <dt>
latest_rtt:  </dt>
          <dt>latest_rtt:</dt>
          <dd>
            <t>The most recent RTT measurement made when receiving an ack acknowledgment for
a previously unacked unacknowledged packet.</t>
          </dd>
          <dt>
smoothed_rtt:  </dt>
          <dt>smoothed_rtt:</dt>
          <dd>
            <t>The smoothed RTT of the connection, computed as described in
<xref target="smoothed-rtt" format="default"/>.</t>
          </dd>
          <dt>
rttvar:  </dt>
          <dt>rttvar:</dt>
          <dd>
            <t>The RTT variation, computed as described in <xref target="smoothed-rtt" format="default"/>.</t>
          </dd>
          <dt>
min_rtt:  </dt>
          <dt>min_rtt:</dt>
          <dd>
            <t>The minimum RTT seen over a period of time, ignoring acknowledgment delay, as
described in <xref target="min-rtt" format="default"/>.</t>
          </dd>
          <dt>
first_rtt_sample:  </dt>
          <dt>first_rtt_sample:</dt>
          <dd>
            <t>The time that the first RTT sample was obtained.</t>
          </dd>
          <dt>
max_ack_delay:  </dt>
          <dt>max_ack_delay:</dt>
          <dd>
            <t>The maximum amount of time by which the receiver intends to delay
acknowledgments for packets in the Application Data packet number
space, as defined by the eponymous transport parameter (Section 18.2
of <xref (<xref section="18.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>). Note that the actual ack_delay in a received
ACK frame may be larger due to late timers, reordering, or loss.</t>
          </dd>
          <dt>
loss_detection_timer:  </dt>
          <dt>loss_detection_timer:</dt>
          <dd>
            <t>Multi-modal timer used for loss detection.</t>
          </dd>
          <dt>
pto_count:  </dt>
          <dt>pto_count:</dt>
          <dd>
            <t>The number of times a PTO has been sent without receiving an ack.</t> acknowledgment.</t>
          </dd>
          <dt>
time_of_last_ack_eliciting_packet[kPacketNumberSpace]:  </dt>
          <dt>time_of_last_ack_eliciting_packet[kPacketNumberSpace]:</dt>
          <dd>
            <t>The time the most recent ack-eliciting packet was sent.</t>
          </dd>
          <dt>
largest_acked_packet[kPacketNumberSpace]:  </dt>
          <dt>largest_acked_packet[kPacketNumberSpace]:</dt>
          <dd>
            <t>The largest packet number acknowledged in the packet number space so far.</t>
          </dd>
          <dt>
loss_time[kPacketNumberSpace]:  </dt>
          <dt>loss_time[kPacketNumberSpace]:</dt>
          <dd>
            <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>
          </dd>
          <dt>
sent_packets[kPacketNumberSpace]:  </dt>
          <dt>sent_packets[kPacketNumberSpace]:</dt>
          <dd>
            <t>An association of packet numbers in a packet number space to information
about them.  Described in detail above in <xref target="tracking-sent-packets" format="default"/>.</t>
          </dd>
        </dl>
      </section>
      <section anchor="initialization" numbered="true" toc="default">
        <name>Initialization</name>
        <t>At the beginning of the connection, initialize the loss detection variables as
follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
loss_detection_timer.reset()
pto_count = 0
latest_rtt = 0
smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2
min_rtt = 0
first_rtt_sample = 0
for pn_space in [ Initial, Handshake, ApplicationData ]:
  largest_acked_packet[pn_space] = infinite
  time_of_last_ack_eliciting_packet[pn_space] = 0
  loss_time[pn_space] = 0
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="on-sending-a-packet" numbered="true" toc="default">
        <name>On Sending a Packet</name>
        <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-fields" format="default"/>.</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,
             in_flight, sent_bytes):
  sent_packets[pn_space][packet_number].packet_number =
                                           packet_number
  sent_packets[pn_space][packet_number].time_sent = now()
  sent_packets[pn_space][packet_number].ack_eliciting =
                                           ack_eliciting
  sent_packets[pn_space][packet_number].in_flight = in_flight
  sent_packets[pn_space][packet_number].sent_bytes = sent_bytes
  if (in_flight):
    if (ack_eliciting):
      time_of_last_ack_eliciting_packet[pn_space] = now()
    OnPacketSentCC(sent_bytes)
    SetLossDetectionTimer()
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="on-receiving-a-datagram" numbered="true" toc="default">
        <name>On Receiving a Datagram</name>
        <t>When a server is blocked by anti-amplification limits, receiving
a datagram unblocks it, even if none of the packets in the
datagram are successfully processed. In such a case, the PTO
timer will need to be re-armed.</t> rearmed.</t>
        <t>Pseudocode for OnDatagramReceived follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
OnDatagramReceived(datagram):
  // If this datagram unblocks the server, arm the
  // PTO timer to avoid deadlock.
  if (server was at anti-amplification limit):
    SetLossDetectionTimer()
]]></artwork>
    if loss_detection_timer.timeout < now():
      // Execute PTO if it would have expired
      // while the amplification limit applied.
      OnLossDetectionTimeout()
]]></sourcecode>
      </section>
      <section anchor="on-receiving-an-acknowledgment" numbered="true" toc="default">
        <name>On Receiving an Acknowledgment</name>
        <t>When an ACK frame is received, it may newly acknowledge any number of packets.</t>
        <t>Pseudocode for OnAckReceived and UpdateRtt follow:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
IncludesAckEliciting(packets):
  for packet in packets:
    if (packet.ack_eliciting):
      return true
  return false

OnAckReceived(ack, pn_space):
  if (largest_acked_packet[pn_space] == infinite):
    largest_acked_packet[pn_space] = ack.largest_acked
  else:
    largest_acked_packet[pn_space] =
        max(largest_acked_packet[pn_space], ack.largest_acked)

  // DetectAndRemoveAckedPackets finds packets that are newly
  // acknowledged and removes them from sent_packets.
  newly_acked_packets =
      DetectAndRemoveAckedPackets(ack, pn_space)
  // Nothing to do if there are no newly acked packets.
  if (newly_acked_packets.empty()):
    return

  // Update the RTT if the largest acknowledged is newly acked
  // and at least one ack-eliciting was newly acked.
  if (newly_acked_packets.largest().packet_number ==
          ack.largest_acked &&
      IncludesAckEliciting(newly_acked_packets)):
    latest_rtt =
      now() - newly_acked_packets.largest().time_sent
    UpdateRtt(ack.ack_delay)

  // Process ECN information if present.
  if (ACK frame contains ECN information):
      ProcessECN(ack, pn_space)

  lost_packets = DetectAndRemoveLostPackets(pn_space)
  if (!lost_packets.empty()):
    OnPacketsLost(lost_packets)
  OnPacketsAcked(newly_acked_packets)

  // Reset pto_count unless the client is unsure if
  // the server has validated the client's address.
  if (PeerCompletedAddressValidation()):
    pto_count = 0
  SetLossDetectionTimer()

UpdateRtt(ack_delay):
  if (first_rtt_sample == 0):
    min_rtt = latest_rtt
    smoothed_rtt = latest_rtt
    rttvar = latest_rtt / 2
    first_rtt_sample = now()
    return

  // min_rtt ignores acknowledgment delay.
  min_rtt = min(min_rtt, latest_rtt)
  // Limit ack_delay by max_ack_delay after handshake
  // confirmation.
  if (handshake confirmed):
    ack_delay = min(ack_delay, max_ack_delay)

  // Adjust for acknowledgment delay if plausible.
  adjusted_rtt = latest_rtt
  if (latest_rtt > >= min_rtt + ack_delay):
    adjusted_rtt = latest_rtt - ack_delay

  rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
  smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="setting-the-loss-detection-timer" numbered="true" toc="default">
        <name>Setting the Loss Detection Timer</name>
        <t>QUIC loss detection uses a single timer for all timeout loss detection.  The
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
below shows how the single timer is set.</t>
        <t>This algorithm may result in the timer being set in the past, particularly if
timers wake up late. Timers set in the past fire immediately.</t>
        <t>Pseudocode for SetLossDetectionTimer follows (where the "^" operator represents
exponentiation):</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
GetLossTimeAndSpace():
  time = loss_time[Initial]
  space = Initial
  for pn_space in [ Handshake, ApplicationData ]:
    if (time == 0 || loss_time[pn_space] < time):
      time = loss_time[pn_space];
      space = pn_space
  return time, space

GetPtoTimeAndSpace():
  duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
      * (2 ^ pto_count)
  // Arm Anti-deadlock PTO starts from now when there are no inflight packets. the current time
  if (no in-flight packets): ack-eliciting packets in flight):
    assert(!PeerCompletedAddressValidation())
    if (has handshake keys):
      return (now() + duration), Handshake
    else:
      return (now() + duration), Initial
  pto_timeout = infinite
  pto_space = Initial
  for space in [ Initial, Handshake, ApplicationData ]:
    if (no in-flight ack-eliciting packets in flight in space):
        continue;
    if (space == ApplicationData):
      // Skip Application Data until handshake confirmed.
      if (handshake is not confirmed):
        return pto_timeout, pto_space
      // Include max_ack_delay and backoff for Application Data.
      duration += max_ack_delay * (2 ^ pto_count)

    t = time_of_last_ack_eliciting_packet[space] + duration
    if (t < pto_timeout):
      pto_timeout = t
      pto_space = space
  return pto_timeout, pto_space

PeerCompletedAddressValidation():
  // Assume clients validate the server's address implicitly.
  if (endpoint is server):
    return true
  // Servers complete address validation when a
  // protected packet is received.
  return has received Handshake ACK ||
       handshake confirmed

SetLossDetectionTimer():
  earliest_loss_time, _ = GetLossTimeAndSpace()
  if (earliest_loss_time != 0):
    // Time threshold loss detection.
    loss_detection_timer.update(earliest_loss_time)
    return

  if (server is at anti-amplification limit):
    // The server's timer is not set if nothing can be sent.
    loss_detection_timer.cancel()
    return

  if (no ack-eliciting packets in flight &&
      PeerCompletedAddressValidation()):
    // There is nothing to detect lost, so no timer is set.
    // However, the client needs to arm the timer if the
    // server might be blocked by the anti-amplification limit.
    loss_detection_timer.cancel()
    return

  timeout, _ = GetPtoTimeAndSpace()
  loss_detection_timer.update(timeout)
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="on-timeout" numbered="true" toc="default">
        <name>On Timeout</name>
        <t>When the loss detection timer expires, the timer's mode determines the action
to be performed.</t>
        <t>Pseudocode for OnLossDetectionTimeout follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
OnLossDetectionTimeout():
  earliest_loss_time, pn_space = GetLossTimeAndSpace()
  if (earliest_loss_time != 0):
    // Time threshold loss Detection
    lost_packets = DetectAndRemoveLostPackets(pn_space)
    assert(!lost_packets.empty())
    OnPacketsLost(lost_packets)
    SetLossDetectionTimer()
    return

  if (bytes_in_flight > 0):
    // 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: (no ack-eliciting packets in flight):
    assert(!PeerCompletedAddressValidation())
    // Client sends an anti-deadlock packet: Initial is padded
    // to earn more anti-amplification credit,
    // a Handshake packet proves address ownership.
    if (has Handshake keys):
      SendOneAckElicitingHandshakePacket()
    else:
      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++
  SetLossDetectionTimer()
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="detecting-lost-packets" numbered="true" toc="default">
        <name>Detecting Lost Packets</name>
        <t>DetectAndRemoveLostPackets is called every time an ACK is received or the time
threshold loss detection timer expires. This function operates on the
sent_packets for that packet number space and returns a list of packets newly
detected as lost.</t>
        <t>Pseudocode for DetectAndRemoveLostPackets follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
DetectAndRemoveLostPackets(pn_space):
  assert(largest_acked_packet[pn_space] != infinite)
  loss_time[pn_space] = 0
  lost_packets = []
  loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)

  // Minimum time of kGranularity before packets are deemed lost.
  loss_delay = max(loss_delay, kGranularity)

  // Packets sent before this time are deemed lost.
  lost_send_time = now() - loss_delay

  foreach unacked in sent_packets[pn_space]:
    if (unacked.packet_number > largest_acked_packet[pn_space]):
      continue

    // Mark packet as lost, or set time when it should be marked.
    // Note: The use of kPacketThreshold here assumes that there
    // were no sender-induced gaps in the packet number space.
    if (unacked.time_sent <= lost_send_time ||
        largest_acked_packet[pn_space] >=
          unacked.packet_number + kPacketThreshold):
      sent_packets[pn_space].remove(unacked.packet_number)
      lost_packets.insert(unacked)
    else:
      if (loss_time[pn_space] == 0):
        loss_time[pn_space] = unacked.time_sent + loss_delay
      else:
        loss_time[pn_space] = min(loss_time[pn_space],
                                  unacked.time_sent + loss_delay)
  return lost_packets
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="upon-dropping-initial-or-handshake-keys" numbered="true" toc="default">
        <name>Upon Dropping Initial or Handshake Keys</name>
        <t>When Initial or Handshake keys are discarded, packets from the space
are discarded and loss detection state is updated.</t>
        <t>Pseudocode for OnPacketNumberSpaceDiscarded follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
OnPacketNumberSpaceDiscarded(pn_space):
  assert(pn_space != ApplicationData)
  RemoveFromBytesInFlight(sent_packets[pn_space])
  sent_packets[pn_space].clear()
  // Reset the loss detection and PTO timer
  time_of_last_ack_eliciting_packet[pn_space] = 0
  loss_time[pn_space] = 0
  pto_count = 0
  SetLossDetectionTimer()
]]></artwork>
]]></sourcecode>
      </section>
    </section>
    <section anchor="congestion-control-pseudocode" numbered="true" toc="default">
      <name>Congestion Control Pseudocode</name>
      <t>We now describe an example implementation of the congestion controller described
in <xref target="congestion-control" format="default"/>.</t>
      <t>The pseudocode segments in this section are licensed as Code Components; see the
copyright notice.</t>
      <section anchor="cc-consts-of-interest" numbered="true" toc="default">
        <name>Constants of interest</name> Interest</name>
        <t>Constants used in congestion control are based on a combination of RFCs, papers,
and common practice.</t>
        <dl>
          <dt>
kInitialWindow:  </dt>
          <dt>kInitialWindow:</dt>
          <dd>
            <t>Default limit on the initial bytes in flight as described in <xref target="initial-cwnd" format="default"/>.</t>
          </dd>
          <dt>
kMinimumWindow:  </dt>
          <dt>kMinimumWindow:</dt>
          <dd>
            <t>Minimum congestion window in bytes as described in <xref target="initial-cwnd" format="default"/>.</t>
          </dd>
          <dt>
kLossReductionFactor:  </dt>
          <dt>kLossReductionFactor:</dt>
          <dd>
            <t>Scaling factor applied to reduce the congestion window when a new loss event
is detected. <xref target="congestion-control" format="default"/> recommends a value is of 0.5.</t>
          </dd>
          <dt>
kPersistentCongestionThreshold:  </dt>
          <dt>kPersistentCongestionThreshold:</dt>
          <dd>
            <t>Period of time for persistent congestion to be established, specified as a PTO
multiplier. <xref target="persistent-congestion" format="default"/> recommends a value of 3.</t>
          </dd>
        </dl>
      </section>
      <section anchor="vars-of-interest" numbered="true" toc="default">
        <name>Variables of interest</name> Interest</name>
        <t>Variables required to implement the congestion control mechanisms
are described in this section.</t>
        <dl>
          <dt>
max_datagram_size:  </dt>
          <dt>max_datagram_size:</dt>
          <dd>
            <t>The sender's current maximum payload size. Does This does not include UDP or IP
overhead.  The max datagram size is used for congestion window
computations. An endpoint sets the value of this variable based on its Path
Maximum Transmission Unit (PMTU; see Section 14.2 of <xref section="14.2" sectionFormat="of" target="QUIC-TRANSPORT" format="default"/>), with
a minimum value of 1200 bytes.</t>
          </dd>
          <dt>
ecn_ce_counters[kPacketNumberSpace]:  </dt>
          <dt>ecn_ce_counters[kPacketNumberSpace]:</dt>
          <dd>
            <t>The highest value reported for the ECN-CE counter in the packet number space
by the peer in an ACK frame. This value is used to detect increases in the
reported ECN-CE counter.</t>
          </dd>
          <dt>
bytes_in_flight:  </dt>
          <dt>bytes_in_flight:</dt>
          <dd>
            <t>The sum of the size in bytes of all sent packets that contain at least one
ack-eliciting or PADDING frame, frame and have not been acknowledged or declared
lost. The size does not include IP or UDP overhead, but does include the QUIC
header and AEAD Authenticated Encryption with Associated Data (AEAD) overhead.
Packets only containing ACK frames do not count
towards toward bytes_in_flight to
ensure congestion control does not impede congestion feedback.</t>
          </dd>
          <dt>
congestion_window:  </dt>
          <dt>congestion_window:</dt>
          <dd>
            <t>Maximum number of bytes allowed to be in flight.</t>
          </dd>
          <dt>
congestion_recovery_start_time:  </dt>
          <dt>congestion_recovery_start_time:</dt>
          <dd>
            <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
congestion recovery.</t>
          </dd>
          <dt>
ssthresh:  </dt>
          <dt>ssthresh:</dt>
          <dd>
            <t>Slow start threshold in bytes.  When the congestion window is below ssthresh,
the mode is slow start and the window grows by the number of bytes
acknowledged.</t>
          </dd>
        </dl>
        <t>The congestion control pseudocode also accesses some of the variables from the
loss recovery pseudocode.</t>
      </section>
      <section anchor="initialization-1" numbered="true" toc="default">
        <name>Initialization</name>
        <t>At the beginning of the connection, initialize the congestion control
variables as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
congestion_window = kInitialWindow
bytes_in_flight = 0
congestion_recovery_start_time = 0
ssthresh = infinite
for pn_space in [ Initial, Handshake, ApplicationData ]:
  ecn_ce_counters[pn_space] = 0
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="on-packet-sent" numbered="true" toc="default">
        <name>On Packet Sent</name>
        <t>Whenever a packet is sent, sent and it contains non-ACK frames, the packet
increases bytes_in_flight.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
OnPacketSentCC(sent_bytes):
  bytes_in_flight += sent_bytes
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="on-packet-acknowledgment" numbered="true" toc="default">
        <name>On Packet Acknowledgment</name>
        <t>Invoked
        <t>This is invoked from loss detection's OnAckReceived and is supplied with the
newly acked_packets from sent_packets.</t>
        <t>In congestion avoidance, implementers that use an integer representation
for congestion_window should be careful with division, division and can use
the alternative approach suggested in Section 2.1 of <xref section="2.1" sectionFormat="of" target="RFC3465" format="default"/>.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
InCongestionRecovery(sent_time):
  return sent_time <= congestion_recovery_start_time

OnPacketsAcked(acked_packets):
  for acked_packet in acked_packets:
    OnPacketAcked(acked_packet)

OnPacketAcked(acked_packet):
  if (!acked_packet.in_flight):
    return;
  // Remove from bytes_in_flight.
  bytes_in_flight -= acked_packet.sent_bytes
  // Do not increase congestion_window if application
  // limited or flow control limited.
  if (IsAppOrFlowControlLimited())
    return
  // Do not increase congestion window in recovery period.
  if (InCongestionRecovery(acked_packet.time_sent)):
    return
  if (congestion_window < ssthresh):
    // Slow start.
    congestion_window += acked_packet.sent_bytes
  else:
    // Congestion avoidance.
    congestion_window +=
      max_datagram_size * acked_packet.sent_bytes
      / congestion_window
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="on-new-congestion-event" numbered="true" toc="default">
        <name>On New Congestion Event</name>
        <t>Invoked
        <t>This is invoked from ProcessECN and OnPacketsLost when a new congestion event is
detected. If not already in recovery, this starts a recovery period and
reduces the slow start threshold and congestion window immediately.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
OnCongestionEvent(sent_time):
  // No reaction if already in a recovery period.
  if (InCongestionRecovery(sent_time)):
    return

  // Enter recovery period.
  congestion_recovery_start_time = now()
  ssthresh = congestion_window * kLossReductionFactor
  congestion_window = max(ssthresh, kMinimumWindow)
  // A packet can be sent to speed up loss recovery.
  MaybeSendOnePacket()
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="process-ecn-information" numbered="true" toc="default">
        <name>Process ECN Information</name>
        <t>Invoked
        <t>This is invoked when an ACK frame with an ECN section is received from the peer.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
ProcessECN(ack, pn_space):
  // If the ECN-CE counter reported by the peer has increased,
  // this could be a new congestion event.
  if (ack.ce_counter > ecn_ce_counters[pn_space]):
    ecn_ce_counters[pn_space] = ack.ce_counter
    sent_time = sent_packets[ack.largest_acked].time_sent
    OnCongestionEvent(sent_time)
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="on-packets-lost" numbered="true" toc="default">
        <name>On Packets Lost</name>
        <t>Invoked
        <t>This is invoked when DetectAndRemoveLostPackets deems packets lost.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
OnPacketsLost(lost_packets):
  sent_time_of_last_loss = 0
  // Remove lost packets from bytes_in_flight.
  for lost_packet in lost_packets:
    if lost_packet.in_flight:
      bytes_in_flight -= lost_packet.sent_bytes
      sent_time_of_last_loss =
        max(sent_time_of_last_loss, lost_packet.time_sent)
  // Congestion event if in-flight packets were lost
  if (sent_time_of_last_loss != 0):
    OnCongestionEvent(sent_time_of_last_loss)

  // Reset the congestion window if the loss of these
  // packets indicates persistent congestion.
  // Only consider packets sent after getting an RTT sample.
  if (first_rtt_sample == 0):
    return
  pc_lost = []
  for lost in lost_packets:
    if lost.time_sent > first_rtt_sample:
      pc_lost.insert(lost)
  if (InPersistentCongestion(pc_lost)):
    congestion_window = kMinimumWindow
    congestion_recovery_start_time = 0
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="removing-discarded-packets-from-bytes-in-flight" numbered="true" toc="default">
        <name>Removing Discarded Packets From from Bytes In in Flight</name>
        <t>When Initial or Handshake keys are discarded, packets sent in that space no
longer count toward bytes in flight.</t>
        <t>Pseudocode for RemoveFromBytesInFlight follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="pseudocode"><![CDATA[
RemoveFromBytesInFlight(discarded_packets):
  // Remove any unacknowledged packets from flight.
  foreach packet in discarded_packets:
    if packet.in_flight
      bytes_in_flight -= size
]]></artwork>
      </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="default">
        <name>Since draft-ietf-quic-recovery-32</name>
        <ul spacing="normal">
          <li>Clarifications to definition of persistent congestion (#4413, #4414, #4421,
#4429, #4437)</li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-31" numbered="true" toc="default">
        <name>Since draft-ietf-quic-recovery-31</name>
        <ul spacing="normal">
          <li>Limit the number of Initial packets sent in response to unauthenticated
packets (#4183, #4188)</li>
        </ul>
]]></sourcecode>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-30" numbered="true" toc="default">
        <name>Since draft-ietf-quic-recovery-30</name>
        <t>Editorial changes only.</t>
    </section>
    <section anchor="since-draft-ietf-quic-recovery-29" numbered="true" numbered="false" anchor="contributors" toc="default">
        <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
      <name>Contributors</name>
      <t>The IETF QUIC Working Group received an enormous amount of packet number space (#3939, #3961)</li>
          <li>Only limit bursts support from many
people. The following people provided substantive contributions to the initial window without information about the path
(#3892, #3936)</li>
          <li>Add normative requirements for increasing and reducing the congestion
window (#3944, #3978, #3997, #3998)</li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-28" numbered="true" toc="default">
        <name>Since draft-ietf-quic-recovery-28</name> this
document:</t>
      <ul spacing="normal">
          <li>Refactored pseudocode to correct PTO calculation (#3564, #3674, #3681)</li> spacing="compact">
        <li>
          <t><contact fullname="Alessandro Ghedini"/></t>
        </li>
        <li>
          <t><contact fullname="Benjamin Saunders"/></t>
        </li>
        <li>
          <t><contact fullname="Gorry Fairhurst"/></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>
      </ul>
    </section>
      <section anchor="since-draft-ietf-quic-recovery-27" numbered="true" toc="default">
        <name>Since draft-ietf-quic-recovery-27</name>
        <ul spacing="normal">
          <li>Added recommendations for speeding up handshake under some loss conditions
(#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 awaiting
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="default">
        <name>Since draft-ietf-quic-recovery-26</name>
        <t>No changes.</t>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-25" numbered="true" toc="default">
        <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="default">
        <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="default">
        <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="default">
        <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="default">
        <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="default">
        <name>Since draft-ietf-quic-recovery-20</name>
        <ul spacing="normal">
          <li>Path validation can be used as initial RTT value (#2644, #2687)</li>
          <li>max_ack_delay transport parameter defaults to 0 (#2638, #2646)</li>
          <li>ACK delay only measures intentional delays induced by the implementation
(#2596, #2786)</li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-19" numbered="true" toc="default">
        <name>Since draft-ietf-quic-recovery-19</name>
        <ul spacing="normal">
          <li>Change kPersistentThreshold from an exponent to a multiplier (#2557)</li>
          <li>Send a PING if the PTO timer fires and there's nothing to send (#2624)</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 packet 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 the
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="default">
        <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 spaces and
pseudocode (#2485, #2451, #2417)</li>
          <li>Declare persistent congestion even if non-probe packets are sent and 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="default">
        <name>Since draft-ietf-quic-recovery-17</name>
        <ul spacing="normal">
          <li>After Probe Timeout discard in-flight packets or send another (#2212, #1965)</li>
          <li>Endpoints discard initial keys as soon as handshake keys are available (#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 controller
(#2138, 2187)</li>
          <li>Process ECN counts before marking packets lost (#2142)</li>
          <li>Mark packets lost before resetting crypto_count and pto_count (#2208, #2209)</li>
          <li>Congestion and loss recovery state are discarded when keys are discarded
(#2327)</li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-16" numbered="true" toc="default">
        <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 and min crypto
timeouts; eliminate timeout validation (#2114, #2166, #2168, #1017)</li>
          <li>Redefine how congestion avoidance in terms of when the period starts (#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 (#1969, #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 acknowledgment (#2060,
#2078)</li>
          <li>Limit ack_delay by max_ack_delay (#2060, #2099)</li>
          <li>Initial keys are discarded once Handshake keys are available (#1951, #2045)</li>
          <li>Reorder ECN and loss detection in pseudocode (#2142)</li>
          <li>Only cancel loss detection timer if ack-eliciting packets are in flight
(#2093, #2117)</li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-14" numbered="true" toc="default">
        <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="default">
        <name>Since draft-ietf-quic-recovery-13</name>
        <ul spacing="normal">
          <li>Corrected the lack of ssthresh reduction in CongestionEvent pseudocode (#1598)</li>
          <li>Considerations for ECN spoofing (#1426, #1626)</li>
          <li>Clarifications for PADDING and congestion control (#837, #838, #1517, #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="default">
        <name>Since draft-ietf-quic-recovery-12</name>
        <ul spacing="normal">
          <li>Changes to manage separate packet number spaces and encryption levels (#1190,
#1242, #1413, #1450)</li>
          <li>Added ECN feedback mechanisms and handling; new ACK_ECN frame (#804, #805,
#1372)</li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-11" numbered="true" toc="default">
        <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="default">
        <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 Retry 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="default">
        <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="default">
        <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="default">
        <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="default">
        <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="default">
        <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="default">
        <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="default">
        <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="default">
        <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 (#415)</li>
          <li>Simplify RTO calculations (#142, #417)</li>
        </ul>
      </section>
      <section anchor="since-draft-ietf-quic-recovery-01" numbered="true" toc="default">
        <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="default">
        <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 anchor="contributors" numbered="true" toc="default">
      <name>Contributors</name>
      <t>The IETF QUIC Working Group received an enormous amount of support from many
people. The following people provided substantive contributions to this
document:</t>
      <ul spacing="normal">
        <li>Alessandro Ghedini</li>
        <li>Benjamin Saunders</li>
        <li>Gorry Fairhurst</li>
        <li>
          <t>        <contact asciiFullname="Kazu Yamamoto" fullname="山本和彦"/>
          </t>
        </li>
        <li>
          <t>        <contact asciiFullname="Kazuho Oku" fullname="奥 一穂"/>
          </t>
        </li>
        <li>Lars Eggert</li>
        <li>Magnus Westerlund</li>
        <li>Marten Seemann</li>
        <li>Martin Duke</li>
        <li>Martin Thomson</li>
        <li>
          <t>        <contact fullname="Mirja Kühlewind"/>
          </t>
        </li>
        <li>Nick Banks</li>
        <li>Praveen Balasubramanian</li>
      </ul>
    </section>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
    </section>
  </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>