[tcpm] F-RTO and RFC 3517 interaction issues

Murari Sridharan <muraris@microsoft.com> Mon, 10 March 2008 17:17 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 4CB1F3A7020; Mon, 10 Mar 2008 10:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.917
X-Spam-Status: No, score=-104.917 tagged_above=-999 required=5 tests=[AWL=-5.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id zhFK725y2DX6; Mon, 10 Mar 2008 10:17:25 -0700 (PDT)
Received: from core3.amsl.com (localhost []) by core3.amsl.com (Postfix) with ESMTP id 7649728C403; Mon, 10 Mar 2008 10:12:34 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 59A9928C402 for <tcpm@core3.amsl.com>; Mon, 10 Mar 2008 10:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Mr6s8CRmx-QB for <tcpm@core3.amsl.com>; Mon, 10 Mar 2008 10:12:24 -0700 (PDT)
Received: from smtp.microsoft.com (mail1.microsoft.com []) by core3.amsl.com (Postfix) with ESMTP id 8C45428C467 for <tcpm@ietf.org>; Mon, 10 Mar 2008 10:08:30 -0700 (PDT)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com ( by TK5-EXGWY-E801.partners.extranet.microsoft.com ( with Microsoft SMTP Server (TLS) id; Mon, 10 Mar 2008 10:06:15 -0700
Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([]) by tk1-exhub-c104.redmond.corp.microsoft.com ([]) with mapi; Mon, 10 Mar 2008 10:05:49 -0700
From: Murari Sridharan <muraris@microsoft.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>, "pasi.sarolahti@nokia.com" <pasi.sarolahti@nokia.com>, "mallman@icir.org" <mallman@icir.org>
Date: Mon, 10 Mar 2008 10:05:46 -0700
Thread-Topic: F-RTO and RFC 3517 interaction issues
Thread-Index: AciC0PuvPI3Il/LvTdqfSHmLW8eJPA==
Message-ID: <FCA794787FDE0D4DBE9FFA11053ECEB60C7947458E@NA-EXMSG-C110.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [tcpm] F-RTO and RFC 3517 interaction issues
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0821736021=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

I am seeing an inconsistency between FRTO and RFC 3517. May be the authors could clarify.

F-RTO defines recovery as follows

Set variable "recover" to
      indicate the highest segment transmitted so far.

RFC 3517 defines

"HighData" is the highest sequence number transmitted at a given


RFC 3517 clearly mandates that if RTO occurs during loss recovery new recovery phase MUST not be initiated until the RecoveryPoint is crossed.

"If an RTO occurs during loss recovery as specified in this document,

   RecoveryPoint MUST be set to HighData.  Further, the new value of

   RecoveryPoint MUST be preserved and the loss recovery algorithm

   outlined in this document MUST be terminated.  In addition, a new

   recovery phase (as described in section 5) MUST NOT be initiated

   until HighACK is greater than or equal to the new value of


Now FRTO spec seems to violate the above rule with the following statement

If the algorithm exits with

   SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus

   allowing fast recovery on incoming duplicate acknowledgments.

This means that if we are in the middle of loss recovery and a real timeout occurs we save the recovery point per RFC 3517. At this point we continue with slow start and congestion avoidance, now say we are still below the earlier recovery point and a new timeout occurs. This time if the timeout is classified as SPUR_TO, then RecoveryPoint is set to SndUNA, overwriting the older value and a new recovery phase can begin, clearly violating RFC 3517.


tcpm mailing list