<pre>Internet Engineering Task Force (IETF)                         V. Paxson
Request for Comments: 6298                              ICSI/UC Berkeley
Obsoletes: <a href="./rfc2988">2988</a>                                                M. Allman
Updates: <a href="./rfc1122">1122</a>                                                       ICSI
Category: Standards Track                                         J. Chu
ISSN: 2070-1721                                                   Google
                                                              M. Sargent
                                                                    CWRU
                                                               June 2011


                  <span class="h1">Computing TCP's Retransmission Timer</span>

Abstract

   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
   <a href="./rfc1122#section-4.2.3.1">Section&nbsp;4.2.3.1 of RFC 1122</a> and upgrades the requirement of
   supporting the algorithm from a SHOULD to a MUST.  This document
   obsoletes <a href="./rfc2988">RFC 2988</a>.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6298">http://www.rfc-editor.org/info/rfc6298</a>.
















<span class="grey">Paxson, et al.               Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The Transmission Control Protocol (TCP) [<a href="#ref-Pos81" title="&quot;Transmission Control Protocol&quot;">Pos81</a>] uses a retransmission
   timer to ensure data delivery in the absence of any feedback from the
   remote data receiver.  The duration of this timer is referred to as
   RTO (retransmission timeout).  <a href="./rfc1122">RFC 1122</a> [<a href="#ref-Bra89" title="&quot;Requirements for Internet Hosts - Communication Layers&quot;">Bra89</a>] specifies that the
   RTO should be calculated as outlined in [<a href="#ref-Jac88" title="&quot;Congestion Avoidance and Control&quot;">Jac88</a>].

   This document codifies the algorithm for setting the RTO.  In
   addition, this document expands on the discussion in <a href="./rfc1122#section-4.2.3.1">Section&nbsp;4.2.3.1
   of RFC 1122</a> and upgrades the requirement of supporting the algorithm
   from a SHOULD to a MUST.  <a href="./rfc5681">RFC 5681</a> [<a href="#ref-APB09" title="&quot;TCP Congestion Control&quot;">APB09</a>] outlines the algorithm TCP
   uses to begin sending after the RTO expires and a retransmission is
   sent.  This document does not alter the behavior outlined in <a href="./rfc5681">RFC 5681</a>
   [<a href="#ref-APB09" title="&quot;TCP Congestion Control&quot;">APB09</a>].

   In some situations, it may be beneficial for a TCP sender to be more
   conservative than the algorithms detailed in this document allow.
   However, a TCP MUST NOT be more aggressive than the following
   algorithms allow.  This document obsoletes <a href="./rfc2988">RFC 2988</a> [<a href="#ref-PA00" title="&quot;Computing TCP's Retransmission Timer&quot;">PA00</a>].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="#ref-Bra97" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">Bra97</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  The Basic Algorithm</span>

   To compute the current RTO, a TCP sender maintains two state
   variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip
   time variation).  In addition, we assume a clock granularity of G
   seconds.





<span class="grey">Paxson, et al.               Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


   The rules governing the computation of SRTT, RTTVAR, and RTO are as
   follows:

   (2.1) Until a round-trip time (RTT) measurement has been made for a
         segment sent between the sender and receiver, the sender SHOULD
         set RTO &lt;- 1 second, though the "backing off" on repeated
         retransmission discussed in (5.5) still applies.

         Note that the previous version of this document used an initial
         RTO of 3 seconds [<a href="#ref-PA00" title="&quot;Computing TCP's Retransmission Timer&quot;">PA00</a>].  A TCP implementation MAY still use
         this value (or any other value &gt; 1 second).  This change in the
         lower bound on the initial RTO is discussed in further detail
         in <a href="#appendix-A">Appendix A</a>.

   (2.2) When the first RTT measurement R is made, the host MUST set

            SRTT &lt;- R
            RTTVAR &lt;- R/2
            RTO &lt;- SRTT + max (G, K*RTTVAR)

         where K = 4.

   (2.3) When a subsequent RTT measurement R' is made, a host MUST set

            RTTVAR &lt;- (1 - beta) * RTTVAR + beta * |SRTT - R'|
            SRTT &lt;- (1 - alpha) * SRTT + alpha * R'

         The value of SRTT used in the update to RTTVAR is its value
         before updating SRTT itself using the second assignment.  That
         is, updating RTTVAR and SRTT MUST be computed in the above
         order.

         The above SHOULD be computed using alpha=1/8 and beta=1/4 (as
         suggested in [<a href="#ref-JK88" title="&quot;Congestion Avoidance and Control&quot;">JK88</a>]).

         After the computation, a host MUST update
         RTO &lt;- SRTT + max (G, K*RTTVAR)

   (2.4) Whenever RTO is computed, if it is less than 1 second, then the
         RTO SHOULD be rounded up to 1 second.

         Traditionally, TCP implementations use coarse grain clocks to
         measure the RTT and trigger the RTO, which imposes a large
         minimum value on the RTO.  Research suggests that a large
         minimum RTO is needed to keep TCP conservative and avoid
         spurious retransmissions [<a href="#ref-AP99" title="&quot;On Estimating End-to-End Network Path Properties&quot;">AP99</a>].  Therefore, this specification
         requires a large minimum RTO as a conservative approach, while




