RFC 3042 (rfc3042) - Page 2 of 9

Enhancing TCP's Loss Recovery Using Limited Transmit

RFC 3042              Enhancing TCP Loss Recovery           January 2001


   First, if an acknowledgment (ACK) for a given segment is not received
   in a certain amount of time a retransmission timeout occurs and the
   segment is resent [RFC 793,PA00].  Second, the "Fast Retransmit"
   algorithm resends a segment when three duplicate ACKs arrive at the
   sender [Jac88,RFC 2581].  However, because duplicate ACKs from the
   receiver are also triggered by packet reordering in the Internet, the
   TCP sender waits for three duplicate ACKs in an attempt to
   disambiguate segment loss from packet reordering.  Once in a loss
   recovery phase, a number of techniques can be used to retransmit lost
   segments, including slow start-based recovery or Fast Recovery
   [RFC 2581], NewReno [RFC 2582], and loss recovery based on selective
   acknowledgments (SACKs) [RFC 2018,FF96].

   TCP's retransmission timeout (RTO) is based on measured round-trip
   times (RTT) between the sender and receiver, as specified in [PA00].
   To prevent spurious retransmissions of segments that are only delayed
   and not lost, the minimum RTO is conservatively chosen to be 1
   second.  Therefore, it behooves TCP senders to detect and recover
   from as many losses as possible without incurring a lengthy timeout
   when the connection remains idle.  However, if not enough duplicate
   ACKs arrive from the receiver, the Fast Retransmit algorithm is never
   triggered---this situation occurs when the congestion window is small
   or if a large number of segments in a window are lost.  For instance,
   consider a congestion window (cwnd) of three segments.  If one
   segment is dropped by the network, then at most two duplicate ACKs
   will arrive at the sender.  Since three duplicate ACKs are required
   to trigger Fast Retransmit, a timeout will be required to resend the
   dropped packet.

   [BPS+97] found that roughly 56% of retransmissions sent by a busy web
   server were sent after the RTO expires, while only 44% were handled
   by Fast Retransmit.  In addition, only 4% of the RTO-based
   retransmissions could have been avoided with SACK, which of course
   has to continue to disambiguate reordering from genuine loss.  In
   contrast, using the technique outlined in this document and in
   [Bal98], 25% of the RTO-based retransmissions in that dataset would
   have likely been avoided.

   The next section of this document outlines small changes to TCP
   senders that will decrease the reliance on the retransmission timer,
   and thereby improve TCP performance when Fast Retransmit is not
   triggered.  These changes do not adversely affect the performance of
   TCP nor interact adversely with other connections, in other
   circumstances.







Allman, et al.              Standards Track