IETF Logo Mail Archive

[tcpm] A question about PTO/RTO rescheduling in RACK draft

Yi Huang <huanyi@microsoft.com> Wed, 17 April 2019 01:48 UTC

Return-Path: <huanyi@microsoft.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658961201A1 for <tcpm@ietfa.amsl.com>; Tue, 16 Apr 2019 18:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viT5zFkFC5RQ for <tcpm@ietfa.amsl.com>; Tue, 16 Apr 2019 18:48:05 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690116.outbound.protection.outlook.com [40.107.69.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71C412015A for <tcpm@ietf.org>; Tue, 16 Apr 2019 18:48:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=We1p6ISzXXqsBSNqHt6dqTUH4vJHCOqzdfot6SBIB6yL3uLGUqsHJAOvvOpSwbgIc+3ufUzMdcWqOQGmWUgRzknPhZHZgSI56h07gC8LTHoy4D6T71xoFeflHm0V6vE8g9uO+yNVaTQQsXNY8wP8GcpzjAD5VDjmaTf3OU8f2RPweRADzka8EFkpSEP0vmdsc7HaTsc8AE0H3B03QNq6p1UhPfyflHUYgBCJQrZgdioO3Y5WijqCwMawn1yfQvuh7DzulTM2ESNEhHAHhWVwS/JaNTAclMDi49OBZjLqDjwG02l7HkEiNJQm8vD8q3juocLeWIPT29skXKzcnmcsNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Buf7kAyQU7bvNp18Qs1vx0AyTOJ+reMNtcPPbMo0OI=; b=qXfKGcG7KRyDp+2XTkJGvI5N5adtwlAo3b75zJcoP7txuyekwwBoHgK+QEsdwElUwdgp61yxdxVWCAvlTrW8L9F/mHwK8NnRUWuhoLTPEgyXQXYfvnEpG3d7ZlRNsgHHMJ3F+641l4iZsQfEMpNgWmvUEMn8VMAwKFfv49m6Ci7STzi2V7tw+87QplAn+7vuxDW1Y+G7Gh6R1RLKwwCscF7xDdw/0+dyyC5cXcCYIUIuMcEkUTuhQdp4/tCECn9H88NKg+tyPnoPp2PkwPx3rlz2Z88wWe+ngEbI57Cakk4yzbwJ/VK/ODwSc11QYJZDOccmM9iywEnIWhH7xn/eLA==
ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Buf7kAyQU7bvNp18Qs1vx0AyTOJ+reMNtcPPbMo0OI=; b=oowqq2xA1rqaUge/QoCRhJAvrV9z+JvFAjulsr0h4RAvH6rAJC9oanB2Ct/Iecy+Y5lTVI0M5lfjG3wKM7Nj9ib75PswruxlJRzZsWHKOOjFq4gw3x9CdO6s4WbgFlCLwAWIKVVRgwUeRdJOFis+BrNcVsZefy6/FbFRghnDTzc=
Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB1042.namprd21.prod.outlook.com (52.132.24.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.1; Wed, 17 Apr 2019 01:48:03 +0000
Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9%8]) with mapi id 15.20.1835.000; Wed, 17 Apr 2019 01:48:03 +0000
From: Yi Huang <huanyi@microsoft.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
CC: Praveen Balasubramanian <pravb@microsoft.com>, Matt Olson <maolson@microsoft.com>
Thread-Topic: A question about PTO/RTO rescheduling in RACK draft
Thread-Index: AdT0v450DAV7LlJPShaJ9NxD6aYmRA==
Date: Wed, 17 Apr 2019 01:48:03 +0000
Message-ID: <BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250@BL0PR2101MB1043.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-17T01:48:01.5391021Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=00d3cf94-4d32-4f59-82ee-607320319143; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com;
x-originating-ip: [2001:4898:80e8:a:90dd:d90c:8727:9001]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b24bacbd-ef04-4826-3a91-08d6c2d6bae2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB1042;
x-ms-traffictypediagnostic: BL0PR2101MB1042:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BL0PR2101MB1042A00DCE0FC4F1AF18BDAAC3250@BL0PR2101MB1042.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(376002)(136003)(396003)(189003)(199004)(25786009)(8990500004)(81166006)(86362001)(74316002)(86612001)(71200400001)(71190400001)(10090500001)(2351001)(9686003)(22452003)(81156014)(1730700003)(106356001)(478600001)(8936002)(256004)(14444005)(14454004)(7736002)(4326008)(8676002)(10290500003)(52536014)(5660300002)(68736007)(9326002)(6116002)(790700001)(33656002)(55016002)(6436002)(2501003)(5640700003)(6916009)(107886003)(6506007)(476003)(54896002)(6306002)(97736004)(2906002)(105586002)(54906003)(316002)(486006)(53936002)(99286004)(7696005)(186003)(102836004)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1042; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: QED+EWv3p4aTCn/1ibZGoqsK4RwHEiu/hTDQyaK09+dKoIvuxsfvCG8GIgpwRskeYZpSC0u9uZyNVcIhnknwDYnZNbMurwcFXl5nyh0CFlg1A5ZM+EWS0ac7pomU/UC1lHGGN+3j9d0OhdvRRvKczSezeEW0yXmUexpRXS0B3RzMfW7ztHeMA9qStAGQ+DKZNGMXm01L1oacEEM6axIU84sSle+b0snka3LcmJvigDM2geyvtY8hqLxOsjyYTRd5Ko6KaNPnKI3oZe/JzCBR6gaKyq0UbKxksQXzQqCd9lRFByE1yk3PmTmw1/+FTsFJ1wAuBtvbvkxaoVcissUfi0nzvmltI08Qj1HnSdGTM9EY1kyEfMq2niL10TkBeo/YgKzRO78rH7M2uIr4j4aKkS6miakAVpgmD2h8juFKaN4=
Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250BL0PR2101MB1043_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b24bacbd-ef04-4826-3a91-08d6c2d6bae2
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 01:48:03.2053 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1042
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/rijyUVumxvoEwEHvOEzftPgHY9s>
Subject: [tcpm] A question about PTO/RTO rescheduling in RACK draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
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>
X-List-Received-Date: Wed, 17 Apr 2019 01:48:07 -0000

Hi,

I have a question about PTO/RTO rescheduling logic in RACK draft. The draft states, in Section 6.5.1, "If there was a previously scheduled PTO or RTO pending, then that pending PTO or RTO should first be cancelled, and then the new PTO should be scheduled". So if an app keeps posting data in an interval less than PTO and RTO (say one byte each time and Cwnd is large enough) and no acks are coming back due to network failures or a receiver that just does not send anything back, the app will never fires RTO since the timer is pushed out each time we send this one byte data. Is this a problem? What is the intention of pushing out the timer for each send? I think in this case the sender should disconnect the connection because, without TLP, the sender would have had several RTOs and closed the connection.

Also, RFC 6298 Section 5 (5.1) states "Every time a packet containing data is sent (including a retransmission), if the timer is not running, start it running so that it will expire after RTO seconds (for the current value of RTO).", which says TCP should schedule timer only when it is not schedule yet and this kind of conflicts with (or is overridden by) what is in RACK/TLP draft.

Thanks,

Yi Huang

v2.23.0 | Report a Bug | By Email