Re: [tsvwg] regarding L4S issue #22 new defect Deployment feasibility

"Black, David" <David.Black@dell.com> Tue, 03 December 2019 21:24 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 51CE912003E for <tsvwg@ietfa.amsl.com>; Tue, 3 Dec 2019 13:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=OOSrIu0E; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=I71sHA02
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 Ceoy05XgQdWd for <tsvwg@ietfa.amsl.com>; Tue, 3 Dec 2019 13:24:55 -0800 (PST)
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 9F56012002F for <tsvwg@ietf.org>; Tue, 3 Dec 2019 13:24:55 -0800 (PST)
Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB3LOq60028332; Tue, 3 Dec 2019 16:24:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=pNWDmeU7GIwhTgEw8209g1XXIRpIkYv+KDmcw84NqSU=; b=OOSrIu0E92RQX2ekL6YHTXqrOdus5LZYZmvPiV7rSJkgd5qL8doiv02G5eKYHPq1ol2Z rb2Jcy4sLklYFLO1ZkwbaYISGys9TUjdi/rAe3k57rVW99XtvXqAu4jv8thA8Nj3MEmW 7t6bZknJt/YdZg8ApxyDTDSy2fIOC5fWPAw87i69B5SLqZKKH/PDetxm8gLe30LWZUql A4n7i2RQPBXdJCYugMk4MI02oSp8kHied4oeoC3JEoJQQ8SOou6D998qLaRziKV65bHJ tayTsqZWY0r7RoupFZfgI2ln4nwLUZE5wZCF9KgTBr5NO+nwyhvGPjc5DVIJZ80oqNgD ow==
Received: from mx0b-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2wknanefpx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Dec 2019 16:24:52 -0500
Received: from pps.filterd (m0090350.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB3LIJGb133386; Tue, 3 Dec 2019 16:24:50 -0500
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2054.outbound.protection.outlook.com [104.47.36.54]) by mx0b-00154901.pphosted.com with ESMTP id 2wnvhytnfx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Dec 2019 16:24:50 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XvaOa3Qg6QjShMdOv1oS4P461qfRupXup3W7qfxt9qf8wd6MUkvHKpBylbPlQM1MS2O/pB9T39TbivyNqEjmoyKseaeRliMWzTZgG+OmHyFWAy03CKGb0hSb2JaBCSa9uFwOVz0TMU3mO3KJ9wuqM8fHXjisPxao67l87wH8bGlBomPNTIrBaOLMpTIg0g8BIQd0/nd+KSussIZquU1JpHcVSHe7iWC30jZMlr+aBKRjnJGthzIXSBg562LafyjE1gPrvLWiIBA9lr2uSDtcn58+mct7bUmKwROSkkhYnnTltbdVC0A9/sQ3vGVOxLzvRi7cPM5kjQ2VGVKBmetLiQ==
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=pNWDmeU7GIwhTgEw8209g1XXIRpIkYv+KDmcw84NqSU=; b=WoD2btPpiNBZLp6Ul4KuVRmiahtdeX8aE+8U4+HzxTRidIluFKT6Up27/ybhL0Jk1KmAXrtgvQyhnrgQ7aScr1s+fYnPT33B1mxuJF2VpQbH2dCKnlta5GXIcOA65ewydTuTs8pGV8mOyf4DqJ4dF/b6A3vy+6lru/pfblZUz9VBEZx0jPM4BHOmkqr3Qr1VHkC9M8NpRUlSZ6jk+joNwY2hTGdUjfm8aGmXsxM5ijWcTtv8ndBgg5urnyPF6Hqjyx13MDBHLoZGMoE8OG9RhuIP41OGBdCLOeKjg6aO65+Yk8jh3L4iFCrpjnT+lMxOyqMg6tXGjdQQQgQoc3TRsg==
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=pNWDmeU7GIwhTgEw8209g1XXIRpIkYv+KDmcw84NqSU=; b=I71sHA02mQ8fruFAOvjeqIvr81R23O2EM8g2hH+NgipWyZw3evf2Z+EWt7yGwSpNXzC2lMiTKxSV2o5MzbPDbgdobCNVld3YzEBSz68gojePoahLOko8km7ViTlA+4ozN/S7GCtgtvsSAGzrIj67ldFEL5evyZbALKOUWpSEgNM=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3133.namprd19.prod.outlook.com (10.255.180.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Tue, 3 Dec 2019 21:24:46 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::9ce:496d:8c66:87d4]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::9ce:496d:8c66:87d4%7]) with mapi id 15.20.2495.014; Tue, 3 Dec 2019 21:24:46 +0000
From: "Black, David" <David.Black@dell.com>
To: Sebastian Moeller <moeller0@gmx.de>, tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [tsvwg] regarding L4S issue #22 new defect Deployment feasibility
Thread-Index: AdWqIBVX+LEgsdU6Qq6i5r7gCb8T9A==
Date: Tue, 3 Dec 2019 21:24:46 +0000
Message-ID: <MN2PR19MB4045424F1F0FBA9817A4B1E283420@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=2019-12-03T21:20:35.8928452Z; 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_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fffc7021-ae13-4b09-643a-08d7783738e9
x-ms-traffictypediagnostic: MN2PR19MB3133:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB31338E02CB0C8042B5BB347083420@MN2PR19MB3133.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(136003)(346002)(396003)(7502003)(53754006)(189003)(199004)(13464003)(5383002)(3846002)(86362001)(7736002)(14454004)(316002)(6116002)(786003)(99286004)(478600001)(107886003)(6246003)(25786009)(33656002)(9686003)(66574012)(55016002)(2906002)(8676002)(229853002)(81156014)(6436002)(74316002)(305945005)(4326008)(5660300002)(71200400001)(66556008)(66476007)(64756008)(66446008)(71190400001)(76116006)(66946007)(52536014)(6506007)(53546011)(186003)(256004)(102836004)(26005)(14444005)(81166006)(110136005)(7696005)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3133; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4TXqUhUhqDusVYjMNwLGCs4Tk3mB/A3HC4QgdIYQdMiDQFS+nAX89j/o8pFq+KQ4iKd22o3r77zCgs8Im+1h6C7MFx7DKKv/2wgPRIST9V82UuXXuTFLct3/h/z6vm0xMW869UIZBNEJwI3c5Bk+lFrHUn0rMIZEkGtPuKUMbxXrWEA8tbVtdkFwhMe19gORK7eoGx7H6X3/8Tr7/VmKEvKrZhhpaoOTa7TtjX+jFnC3WkniJ900kSzTR9YQbIf5kZd8vr5IoDjQki/bC+l+Me8Jr3sSdaviiGHg0Z3hoeGxecwikc0RL4EkFJCVyP0tILDT0E5BpVDybmlZvFQksvletwhGnuWpE/2PcTBznnZBxPE/5EsGIKugygy3yKcVPVg1jIWn7Qh80iX3cLDp+agR0ZMNM7S9BwaIu0tF1njr1mu7qdbwY+HfjPHEuRj9
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fffc7021-ae13-4b09-643a-08d7783738e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 21:24:46.8314 (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: A/+givks2Ll05C/KJek3/e5z22vKgdfUy8zVXEEAY/xPGsZz20qrmj+irlVttV8HoOnjHre5Y/FSjIeB26Pr+g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3133
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-03_06:2019-12-02,2019-12-03 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 mlxscore=0 spamscore=0 priorityscore=1501 phishscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912030158
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 clxscore=1015 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912030159
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qNIhSGd5kw_98oRr47wByIKlOK8>
Subject: Re: [tsvwg] regarding L4S issue #22 new defect Deployment feasibility
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: Tue, 03 Dec 2019 21:24:57 -0000

Hi Sebastian,

> I just had a look at the issue tracker and for L4S issue #22 I see the following text:
> 
> "Issue #16 is the only identified incremental deployment issue. "

It's not easy to tell from how the tracker is displayed in a browser, but that text is part of a comment from Bob Briscoe.

> But the truth of the matter is, the L4S reference scheduler does not even
> manage to guarantee that equal sharing robustly, as testing of both the L4S
> and the SCE team confirmed. This issue is especially relevant with the
> internet wide scope of the desired dual queue AQM roll-out, and can hence
> not be solved by affected end-users by imply not using L4S/ETC(1) flows
> unilaterally, and the fact that end-user to CDN RTTs are getting shorter and
> shorter.
> 
> 
> I would like to kindly request this issue "failure of equitable sharing between
> L4S's two queues" to be added to the issue tracker and also being addressed
> in the L4S arch and the dualq drafts, please.

Please add a short summary of this concern as a comment to this issue in the tracker, including some of the text after "But, the truth of the matter is,"  (above) to shed some light on the specific scenario(s) of concern.  That'll help ensure that this concern is not overlooked.

Thanks, --David

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Sebastian Moeller
> Sent: Monday, December 2, 2019 4:02 PM
> To: tsvwg IETF list
> Subject: [tsvwg] [tsvw] regarding L4S issue #22 new defect Deployment
> feasibility
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi all,
> 
> I just had a look at the issue tracker and for L4S issue #22 I see the following
> text:
> 
> "Issue #16 is the only identified incremental deployment issue. "
> 
> And I am not convinced that is true. The fact that L4S's designated sharing
> mechanism the dual queue coupled AQM does not robustly and reliably
> share bandwidth equitably between the L4S and the standard queue looks
> like a relevant deployment issue.
> 
> I am pretty sure none of the end-users exposed to L4S will expect that
> (short) RTT L4S flows will basically throttle all other standard (internet-size-
> RTT) flows. A naive reading of the L4S and dual queue RFCs gives the reader
> the idea of equitable sharing between both traffic types, which already
> seems rather generous to the new comer L4S. Essentially with that prima
> facie reading, a single L4S flow might take the same 50% of the bandwidth as
> an arbitrarily sized flock of flows in the standard queue, giving L4S a
> noticeable boost given the relative likelihood to encounter L4S versus
> standard compliant traffic sources on the existing internet.
> But the truth of the matter is, the L4S reference scheduler does not even
> manage to guarantee that equal sharing robustly, as testing of both the L4S
> and the SCE team confirmed. This issue is especially relevant with the
> internet wide scope of the desired dual queue AQM roll-out, and can hence
> not be solved by affected end-users by imply not using L4S/ETC(1) flows
> unilaterally, and the fact that end-user to CDN RTTs are getting shorter and
> shorter.
> 
> 
> I would like to kindly request this issue "failure of equitable sharing between
> L4S's two queues" to be added to the issue tracker and also being addressed
> in the L4S arch and the dualq drafts, please.
> 
> 
> Best Regards
> 	Sebastian
>