[tsvwg] FW: path forward on L4S issue #16

"Black, David" <David.Black@dell.com> Mon, 08 June 2020 13:32 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A913A07F8 for <tsvwg@ietfa.amsl.com>; Mon, 8 Jun 2020 06:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=OsaPwyop; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=n3s55Q81
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 r9QkIGoCvclQ for <tsvwg@ietfa.amsl.com>; Mon, 8 Jun 2020 06:32:27 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 EF16D3A07DE for <tsvwg@ietf.org>; Mon, 8 Jun 2020 06:32:26 -0700 (PDT)
Received: from pps.filterd (m0170392.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 058DPM4G022460 for <tsvwg@ietf.org>; Mon, 8 Jun 2020 09:32:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=sBj/y/I8+piCgLcnub0qS/cP7DqUh2lPzAl2IGhqfPw=; b=OsaPwyopPbyTITFjkypPC0Bz5Rij2Ea1nOCHldPZyUJIdEJK0glybeXN6MigJSNXST5m eYiqF7/iL9uRDibuiyiPwb+VVeWtsVNbq4rIvg34xUBvYHS58DqSOc1nbrvQAIRRNjYX XODjqj9+7OQgncizqs15jtGpMY5+AquMTWwl4Y7g0XYuWJghaQRRyGTGIEa5Dp5OELU2 bW1ofW+Pg9VlgUB9O7TR4fUYdcekqK7rw+Z4rGMs5x63jOQeTJETNckJrndOLgQ13Lpe u414xfpboRlmsJ5cd/PvrnQXbdY6sCmcXwzRb2hYWmWKZbVNa9+5JR+jwTK2HryYKx56 KQ==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 31g6ac4k9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Mon, 08 Jun 2020 09:32:26 -0400
Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 058DJlC3109767 for <tsvwg@ietf.org>; Mon, 8 Jun 2020 09:32:25 -0400
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by mx0b-00154901.pphosted.com with ESMTP id 31g5du8btu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <tsvwg@ietf.org>; Mon, 08 Jun 2020 09:32:25 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UqoyGOQBDUdwKe4Hrr4SHUix8iYwDPsKP7dVbUL9HczlkbJXA0FgLAia5neYLhZi6J1k+mE7cqZLZcTMlxW1squrDMvork8ikH8ca3ZVlJNmCXNxREEVwMY/+TXiHTFyiCUpB7SLiPAosrmw7l5uFNXx6ziR5RPo/UK76m3+Wr/iaqii+1h7hwU2Jyaf+puo3kIMTG38rNCJ582+E/6SbsTrCW5Ppge92XxmXOHli+f84HkoosqahGobeEznODEdkAX5AFHoEpLlpJHAfm+2XMr/3PjeZO3LBPVQT1Zgp2zghlj4Sj7SFWrpOFbbPs9I4iMv90AHJ0eD8V9i8QoU/w==
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=sBj/y/I8+piCgLcnub0qS/cP7DqUh2lPzAl2IGhqfPw=; b=ZFWG2AoJuT+6jbHVnBTmE9kEdWrDClqnWu6dZmtCyzDlMuAaZMzp7cl2Js0DianvFE7c1lDN6Dr4C12vWokQVigPDysQ1ekBPnfGh4UCS42hx6BcHcABMr0OECaJYV2R1e469OBnJGf9e4sT6mI+J7O+cWTJNvYTZldzkpO4ovQzeeMtYsMbOp3lzUElWUR/kVdPn4H/Fy/lwvYzU2PKT5EG5e9t/LfJJwgSxHfidv46DtXalCKGuUg54kd+vvoXeBvQHqc6g2VSPVYPlhAGmI+Y1z7GoqVzBSmc8dmkg0J9XPBdk2PrE8bLsiu1TvsieGU68lCz43MFedJ4QKFFgw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sBj/y/I8+piCgLcnub0qS/cP7DqUh2lPzAl2IGhqfPw=; b=n3s55Q81/tbQCl5djHhLnt+20I9VtnJ9fsIpgIyiZwds+6u3BiL9n1goeIkGXVtfla0TxfAbRfMrTK0Ptasu7MVvCunve9BYQfkoKLV8JCtZo9szZwDlbx39hZFy2wVZfLKKsK9zZjdqsaX0MdDRaQ9iSXn01adO42bR4CpHWdI=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB2511.namprd19.prod.outlook.com (2603:10b6:208:aa::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 13:32:24 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::3574:5511:eec9:567]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::3574:5511:eec9:567%9]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 13:32:24 +0000
From: "Black, David" <David.Black@dell.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWOrJVTUWYaYrQjUWaXRJOx9crpKjJIT0QgAWbj/A=
Date: Mon, 8 Jun 2020 13:32:23 +0000
Message-ID: <MN2PR19MB404568DB25537BBEAC2D869983850@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <8a8947e1-f852-c489-c85a-be874039f132@mti-systems.com> <MN2PR19MB404584BEA107C796469F311C83860@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB404584BEA107C796469F311C83860@MN2PR19MB4045.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=40de05b4-dc85-4204-912a-694564ce5b35; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-06-08T13:31:52.0428556Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=dell.com;
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13fcd874-6472-431f-7f99-08d80bb060f4
x-ms-traffictypediagnostic: MN2PR19MB2511:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB2511C6468C39817DCEF2978383850@MN2PR19MB2511.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 042857DBB5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Jg2nwIf+WjOtK64LE+uKe02xgDxBOlSa7guNIpfOFZpqQMJhgyCEjpzDnnmQf5bXS6SL7gDj1HBdIYSmsebIt38hlOOahsg/GIKBcNb99c1jgxbVigyqqlCTkHTciqvITmxQQwdd27QKeX/EY3Xwmh2Ckcc+97LH8nF0tN2YM1+X4+kkRBMLX2Qo99+eRN9QdmmC4Vi+2R5EBxr3E6GgChel5bLPYNKRQObXh4h8aHGxo7DpbvSN5KyU4nPN5mvMrjTJr8GoJSsHKoxEo3N0HsMgaWLPirFdgY7cuUEmo7PjpLmIaVdE43Fj1s+11u8jAiEyIfTXjJVp4RRge6EUeUktWIle0MxZYFfr3kSR9hXpZjprmsrbEfg60CwqoLllftsQ/gEMgNvz9Kb1lBBYQA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(39860400002)(346002)(396003)(376002)(136003)(786003)(71200400001)(66476007)(66556008)(64756008)(66446008)(52536014)(316002)(66946007)(53546011)(6506007)(186003)(5660300002)(26005)(2906002)(6916009)(55016002)(76116006)(9686003)(107886003)(86362001)(8676002)(4326008)(966005)(478600001)(83380400001)(33656002)(7696005)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: MxUGS76ps1nnedFOwSuevdiioKRqYuxYLohf+rmBZkkGKSbLzowgudnS96Mz+0r3G9DGpjR3ftLOzwXUEWRiIG2WHAY5FTRsLTxFbUXWfu2lW95qY19ANZlDvO1o1ZaoRzUGhD5denKgSwZ5vqDJ8SFF71ObHPkBmn4v8lD21WAm9Q25tI3YmOSVQQN2jXwWbeQYcRqsBhRbvisyKSO9rcmCk4acIIex8wiEvExkgAC75huCVSbWOZVvWjrlKG/1KWPqP0m244luSuQeYAuWtCWNv0FeB+Wydzvx81Wnceqk/Rvul6B4E8ALf7zi5XSeZP4VvDnBLwR3rO2x8sevezoHHyaXl8u4lrwpvC/ziizrE8KN5xnpzS9PnEjjJps8KhVjgMJC1SpeZrWDrQzDRR+zH2E2AnkMYightrvZT0epS6B/i2T7sM0CZgIiT3BNzNZq99gMT62n2PM9FG+fH3JtFuY+z0rtt2YnMrmdZsw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13fcd874-6472-431f-7f99-08d80bb060f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 13:32:24.0147 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cvVTah4L60hTzhdZVtqjbKOacJabbIaSn4SUpXxYj78cgEWXjeg10OvoqY95OAOM0Lwh7rLkpGxI44X93BaT9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2511
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-08_12:2020-06-08, 2020-06-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 cotscore=-2147483648 clxscore=1015 mlxscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006080100
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006080100
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/GwQvHNdwLQgBl-IkeQJrOYAF6M8>
Subject: [tsvwg] FW: path forward on L4S issue #16
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2020 13:32:30 -0000

