[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhFK725y2DX6; Mon, 10 Mar 2008 10:17:25 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) 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 [127.0.0.1]) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [131.107.115.212]) 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 (157.54.46.188) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 10 Mar 2008 10:06:15 -0700
Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.54.46.188]) 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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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 point. 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 RecoveryPoint." 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. Thanks Murari
_______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] F-RTO and RFC 3517 interaction issues Murari Sridharan
- Re: [tcpm] F-RTO and RFC 3517 interaction issues Pasi Sarolahti
- Re: [tcpm] F-RTO and RFC 3517 interaction issues Murari Sridharan
- Re: [tcpm] F-RTO and RFC 3517 interaction issues Murari Sridharan
- Re: [tcpm] F-RTO and RFC 3517 interaction issues Pasi Sarolahti
- Re: [tcpm] F-RTO and RFC 3517 interaction issues Murari Sridharan