Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt

Praveen Balasubramanian <pravb@microsoft.com> Mon, 22 July 2019 22:48 UTC

Return-Path: <pravb@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 1BAB712006B for <tcpm@ietfa.amsl.com>; Mon, 22 Jul 2019 15:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 RbWfGOeYPVIa for <tcpm@ietfa.amsl.com>; Mon, 22 Jul 2019 15:48:33 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820129.outbound.protection.outlook.com [40.107.82.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167F1120094 for <tcpm@ietf.org>; Mon, 22 Jul 2019 15:48:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DnlrRxIZrt4aj5YkyDd24QL6vREk10rrZ+u7I0dXFY0Y14GUgu8nETxv5w0CEoG9DM15S39CxY98q3Uq+5//GGim50bTLbMKLskjiP+OV2ZOzQcaJye4T4z3a15qeFwWRFRajp8g4JCHAl7sdxaSTdADtKCW9AoKCYQccQzLeSfeAcmhVTd3+3y+QPCcBvs7kphqxlNbYIsep74OdX2VleXjvlevGC7IJC9H6MZ5fqwV2+c6KDLmpNYxFI+EutCQzgm9DWWkO5mdDkOELEbLOCQK9HjeSDOVMFgr1wtRc3UW8+ZdwnPQU4Mysd+afjHJ4wXPCQptUkdrYirazYdejw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z+VD19N2s6+xVffEBoyeKDLNB5x+nTc2AdgxZykOW7I=; b=RqEnqd4PrKjPiyMSk8e1oOKAlGf2zC4CYpFKgplPCO688cP/68LX6mLGZadHsSRYXcYraiVxOoqdUySDTJWlzZyKn+iWoHp8107Vv+KH15/psl+HEcCeDrgT/Y63yGdMi9zULlm4eVgpYjB9XgN1HfgMBrJgiK91VEfyENdkD4rZKGiXC+puoS8TAnd98PJt8eR5XRWkRwkmibRolnC7tMou1WCoYRqU9glUfCJzLsXymkS3rOXvYf//7fWQ/pjq24z9LCaaKffW1gVQN1cTZnqKK4Kx3jCieNG5KyvWqu6N7cRbfRzqWTWuD0EPl1XKAfO5TGJKrWMSLyJYJUIyig==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;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=Z+VD19N2s6+xVffEBoyeKDLNB5x+nTc2AdgxZykOW7I=; b=me6rVDrgyNa+MK3d1UoEfRiS+Y1nrXbTzGHfpG+hLCiQAaUqimW0/bCuYdFdEsX4uwTehPcx801TdPK0gH2atatlgl1gbZWr1e604BW6TF2gYBktMYHbHZ6MYkiDkaTHYfszXh3/GJJD2x2BX+TUrwBcRtGIICNiZDDQ9XHYrPc=
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0985.namprd21.prod.outlook.com (52.132.146.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.2; Mon, 22 Jul 2019 22:48:31 +0000
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::b911:fd5d:e7d6:2dab%4]) with mapi id 15.20.2136.000; Mon, 22 Jul 2019 22:48:31 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Neal Cardwell <ncardwell@google.com>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, Matt Olson <maolson@microsoft.com>, Yi Huang <huanyi@microsoft.com>
Thread-Topic: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt
Thread-Index: AQHVNeDXs6wG1Y3E+0uQvV9n53yFv6bBV5MAgAEMkwCAAHXTQIAADLKAgBRsHXA=
Date: Mon, 22 Jul 2019 22:48:29 +0000
Message-ID: <MW2PR2101MB1049F44BDAA89FC27D4576D8B6C40@MW2PR2101MB1049.namprd21.prod.outlook.com>
References: <156262678491.777.1949510542578853249.idtracker@ietfa.amsl.com> <MW2PR2101MB10495E1951F40C4CE6526413B6F60@MW2PR2101MB1049.namprd21.prod.outlook.com> <CADVnQykFdbxfzzukb9nXtQX2gYFhEi7w+WBFozD4ivNg510EYA@mail.gmail.com> <MW2PR2101MB1049A6A61D6D29619D3A71D0B6F10@MW2PR2101MB1049.namprd21.prod.outlook.com> <CADVnQymauhrLBNn0PrhF3UZHf6sDkiLhzGQ059p8oU3ABQcTNQ@mail.gmail.com>
In-Reply-To: <CADVnQymauhrLBNn0PrhF3UZHf6sDkiLhzGQ059p8oU3ABQcTNQ@mail.gmail.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=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-22T22:48:28.6872475Z; 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=8356c032-e979-46a7-a376-d9421e72cae0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-originating-ip: [2001:4898:80e8:9:6c75:cda3:12a0:f9f8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9e881fc4-5a39-434c-59b3-08d70ef6b88b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB0985;
x-ms-traffictypediagnostic: MW2PR2101MB0985:|MW2PR2101MB0985:
x-ms-exchange-transport-forked: True
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <MW2PR2101MB09854550F09C431A0DF6FEA9B6C40@MW2PR2101MB0985.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(396003)(39860400002)(366004)(346002)(199004)(189003)(13464003)(54094003)(476003)(25786009)(790700001)(66476007)(66556008)(64756008)(66446008)(6116002)(966005)(606006)(5660300002)(14454004)(76116006)(66946007)(229853002)(11346002)(33656002)(446003)(86362001)(256004)(14444005)(15650500001)(2420400007)(99286004)(19627235002)(52536014)(2906002)(22452003)(316002)(54906003)(110136005)(4326008)(7696005)(68736007)(6246003)(107886003)(8936002)(81166006)(81156014)(76176011)(71190400001)(53936002)(74316002)(7110500001)(55016002)(71200400001)(236005)(54896002)(9686003)(6306002)(486006)(7736002)(6436002)(186003)(10290500003)(8676002)(8990500004)(46003)(102836004)(6506007)(53546011)(478600001)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0985; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: e6qrrfYzcwAextFWchNtlqg0hmtvtA73dEfBw0WPhOZW7kmNGNTfzTv3OaPZ1EoASQuCpUgrQFIZ3MD4GpHigpEWUlrrwucATBEK5PbOkBRUZkEl5gxiDYXUM+CMzHPX4zfNpwiE/5qBq9Qw5BX4aJhCXG1qwt37Swlljhuoc1XuRf3cYxstVWaMmNMKSdgHI/Px3Y0n3SRV8G8p+LSC574/kqmHzwisEMlupaiLf0Gr7Xr56qdmQQbWxVkrMS+mDO/JxYHC+uPx/Su/EOJBixQm5KVXjW6NVRW+bTrilhfOajzLQyG79B+q+mib33KGpOQOIZP21+9eDkkPWB98yjVoemQ/gj2lYXgi32gckdUkSQJh5reQ4Atf/JeMlL030bl4uhYGGj8/FD2xc3g36UqlRxoM29GB63xvYUL2gVU=
Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB1049F44BDAA89FC27D4576D8B6C40MW2PR2101MB1049_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e881fc4-5a39-434c-59b3-08d70ef6b88b
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 22:48:31.2770 (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-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0985
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/rY3wDl2QQAOMtvGyE7I8vYrWJ4s>
Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt
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: Mon, 22 Jul 2019 22:48:37 -0000

We published the next revision incorporating changes to the algorithm and some editorial fixes.

From: Neal Cardwell <ncardwell@google.com>;
Sent: Tuesday, July 9, 2019 3:54 PM
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>;
Cc: Praveen Balasubramanian <pravb@microsoft.com>;; tcpm@ietf.org; Matt Olson <maolson@microsoft.com>;; Yi Huang <huanyi@microsoft.com>;
Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt

On Tue, Jul 9, 2019 at 6:18 PM Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org<mailto:40microsoft.com@dmarc.ietf.org>> wrote:
Re (1). Great catch Neal. That's a bug in the draft and not in our implementation. Eta is computed based on lastRoundMinRTT and not currentRoundMinRTT.. We will fix this in next revision.

Got it. Thanks!

What was the reason for Linux to switch to lifetimeMinRTT? On Wifi links RTT does fluctuate a lot.

I'm not sure what the motivation was. The "Taming the Elephants" paper and dissertation both use the lastRoundMinRTT, but the code that was submitted to Linux (ae27e98a51526595837 on Oct 29 2008) uses the  lifetimeMinRTT, without a comment about the rationale. I can imagine both approaches having pros and cons.

Re (2). I agree that the goal is to find a function that's faster than CA and slower than slow start. LSS works well in practice. For long lived flows on high BDP links incorporating the CUBIC CA early can help and that's a good idea. But given that this is an informational RFC describing the current implementation, we'd have to experiment and deploy any changes before updating the text. We will look into it.

Makes sense.

thanks,
neal


-----Original Message-----
From: tcpm <tcpm-bounces@ietf.org<mailto:tcpm-bounces@ietf.org>> On Behalf Of Neal Cardwell
Sent: Tuesday, July 9, 2019 8:07 AM
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org<mailto:40microsoft.com@dmarc.ietf.org>>
Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>; Matt Olson <maolson@microsoft.com<mailto:maolson@microsoft.com>>
Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt

On Mon, Jul 8, 2019 at 7:11 PM Praveen Balasubramanian <pravb=40microsoft..com@dmarc.ietf.org<mailto:40microsoft..com@dmarc.ietf.org>> wrote:
>
> We submitted a draft for modified slow start using HyStart and Limited Slow Start. Feedback is welcome.

Thanks for posting this draft! (
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-balasubramanian-tcpm-hystartplusplus-00&amp;data=02%7C01%7Cpravb%40microsoft.com%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636982816578522537&amp;sdata=GttDyDYhw3sG%2BxDGAFSefMYeRyNfjeUih6XVvbJa7MQ%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-balasubramanian-tcpm-hystartplusplus-00&data=02%7C01%7Cpravb%40microsoft.com%7Ca9fc7690aa17431e74e008d704c0649d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983096687312111&sdata=R2jKzyocU4bv2tHdS62k3yAB2d3UagtpKlfAc5gdHgc%3D&reserved=0>
)

This is a very nice, clear document, IMHO.

I was curious about a couple of items:

(1) In the draft the condition for exiting slow start is:

            Eta = clamp(MIN_ETA, currentRoundMinRTT / 8, MAX_ETA)
            if (currentRoundMinRTT >= (lastRoundMinRTT + Eta))

The use of currentRoundMinRTT/8 to compute Eta is counterintuitive to me, and is different from both the Hystart paper and the Linux CUBIC Hystart implementation from the CUBIC authors.

The Hystart paper used (modified pseudocode):

  if (currentRoundMinRTT> lastRoundMinRTT + clamp(lastRoundMinRTT / 16))

The Linux implementation from the Hystart author Sangtae Ha in 2008 used the approach (pseudocode):

  if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 16))

