IETF Logo Mail Archive

Re: [tcpm] [EXTERNAL] Re: Linux doesn’t implement RFC3465

Praveen Balasubramanian <pravb@microsoft.com> Tue, 03 August 2021 00:46 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 5EA343A2353 for <tcpm@ietfa.amsl.com>; Mon, 2 Aug 2021 17:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 lUETfSR26sA8 for <tcpm@ietfa.amsl.com>; Mon, 2 Aug 2021 17:46:21 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650103.outbound.protection.outlook.com [40.107.65.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E903A2357 for <tcpm@ietf.org>; Mon, 2 Aug 2021 17:46:20 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=URpPPNFnu7+Nkl65qsCw7RKDNL9UTX55kcKnHL3e6SFVcqLDwGrfmh3MpC9ngj9RFe3oUHlIK64NlIjTea3RdfqHW4Aj3/sg5vJgBa4dPpBXPALgsyQwSl41Xq4rXpzNvp6dMP4DGhPVVbXSvCWVA9HpT4suzwcNWHiC/qr3O7G6FwNjwil4QUwShN2fgz0ZimkN95Z6YhoQir8bdltNHB8GGEUwj1hAu/NhQf/R7p8UkrxXUhO0b7LM9/Hol3GAh8h7MtUh9Lr+avrhTecYvs5CUDN4ahkqz+CSd/Qt1UKujUNUA080glTad/vIl0gb5+I/YpUqbgcNGA0PPlULWA==
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=cdzKlrG5Y+Tx3CUuFh2VhMRWnDHMNYzHAesMP8VRYzs=; b=oWl5Lxo/T9ohz7BkBssHGCH/m3cq4Igsl4hcBsTi26tQFlGlgQi1kvMllsHN8kc3qGJmFLHT0E9c2qznkXu88JQYfJbG4Z9e4hbAAb+lmTSSGDSIw9FJiRDNozueAbossAijfofDH9UqABZW0cIafmDIM5Ti8696dn//8qD8X0di0kMh5k+Qe+vb/BSc23hXP9YBRDzcM+nC7tjvVJuz4Q1fywvMzq238RJXLO1sfqqpNLSCwaLm0DnzPuICrOfWEhuEOsOSumOsWRBx/YWo79ueNn2nCYt3OKtQX6+6XeM5GePGkc+H3t7acDUzbFDzI0UnPXVXXQXkCDs7oIuHaw==
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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cdzKlrG5Y+Tx3CUuFh2VhMRWnDHMNYzHAesMP8VRYzs=; b=jUai2bqJ3hsnWnxTT9/y+m4FfbIPI7xZtVAwXW/ZEZiosEJ0J4VwPIctJJ2vb0Rw72IWnEa1dOqLIwT1elSp6+2GP6xdhMg9bsk73YqP6GJwpdsJ3B+kcKiDv2u889oo1W1DqMoJUjv+Mp/Iig3lqdwGAvL1z6sVEA+lH+fTXso=
Received: from PH0PR00MB1030.namprd00.prod.outlook.com (2603:10b6:510:48::7) by PH0PR00MB0981.namprd00.prod.outlook.com (2603:10b6:510:37::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4424.0; Tue, 3 Aug 2021 00:46:15 +0000
Received: from PH0PR00MB1030.namprd00.prod.outlook.com ([fe80::1123:3957:e983:ce92]) by PH0PR00MB1030.namprd00.prod.outlook.com ([fe80::1123:3957:e983:ce92%6]) with mapi id 15.20.4429.000; Tue, 3 Aug 2021 00:46:15 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: "ncardwell=40google.com@dmarc.ietf.org" <ncardwell=40google.com@dmarc.ietf.org>, "vidhi_goel@apple.com" <vidhi_goel@apple.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Thread-Topic: [EXTERNAL] Re: [tcpm] Linux doesn’t implement RFC3465
Thread-Index: AQHXg/VmIGQ1NXlS/Uqlnv2gvav8R6tZ5ikAgAAP/4CAAAfJgIAAFFQAgABT2oCAAAfpAIAAR2EAgAXT8oCAAEKRAIAACfiAgAACaoCAAAMVgIAAAYCAgAAEkICAABM14A==
Date: Tue, 03 Aug 2021 00:46:15 +0000
Message-ID: <PH0PR00MB10302B312DB96B8A6324C55FB6F09@PH0PR00MB1030.namprd00.prod.outlook.com>
References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <CADVnQynkBxTdapXN0rWOuWO3KXQ2qb6x=xhB35XrMU38JkX2DQ@mail.gmail.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <DF5EF1C7-0940-478A-9518-62185A79A288@apple.com> <E150D881-4AB3-4AEA-BE0C-1D4B47B2C531@icir.org> <CADVnQynjE+D-OSvdOVROjT3y1cnHHWqdNQSmphLAJ+HsBTUAJQ@mail.gmail.com> <A1B50403-2405-4348-9626-025D255DEAE7@icir.org> <CADVnQykM8p-bVz_oPrje1yNh9_7_isAUL+wnQWDoY9Gs18sLPQ@mail.gmail.com> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <CAK6E8=fFWAE_NSr45i2mdh6NmYDusUFW3GYGtuo-FcL07sox9A@mail.gmail.com> <D6B865F7-9865-4B6F-986B-F44ABE5F12B0@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <CAK6E8=c+KeQxWJq0e98hY9XsQ2vhdr3SiKkypC7kwdZbBRgdXA@mail.gmail.com> <A39F73BE-4BF1-479D-911F-0CAC6D91D924@icir.org> <CAK6E8=eEnVtMNBpu0noFAud4BTWdupCH+QY1beFjTtD9ADkK5g@mail.gmail.com> <CADVnQynWSCpEBeEtHL0JHCBYwyymX0vku_VbfeDQ_snUoCX=ZA@mail.gmail.com> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <CADVnQy=6XE7mFZRdBar3YXjUMc5URJYcsJvNdUGy26Zz7gajKQ@mail.gmail.com>
In-Reply-To: <CADVnQy=6XE7mFZRdBar3YXjUMc5URJYcsJvNdUGy26Zz7gajKQ@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_ActionId=b89cfd66-8008-4f6e-a422-6144fe6ed115; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-08-03T00:27:05Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eeda92c5-89fd-44c6-640a-08d956181986
x-ms-traffictypediagnostic: PH0PR00MB0981:
x-microsoft-antispam-prvs: <PH0PR00MB098113602DC971249C5FA88BB6F09@PH0PR00MB0981.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /Jgf0rgr1ynOQtHXb8pl29JeTT0/lMEBZd8oI9We9dkTBfUNj7FU9uj1fRAipChn+ftEywdsTDQaCGlv8E1499NXw1nF46Tqrvz4L/d6z47Cr9Vk66HojOzgpdfS08OWE7JJ4peU3YxJT1WLsuqIc4MPHg/acKGO9jG7va1sYO5pQYnnfrX5QAZqI4RExKUfdkoGlx+oBfsTaLnth3W1+OJPeYhjlonkAbgnTX8fReIq6EYLjNsXsKKn2WIrknzLpYfRsmH9w53d8BWMXs9fjsGY64RKN9B1NkRGyJx1gvrP/QBOts/ij0WV36MrlWvzPMrS0I9310qyWUus8Pbn4ru0B0OeWAyur78PLveLrrbFkwRpsqpk9w0/vqtFFWZQesOY+i3hRDME3xodCSJHDZ4Fns9CAvuTN/3OA9t1BUjZ6mTzZ/t0ERAt6lzQm6ptkL9cyBSFn1sA7TLQgpI6vCUVa0t6D3N8WQZQE8UylZpI9AI868ZUCOzH0Nr9LenfV8nrKdEpViRn0/r1AOCwcb5v1v6+jxe+VljyHpqD4+62FZBi4aKCWkjVF3S8ddMJo8rxwL8OnpbIvcw42cZvFCK9mxNJAWT3UHApgjgpY5yEBOYa70YdMrhXv/vWDgzCpmpgyc+lR5DIgs9NEc4ulE2R4xA36YyiPUzs28Rt5EY2UeOCCQ9xYddIJlhcwDoWrPWjoPy7NE1BsHTGVshEJQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR00MB1030.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(122000001)(508600001)(83380400001)(9686003)(38070700005)(110136005)(38100700002)(186003)(33656002)(8990500004)(7696005)(82950400001)(54906003)(5660300002)(82960400001)(6506007)(55016002)(71200400001)(66946007)(76116006)(66556008)(53546011)(316002)(10290500003)(52536014)(8936002)(66476007)(64756008)(66446008)(4326008)(86362001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 8iWfbhx2R2QoUWAQP8wO6qjeur20Kb89X0O5oYKBjdhe0VpeSUpZP3OD6aLZA/mCj2E2aStvH5juj3CWqGqjaiqeqKwAi29AazOAcKX3UXSyQRs2kZ+elcfTr6Xt6kthfJGWEvyvxApUyeKatI2lnfvHvdOI+OQk00pBk8uD7L/8FbR9y08Jc0pGqsBaSvy/ZYSbel800+nIQDzaYOFVs5i711NxT1gC3kR3kx1isXaZfvEfd//JVQlCZIqCHtUiOXKMcIcO+X59R3pms+Nf5L90+5KsUs7sz2iPvMYZjhDP0p+4u2ozMmKLs3EmaCBN4KdNCmpKebwg4sosnP4m98QBdxExAA3scEDrCsr80gvjcujrlonvg/hLql0FcHTubGMWqv9btkrwX6/C9syyq13EhpQIKen8soYnEulYi/w+sWOkVKbH1RhvUHwE+YtlOtmBD/urLVqDoqZmv3FtaLyaa0TxOTJ5u45Vtnb/5Sk9KrJ6Zwy++3GeTjMlDTgRs0HyMQYZ+WaFut08KMu7/2bUHZFuvTyAEjb6/Fe4NI57t6XvvWU8n7Hym3qNf1jRIEphSdrbulp4BiZ9AC0YeI6Uk6TLZnaXWEfY5tImg4dKmikm/YHgd1l4kEuIVNyrAcL+mEcBYso3KT7eJ/r7m9qTqGM7jTeNZdxfB8XUTYkkq8UlvIAtrY45NaMPSL21gIJRqkp1VKQ0mQg6hQnHzCgztKr4TNMLYA6kdNNMnLd4ieLOq10scWo/K+fgEEALXeqm71z5V1CQxY/Av34w+SZPoh+ZzULWaFSo5guy2OYVzJS9COIX/La9pO9t/6uvfvETXkwXGVEA3UPnuPIEV8pqMmcUwvS4oS0FEkkdImNZEKMe60vV5SAZR8M37qmIMo2WYbdRGPmzXaIkpsRDTP0eb/3iIvDwglO1RF3GSdMr6MmUc9XiaLM/ga+3FsMlRmr6bR4oaut9y8SkHBkO+ntt3B+3RJH2b+ClOiUYmLqFFvU6sXj3KFQpYytaDwFj5w0gfeBBCCxjswC7ntg1Fbe0XE7Be6qzksJ0DOjAKMl3VtHIzUNNzn8PKOV9xrWYTU0xobpNlFnbMXi6Y40jDSdwYi0/hVVqR9Tt1xqgyB1x1i90HYe399Fka2mqf9WYaIQHXQTRlDkrylMnmkDyqpRoGXwfc2UZBNac2LEgvxtg0Kdh8Xpx7QEQ3p86/zXMCDusBnYjHGTlsVRtg2IDvLpel0v0Qqe9xlEBHR3dRS2nj9Bi7ItHncMHjwYUDxkoDkqebC8rDz8v7cuRR2JGUf+SWLdoLo8y4iH3jWhW51LOCiipSOfE3WCjjoR88MMahliu1W7FwsFyyegKFtbULFshnAygVhoqyMrrtyQQ0nsObu5vmo9CtYLOlbADDCHZ
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PH0PR00MB10302B312DB96B8A6324C55FB6F09PH0PR00MB1030namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR00MB1030.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eeda92c5-89fd-44c6-640a-08d956181986
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 00:46:15.5554 (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: Em+epCCKmcYvq3M0gZXb018VMw6IwrKDRaof6VlX2PsoB59MQOhetX6TPpRa5Ij6VY7PGmWRe3l5qnZO2Wm5dtwBwKHBxIfiO1fbyyhBXns=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR00MB0981
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/HyNUR9OFwj0m3a12j_XviyNv6Vk>
Subject: Re: [tcpm] [EXTERNAL] Re: Linux doesn’t implement RFC3465
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: Tue, 03 Aug 2021 00:46:25 -0000

In experiments a few years ago on DC networks, values over L=8 resulted in a noticeable increase in packet drops and retransmissions (without pacing). Windows TCP has been using L=8 for many years now. If we do want to specify a fallback L value for implementations that cannot pace, my suggestion would be to use the value 8.

Neal, are there cases where Linux is or can be deployed with infinite L and no pacing?

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Monday, August 2, 2021 4:18 PM
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
Subject: [EXTERNAL] Re: [tcpm] Linux doesn’t implement RFC3465



On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <vidhi_goel@apple.com<mailto:vidhi_goel@apple.com>> wrote:

On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <mallman@icir.org<mailto:mallman@icir.org>> wrote:

> The fact is that Linux CC has long moved to infinite L since 2031,

So, if our experience is with L=\infinity and it is demonstrably OK
why don't we say *THAT* instead of "make L=5 or L=10"?  I would
submit that it makes more sense to leverage experience than it does
to make things up.
+1

Yes, I agree that would be a great approach to take.

So, we are saying it is fine to ignore L completely and simply increase cwnd by bytes_acked during slow start? And if this causes large bursts to be sent out (when an implementation doesn’t do pacing), that is fine?

Yes, I think that is the proposal on the table, and it sounds good to me.

A rationale would be:

(1) Implementations SHOULD pace (RFC 7661).

(2) Implementations that don't pace will generally be causing large bursts for many different reasons anyway (data and/or ACK aggregation in the network or end hosts), restart from idle,...) so having a constant L does not provide enough protection from bursts to justify the cost in reduced performance (in the form of slower slow-start). In support of this, experience with this as the default behavior in Linux TCP over the  2013-2021 period suggests this works well enough in practice.

neal

v2.23.0 | Report a Bug | By Email