[rfc-dist] RFC 5682 on Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP

rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Thu, 01 October 2009 00:10 UTC

From: "rfc-editor at rfc-editor.org"
Date: Wed, 30 Sep 2009 17:10:35 -0700
Subject: [rfc-dist] RFC 5682 on Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP
Message-ID: <20091001001035.2BE8D33319B@bosco.isi.edu>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5682

        Title:      Forward RTO-Recovery (F-RTO): An Algorithm 
                    for Detecting Spurious Retransmission Timeouts with 
                    TCP 
        Author:     P. Sarolahti, M. Kojo,
                    K. Yamamoto, M. Hata
        Status:     Standards Track
        Date:       September 2009
        Mailbox:    pasi.sarolahti at iki.fi, 
                    kojo at cs.helsinki.fi, 
                    yamamotokaz at nttdocomo.co.jp,
                    hatama at s1.nttdocomo.co.jp
        Pages:      19
        Characters: 47337
        Updates:    RFC4138

        I-D Tag:    draft-ietf-tcpm-rfc4138bis-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5682.txt

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.  [STANDARDS TRACK]

This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: 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.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute