Re: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc4138bis-00.txt

Pasi Sarolahti <> Wed, 13 June 2007 16:08 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HyVOr-0002Sj-0H; Wed, 13 Jun 2007 12:08:49 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HyVOp-0002Se-Qa for; Wed, 13 Jun 2007 12:08:47 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1HyVOo-0003s1-V1 for; Wed, 13 Jun 2007 12:08:47 -0400
Received: from ( []) by (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5DG8PhQ016352 for <>; Wed, 13 Jun 2007 19:08:45 +0300
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:08:40 +0300
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:08:40 +0300
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:08:40 +0300
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <>
References: <>
Message-Id: <>
From: Pasi Sarolahti <>
Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc4138bis-00.txt
Date: Wed, 13 Jun 2007 19:07:31 +0300
X-Pgp-Agent: GPGMail 1.1.2 (Tiger)
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 13 Jun 2007 16:08:40.0606 (UTC) FILETIME=[1B99EBE0:01C7ADD5]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1076952673=="


In few past IETFs there there have been requests to advance F-RTO  
from Experimental to Proposed Standard. F-RTO was discussed in Prague  
in the tcpm meeting and also mentioned in the tsv-area presentation  
on Windows Vista TCP features, where advancement of F-RTO was  
supported by the presenters. Therefore, to go forward with this  
process we have submitted this draft, which is based on RFC 4138 with  
the following diffs:

     * Removed description of the SACK-enhanced algorithm
     * Removed SCTP considerations
     * Removed earlier Appendix sections, except Appendix C from RFC  
4138, which is now Appendix A
     * Clarified text about the possible response algorithms
     * Added section that summarizes the evaluation of RFC 4138

Related to the last point, there is a companion draft titled  
"Evaluation of RFC 4138" available at 
draft-kojo-tcpm-frto-eval-00.txt , that aims to evaluate the benefits  
and possible problems with F-RTO. This draft also refers to the  
papers about F-RTO if anyone is interested to have further reading.

The reason for removing SACK and SCTP sections is that although the  
basic F-RTO has been implemented in a number of systems, we feel that  
there are no sufficient experimental experience with these variants,  
so they could be left out from the Proposed Standard document.

Please give feedback about the above-mentioned changes or anything  
else related to draft. We are also looking for comments/guidance on  
how to move forward with the draft.

Many thanks,
- Pasi

PS. I will be on summer holidays starting from this weekend and will  
not be able myself to read mails very actively, but the co-authors  
should be available to take part in any follow-up discussion on the  

On Jun 12, 2007, at 22:50, ext wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the TCP Maintenance and Minor  
> Extensions Working Group of the IETF.
> 	Title		: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting  
> Spurious Retransmission Timeouts with TCP
> 	Author(s)	: P. Sarolahti, et al.
> 	Filename	: draft-ietf-tcpm-rfc4138bis-00.txt
> 	Pages		: 17
> 	Date		: 2007-6-12
>     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.   
>     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.
> A URL for this Internet-Draft is:
> To remove yourself from the I-D Announcement list, send a message to
> with the word unsubscribe in the body of
> the message.
> You can also visit
> to change your subscription settings.
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-tcpm-rfc4138bis-00.txt".
> A list of Internet-Drafts directories can be found in
> or
> Internet-Drafts can also be obtained by e-mail.
> Send a message to:
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-tcpm-rfc4138bis-00.txt".
> NOTE:	The mail server at can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <>
> _______________________________________________
> tcpm mailing list

tcpm mailing list