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

"Black, David" <David.Black@dell.com> Fri, 05 June 2020 00:36 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 A13793A1194 for <tsvwg@ietfa.amsl.com>; Thu, 4 Jun 2020 17:36:36 -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=Ag1OjXH+; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=pMjX88/z
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 ToBlX7NkWVVK for <tsvwg@ietfa.amsl.com>; Thu, 4 Jun 2020 17:36:34 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 CD7963A1192 for <tsvwg@ietf.org>; Thu, 4 Jun 2020 17:36:21 -0700 (PDT)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0550Qiwf009396; Thu, 4 Jun 2020 20:36:20 -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=0cNMVKPbXAdFEV0h2goi+O24qhLEGncYXQaTbxyIND8=; b=Ag1OjXH+V5V4R/BYHtcwzrhLzF4Pgyw1X7KrbWJAUyNsLRrkLGOat2puQmqRBD5gh3dE DXu5WPrMidnYAyBPl/LUM0ah7iCdJkq1CzZ+z7cNcfVv+AuZ/AoOrfM0utdICwtYHRaB f+nRgQkRE0UmrvTinmlA4731yQWmw/N6ZZa/6dUlkJFW2UTQukxJ7mXkozY/uuuKp5lj ju6PKePoz1uFOMQSkPjB3Quzhx6hakc+7jQMQ3PGYOVzewb5Km7Eo4qRwSRH81YOyHff nX8dDwziq8wdKVAO3jOO3SZ5zSJHHM+6cZH29Gklxzer4R337jX3jqdZniAJNS74dIgL Cg==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 31f91ggb3b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Jun 2020 20:36:20 -0400
Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0550U6rW068443; Thu, 4 Jun 2020 20:36:19 -0400
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2102.outbound.protection.outlook.com [104.47.58.102]) by mx0a-00154901.pphosted.com with ESMTP id 31f932hky9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Jun 2020 20:36:19 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EfURdixvO7jPNbBpuYPw+mPrRlN11VoDbY/GxYfMA4otOmMOfpAWF9fvMJ2QIl9+hgIoGHzhuTLmezo9pdwETjIMWeZ65sfMccDwr94i6I2n534h3/3+4t8+qKNefdjpW7rGCLL51YbKt6ljh+/FteXlz7M+/8Gz0uQb4iaoS/f21K2yFqXKDqbY9Y61QlLpK2MweK5z3jGwnp3LBxSAez4oKOXWFfzHP1fpQHkKra0L/IJe9R+q9DTG3FcFsWZ0FNzig9xEKyeMLsFQYLjoS+bKxbTw09uIY6WkC9gt0eRgLLQ+vh5go7+LO8tI91vvIKKFJYYVptLUFuRf0Lt/kw==
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=0cNMVKPbXAdFEV0h2goi+O24qhLEGncYXQaTbxyIND8=; b=FtmJyBOiwAEqX9N0CKPDxT4kBvPWAjAjmUPewjC6EEQKxqfreU7J3kfCFTRnYkGXsvRXQoN980yiXl0vZyeSpiCA7aXS9U+fuJaDIJXv2XzVbx0C+ahfw67aZbL7npaWsmJrHzUEy0r1GXkq+Gq/H7aHVMkfSbm0/fJO9PGEZB7pvp8tT1S23VGtqCfOmFG1esaa61UldTxzTWW31uxHZ5UnWgj3KpkfbTTYNtcr82PNXv2tqPwki8hNT8/k4GHZGgtQ7Ao60HO2G9hKddvpYWO5n6cIpNHYyfac0C7LpqQL+zmawiCrBpKC0zPt4hqyTtVupgc8ubA3gWiRrGOdNQ==
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=0cNMVKPbXAdFEV0h2goi+O24qhLEGncYXQaTbxyIND8=; b=pMjX88/zxwS7+7bFmnBuoc5hXd8mbHU9I+zzyINdlYLmXIBlQxiJi+zjrmgKLd5AWaFq2os8UuPeNewwT3AjKDck+tH/XPJ6LUi8crt74mfbsm7sibd5bC+YvOPEP9/2Zo+9bX4JrBYe4IhtL+7JgTi+VJtPPcaqxQjb2aHmqwM=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3469.namprd19.prod.outlook.com (2603:10b6:208:194::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Fri, 5 Jun 2020 00:36:17 +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.018; Fri, 5 Jun 2020 00:36:17 +0000
From: "Black, David" <David.Black@dell.com>
To: Wesley Eddy <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWOrJVTUWYaYrQjUWaXRJOx9crpKjJIT0Q
Date: Fri, 5 Jun 2020 00:36:17 +0000
Message-ID: <MN2PR19MB404584BEA107C796469F311C83860@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <8a8947e1-f852-c489-c85a-be874039f132@mti-systems.com>
In-Reply-To: <8a8947e1-f852-c489-c85a-be874039f132@mti-systems.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_Enabled=True; MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_Owner=david.black@emc.com; MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_SetDate=2020-06-04T23:53:43.0987332Z; MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_Name=Internal Use; MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_Application=Microsoft Azure Information Protection; MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_ActionId=dc860245-1f79-4719-9c0b-200eac10f5d3; MSIP_Label_7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90_Extended_MSFT_Method=Manual; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_Enabled=True; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_Owner=david.black@emc.com; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_SetDate=2020-06-04T23:53:43.0987332Z; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_Name=Visual Marking; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_Application=Microsoft Azure Information Protection; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_ActionId=dc860245-1f79-4719-9c0b-200eac10f5d3; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_Parent=7de70ee2-0cb4-4d60-aee5-75ef2c4c8a90; MSIP_Label_da6fab74-d5af-4af7-a9a4-78d84655a626_Extended_MSFT_Method=Manual
authentication-results: mti-systems.com; dkim=none (message not signed) header.d=none;mti-systems.com; 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: c07543a5-ec99-4dc7-f40b-08d808e875ea
x-ms-traffictypediagnostic: MN2PR19MB3469:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB34694B7AF9256642F20A3BA983860@MN2PR19MB3469.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0425A67DEF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FoWmXmtz141I0r3cHd3MELxLgLQPvZbXg4Ioav0PfBT8AMS4rCV8ybzNN8sfwc4Inks1dr2NZfbHtHHhj5+FIPJrEPKVXthF/O4TZDi+rsKqFqbcGDMFUgON22e5Xj8iPDuoMUbFzIkFGdyvlI0FjQxl38WRobbey1Lda4Im0QGrpu91o63Y/ImUXpJzxSDhrOQZMD+tdESIjqhIR0PtB+7LKilb/GESCo1q5V0aEhndy/owaT83dVu90nspl64KDfYmRjyxNnhDZLrl/mZw6Ilb+e4ALuqIG+WXcizyf4unXa1plsJ+s1/JPxxOnSJaUa1pduvccXsscXwckRzQL9QZBr9Ai7EPfHi5zXQJCr/Hm5bxw4qYDALvjOq/80jzdYYuw3+F3s09goH37cMT/A==
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:(396003)(366004)(376002)(346002)(39860400002)(136003)(2906002)(66446008)(66556008)(66476007)(64756008)(55016002)(478600001)(76116006)(186003)(66946007)(6506007)(26005)(86362001)(7696005)(53546011)(107886003)(83380400001)(4326008)(8936002)(5660300002)(52536014)(9686003)(786003)(110136005)(966005)(8676002)(316002)(71200400001)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Co9w/dhUbaFb7GKn0f0ZNBR89SqFConVqNYhbBgAeus++s9dZm/SBikbFy7c9oU6ui6518IIIPsJW9TpWk/CvQAoDcM9GzKgJcw3vAIGDVfqKGuvVoR94SSe0JcWCdzBrowzyAzB2XPzuZsOTu+XnDq1rPDa5NYTHvU8tDYwOkHW1SZA4xWJpCKFsKyxfcBx9H5i7g4lT1YSa6tMDPYwgY8OnvOV7v8HO7nLO/e0c6r/iiDIvVs9FsUglUVd5WvHKxXixZcKuzXVPE/Jz/XV22tmm8vCh59Okc8ZQr4Q0iAOb5wHj7BEMb/yWdIzi2Bf0NdW7f+qPGk22asBpl++ArPZYiu8ag90ty6V7JydEsoas+v/SGogWha8LXQSjhVE41VJ1P3po6pn3X6QNRgqs2e6lSC84kuUcywNnaCc1ztAVnHDV1wjF181qJopDBgQm9UOaoUnS2BvrDJoIyZdV9LyUce578exGtCPYGmHaiI=
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: c07543a5-ec99-4dc7-f40b-08d808e875ea
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 00:36:17.4013 (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: SRU+G3KZh741fzxC1DfFKzcXraTG70fikphvN7eUF9065S+fwCR2JjuwVUPpbVbHJdOf9oviVZR0H9W20O1hPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3469
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-04_13:2020-06-04, 2020-06-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 adultscore=0 cotscore=-2147483648 mlxscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050001
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0 mlxscore=0 spamscore=0 bulkscore=0 malwarescore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050001
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/498dRhs9mLDsUIx2Z_FDdYNqhnE>
Subject: Re: [tsvwg] 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: Fri, 05 Jun 2020 00:36:43 -0000

Internal Use - Confidential

> 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?