<span class="grey">Paxson, et al.               Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


         at the same time acknowledging that at some future point,
         research may show that a smaller minimum RTO is acceptable or
         superior.

   (2.5) A maximum value MAY be placed on RTO provided it is at least 60
         seconds.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Taking RTT Samples</span>

   TCP MUST use Karn's algorithm [<a href="#ref-KP87" title="&quot;Improving Round-Trip Time Estimates in Reliable Transport Protocols&quot;">KP87</a>] for taking RTT samples.  That
   is, RTT samples MUST NOT be made using segments that were
   retransmitted (and thus for which it is ambiguous whether the reply
   was for the first instance of the packet or a later instance).  The
   only case when TCP can safely take RTT samples from retransmitted
   segments is when the TCP timestamp option [<a href="#ref-JBB92" title="&quot;TCP Extensions for High Performance&quot;">JBB92</a>] is employed, since
   the timestamp option removes the ambiguity regarding which instance
   of the data segment triggered the acknowledgment.

   Traditionally, TCP implementations have taken one RTT measurement at
   a time (typically, once per RTT).  However, when using the timestamp
   option, each ACK can be used as an RTT sample.  <a href="./rfc1323">RFC 1323</a> [<a href="#ref-JBB92" title="&quot;TCP Extensions for High Performance&quot;">JBB92</a>]
   suggests that TCP connections utilizing large congestion windows
   should take many RTT samples per window of data to avoid aliasing
   effects in the estimated RTT.  A TCP implementation MUST take at
   least one RTT measurement per RTT (unless that is not possible per
   Karn's algorithm).

   For fairly modest congestion window sizes, research suggests that
   timing each segment does not lead to a better RTT estimator [<a href="#ref-AP99" title="&quot;On Estimating End-to-End Network Path Properties&quot;">AP99</a>].
   Additionally, when multiple samples are taken per RTT, the alpha and
   beta defined in <a href="#section-2">Section 2</a> may keep an inadequate RTT history.  A
   method for changing these constants is currently an open research
   question.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Clock Granularity</span>

   There is no requirement for the clock granularity G used for
   computing RTT measurements and the different state variables.
   However, if the K*RTTVAR term in the RTO calculation equals zero, the
   variance term MUST be rounded to G seconds (i.e., use the equation
   given in step 2.3).

       RTO &lt;- SRTT + max (G, K*RTTVAR)

   Experience has shown that finer clock granularities (&lt;= 100 msec)
   perform somewhat better than coarser granularities.





<span class="grey">Paxson, et al.               Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


   Note that [<a href="#ref-Jac88" title="&quot;Congestion Avoidance and Control&quot;">Jac88</a>] outlines several clever tricks that can be used to
   obtain better precision from coarse granularity timers.  These
   changes are widely implemented in current TCP implementations.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Managing the RTO Timer</span>

   An implementation MUST manage the retransmission timer(s) in such a
   way that a segment is never retransmitted too early, i.e., less than
   one RTO after the previous transmission of that segment.

   The following is the RECOMMENDED algorithm for managing the
   retransmission timer:

   (5.1) Every time a packet containing data is sent (including a
         retransmission), if the timer is not running, start it running
         so that it will expire after RTO seconds (for the current value
         of RTO).

   (5.2) When all outstanding data has been acknowledged, turn off the
         retransmission timer.

   (5.3) When an ACK is received that acknowledges new data, restart the
         retransmission timer so that it will expire after RTO seconds
         (for the current value of RTO).

   When the retransmission timer expires, do the following:

   (5.4) Retransmit the earliest segment that has not been acknowledged
         by the TCP receiver.

   (5.5) The host MUST set RTO &lt;- RTO * 2 ("back off the timer").  The
         maximum value discussed in (2.5) above may be used to provide
         an upper bound to this doubling operation.

   (5.6) Start the retransmission timer, such that it expires after RTO
         seconds (for the value of RTO after the doubling operation
         outlined in 5.5).

   (5.7) If the timer expires awaiting the ACK of a SYN segment and the
         TCP implementation is using an RTO less than 3 seconds, the RTO
         MUST be re-initialized to 3 seconds when data transmission
         begins (i.e., after the three-way handshake completes).

         This represents a change from the previous version of this
         document [<a href="#ref-PA00" title="&quot;Computing TCP's Retransmission Timer&quot;">PA00</a>] and is discussed in <a href="#appendix-A">Appendix A</a>.






<span class="grey">Paxson, et al.               Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


   Note that after retransmitting, once a new RTT measurement is
   obtained (which can only happen when new data has been sent and
   acknowledged), the computations outlined in <a href="#section-2">Section 2</a> are performed,
   including the computation of RTO, which may result in "collapsing"
   RTO back down after it has been subject to exponential back off (rule
   5.5).

   Note that a TCP implementation MAY clear SRTT and RTTVAR after
   backing off the timer multiple times as it is likely that the current
   SRTT and RTTVAR are bogus in this situation.  Once SRTT and RTTVAR
   are cleared, they should be initialized with the next RTT sample
   taken per (2.2) rather than using (2.3).

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   This document requires a TCP to wait for a given interval before
   retransmitting an unacknowledged segment.  An attacker could cause a
   TCP sender to compute a large value of RTO by adding delay to a timed
   packet's latency, or that of its acknowledgment.  However, the
   ability to add delay to a packet's latency often coincides with the
   ability to cause the packet to be lost, so it is difficult to see
   what an attacker might gain from such an attack that could cause more
   damage than simply discarding some of the TCP connection's packets.

   The Internet, to a considerable degree, relies on the correct
   implementation of the RTO algorithm (as well as those described in
   <a href="./rfc5681">RFC 5681</a>) in order to preserve network stability and avoid congestion
   collapse.  An attacker could cause TCP endpoints to respond more
   aggressively in the face of congestion by forging acknowledgments for
   segments before the receiver has actually received the data, thus
   lowering RTO to an unsafe value.  But to do so requires spoofing the
   acknowledgments correctly, which is difficult unless the attacker can
   monitor traffic along the path between the sender and the receiver.
   In addition, even if the attacker can cause the sender's RTO to reach
   too small a value, it appears the attacker cannot leverage this into
   much of an attack (compared to the other damage they can do if they
   can spoof packets belonging to the connection), since the sending TCP
   will still back off its timer in the face of an incorrectly
   transmitted packet's loss due to actual congestion.

   The security considerations in <a href="./rfc5681">RFC 5681</a> [<a href="#ref-APB09" title="&quot;TCP Congestion Control&quot;">APB09</a>] are also applicable
   to this document.









<span class="grey">Paxson, et al.               Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Changes from <a href="./rfc2988">RFC 2988</a></span>

   This document reduces the initial RTO from the previous 3 seconds
   [<a href="#ref-PA00" title="&quot;Computing TCP's Retransmission Timer&quot;">PA00</a>] to 1 second, unless the SYN or the ACK of the SYN is lost, in
   which case the default RTO is reverted to 3 seconds before data
   transmission begins.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgments</span>

   The RTO algorithm described in this memo was originated by Van
   Jacobson in [<a href="#ref-Jac88" title="&quot;Congestion Avoidance and Control&quot;">Jac88</a>].

   Much of the data that motivated changing the initial RTO from 3
   seconds to 1 second came from Robert Love, Andre Broido, and Mike
   Belshe.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-APB09">APB09</a>] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
           Control", <a href="./rfc5681">RFC 5681</a>, September 2009.

   [<a id="ref-Bra89">Bra89</a>] Braden, R., Ed., "Requirements for Internet Hosts -
           Communication Layers", STD 3, <a href="./rfc1122">RFC 1122</a>, October 1989.

   [<a id="ref-Bra97">Bra97</a>] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-JBB92">JBB92</a>] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for
           High Performance", <a href="./rfc1323">RFC 1323</a>, May 1992.

   [<a id="ref-Pos81">Pos81</a>] Postel, J., "Transmission Control Protocol", STD 7, <a href="./rfc793">RFC 793</a>,
           September 1981.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-AP99">AP99</a>]  Allman, M. and V. Paxson, "On Estimating End-to-End Network
           Path Properties", SIGCOMM 99.

   [<a id="ref-Chu09">Chu09</a>] Chu, J., "Tuning TCP Parameters for the 21st Century",
           <a href="http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf">http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf</a>, July
           2009.

   [<a id="ref-SLS09">SLS09</a>] Schulman, A., Levin, D., and Spring, N., "CRAWDAD data set
           umd/sigcomm2008 (v. 2009-03-02)",
           <a href="http://crawdad.cs.dartmouth.edu/umd/sigcomm2008">http://crawdad.cs.dartmouth.edu/umd/sigcomm2008</a>, March, 2009.




<span class="grey">Paxson, et al.               Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


   [<a id="ref-HKA04">HKA04</a>] Henderson, T., Kotz, D., and Abyzov, I., "CRAWDAD trace
           dartmouth/campus/tcpdump/fall03 (v. 2004-11-09)",
           <a href="http://crawdad.cs.dartmouth.edu/dartmouth/campus/tcpdump/fall03">http://crawdad.cs.dartmouth.edu/dartmouth/campus/</a>
           <a href="http://crawdad.cs.dartmouth.edu/dartmouth/campus/tcpdump/fall03">tcpdump/fall03</a>, November 2004.

   [<a id="ref-Jac88">Jac88</a>] Jacobson, V., "Congestion Avoidance and Control", Computer
           Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
           1988.

   [<a id="ref-JK88">JK88</a>]  Jacobson, V. and M. Karels, "Congestion Avoidance and
           Control", <a href="ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z">ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z</a>.

   [<a id="ref-KP87">KP87</a>]  Karn, P. and C. Partridge, "Improving Round-Trip Time
           Estimates in Reliable Transport Protocols", SIGCOMM 87.

   [<a id="ref-PA00">PA00</a>]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
           Timer", <a href="./rfc2988">RFC 2988</a>, November 2000.


































<span class="grey">Paxson, et al.               Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Rationale for Lowering the Initial RTO</span>

   Choosing a reasonable initial RTO requires balancing two competing
   considerations:

   1. The initial RTO should be sufficiently large to cover most of the
      end-to-end paths to avoid spurious retransmissions and their
      associated negative performance impact.

   2. The initial RTO should be small enough to ensure a timely recovery
      from packet loss occurring before an RTT sample is taken.

   Traditionally, TCP has used 3 seconds as the initial RTO [<a href="#ref-Bra89" title="&quot;Requirements for Internet Hosts - Communication Layers&quot;">Bra89</a>]
   [<a href="#ref-PA00" title="&quot;Computing TCP's Retransmission Timer&quot;">PA00</a>].  This document calls for lowering this value to 1 second
   using the following rationale:

   - Modern networks are simply faster than the state-of-the-art was at
     the time the initial RTO of 3 seconds was defined.

   - Studies have found that the round-trip times of more than 97.5% of
     the connections observed in a large scale analysis were less than 1
     second [<a href="#ref-Chu09" title="&quot;Tuning TCP Parameters for the 21st Century&quot;">Chu09</a>], suggesting that 1 second meets criterion 1 above.

   - In addition, the studies observed retransmission rates within the
     three-way handshake of roughly 2%.  This shows that reducing the
     initial RTO has benefit to a non-negligible set of connections.

   - However, roughly 2.5% of the connections studied in [<a href="#ref-Chu09" title="&quot;Tuning TCP Parameters for the 21st Century&quot;">Chu09</a>] have an
     RTT longer than 1 second.  For those connections, a 1 second
     initial RTO guarantees a retransmission during connection
     establishment (needed or not).

     When this happens, this document calls for reverting to an initial
     RTO of 3 seconds for the data transmission phase.  Therefore, the
     implications of the spurious retransmission are modest: (1) an
     extra SYN is transmitted into the network, and (2) according to <a href="./rfc5681">RFC</a>
     <a href="./rfc5681">5681</a> [<a href="#ref-APB09" title="&quot;TCP Congestion Control&quot;">APB09</a>] the initial congestion window will be limited to 1
     segment.  While (2) clearly puts such connections at a
     disadvantage, this document at least resets the RTO such that the
     connection will not continually run into problems with a short
     timeout.  (Of course, if the RTT is more than 3 seconds, the
     connection will still encounter difficulties.  But that is not a
     new issue for TCP.)

     In addition, we note that when using timestamps, TCP will be able
     to take an RTT sample even in the presence of a spurious
     retransmission, facilitating convergence to a correct RTT estimate
     when the RTT exceeds 1 second.



<span class="grey">Paxson, et al.               Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


   As an additional check on the results presented in [<a href="#ref-Chu09" title="&quot;Tuning TCP Parameters for the 21st Century&quot;">Chu09</a>], we
   analyzed packet traces of client behavior collected at four different
   vantage points at different times, as follows:

   Name       Dates            Pkts.   Cnns.  Clnts. Servs.
   --------------------------------------------------------
   LBL-1      Oct/05--Mar/06   292M    242K   228    74K
   LBL-2      Nov/09--Feb/10   1.1B    1.2M   1047   38K
   ICSI-1     Sep/11--18/07    137M    2.1M   193    486K
   ICSI-2     Sep/11--18/08    163M    1.9M   177    277K
   ICSI-3     Sep/14--21/09    334M    3.1M   170    253K
   ICSI-4     Sep/11--18/10    298M    5M     183    189K
   Dartmouth  Jan/4--21/04     1B      4M     3782   132K
   SIGCOMM    Aug/17--21/08    11.6M   133K   152    29K

   The "LBL" data was taken at the Lawrence Berkeley National
   Laboratory, the "ICSI" data from the International Computer Science
   Institute, the "SIGCOMM" data from the wireless network that served
   the attendees of SIGCOMM 2008, and the "Dartmouth" data was collected
   from Dartmouth College's wireless network.  The latter two datasets
   are available from the CRAWDAD data repository [<a href="#ref-HKA04" title="&quot;CRAWDAD trace dartmouth/campus/tcpdump/fall03 (v. 2004-11-09)&quot;">HKA04</a>] [<a href="#ref-SLS09" title="&quot;CRAWDAD data set umd/sigcomm2008 (v. 2009-03-02)&quot;">SLS09</a>].  The
   table lists the dates of the data collections, the number of packets
   collected, the number of TCP connections observed, the number of
   local clients monitored, and the number of remote servers contacted.
   We consider only connections initiated near the tracing vantage
   point.

   Analysis of these datasets finds the prevalence of retransmitted SYNs
   to be between 0.03% (ICSI-4) to roughly 2% (LBL-1 and Dartmouth).

   We then analyzed the data to determine the number of additional and
   spurious retransmissions that would have been incurred if the initial
   RTO was assumed to be 1 second.  In most of the datasets, the
   proportion of connections with spurious retransmits was less than
   0.1%.  However, in the Dartmouth dataset, approximately 1.1% of the
   connections would have sent a spurious retransmit with a lower
   initial RTO.  We attribute this to the fact that the monitored
   network is wireless and therefore susceptible to additional delays
   from RF effects.

   Finally, there are obviously performance benefits from retransmitting
   lost SYNs with a reduced initial RTO.  Across our datasets, the
   percentage of connections that retransmitted a SYN and would realize
   at least a 10% performance improvement by using the smaller initial
   RTO specified in this document ranges from 43% (LBL-1) to 87%
   (ICSI-4).  The percentage of connections that would realize at least
   a 50% performance improvement ranges from 17% (ICSI-1 and SIGCOMM) to
   73% (ICSI-4).



<span class="grey">Paxson, et al.               Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6298">RFC 6298</a>          Computing TCP's Retransmission Timer         June 2011</span>


   From the data to which we have access, we conclude that the lower
   initial RTO is likely to be beneficial to many connections, and
   harmful to relatively few.

   Authors' Addresses

   Vern Paxson
   ICSI/UC Berkeley
   1947 Center Street
   Suite 600
   Berkeley, CA 94704-1198

   Phone: 510-666-2882
   EMail: vern@icir.org
   <a href="http://www.icir.org/vern/">http://www.icir.org/vern/</a>


   Mark Allman
   ICSI
   1947 Center Street
   Suite 600
   Berkeley, CA 94704-1198

   Phone: 440-235-1792
   EMail: mallman@icir.org
   <a href="http://www.icir.org/mallman/">http://www.icir.org/mallman/</a>


   H.K. Jerry Chu
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA 94043

   Phone: 650-253-3010
   EMail: hkchu@google.com


   Matt Sargent
   Case Western Reserve University
   Olin Building
   10900 Euclid Avenue
   Room 505
   Cleveland, OH 44106

   Phone: 440-223-5932
   EMail: mts71@case.edu





Paxson, et al.               Standards Track                   [Page 11]
</pre>