<?xml version="1.0"?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 03/15/23 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
  <!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY rfc5681 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
  <!ENTITY rfc8312 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8312.xml">
  <!ENTITY rfc9002 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9002.xml">
  <!ENTITY rfc9260 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"> [
  <!ENTITY rfc8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> nbsp    "&#160;">
  <!ENTITY rfc1191 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"> zwsp   "&#8203;">
  <!ENTITY rfc1122 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"> nbhy   "&#8209;">
  <!ENTITY rfc4821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"> wj     "&#8288;">
]>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc compact='yes'?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<!-- <?rfc-ext parse-xml-in-artwork='yes' ?> -->
<!-- <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> -->

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

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev='HyStart++'>HyStart++: Modified&nbsp;Slow&nbsp;Start&nbsp;for&nbsp;TCP</title> abbrev="HyStart++">HyStart++: Modified Slow Start for TCP</title>
    <seriesInfo name="RFC" value="9406"/>
    <author initials='P.' surname='Balasubramanian' fullname='Praveen Balasubramanian'> initials="P." surname="Balasubramanian" fullname="Praveen Balasubramanian">
      <organization>Confluent</organization>
      <address>
        <postal>
          <street>899 West Evelyn Ave</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94041</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>pravb.ietf@gmail.com</email>
      </address>
    </author>
    <author initials='Y.' surname='Huang' fullname='Yi Huang'> initials="Y." surname="Huang" fullname="Yi Huang">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>94052</code>
          <country>USA</country>
          <code>98052</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 425 703 0447</phone>
        <email>huanyi@microsoft.com</email>
      </address>
    </author>
    <author initials='M.' surname='Olson' fullname='Matt Olson'> initials="M." surname="Olson" fullname="Matt Olson">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 425 538 8598</phone>
        <email>maolson@microsoft.com</email>
      </address>
    </author>
    <date/>
    <area>Transport</area>
    <date year="2023" month="May" />
    <area>tsv</area>
    <workgroup>tcpm</workgroup>
    <keyword>TCP</keyword>
    <keyword>congestion control</keyword>
    <abstract>
      <t> This document describes HyStart++, a simple modification to
      the slow start phase of congestion control algorithms.
      Slow start can overshoot the ideal send rate
      in many cases, causing high packet loss and poor performance.
      HyStart++ uses increase in round-trip delay as a heuristic to
      find an exit point before possible overshoot.
      It also adds a mitigation to prevent jitter from causing
      premature slow start exit.
      </t>
    </abstract>
  </front>
  <middle>
    <section title='Introduction'> numbered="true" toc="default">
      <name>Introduction</name>
      <t> <xref target="RFC5681"/> target="RFC5681" format="default"/> describes the slow start
      congestion control algorithm for TCP. The slow start
      algorithm is used when the congestion window (cwnd)
      is less than the slow start threshold (ssthresh).
      During slow start, in the absence of packet loss signals,
      TCP increases the cwnd exponentially to probe the network capacity.
      This fast growth can overshoot the ideal sending rate
      and cause significant packet loss which that cannot always
      be recovered efficiently.
      </t>
      <t>
      <t>HyStart++ builds upon Hybrid Start (HyStart), originally described in
      <xref target="HyStart" format="default"/>. HyStart++ uses increase in
      round-trip delay as a signal to exit
      slow start before potential packet loss occurs as a result
      of overshoot. This is one of two algorithms specified in
      <xref target="HyStart"/>. target="HyStart" format="default"/> for finding a safe exit point for
      slow start. After the slow start exit, a new
      Conservative Slow Start (CSS) phase is used to determine
       whether the slow start exit was premature and to resume
       slow start. This mitigation improves performance in the
       presence of jitter.
      HyStart++ reduces packet loss and retransmissions, and
      improves goodput in lab measurements and real world real-world
      deployments.
      </t>
      <t>  While this document describes Hystart++ HyStart++ for TCP, it can
      also be used for other transport protocols which that use slow start start,
      such as QUIC <xref target="RFC9002"/> target="RFC9002" format="default"/>
      or SCTP the Stream Control Transmission Protocol (SCTP) <xref target="RFC9260"/>. target="RFC9260" format="default"/>.
      </t>
    </section>
    <section title="Terminology" anchor="term">
      <t> The anchor="term" numbered="true" toc="default">
      <name>Terminology</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 14 BCP&nbsp;14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
      when, they appear in all capitals, as shown here.
      </t> here.</t>
    </section>
    <section title='Definitions'> numbered="true" toc="default">
      <name>Definitions</name>
      <t> We To aid the reader, we repeat here some definition definitions from
      <xref target="RFC5681"/> to aid the reader. target="RFC5681" format="default"/>:
      </t>
      <t>
      <dl spacing="normal" newline="false">
      <dt> SENDER MAXIMUM SEGMENT SIZE (SMSS):
      The SMSS is the (SMSS):</dt>
      <dd>The size of the
      largest segment that the sender can transmit. This value can be
      based on the maximum transmission unit of the network, the path Path
      MTU discovery Discovery algorithm <xref target="RFC1191"/>, target="RFC1191" format="default"/>
      <xref target="RFC4821"/> algorithm, target="RFC4821" format="default"/>, RMSS (see next item),
      or other factors. The size does not include the TCP/IP headers
      and options.
      </t>
      <t> options.</dd>

      <dt> RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the (RMSS):</dt><dd>The
      size of the largest segment that the receiver is willing to accept.
      This is the value specified in the MSS option sent by the
      receiver during connection startup.  Or, if the MSS option
      is not used, it is 536 bytes <xref target="RFC1122"/>. target="RFC1122" format="default"/>.
      The size does not include the TCP/IP headers and
      options.
      </t>
      <t>
      options.</dd>

      <dt> RECEIVER WINDOW (rwnd): The (rwnd):</dt><dd>The most recently advertised
      receiver window.
      </t>
      <t> window.</dd>

      <dt> CONGESTION WINDOW (cwnd): A (cwnd):</dt><dd>A TCP state variable that
      limits the amount of data a TCP can send.
      At any given time, a TCP MUST NOT <bcp14>MUST NOT</bcp14> send
      data with a sequence number higher than the sum of the highest
      acknowledged sequence number and the minimum of the cwnd and rwnd.
      </t> rwnd.</dd>
      </dl>
    </section>
    <section title='HyStart++ Algorithm'> numbered="true" toc="default">
      <name>HyStart++ Algorithm</name>
      <section title='Summary'> numbered="true" toc="default">
        <name>Summary</name>
        <t> <xref target="HyStart"/> target="HyStart" format="default"/> specifies two algorithms
        (a "Delay Increase" algorithm and an "Inter-Packet Arrival"
        algorithm) to be run in parallel to detect that the sending
        rate has reached capacity. In practice, the Inter-Packet
        Arrival algorithm does not perform well and is not able
        to detect congestion early, primarily due to ACK compression.
        The idea of the Delay Increase algorithm is to look for
        spikes in RTT (round-trip time), which suggest that the
        bottleneck buffer is filling up.
        </t>
        <t> In HyStart++, a TCP sender uses traditional standard slow start
        and then uses the "Delay Increase" Delay Increase algorithm to trigger an
        exit from slow start. But instead of going straight from
        slow start to congestion avoidance, the sender spends a
        number of RTTs in a Conservative Slow Start (CSS) phase
        to determine whether the exit from slow start was premature.
        During CSS, the congestion window is grown exponentially like in a
        fashion similar to regular slow start, but with a smaller exponential base,
        resulting in less aggressive growth.
        If the RTT reduces during CSS, it's concluded that the RTT
        spike was not related to congestion caused by the connection
        sending at a rate greater than the ideal send rate, and the
        connection resumes slow start. If the RTT inflation
        persists throughout CSS, the connection enters congestion
        avoidance.
        </t>
      </section>
      <section title='Algorithm Details'> numbered="true" toc="default">
        <name>Algorithm Details</name>
        <t> The following pseudocode uses a limit, L, to control the
        aggressiveness of the cwnd increase during both standard slow
        start and CSS. While an arriving ACK may newly acknowledge an
        arbitrary number of bytes, the Hystart++ HyStart++ algorithm limits the
        number of those bytes applied to increase the cwnd to L*SMSS bytes. </t>
        <t> lastRoundMinRTT and currentRoundMinRTT are initialized
        to infinity at the initialization time. currRTT &nbsp;currRTT is the RTT
        sampled from the latest incoming ACK and initialized to
        infinity. </t>
            <sourcecode type="pseudocode">
        <sourcecode>
