[tsvwg] David Black (individual) on safety of L4S for the Internet

"Black, David" <David.Black@dell.com> Fri, 08 May 2020 20:01 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 DE4843A0E89 for <tsvwg@ietfa.amsl.com>; Fri, 8 May 2020 13:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=Pim/YkdL; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=fv0bkCQF
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 iNF4WZgOMxyI for <tsvwg@ietfa.amsl.com>; Fri, 8 May 2020 13:01:06 -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 E39F13A0E88 for <tsvwg@ietf.org>; Fri, 8 May 2020 13:01:05 -0700 (PDT)
Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 048Jvp7A028032 for <tsvwg@ietf.org>; Fri, 8 May 2020 16:01:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=PLttBZjCLJDyydXmNGPjUXlR8TAbdGdn2k6a9vgV1hI=; b=Pim/YkdLomn659rc3o40gUvKV8DhWkYaghaiYXu8ttt5y7t5rw3LmX8TrsfHThtDsv2h icshW40l2C64o+7JjO2Py8h29DCHbGUlYujc6uQP+CwknZKvPt/5u0Q5/AfJ5zC4BWpC xVfF19JPHXHOvS/Jq3d0mnI+QmM300+7m0ebrrWhmqACvETm/eTKtCXER7fzC7xKW4fI D+ZY8Knr0YXwifhulxloKMOGpuSsEbMSGRlGpXe9R5bjFzjV7LrZ/JD8DnxATL9QjysV ggyKSfb87Uvck+XBaB/8UhllQq+O+kn3ptIqGs1NLgx5nWPmuoxGe+EoiTv35E2oEaYt 0Q==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 30vthwavs3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Fri, 08 May 2020 16:01:04 -0400
Received: from pps.filterd (m0089483.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 048JsxZu036641 for <tsvwg@ietf.org>; Fri, 8 May 2020 16:01:04 -0400
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2048.outbound.protection.outlook.com [104.47.66.48]) by mx0b-00154901.pphosted.com with ESMTP id 30w5m57djy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <tsvwg@ietf.org>; Fri, 08 May 2020 16:01:04 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IrJf20T1A9aWcVJ5tWHmfREsZIZsm5nGRPaJeD+y1GMqOve08a2eAleXtw59lpJZimyjA4eoLs1FEY+K6sSmvR4D/XHVfTRid6gqk1fnGOtZoWsA8YSpxshnJsUPfCbZv+FNl9UoVoGPsArgECmrmqdJYlHcuGNWnz9whxy6fg4BdVHvITg452GAFKq57c8DjWwiwvMy57JWFPEgjM69zzd0S16yLxAMXe3sw42x1SA185byaAibMMz8veuwsDJwceaGPgD9lUNcICncXzeR4jv7we+FdseoI/TshtRxEcExgbH1iT9L31HlwLjxnORrmB5adkwzWbg9/6uRURpsBA==
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=PLttBZjCLJDyydXmNGPjUXlR8TAbdGdn2k6a9vgV1hI=; b=SuJELPjmyRtupi3GfKEhhdAoW9X6sPV5UbmixANTdUPnaFKu68P2q9CFQVjsJfzWC1yo+Xzb1CWfKnIPXQPCf2APrdd9+N9ayivwkvq0L/+E/2aSPfPqi3lUSgWB8tDpGHBarJDeJzox0hn7v7Vh95ndpErQEbOTDou+EWBtWjyDs+DRW2aPSHLPW1dV3xOy9Xr1TG60D3B1WCrAN6yP9rdyVdljOlH1mywpxAz1lrSRVAG3MFt16vB6o7DE2mSwUczFnRCpCcgqeFT1h8isYS29kCY6cTPZBc2x850YqZaIFcDXIEZVGZcQx5lt2H14Iqib8nYog1sEzDTsEjlU4A==
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=PLttBZjCLJDyydXmNGPjUXlR8TAbdGdn2k6a9vgV1hI=; b=fv0bkCQF/G2H2keoBpXkGqIYH7GVqgJ1a3F8sSwFgv/v19bMSk5QVbBJSjo+JPddbUjZ4+vfpwgjXAj5GVMaqJcC+3Aj8zN67AC6XBvw9jxDwEXIJ80QtpRgecRg5o21sS22csn/p+cf4jf+RdnoAWqmJdpoPf1WRgKGJAr6AJo=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB2735.namprd19.prod.outlook.com (2603:10b6:208:f5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Fri, 8 May 2020 20:01:01 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd%3]) with mapi id 15.20.2979.033; Fri, 8 May 2020 20:01:01 +0000
From: "Black, David" <David.Black@dell.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: David Black (individual) on safety of L4S for the Internet
Thread-Index: AdYlazOuUjQjHzTnQCi7t5vPqFGjWA==
Date: Fri, 08 May 2020 20:01:01 +0000
Message-ID: <MN2PR19MB4045DBC270D70DECE5F2B4AC83A20@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_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-05-08T19:02:06.2516105Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=d8a91afc-0cb5-4a6d-9b87-56e8f7aba736; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
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: 1dff4bc1-17f7-429e-8d52-08d7f38a889e
x-ms-traffictypediagnostic: MN2PR19MB2735:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB273536965785E6757E953C4483A20@MN2PR19MB2735.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 039735BC4E
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dYpJwcrwbHI0Oo5vMd0aX1CRryvJpB5iwNyrDtmfYWTZg8V1gRQumvmiu23jzvjqs9sBOFBYIXYe1tetwEnB9GrEmVo+HrSIv0dA7VCkHtuk8QEQz6a6zPZKtYfX2VeyP7T1fU2WiGofzVCyyiafTHQqRdCyQA5QPtDUDLZXAbF6VxoFNAYON2g5x+AkGMVIV1H9Gax2yqeErXm61ld9mYT0kJqFi7lCeSoyc4s/P3QK5dGKmEQJie4JoqZNL03ZFCL8EULyVzYC4F6fBky9qQf/e4vTrbbp1NT83VwfgP8N0HHE1Sllrvv4a3POkBArDuBMj2BX6QDZqrFHWpUXl9fEHYM/9S0SShQSRFxSlF3yU1XDe9S0eb1xnQcabq54cVPhGFZcRS4spf+5Nn9TiQhGDh0osdsmSbyjf9IPMEQww2F/P4TKOR00dScf6wwIGRzECWLR+yEO5D6l63fuGUdp8NUAmy7b0bxI0RDnx2ctz3jnXECscm41v74nDl/006hSdg+ycOQy+6nWyzkd3A==
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:(4636009)(366004)(346002)(136003)(396003)(39860400002)(376002)(33430700001)(71200400001)(52536014)(66946007)(786003)(316002)(8676002)(66476007)(64756008)(33656002)(66556008)(76116006)(66446008)(2906002)(478600001)(86362001)(8936002)(55016002)(9686003)(6916009)(4326008)(107886003)(6506007)(33440700001)(83300400001)(83310400001)(83320400001)(26005)(186003)(7696005)(5660300002)(66574014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: tapPO1OZBWo7NxY19XiUPWM5EszWGz2A8imHdOX6quOAmEYVzZWRQ/LAeUbP6zLD2W3QfmZxsRJ+6dlFdpHqaVu29BgMgsnu2Lf8Ks574Vb+kkO93hBWRYhyhL6DOSdGOno4tgqNgLjx+GTFH5gxbBeUHmQ+T2GR59t6dV1xBDxLFCwhoF83gjgpoaYq9ZNxzG9kjge/5W+rbzYXMe03wTd8ialM80TA/e5PkCcpcy8uSQXv3zw7/HfcgOv4po3pPD2G5EAyDKEx5w88gGODpSphL2xneRcw0BreNxM/hEP/23eNpayrjyTIOWFNbia0UQouTUm9/DeJfVDgLz5YeaWe9HdJTBsdQ4b+vY7H47L0tcM87Ne3sTrZ0nlYnlYLVxrdl5ewJX8kSjyfk02gGNTVl2TkisDw2KT78zvINmfY56WVWWmv7uv4TJM7gOZu3G3CyKWcXT/4Fy3qHuMuUTqj0eH+LqE++3PgPkbt4A8=
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB4045DBC270D70DECE5F2B4AC83A20MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1dff4bc1-17f7-429e-8d52-08d7f38a889e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 20:01:01.7411 (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: wuks3EZpT5qm8wr48Yb60s3dXULTs5PdbIupEEmRDbP3o7DR1JU0Fp8RwsYvKCD+QB25O8BOvx6ZcZzXvKTmMg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2735
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_18:2020-05-08, 2020-05-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 suspectscore=0 clxscore=1015 bulkscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=996 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005080167
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 spamscore=0 impostorscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005080168
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/xMWWL4TPF_zrRKqx9twIW2GYs0o>
Subject: [tsvwg] David Black (individual) on safety of L4S for the Internet
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, 08 May 2020 20:01:13 -0000

This the longer explanation of why I find myself in group 2 on the ECT(1) question because "If you believe L4S will not be safe for the internet without significant architectural changes, you are in this group."

Current practice is not to mix DCTCP-like traffic (1/p-class congestion control) with TCP-like traffic (1/sqrt(p)-class congestion control, e.g., NewReno) in the same queue because the DCTCP-like traffic outcompetes the TCP-like traffic to the point of starvation of the latter.  By using ECT(1) as the only classifier for low-latency traffic, L4S causes mixing of those two classes of traffic at network nodes that have not been modified to use ECT(1) as a classifier.  Hence the L4S experiment proponents are responsible for the safety of that traffic mixing at unmodified nodes.  I understand the L4S approach to achieving safety at unmodified nodes to be use of TCP Prague, specifically its heuristics that detect RFC 3168 bottlenecks.  As previously discussed, this traffic mixing does not cause problems at otherwise unmodified nodes that use FQ.

For the proposed Internet-wide L4S experiment, the technology to be tested is necessarily experimental, but the safety of the experiment needs to be fundamental to avoid serious damage if things go wrong.  I do not currently see a strong safety case for L4S+TCP Prague - an example of such a strong safety case can be found in QUIC congestion control, where the fact that it is based on NewReno congestion control provides strong assurance that QUIC congestion control is safe for the Internet.   In contrast, TCP Prague is still research (it's great research and I applaud the people who have invested their time and effort in it for what has been achieved), but a safety case ought not to be based on not-yet-stable research, and I don't think another 6 months of testing and bug fixing will leave TCP Prague as anything other than research (ruling out group 3 for me).  Further, the L4S low-latency service will likely be used by protocols other than TCP Prague, which may not receive the level of scrutiny and testing that has been applied to TCP Prague.  The safety case needs to come from elsewhere.

If ECT(1)-marked traffic starts causing problems, network operators are not going to wait for TCP Prague or other protocol implementations to be patched - they're going to take action, e.g., as Neal Cardwell describes (and I've heard about this sort of potential consequence in other conversations, so please don't blame Neal for this):

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

In contrast to reliance on TCP Prague, that combination of FQ and bleaching looks like it could provide a robust safety case.  It would be most unfortunate if things wind up depending on this, especially bleaching, as the fact that ECT(1) is not bleached at network boundaries was a major reason for selection of ECT(1) as the identifier for low-latency L4S traffic.  Among the implications is that if the L4S experiment fails, that bleaching could be around much longer, making it infeasible to use ECT(1) for anything else Internet-wide.  In my view, it is the responsibility of the L4S proponents to design the L4S  technology and structure the experiment in a fashion that makes ECT(1) bleaching unlikely and/or likely to be limited in scope if it happens.

Thanks, --David
----------------------------------------------------------------
David L. Black, Sr. Distinguished Engineer, Dell EMC
Dell Technologies, Infrastructure Systems Group
176 South St., Hopkinton, MA  01748
+1 (774) 350-9323<tel:+17743509323>           Mobile: +1 (978) 394-7754<tel:+19783947754>
David.Black@dell.com<mailto:David.Black@dell.com>
----------------------------------------------------------------