Eric Dumazet changed the Linux approach in 2014 to use a different constant scaling factor (also pseudocode):

  if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 8))

I am curious about the rationale for:

(a) Using an RTT threshold for exiting slow-start that is based on currentRoundMinRTT/8, rather than being purely a function of the RTT values from previous rounds (as in the Hystart paper) or the lifetime of the connection (as in Linux)?

(b) Using a function of lastRoundMinRTT and currentRoundMinRTT for the exit threshold, rather than a function of the min RTT over the lifetime of the connection ("lifetimeMinRTT" in my pseudocode, above)?
Is the rationale here partly to deal with fluctuations in RTT due to cellular/wifi/DOCSIS paths with noisy RTTs?

Any background on the motivation would be interesting to hear, or perhaps to include in future drafts.

(2) The Limited Slow-Start approach described in the draft seems to boil down to increasing cwnd by roughly ssthresh/4 each round trip.
It does seem like that would be considerably faster than Reno or CUBIC would normally grow in congestion avoidance, for the first few seconds after exiting slow start. But it does seem to be essentially just a large additive increase. And so it would seem that if CUBIC were instead in its native CUBIC congestion avoidance instead of limited slow-start, then CUBIC would eventually (e.g. after a few seconds) tend to reach the rapid-growth convex portion of the cubic curve, and eventually grow much faster (eventually reaching exponential growth of 1.5x per round trip). I wonder if it would be advantageous for CUBIC connections exiting HyStart++ to use a  strategy of growing the cwnd using the maximum of the schedule calculated using limited slow-start and the schedule calculated using the normal CUBIC congestion avoidance logic. That seems like it might have the potential to mitigate performance issues for CUBIC connections that spuriously exit slow-start too soon?

best regards,
neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7Ccf008cd4a3ae41e87e7d08d7047f2c33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636982816578522537&amp;sdata=0Sjqt2FWz1rKTqply%2FMJIzGeleyolWWNObL58KdCxm4%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40microsoft.com%7Ca9fc7690aa17431e74e008d704c0649d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983096687312111&sdata=ToR6qaSuhKKBGhEHwfpwTfOovkKKTOCHRBo2t59V1K4%3D&reserved=0>