lastRoundMinRTT = infinity
currentRoundMinRTT = infinity
currRTT = infinity
            </sourcecode>

        <t>Hystart++
        <t>HyStart++ measures rounds using sequence numbers, as
        follows:
        Define
        follows:</t>
        <ul spacing="normal">
        <li>Define windowEnd as a sequence number initialized to SND.NXT.
        When SND.NXT.</li>
        <li>When windowEnd is ACKed, the current round ends and windowEnd
        is set to SND.NXT.</t> SND.NXT.</li>
	</ul>
        <t> At the start of each round during standard slow start
        (<xref target="RFC5681"/>)
        <xref target="RFC5681" format="default"/> and CSS, initialize the variables
        used to compute the last round round's and current round's minimum RTT:
            <sourcecode type="pseudocode">
        </t>
        <sourcecode>
lastRoundMinRTT = currentRoundMinRTT
currentRoundMinRTT = infinity
rttSampleCount = 0
            </sourcecode>
        </t>
        <t> For each arriving ACK in slow start, where N is the
        number of previously unacknowledged bytes acknowledged
        in the arriving ACK: </t>
        <t>Update the cwnd: </t>
<sourcecode type="pseudocode">
        <sourcecode>
  cwnd = cwnd + min(N, L * SMSS)
</sourcecode>
        <t> Keep track of the minimum observed RTT: </t>
