Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP
RFC 5682

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                       P. Sarolahti
Request for Comments: 5682                         Nokia Research Center
Updates: 4138                                                    M. Kojo
Category: Standards Track                         University of Helsinki
                                                             K. Yamamoto
                                                                 M. Hata
                                                              NTT Docomo
                                                          September 2009

        Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
               Spurious Retransmission Timeouts with TCP

Abstract

   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.

   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.

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Sarolahti, et al.           Standards Track                     [Page 1]
RFC 5682                         F-RTO                    September 2009

Copyright and License Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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 BSD License.

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions and Terminology ................................5
   2. Basic F-RTO Algorithm ...........................................5
      2.1. The Algorithm ..............................................5
      2.2. Discussion .................................................7
   3. SACK-Enhanced Version of the F-RTO Algorithm ....................9
      3.1. The Algorithm ..............................................9
      3.2. Discussion ................................................11
   4. Taking Actions after Detecting Spurious RTO ....................11
   5. Evaluation of RFC 4138 .........................................12
   6. Security Considerations ........................................13
   7. Acknowledgments ................................................14
   Appendix A. Discussion of Window-Limited Cases ....................15
   Appendix B. Changes since RFC 4138 ................................16
   References ........................................................16
      Normative References ...........................................16
      Informative References .........................................17

Sarolahti, et al.           Standards Track                     [Page 2]
RFC 5682                         F-RTO                    September 2009

1.  Introduction

   The Transmission Control Protocol (TCP) [Pos81] has two methods for
   triggering retransmissions.  First, the TCP sender relies on incoming
   duplicate acknowledgments (ACKs), which indicate that the receiver is
   missing some of the data.  After a required number of successive
   duplicate ACKs have arrived at the sender, it retransmits the first
   unacknowledged segment [APB09] and continues with a loss recovery
   algorithm such as NewReno [FHG04] or SACK-based (Selective