Re: [tsvwg] Your NQB presentation
"Black, David" <David.Black@dell.com> Tue, 03 December 2019 21:35 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 ABCB7120077 for <tsvwg@ietfa.amsl.com>; Tue, 3 Dec 2019 13:35:56 -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=b/5K4ajM; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=JwjUVU0B
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 1vNvLOlg2fmX for <tsvwg@ietfa.amsl.com>; Tue, 3 Dec 2019 13:35:54 -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 3B4AF120072 for <tsvwg@ietf.org>; Tue, 3 Dec 2019 13:35:54 -0800 (PST)
Received: from pps.filterd (m0170393.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB3LUC9v027708; Tue, 3 Dec 2019 16:35:47 -0500
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=ifYsE3GndqBBjYwnP1VqRzcozkR9zW47l75NqC1JlaE=; b=b/5K4ajM9EANxI3UsnWlIqIbAprzSU3ulzQeVxv8iymkdArhuv3gxzFhIHNGF2AxCstJ PBYi3QkySjOhoSSzmmF4F1KbTC2jj0YxUv57YZgwtIb5H7e8hKlLARB9QpYG66yLumAC 6HwuTSGZuCWn7UCXzAmjYpugY8NEdkUok+P4+wF7YdC3frSmeRSKtmPPWH88WRHFuurM B07MmsU7gaVs7Xwc1G+iWH2JDr4OOrntaBmISCG6c/F+6Vj0TcBm7AY5agYNQewATNFh a6z2vETkzI9CewvdO3KUfucemLS9vfv4CG1Jl+0SLPoXE7Jd96ZvklWsjHJIKb7mDVGm fA==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2wkmmm6haf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Dec 2019 16:35:47 -0500
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 xB3LRVcK114201; Tue, 3 Dec 2019 16:35:46 -0500
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2059.outbound.protection.outlook.com [104.47.32.59]) by mx0b-00154901.pphosted.com with ESMTP id 2wnfhux7fx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Dec 2019 16:35:46 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZYkz3mxahM3XV/GxtQLmizEQpJLoIuuWUV6YmJ+sK9qvMRY0JjQFRTJdOm2NfY2dX3fJ7EwDH9uY7Ez7Au7S3FwTlhj6OQwU6pzhhArEkstptyjHxNfR14hPU1OQ2t52Xc11twvLwXPmeclbXEXAc2L63E2fN4AvHSqqjykuuxa3jioVfBa9LGDLSHoNSRZnx79D25DNy/RMKzNMfIOzpJZwywSiI/U5/nr99uh6Wy9pnvvQu+ONT5LDOCVs2aCjfZQvddH6V1OvMkekzJ5TbE0EMUKadV+e2xnp5lWrMdzcnZ4gva5/e+aRVcCAIS2ZxnilVBWuqRKUCPXaJUo3UQ==
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=ifYsE3GndqBBjYwnP1VqRzcozkR9zW47l75NqC1JlaE=; b=RriEpLYmOo4L2ZepyxGZYLChWpFFPcoTX+0NsUyx2FpMo6qCo61VimOyAbwghD3vcYjoFnG70vGgI+YFfZydtkU+vySXbcXqj+k4Sjdj3lYSLMMn4WJ/ACowkCUdU0qPj5EIwwkGIJSFOAdHBMfX9aywfd28/oXaQX8/Pwp7OmB2gqHQxvt4RBas+JIzg/B68JXQqvBAsK/0fc0q2j323ORuA7WT2XMftG8Do5BMYCpD0QIaI2zEnuJqjuQkx4TOPdtgr7wc6DZ7CfPnBn7Qp5jWS1Fiy3lTz99aIVfxPZULksp7eK8E8xs9Ax2c79gUp5WJDjVHU6T316F6pqfASg==
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=ifYsE3GndqBBjYwnP1VqRzcozkR9zW47l75NqC1JlaE=; b=JwjUVU0BR0d9INRm8uC6Vogu65gMmoDWPC/vl48Is71Jfe2eMsXtGkZjzYzgU4XABuHOZcEjUCwjk27QgvZ0fIEB1LlgsoM62OZOmgZw+B27GJIk3g6razWcVg99B2rKaqotYrdNMTGzUG5ngLKIGWRKt8basJf9Nl8DexsMnQE=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3470.namprd19.prod.outlook.com (52.135.37.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.21; Tue, 3 Dec 2019 21:35:35 +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:35:35 +0000
From: "Black, David" <David.Black@dell.com>
To: Sebastian Moeller <moeller0@gmx.de>, Greg White <g.white@CableLabs.com>
CC: tsvwg IETF list <tsvwg@ietf.org>, Michael Welzl <michawe@ifi.uio.no>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] Your NQB presentation
Thread-Index: AQHVoNRcHaf5HMvPdkidXvMItrLKVKeWej8AgAALFICAAFqkAIASHypg
Date: Tue, 03 Dec 2019 21:35:35 +0000
Message-ID: <MN2PR19MB4045A5AF7BDBB95EA77720BC83420@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <B654E9D3-A5E2-45AC-A4D3-E86757263CFB@gmx.de> <490F228F-57B3-430F-ABC8-38350E44EAC7@cablelabs.com> <AAEB98A9-9524-4772-B9D2-95E10DD90677@ifi.uio.no> <B2BBC082-8D8E-417A-BD85-E4BDD577A503@cablelabs.com> <A0B8EDE2-6D85-48CF-A86F-D869B1A5D55D@gmx.de>
In-Reply-To: <A0B8EDE2-6D85-48CF-A86F-D869B1A5D55D@gmx.de>
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:35:34.5087727Z; 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: 8d64781a-3d02-4953-4b0c-08d77838bb6d
x-ms-traffictypediagnostic: MN2PR19MB3470:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB34707E906122C9B9AA9602C683420@MN2PR19MB3470.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)(346002)(39860400002)(366004)(376002)(136003)(396003)(199004)(189003)(7502003)(13464003)(81156014)(52536014)(54906003)(110136005)(316002)(8676002)(446003)(5660300002)(99286004)(74316002)(2906002)(229853002)(11346002)(786003)(256004)(33656002)(561944003)(86362001)(305945005)(8936002)(71200400001)(478600001)(966005)(71190400001)(6436002)(81166006)(66574012)(66946007)(102836004)(25786009)(66476007)(6246003)(64756008)(76176011)(7696005)(66556008)(4326008)(3846002)(6116002)(76116006)(14454004)(66446008)(53546011)(6506007)(107886003)(6306002)(26005)(9686003)(55016002)(186003)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3470; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 9iTugEk02ExxQQh8yb3vFUedK3hmjGhQNrGnSFpYhX0taIs3MkAVs4qwvhSG1mz6fKuXTPD1WEhAEvdHwa2fG9FWz/GTEaUxFCLW6kO30yf9GMPAXbHu7Iww4d8rq+mMQbdd3kgBYqK+7qDUWDWSe7inyurE4QUQPjZsqFgOHvtMCcguUgTeS0LceHR5n9gTH6/HJXNq6BmN2J4yjyzyuL7UcIrP10PV0EzSwCHLnDA0gjsUwvo8NDAm13maC+rsKOGOqmhvoifLwNq7ufc1Vu3pqthZgf8Oa4EWDQG09BVHUZocDPHC8tEO/+AFHt4v98GRbgQPpdRR+Ia7Zq8+3cS0cq/NpXExNwmivroQAglENlTNyvmhRkVyMJVFZg9hS18TCpUgnzR9W51qrhCSLUkga24fOzbeDm8pjplqDbRCl7nj6A6RhXLWTqWD/RCZc6wHWBLzNIoyf1qMEJx7KMxGLcT/xOWzcfewo40qEjI=
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: 8d64781a-3d02-4953-4b0c-08d77838bb6d
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 21:35:35.3431 (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: YXZwMQVEpZpCfjqJhYKpNfd43lnu7T7sv1GPJ8aXi/9Qv+hRZPX/w8e8/lwjLEYnCRlGuQqlaAUGC6x1pWb98g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3470
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 mlxscore=0 malwarescore=0 phishscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 suspectscore=0 clxscore=1011 spamscore=0 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912030159
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 phishscore=0 adultscore=0 spamscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912030160
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/OZDlAhDg_EndOmym1K6OD6vwWJg>
Subject: Re: [tsvwg] Your NQB presentation
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:35:57 -0000
Inline ... Thanks, --David > -----Original Message----- > From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Sebastian Moeller > Sent: Friday, November 22, 2019 3:43 AM > To: Greg White > Cc: tsvwg IETF list; Michael Welzl > Subject: Re: [tsvwg] Your NQB presentation > > > [EXTERNAL EMAIL] > > Hi Greg, > > > > On Nov 22, 2019, at 04:18, Greg White <g.white@CableLabs.com> wrote: > > > > Hi Michael, > > > > Thanks for sending the reference. I only scanned it, but on first blush I > don’t think this study reports on the situation that we’re discussing. I likely > missed it, so if you think I’m wrong, could you point out where in the data it is > reported? > > > > To be clear, I think the specific situation we’re talking about is where a > residential ISP allows DSCPs marked by 3rd parties to be delivered intact to > their residential customers. How many of the 39 “Home Network” nodes in > that data set received DSCP marked traffic that had passed through an > interconnect? > > [SM] I have a bad feeling of taking something completely arbitrary as > assuming DSCP bleaching as default as part of NQB's safety considerations. > To add anectdotal data to Michael's and Gorry's studies old ISP, DT, has this > idea to use 3 address bits in IPv6 for their own prioritization purposes and > leave DSCPs otherwise untouched. I ran a few rrul/rrul_cs8 tests back in the > day ans saw CS5 dscps on the incoming packets. I believe the upshot of this > is, that currently DSCP conservation over the internet e2e is too unreliable > both for assuming absence or presence of the senders mark during transit/at > the receiver. Describing this in the RFC seems helpful, but please let's not > design a system where the default line of defense against misuse is to relay > on the "internet" to do something reliably to DSCPs. [David>] That's not what's going on with the requirement that Greg and I have discussed. The intent of that requirement is that any equipment that supports the NQB DSCP has to be configured by default to bleach it to best effort (e.g., as shipped from the factory) on interfaces that may send traffic into WiFi and related networks. Hence, if unbleached NQB traffic gets sent into such a network and causes problems, someone actively did something to cause that to happen, and undoing that would be a good first step ;-). > If I understand it correctly most new proposals for DSCPs/PHB also > expect/hope/argue for making DSCPs end-to-end, so it is not completely > unlikely for DSCP survival to increase over time instead of decrease. In the > light of this I think caution is warranted in regards to the non-managed NQB > scenario, where the sender marks NQB (and that is fine/correct) but the > network path does not re-map the DSCP and the leaf networks wireless AP is > just using the default DSCP to AC mapping. Out of the three components the > first is currently rare, the second less rare, and the third rather the norm. [David>] When we get the intended requirement expressed correctly (stay tuned, don't have precise text, yet), the network path will be required to default to re-mapping the DSCP - if that remapping is removed to preserve the DSCP, someone or something made a conscious decision to do that. > > We already established the potential for negative side-effects* of > too much NQB traffic over AC_VI and agree that proper management, by > either the (then NQB-aware) AP or the upstream network admitting the NQB > packets into the leaf network, is a valid and (if done conservatively) sufficient > remedy for reducing the level of side-effects to an acceptable level. > > What I worry here, and why I would recommend to use a DSCP that > maps to AC_BE unless the leaf network is known to handle NQB over wifi > properly, is that in the generic case, the existence of the benevolent entity > controlling the NQB rate simply is not guaranteed to exist. I am just a user of > limited phantasy, so the only solution I came up with is to use a NQB DSCP > that by default maps to AC_BE, which NQB-aware APs can and should treat > differently, and that a benevolent controlling ISP can, if it safe to do so, > "escalate" to an DSCP that maps into AC_VI even on non NQB-aware > hardware. > > I realize that my proposal suffers from the fact that on non NQB- > aware wifi networks the upstream traffic will not map into AC_VI, but I > consider that to be a fair and acceptable the price to pay for peaceful > coexistence with existing wifi networks. The core of the NQB rationale and > use is very much about not using prioritization and assuring equitable sharing > between the NQB and QB queues, which I fully endorse. I fail to understand > why this principle should not apply on wifi. > > "5. Non Queue Building PHB Requirements > [...] > The NQB queue SHOULD be given equal priority compared to queue- > building traffic of equivalent importance. The node SHOULD provide a > scheduler that allows QB and NQB traffic of equivalent importance to > share the link in a fair manner, e.g. a deficit round-robin scheduler > with equal weights." > > > I fully endorse this (especially the "equal priority" and "fair manner" > qualifiers) and just think that this also should be taken into consideration > when selecting a DSCP in the light of the probability of un-controlled NQB > traffic hitting a not NQB-aware wifi network. > > By now, I believe I have iteratively refined my argument and rationale, and > assume whoever is convincible by this line of argument is convinced, and > who ever is not convinced will never be. So I will try to refrain from posting > this rationale again unless prodded to. > > > Best Regards > Sebastian > > > > *) Simple rrul_cs8 testing shows that both AC_VO and AC_VI flooding traffic > can/will completely starve out AC_BE traffic. > > > > > > > -Greg > > > > > > From: tsvwg <tsvwg-bounces@ietf.org> on behalf of Michael Welzl > <michawe@ifi.uio.no> > > Date: Friday, November 22, 2019 at 10:38 AM > > To: tsvwg IETF list <tsvwg@ietf.org> > > Subject: Re: [tsvwg] Your NQB presentation > > > > Just as a data point, > > > >> I think we share the belief that the vast majority (all?) residential ISPs > currently bleach ALL DSCPs to default for their residential customers, and so > the 0x2A value will already be handled in the same manner, but these > requirements and the (to be written) informative text will help ensure > operators only deviate from that default state consciously. > > > > “all?” / ALL would contradict with at least one measurement study. See: > > https://www.sciencedirect.com/science/article/pii/S0166531619300203 > > (where at least the ARK nodes count as “residential”), and references > therein. > > > > Cheers, > > Michael
- [tsvwg] Your NQB presentation Sebastian Moeller
- Re: [tsvwg] Your NQB presentation Greg White
- Re: [tsvwg] Your NQB presentation Black, David
- Re: [tsvwg] Your NQB presentation Michael Welzl
- Re: [tsvwg] Your NQB presentation Greg White
- Re: [tsvwg] Your NQB presentation Michael Welzl
- Re: [tsvwg] Your NQB presentation Sebastian Moeller
- Re: [tsvwg] Your NQB presentation Black, David
- Re: [tsvwg] Your NQB presentation Sebastian Moeller