Without stupid confidential tag this time ...

Thanks, --David

> I think fixing this is part of making the classic queue detection and 
> end-host performance robust in as many cases as possible when trying 
> to take advantage of L4S in the network, but doesn't lead to a safety 
> issue.
>
> Are there any plans or thoughts on how to proceed on issue #16 that people can share?

[Writing as an individual, not WG chair] I have an alternate perspective on this issue, and suggest an alternate approach to addressing it.

Under the heading of TCP Prague, an enormous amount of work has gone into endpoint detection of RFC 3168 ECN bottlenecks and endpoint-based problem avoidance.   Of the test results that have been posted, Pete Heist's scenario 8 results (https://mailarchive.ietf.org/arch/msg/tsvwg/-gx8R1jcwiCsX1_5cdnvl3kKlOs/) ought to give everyone pause, as they show TCP Prague flows getting into trouble competing among themselves.

This TCP Prague work on bottleneck detection and problem avoidance has been going on for a year, and while it's produced some very interesting results and I'm sure that more progress will be made, I'm skeptical that relying on it to close issue #16 will yield much more than rounds of finding new problems in the next five versions of TCP Prague.   Beyond that, I'd expect to see quite a bit of L4S low latency traffic from protocols whose endpoint implementations have not been scrutinized to anything approaching the degree of attention that has been recently devoted to TCP Prague, and hence are at more risk of getting into trouble.