<sourcecode type="pseudocode">
        <sourcecode>
  currentRoundMinRTT = min(currentRoundMinRTT, currRTT)
  rttSampleCount += 1
</sourcecode>
        <t>For rounds where at least N_RTT_SAMPLE RTT samples have been
obtained and currentRoundMinRTT and lastRoundMinRTT are valid,
check to see if delay increase triggers slow start exit:</t>
<sourcecode type="pseudocode">
        <sourcecode>
if ((rttSampleCount &gt;= N_RTT_SAMPLE) AND
    (currentRoundMinRTT != infinity) AND
    (lastRoundMinRTT != infinity))
  Compute a RTT Threshold clamped between MIN_RTT_THRESH and MAX_RTT_THRESH
  RttThresh = max(MIN_RTT_THRESH,
    min(lastRoundMinRTT / MIN_RTT_DIVISOR, MAX_RTT_THRESH))
  if (currentRoundMinRTT &gt;= (lastRoundMinRTT + RttThresh))
    cssBaselineMinRtt = currentRoundMinRTT
    exit slow start and enter CSS
</sourcecode>
        <t> For each arriving ACK in CSS, where N is the number
        of previously unacknowledged bytes acknowledged in
        the arriving ACK:</t>
        <t> Update the cwnd: </t>
              <sourcecode type="pseudocode">
        <sourcecode>
cwnd = cwnd + (min(N, L * SMSS) / CSS_GROWTH_DIVISOR)
              </sourcecode>
        <t> Keep track of the minimum observed RTT: </t>
                <sourcecode type="pseudocode">
        <sourcecode>
currentRoundMinRTT = min(currentRoundMinRTT, currRTT)
rttSampleCount += 1
                </sourcecode>
        <t> For CSS rounds where at least N_RTT_SAMPLE RTT
            samples have been obtained, check to see if the current round's
            minRTT drops below baseline (cssBaselineMinRtt) indicating that HyStart
            slow start exit was spurious:
        </t>
                <sourcecode type="pseudocode">
        <sourcecode>
if (currentRoundMinRTT &lt; cssBaselineMinRtt)
  cssBaselineMinRtt = infinity
  resume slow start including HyStart++
                </sourcecode>
        <t> CSS lasts at most CSS_ROUNDS rounds. If the transition
        into CSS happens in the middle of a round, that partial
        round counts towards the limit. </t>
        <t> If CSS_ROUNDS rounds are complete,
        enter congestion avoidance by setting the ssthresh to the current cwnd.  </t>
        <sourcecode type="pseudocode">
        <sourcecode>
ssthresh = cwnd
        </sourcecode>
        <t> If loss or ECN-marking Explicit Congestion Notification (ECN) marking is observed anytime at any time during
        standard slow start or CSS, enter congestion avoidance
        by setting the ssthresh to the current cwnd.
</t>
<sourcecode type="pseudocode">
        <sourcecode>
ssthresh = cwnd
</sourcecode>
      </section>
      <section title='Tuning constants numbered="true" toc="default">
        <name>Tuning Constants and other considerations'> Other Considerations</name>
        <t> It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that a HyStart++ implementation use
      the following constants:
      <sourcecode type="pseudocode">
        </t>
        <sourcecode>
