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

Matt Olson <maolson@microsoft.com> Wed, 17 April 2019 18:52 UTC

Return-Path: <maolson@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 D861412037D for <tcpm@ietfa.amsl.com>; Wed, 17 Apr 2019 11:52:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QvCOEpY9IzoW for <tcpm@ietfa.amsl.com>; Wed, 17 Apr 2019 11:52:16 -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 6D6AB1200A3 for <tcpm@ietf.org>; Wed, 17 Apr 2019 11:52:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=mMuCgXVbqzFQg15MZcBEkyhDDKXQlV/2vKF1sa/4zsA6BZ5Tbhc932T4VKNN7pJdBYRnQ0G9Q9uTRS+ZwmOIJ1ieztrcbSM+YE2ksM0J2z2l8GI5tLlcLvDzmLoz9hJV30kcWFC+akSXisndyd6TipT5Yfn0u4tJzotDk590V9yN9r7azLJYzRaIinB8MCtHVa++IKC5DuHqfI3upAd4L7a3mhsYDr+u0rdiNzuYZgUlcXphgDvEIXwmrASsaIJqxOlXz9OF4V9PUtKTrGiIKLl+N3RLRSZj1mWEzWE8KvYP/Mqodf5xaohFhJ0X2QccoY5IRATh93a9EQivSeWBzA==
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=l1FIqbahlHvjT8uvIlKO1cyeVeYVy6QDZ33GC56C8ww=; b=nduv4ERVCFyqBAK+6bbhfztsg7czCEvblbeCTcAKDY2/WCyZD0+TcRWNDUtws5NWWTY6+UcE0cAOoEv3Hp0Dvw0oiARiPf4VtI3WS5w0IK+eKUExOA70jR6ReCA8EwZNds65SkTBP24ZEr5OfI9od8CosCpgeejs5i21x5YntGmrRZaoP5K7IgWNSKn5/XAgjVMnq4VvK2MPsE/2EFzlvjOemNGILwJGdZyi+lJWnlrxWQ+Gl11kT0WjUX7CrO4PGVuUfIZeLBP69nOcqqzHYE/XH8bT6jZYDgGbC9n/v7LmjZK7o5JHtzR+8JyCohX1otIVu9xv5ipXktwYra1iCA==
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=l1FIqbahlHvjT8uvIlKO1cyeVeYVy6QDZ33GC56C8ww=; b=ZixImEyYTTC82hcaS1BtPhug2MoE/gEkjPRzUrjXUadl01F8Y7xO4gn1aN2bJhMjSkycfwZ2mUtDDky4ARVGtJ93JIw0A/47j/xDMEqKC37iFAFKREsNe6cD1FzFeuecc4ZWkhDReziD3tscoNbLr4WYXkBOhjfh/zdH82Lx3s8=
Received: from BYAPR21MB1256.namprd21.prod.outlook.com (20.179.57.160) by BYAPR21MB1334.namprd21.prod.outlook.com (20.179.60.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.2; Wed, 17 Apr 2019 18:52:15 +0000
Received: from BYAPR21MB1256.namprd21.prod.outlook.com ([fe80::a4a4:9084:90b3:f89d]) by BYAPR21MB1256.namprd21.prod.outlook.com ([fe80::a4a4:9084:90b3:f89d%9]) with mapi id 15.20.1835.003; Wed, 17 Apr 2019 18:52:15 +0000
From: Matt Olson <maolson@microsoft.com>
To: hiren panchasara <hiren@strugglingcoder.info>, Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] A question about PTO/RTO rescheduling in RACK draft
Thread-Index: AdT0v450DAV7LlJPShaJ9NxD6aYmRAAibyEAAADFGxA=
Date: Wed, 17 Apr 2019 18:52:14 +0000
Message-ID: <BYAPR21MB12568E60F973DB41C4905D8EBC250@BYAPR21MB1256.namprd21.prod.outlook.com>
References: <BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250@BL0PR2101MB1043.namprd21.prod.outlook.com> <20190417181344.GM31257@strugglingcoder.info>
In-Reply-To: <20190417181344.GM31257@strugglingcoder.info>
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=maolson@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-17T18:52:13.6932571Z; 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=f017d8d7-0615-48d3-909a-0b8cfa969d3a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=maolson@microsoft.com;
x-originating-ip: [2001:4898:80e8:1:a0b8:a831:97ff:692b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 78e49b04-6c72-4a66-7943-08d6c365cef9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR21MB1334;
x-ms-traffictypediagnostic: BYAPR21MB1334:
x-microsoft-antispam-prvs: <BYAPR21MB13341BBE22A2D87C65F479C9BC250@BYAPR21MB1334.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(366004)(346002)(376002)(13464003)(189003)(199004)(55016002)(33656002)(478600001)(9686003)(86362001)(53936002)(10090500001)(102836004)(86612001)(6246003)(186003)(76176011)(7696005)(14444005)(105586002)(256004)(99286004)(11346002)(5660300002)(6506007)(14454004)(476003)(74316002)(8936002)(8676002)(53546011)(305945005)(81166006)(68736007)(6116002)(52536014)(106356001)(22452003)(7736002)(6436002)(446003)(81156014)(46003)(2906002)(71200400001)(229853002)(25786009)(97736004)(4326008)(486006)(71190400001)(316002)(10290500003)(8990500004)(110136005)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR21MB1334; H:BYAPR21MB1256.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: 5bkkhJj2w2b+GLrI+Z9Lw8V/jaDNqpUq0ett7grR64SVR99+EFFiAk/4N+YMCBriv+rWHAEukyuU/F6ewPWBhIfPlMkFPz6r4TI+Wg2CsvKwOs1zPJnDqKyQkeZo19nbLWFrnTdXnjiWVUqJm6mPMEENicwKRVjV/gGXaHS2WAADrDmmRxccUNqaPMqMBe6oeCgIYPPqqOFT+8+IJqdpJ3bj5LpfqohSy3fGIOEOJolvs4ohw2pdt3DiuklehqgQr1FZeHHOvILkyaXVp/zQ9laZmGpuQZ9D4suPtu/5Xsb6nKIQfF8phjufFpJRMi4p8d6RraYBAzId3dhIG2ar9kGfVHhXqBHT7iqozK7X3OH+nm4qVctDCRfODdKpXt1r8qWI6FosbNOcOH8hqI5Pv0Kpp8u0rsMcVcJt9bZrBMA=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78e49b04-6c72-4a66-7943-08d6c365cef9
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 18:52:14.9074 (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: BYAPR21MB1334
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/0Wy-P8vyEC4OUagyp40PkYDBZoE>
X-Mailman-Approved-At: Thu, 18 Apr 2019 09:46:11 -0700
Subject: Re: [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 18:52:19 -0000

Previously, you'd start the RTO timer on the first packet, and the timer would run until an ACK was received. Now, the timer is reset on each new packet. So the concern is that there exist cases where previously TCP would reduce the CWnd and retransmit, but not anymore.

If all such cases are app-limited cases, then I like Hiren's point about this being a "keep CWnd in check while app-limited" problem. 

-----Original Message-----
From: hiren panchasara <hiren@strugglingcoder.info>; 
Sent: Wednesday, April 17, 2019 11:14 AM
To: Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>;
Cc: tcpm@ietf.org; Matt Olson <maolson@microsoft.com>;
Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft

On 04/17/19 at 01:48P, Yi Huang wrote:
> Hi,

Hi!
I don't see anything inherently wrong in how this works or I am missing something.
> 
> 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?
By growing CWND, TCP has decided that it is okay to send that much without needing an ACK.
I think something along the lines of detecting that connection is app-limited OR doing newcwv like validation may help to keep CWND in check?

> What is the intention of pushing out the timer for each send?
6.5.1 (Step 1) indicated a few conditions for scheduling PTO (i.e.
pushing out the timer) so its not blindly doing for each send. But it would do that for the case you described as app *is* handing new data to be sent to TCP.

>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.
I am probably not understanding something. I think you are saying TLP is causing RTO to be pushed out unnecessarily.

One cannot schedule PTO when a TLP is out. So, on first timeout i.e. PTO as we prefer that over RTO, you send a TLP out. And if you don't get an ACK back for that, next timeout would be an RTO as 6.5.1.  Phase 1 condition 1 suggests.

But if there is new data to be sent, RTO would also gets pushed out, no?
> 
> 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.

I am not sure I follow. For the connection, you need a timeout mechanism. And RACK draft suggests keeping PTO aligned with RTO as the former is less expensive. Try PTO and if it doesn't work, do RTO.

I believe the wordings around "first cancel the pending one and then only schedule new one" are for clarity around implementation details.
Gist is to not keep 2 sets of timers running for the same timeout mechanism. 

Someone with more clue on the list would probably correct me. :-) Cheers, Hiren