As an alternative, I suggest starting from Neil Cardwell's network and operator perspective (from https://mailarchive.ietf.org/arch/msg/tsvwg/kyDZ7vYLeOk1V15nZfNXGmaUNxk/):

	- L4S flows potentially causing unfairness in RFC3168 ECN bottlenecks has
	been mentioned as a potential concern. However, a robust RFC3168 ECN
	bottleneck should already have a mechanism to avoid unfairness caused by
	flows that are marked as ECT(0|1) and yet not performing RFC3168 responses.
	In particular, many of the large sources of known deployments of  RFC3168
	--  Linux fq_codel and cake -- are already deployed with fair queueing. In
	such bottlenecks L4S traffic should not cause harm to other non-L4S flows.
	Furthermore, if there really are ISPs with deployments of RFC3168
	bottlenecks that have neither FQ nor any other protection from
	non-RFC3168-ECT(1) flows, then they can bleach incoming ECT(1) code points
	to Not-ECT and treat L4S as Not-ECT (ISPs typically already transform the
	DSCP byte at their ingress anyway). So I do not see harm to RFC3168 ECN
	bottlenecks as a prohibitive concern.

	- More generally, if there is any problem discovered with the L4S
	experiment, either the algorithm or particular implementations, bottlenecks
	can easily identify L4S traffic and bleach it into Not-ECT, and treat it
	like Reno/CUBIC traffic.

TCP Prague is not only not mentioned in the text quoted above, it appears nowhere in the entire email from which that was extracted.  Nonetheless, the email lays out an approach to L4S safety, although as initially proposed, it invites operator bleaching of ECT(1), which would be unfortunate, as ECT(1) not being subject to bleaching is among the key reasons for using it.  Refining that approach might produce something more robust that doesn't invite ECT(1) bleaching, and that recognizes that FQ is not a 100% solution to flow interference (e.g., courtesy of the birthday paradox for the number of hash buckets in an FQ implementation).  As noted before, please don't cast aspersions in Neal's direction for introducing the notion of operator bleaching of ECT(1).

So, I would suggest focusing attention on networks and operators as an alternative approach to focusing on endpoints.

Thanks, --David

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Wesley Eddy
> Sent: Thursday, June 4, 2020 4:54 PM
> To: tsvwg@ietf.org
> Subject: [tsvwg] path forward on L4S issue #16
> 
> 
> [EXTERNAL EMAIL]
> 
> I think we should discuss the path forward on L4S issue #16 and what 
> people are working on, planning to do, or expecting to see in this regard.
> 
> This is the issue on interaction with RFC 3168 ECN AQMs in the network.
> 
> I think this is one of the more important ones in many recent 
> discussions, so would like to make sure we're agreeing on what it will 
> take to complete or what success will look like.
> 
> The classic bottleneck detection work is a key part of this.  In that 
> vein, I'd like to subsume issue #29 (that it looks like Pete Heist
> opened) under this one and close #29.  Issue #29 shows some cases 
> where an L4S queue is misidentified as a classic one.  I think fixing 
> this is part of making the classic queue detection and end-host 
> performance robust in as many cases as possible when trying to take 
> advantage of L4S in the network, but doesn't lead to a safety issue.
> 
> Are there any plans or thoughts on how to proceed on issue #16 that 
> people can share?