MIN_RTT_THRESH = 4 msec
MAX_RTT_THRESH = 16 msec
MIN_RTT_DIVISOR = 8
N_RTT_SAMPLE = 8
CSS_GROWTH_DIVISOR = 4
CSS_ROUNDS = 5
L = infinity if paced, L = 8 if non-paced
      </sourcecode>
      </t>
        <t> These constants have been determined with lab measurements
      and real world real-world deployments. An implementation MAY <bcp14>MAY</bcp14> tune them for
      different network characteristics.
        </t>
        <t> The delay increase sensitivity is determined
      by MIN_RTT_THRESH and MAX_RTT_THRESH. Smaller values of
      MIN_RTT_THRESH may cause spurious exits from slow start. Larger
      values of MAX_RTT_THRESH may result in slow start not exiting
      until loss is encountered for connections on large RTT paths.
        </t>
        <t>MIN_RTT_DIVISOR is a fraction of RTT to compute the delay threshold.
      A smaller value would mean a bigger larger threshold and thus less sensitive sensitivity to
      delay increase, and vice versa.
        </t>
        <t> While all TCP implementations are REQUIRED <bcp14>REQUIRED</bcp14> to take at least one RTT
      sample each round, implementations of HyStart++ are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to take
      at least N_RTT_SAMPLE RTT samples. Using lower values of N_RTT_SAMPLE will
      lower the accuracy of the measured RTT for the round;
      higher values will improve accuracy at the cost of more
      processing.
        </t>
        <t> The minimum value of CSS_GROWTH_DIVISOR MUST <bcp14>MUST</bcp14> be at least 2.
      A value of 1 results in the same aggressive behavior as regular
      slow start. Values larger than 4
      will cause the algorithm to be less aggressive and maybe less
      performant.
        </t>
        <t> Smaller values of CSS_ROUNDS may miss detecting jitter jitter,
      and larger values may limit performance.
        </t>
        <t> Packet pacing <xref target="ASA00"/> target="ASA00" format="default"/> is a possible mechanism to
      avoid large bursts and their associated harm. A paced TCP implementation SHOULD <bcp14>SHOULD</bcp14>
      use L = infinity. Burst concerns are mitigated by pacing pacing, and this
      setting allows for optimal cwnd growth on modern networks.
        </t>
        <t> For TCP implementations that pace to mitigate burst concerns, L
      values smaller than INFINITY infinity may suffer performance problems due to slow
      cwnd growth in high speed high-speed networks. For non-paced TCP implementations, L values
      smaller than 8 may suffer performance problems due to slow cwnd growth in high
      speed high-speed networks; L values larger than 8 may cause an increase in burstiness
      and thereby loss rates, and result in poor performance.
        </t>
        <t> An implementation SHOULD <bcp14>SHOULD</bcp14> use HyStart++ only for the
      initial slow start (when the ssthresh is at its initial value
      of arbitrarily high per <xref target="RFC5681"/>) target="RFC5681" format="default"/>) and fall
      back to using traditional standard slow start for the remainder of
      the connection lifetime. This is acceptable because subsequent
      slow starts will use the discovered ssthresh value to exit slow
      start and avoid the overshoot problem. An implementation MAY <bcp14>MAY</bcp14>
      use HyStart++ to grow the restart window
      (<xref target="RFC5681"/>)
      <xref target="RFC5681" format="default"/> after a long idle period.
        </t>
        <t>
      In application limited application-limited scenarios, the amount of data in
      flight could fall below the bandwidth-delay product (BDP) and
      result in smaller RTT samples samples, which can trigger an exit back to
      slow start. It is expected that a connection might oscillate
      between CSS and slow start in such scenarios. But this behavior
      will neither result in a connection prematurely entering
      congestion avoidance nor cause overshooting compared to
      slow start.
        </t>
      </section>
    </section>
    <section title='Deployments numbered="true" toc="default">
      <name>Deployments and Performance Evaluations'> Evaluations</name>
      <t> As At the time of February 2023, this writing, HyStart++ as described
        in this document has been default enabled for all TCP
        connections in the Windows operating system for over
        two years with pacing disabled and an actual L = 8.
      </t>
      <t> In lab measurements with Windows TCP, HyStart++ shows
        both
        goodput improvements as well as reductions in packet
        loss and retransmissions compared to traditional standard slow start.
        For example, across a variety of tests on a 100 Mbps link
        with a bottleneck buffer size of bandwidth-delay product,
        HyStart++ reduces bytes retransmitted by 50% and
        retransmission timeouts (RTOs) by 36%.
      </t>
      <t> In an A/B test where we compare compared an implementation of HyStart++
        (based on an earlier draft 01 version of this document) to
        traditional
        standard slow start across a large Windows device
        population, out of 52 billion TCP connections, 0.7% of
        connections move from 1 RTO to 0 RTOs and another 0.7% of
        connections move from 2 RTOs to 1 RTO with HyStart++.
        This test did not focus on send-heavy connections connections, and
        the impact on send-heavy connections is likely much
        higher. We plan to conduct more such production
        experiments to gather more data in the future.
      </t>
    </section>
    <section title='Security Considerations'> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t> HyStart++ enhances slow start and inherits the general
      security considerations discussed in <xref target="RFC5681"/>. target="RFC5681" format="default"/>.
      </t>
      <t>An attacker can cause Hystart++ HyStart++ to exit slow start prematurely
      and impair the performance of a TCP connection by, for example,
      dropping data packets or their acknowledgements.</t> acknowledgments.</t>
      <t>The ACK division attack outlined in <xref target="SCWA99"/> target="SCWA99" format="default"/> does not affect
      Hystart++
      HyStart++ because the congestion window increase in Hystart++ HyStart++ is based
      on the number of bytes newly acknowledged in each arriving ACK rather than by
      a particular constant on each arriving ACK.
      </t>
    </section>
    <section title='IANA Considerations'>
      <t> This numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.
      </t>
    </section>

    <section title='Acknowledgements'>
      <t> During the discussions of this work on the TCPM mailing list, in working group meetings,
        helpful comments, critiques, and reviews were received from (listed alphabetically by last name):
        Mark Allman, Bob Briscoe, Neal Cardwell, Yuchung Cheng, Junho Choi, Martin Duke, Reese Enghardt,
        Christian Huitema, Ilpo Järvinen, Yoshifumi Nishida, Randall Stewart, and Michael Tuexen.
      </t> IANA actions.</t>
    </section>
  </middle>
  <back>
    <references title='Normative References'>
      &rfc2119;
      &rfc5681;
      &rfc8174;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

    <references title='Informative References'>
      <references>
        <name>Informative References</name>

        <reference anchor='HyStart' target='https://doi.org/10.1016/j.comnet.2011.01.014'> anchor="HyStart" target="https://doi.org/10.1016/j.comnet.2011.01.014">
          <front>
            <title>Taming the elephants: New TCP slow start</title>
            <author initials="S." surname="Ha">
          </author>
            <author initials="I." surname="Ree"> surname="Rhee">
          </author>
            <date month="June" year="2011"/>
          </front>
        <seriesInfo name="" value="Computer
          <refcontent>Computer Networks vol. 55, no. 9, pp. 2092-2110"/> 2092-2110</refcontent>
          <seriesInfo name="DOI" value="10.1016/j.comnet.2011.01.014"/>
        </reference>
      &rfc9002;
      &rfc9260;
      &rfc1191;
      &rfc4821;
      &rfc1122;

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9002.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>

        <reference anchor='SCWA99' target='https://doi.org/10.1145/505696.505704'> anchor="SCWA99" target="https://doi.org/10.1145/505696.505704">
          <front>
            <title>TCP congestion control with a misbehaving receiver</title>
            <author initials="S." surname="Savage">
          </author>
            <author initials="N." surname="Cardwell">
          </author>
            <author initials="D." surname="Wetherall">
          </author>
            <author initials="T." surname="Anderson">
          </author>
            <date month="October" year="1999"/>
          </front>
        <seriesInfo name="" value="ACM
          <refcontent>ACM SIGCOMM Computer Communication Review, 29(5)"/> vol. 29, issue 5, pp. 71-78</refcontent>
          <seriesInfo name="DOI" value="10.1145/505696.505704"/>
        </reference>

        <reference anchor='ASA00' target='https://doi.org/10.1109/INFCOM.2000.832483'> anchor="ASA00" target="https://doi.org/10.1109/INFCOM.2000.832483">
          <front>
            <title>Understanding the Performance performance of TCP Pacing</title> pacing</title>
            <author initials="A." surname="Aggarwal">
          </author>
            <author initials="S." surname="Savage">
          </author>
            <author initials="T." surname="Anderson">
          </author>
            <date month="March" year="2000"/>
          </front>
        <seriesInfo name="" value="Proceedings
          <refcontent>Proceedings IEEE INFOCOM 2000"/> 2000</refcontent>
          <seriesInfo name="DOI" value="10.1109/INFCOM.2000.832483"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t> During the discussions of this work on the TCPM mailing list and in working group meetings,
        helpful comments, critiques, and reviews were received from (listed alphabetically by last name)
        <contact fullname="Mark Allman"/>, <contact fullname="Bob Briscoe"/>, <contact fullname="Neal Cardwell"/>, <contact fullname="Yuchung Cheng"/>, <contact fullname="Junho Choi"/>, <contact fullname="Martin Duke"/>, <contact fullname="Reese Enghardt"/>,
        <contact fullname="Christian Huitema"/>, <contact fullname="Ilpo Järvinen"/>, <contact fullname="Yoshifumi Nishida"/>, <contact fullname="Randall Stewart"/>, and <contact fullname="Michael Tüxen"/>.
      </t>
    </section>
  </back>
</rfc>