Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions

"Black, David" <David.Black@dell.com> Fri, 08 November 2019 23:43 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 95286120147 for <tsvwg@ietfa.amsl.com>; Fri, 8 Nov 2019 15:43:26 -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=Chla64pX; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=KjXP+0XW
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 ZSZ_A-f4fIaA for <tsvwg@ietfa.amsl.com>; Fri, 8 Nov 2019 15:43:21 -0800 (PST)
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 2BB6C1200C3 for <tsvwg@ietf.org>; Fri, 8 Nov 2019 15:43:21 -0800 (PST)
Received: from pps.filterd (m0170394.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA8NeQ9k019745; Fri, 8 Nov 2019 18:43:15 -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=sZsP49z54fByzRl592kS7epi7wZa62UvK3Ja9nCLkeY=; b=Chla64pXWGZenK4B0LfIaeHIHTWXf8BJYMm9ffrPjSrX/fhutCIctp5A6750GAww5+Lm LAdBF9tTaL9QZc4A/LBc1UHOyQiqW4GkGW4Oeb+94vTbsNugAVd/mmHXmTTg/NhElivc BSwzCBopi3Rdq1mErITIM5/7pE/NS0wF0iPZrhpWbEyKhSrbnrSRSh4cNmsfAgYzTwPV DYzFxjpV/3jgwfwIYq9dB8FbtWsN/RhJ3Par70KMzf1f/XiFK6uYUIaNNIxm7arFMQbW ZufCDCRyJsOGAZZF/ys+SW+lbhUWdG/I7Sc9g73O3KiMctGlIOaXV8hLws91VUXnqyBc +Q==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2w5hg584yj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Nov 2019 18:43:14 -0500
Received: from pps.filterd (m0134318.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA8NbwfQ184022; Fri, 8 Nov 2019 18:43:14 -0500
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2052.outbound.protection.outlook.com [104.47.38.52]) by mx0a-00154901.pphosted.com with ESMTP id 2w5hfr0kux-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 18:43:14 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z7SXKOsfrDvr9hqT6cJE1gMvwxhT6ry12rL2RN5ReTu7z/VIx1k/2ZsouKhDD1oaJIHd+HKihSUbD66ar2arAiiHybnpKv7P6xyYNT7u/ZTH6s6w1kYadOSK4WgsjjibBZreuGpV9/h17/8XKqjVDuaMZa3lyYcQi5jti9OhaFKqwYRmJc1r9kXRcM/sBYkBsuYhpsQzZ+exrnBaxeihrwpRWKj6rF94w7e4i7JKpKugRGj1pyjeFMaKCFmzMLMjOKWezA7c14X8Mj+fe5yYisvA9NnX/nT5DPR6KtO7z9/2eSU7Ce1xGx56PTfl/KrbAfWzLP02uKMfa9pGjsC2Zg==
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=sZsP49z54fByzRl592kS7epi7wZa62UvK3Ja9nCLkeY=; b=Sy+JqXZxV7sZh3ljt0+t56p+Z26HnqMF+xdQZ9nqPSzyoxcu/3eYHaWzp5xDDhn7PRZGkc7abNR+Mg8k7bv/8GS6fXTr/9EnWjr7YHqC/v4D0MTXz9Gm1dPv1VwD0WbRxrlB9C5ZbGW/BshQVORX56cH16MQSa0maUbULfEB1TFWQSQeyZeLXFb4jiCuJ/dyYoC4Kdcx+9OhU6w28SeNk0Bs/EcG3hOlzJy0UcvLX1lQ9Z+lnn/n6X7YXWZki81SQLCl+0ox7iyIM4f2pFc+0IglWKCzsJjtsX6q1PpV8HA9/FiqkelaUN38CSct9xM5zAEwCjBoalg96HEFj7fPtw==
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=sZsP49z54fByzRl592kS7epi7wZa62UvK3Ja9nCLkeY=; b=KjXP+0XWQeOgbx1BaicghKR4R8dXng6bsSpUbgTHrWXVhGeCkxsj5Cd9neKFEyYAQiF4eJWp3Xg+ll4ZTkLuhDWzhSuGAmh2Lg2SF/R4i+5FHgsv7T2Mke1Z1sghzeUAD6R+d11ZYaHW0PbpsXh5ZWt86/bcrnWBDvhRB6t27GM=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB2575.namprd19.prod.outlook.com (20.179.83.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Fri, 8 Nov 2019 23:43:12 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594%6]) with mapi id 15.20.2430.023; Fri, 8 Nov 2019 23:43:12 +0000
From: "Black, David" <David.Black@dell.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Greg White <g.white@CableLabs.com>, tsvwg IETF list <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] draft-ietf-tsvwg-nqb, more questions
Thread-Index: AQHVk168g4JkWCsXvkKSWKsK//1LrKd7uScAgACOhICAA/GTgIAADZmAgAAMUoCAAAeRAIAAAlwAgAANqoCAAAnggIABPfSwgAA9qACAAAEgcA==
Date: Fri, 8 Nov 2019 23:43:12 +0000
Message-ID: <MN2PR19MB4045EEFDB1F3CE84DC0ECF77837B0@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <90ED003C-CC25-4ED4-90D8-BA572E39D852@gmx.de> <AC0FF00A-9AA7-4582-8F96-1E4E27AEB8D8@cablelabs.com> <20DE8A61-AD71-4C60-A90E-1CCB22E3C6BE@gmx.de> <FA5AC140-F5AA-410B-8067-1B042868049A@cablelabs.com> <CCE580A4-4075-4E2D-9392-DB35389F289B@gmx.de> <28A4C4A8-91C6-4C3F-8563-F862A7247833@cablelabs.com> <084B4D20-5A54-45EE-9519-469BC860C088@gmx.de> <D6C969B0-1F24-434F-9C5C-376BB6C61F8B@cablelabs.com> <E005A81D-6A48-4CF6-A262-BE3F891D5714@gmx.de> <E9A88675-15A2-4D00-AB17-B1F5AD39EB89@cablelabs.com> <MN2PR19MB4045880399E027F159164051837B0@MN2PR19MB4045.namprd19.prod.outlook.com> <449D8EE5-0EA0-4B6C-8C66-4456D238044C@gmx.de>
In-Reply-To: <449D8EE5-0EA0-4B6C-8C66-4456D238044C@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-11-08T23:43:05.6454106Z; 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: [168.159.213.213]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 824f4103-0d48-4f59-9a54-08d764a56b23
x-ms-traffictypediagnostic: MN2PR19MB2575:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB2575C902BF25188DCD6CFD5B837B0@MN2PR19MB2575.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:143;
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(366004)(136003)(13464003)(52084003)(7502003)(52314003)(199004)(189003)(66066001)(14454004)(6436002)(71190400001)(55016002)(8936002)(9686003)(6306002)(786003)(76116006)(66946007)(71200400001)(54906003)(446003)(64756008)(2906002)(486006)(66556008)(316002)(66476007)(6506007)(256004)(11346002)(476003)(14444005)(66446008)(3846002)(229853002)(4326008)(53546011)(186003)(99286004)(52536014)(561944003)(6246003)(966005)(33656002)(25786009)(102836004)(478600001)(305945005)(107886003)(5660300002)(7696005)(74316002)(86362001)(26005)(76176011)(30864003)(81156014)(81166006)(6116002)(8676002)(6916009)(7736002)(66574012)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB2575; 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: Xohrk2s79EOVGjwYbPYMTWoGWwQv80yupt25nW2uygdD3/9DTC2IXsqouXPSelomNdY1Gp25VADLD8OMZ9yccLP+ZRcLl8QSUpwDx6AnEPdgtm2Uj/9Ksn1FhaDabv/Kb7m09/ZRsIR3hVdLD3XbZU3gki9uC0l0PKoGfZX0fW/ecZZf1Srxl9xgNBO3KLIkqSaguPnMgIBlz6nZq2pRxwISvaslHIL/BXDo/dGjw5f2IyVnmfTtdJotV/V6bfGfCu0KWa/NE66RW96jAiJtumKajGGiiy0LHyS6B90eO3ixw7ldHJziZdjTSJpAPYgI3YHD1jAcPUNG/hHVNTA+97TNJiybhu4o28v5CZkTyk0KlX/4w9llhj3UQcpRb1z919fG/yIzZet57TQ2f9vO35/ao+DiojnkyK9irx0GQ5TMuMxEo/k8Ia//uX8MCQMYLElVJOF5xwXOihiRHAUaeJ3B+Z83Byv+3wK/AXT3Ifn1cic6QbUo25KW7lXJ7VI1
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: 824f4103-0d48-4f59-9a54-08d764a56b23
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 23:43:12.4000 (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: CDi8wkhmRnbZVJqFkhYvTPRL1P6jAg6oeYL+diR36pz9HqF5AYM7VH5GovfYljC4TUpc4ArmbAEO7NTbIJin8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2575
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-08_09:2019-11-08,2019-11-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 adultscore=0 impostorscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911080226
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 clxscore=1015 phishscore=0 impostorscore=0 adultscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911080226
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1dvrlO2jDXJYGwbM8vUp2-zm9Qk>
Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
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 Nov 2019 23:43:27 -0000

Looks like progress - more inline ...

Thanks, --David

> -----Original Message-----
> From: Sebastian Moeller <moeller0@gmx.de>
> Sent: Friday, November 8, 2019 6:23 PM
> To: Black, David
> Cc: Greg White; tsvwg IETF list
> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
> 
> 
> > On Nov 8, 2019, at 20:56, Black, David <David.Black@dell.com> wrote:
> >
> > Hi Greg,
> >
> > Backing up a few messages, I might have found a way out of this debate.
> Sebastian wrote:
> >
> >>    	[SM] Sorry with source, I was not talking about individual senders,
> >> but about the "NQB/L4S complex" that I expect to cause a lot of NQB marked
> >> traffic to appear on the ingress side of home users once it gets off the
> >> ground.
> >
> > That specific situation appears to be straightforward to address because
> the edge of the ISP network that supports Diffserv is involved.   Specifically,
> the specification of the NQB PHB ought to include text to the effect that
> outbound NQB-marked traffic MUST be rate limited at the egress from the
> Diffserv domain/region if the downstream (receiving) network is not known
> to support NQB (this is not the precise language, but should convey the
> concept).
> 
> 	[SM] I like this idea, I just wonder how that is going to work in the
> light of highly variable transmit rates on wifi links? IMHO AP & stations are in
> a better position to meaningfully rate limit than any upstream element.

[David>] Apply a generous "fudge factor" so that the NQB rate limit is well short of any rate that could cause trouble.  My initial sense is that this NQB rate limit limit is a safety limit that does not have an optimization goal, so the rate can be set well short of transmission rates that have a reasonable possibility of causing trouble.  As part of, this, I'm hoping that there's limited downside to remarking more NQB traffic to Default (best effort) than necessary in this situation.  I understand that the WiFi AP/station would be a more effective location for this sort of functionality, but in this situation, we are able specify the functionality of the immediate upstream ISP element, but not the well-worn WiFi AP that the user bought on eBay last week.

I would leave configuration of NQB rate limits to network operators.  Also, in extremis, zero is always a safe NQB egress rate ;-), so would it help to require that the NQB egress rate be configurable to zero?

> 
> 
> > In the reverse direction rate limiting NQB traffic on ingress (or outright
> bleaching it to best effort if the subscriber should not be using NQB in the
> first place) seems like a good idea, and may rise to the level of a MUST
> requirement if the NQB-supporting  network that the traffic is entering does
> not implement traffic protection for the NQB "queue" at each network node.
> With a little creativity, the necessary rate limiting might be able to take
> advantage of an NQB queue protection mechanism if one is present at the
> Diffserv edge.
> >
> > The individual sender situation appears to be of less concern, as at least in
> this case it looks like an instance of:
> >
> > 	If you point the gun at your own foot and pull the trigger, do not ask
> where the hole in your foot came from.
> >
> > As, at least for the home user, the result is only to damage her own WiFi
> network, particularly if the ISP ingress node protects its network from the
> user sending too much NQB-marked traffic.
> >
> > Thanks, --David
> >
> >> -----Original Message-----
> >> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Greg White
> >> Sent: Thursday, November 7, 2019 7:45 PM
> >> To: Sebastian Moeller
> >> Cc: tsvwg IETF list
> >> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> It seems as if you are arguing from religious grounds.   There is no
> "NQB/L4S
> >> complex" that is nefariously seeking to saturate your home network.
> >>
> >> So, I will try to ask the question again.
> >>
> >> If the policy that gets written into the RFC is that NQB traffic should not be
> >> high data rate traffic, then this achieves your objective?  If we include a
> >> paragraph like that which exists in RFC 8325 that explains why, in the case
> of
> >> WiFi networks, it should not be high data rate traffic, would that be
> >> sufficient?
> >>
> >> -Greg
> >>
> >>
> >> ´╗┐On 11/7/19, 5:09 PM, "Sebastian Moeller" <moeller0@gmx.de> wrote:
> >>
> >>
> >>
> >>> On Nov 8, 2019, at 00:20, Greg White <g.white@CableLabs.com> wrote:
> >>>
> >>> You've still missed the point.
> >>>
> >>>   	[SM] It will keep one expected major source of DSCP marked traffic
> >> on a sane(r) policy.
> >>>
> >>> No. It won't.
> >>>
> >>> What will keep that source on a sane policy is that they have an interest
> >> in having a sane policy.  This IETF draft does not create that interest, nor
> >> would it prevent them from running amok.
> >>>
> >>> -Greg
> >>
> >>    	[SM] Sorry with source, I was not talking about individual senders,
> >> but about the "NQB/L4S complex" that I expect to cause a lot of NQB
> marked
> >> traffic to appear on the ingress side of home users ionce it gets off the
> >> ground. And my point is very much to give my best arguments to make
> sure
> >> you do not end up writing a bad policy into an RFC. What ever you do in
> the
> >> real world is outside of the scope of the IETF, but taking that as an
> argument
> >> in favor of bad engineering is simply a bad argument.
> >>    	And regarding your interpretation of individual senders, it is clear that
> >> remote senders have a snowballs chance in hell to react timely to the
> >> variable bitrates on a wifi segment, hence the wifi elements AP (and
> ideally
> >> STAs) will need to enforce sanity and make sure tp avoid starvation. This is
> >> not a new requirement, but the status quo is that most traffic is AC_BE, so
> >> the lack of enforcement was sort of tolerable; but either NQB withers
> away
> >> and will not be used (and all of this discussion does not matter) or it will be
> >> used and then you better make sure that NQB will not be found out as a
> >> reason why non-NQB on-line gaming starts to suck. But really looking at
> the
> >> AC stats from my laptop:
> >>
> >>    laptop:~ user$ sudo netstat -I en0 -qq
> >>    en0:
> >>         [ sched:  FQ_CODEL  qlength:    0/128 ]
> >>         [ pkts:          0  bytes:          0  dropped pkts:    185 bytes:  55724 ]
> >>    =====================================================
> >>         [ pri: VO (1)	srv_cl: 0x400180	quantum: 600	drr_max: 8 ]
> >>         [ queued pkts: 0	bytes: 0 ]
> >>         [ dequeued pkts: 171322	bytes: 15967234 ]
> >>         [ budget: 0	target qdelay: 10.00 msec	update
> interval:100.00 msec ]
> >>         [ flow control: 0	feedback: 0	stalls: 0	failed: 0 ]
> >>         [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
> >>         [ flows total: 0	new: 0	old: 0 ]
> >>         [ throttle on: 0	off: 0	drop: 0 ]
> >>    =====================================================
> >>         [ pri: VI (2)	srv_cl: 0x380100	quantum: 3000	drr_max: 6 ]
> >>         [ queued pkts: 0	bytes: 0 ]
> >>         [ dequeued pkts: 1081254	bytes: 95307849 ]
> >>         [ budget: 0	target qdelay: 10.00 msec	update
> interval:100.00 msec ]
> >>         [ flow control: 0	feedback: 0	stalls: 0	failed: 0 ]
> >>         [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
> >>         [ flows total: 0	new: 0	old: 0 ]
> >>         [ throttle on: 0	off: 0	drop: 0 ]
> >>    =====================================================
> >>         [ pri: BE (7)	srv_cl: 0x0	quantum: 1500	drr_max: 4 ]
> >>         [ queued pkts: 0	bytes: 0 ]
> >>         [ dequeued pkts: 41792980	bytes: 10120070005 ]
> >>         [ budget: 0	target qdelay: 10.00 msec	update
> interval:100.00 msec ]
> >>         [ flow control: 9	feedback: 9	stalls: 8	failed: 0 ]
> >>         [ drop overflow: 0	early: 5	memfail: 0	duprexmt:0 ]
> >>         [ flows total: 0	new: 0	old: 0 ]
> >>         [ throttle on: 0	off: 0	drop: 0 ]
> >>    =====================================================
> >>         [ pri: BK (8)	srv_cl: 0x100080	quantum: 1500	drr_max: 2 ]
> >>         [ queued pkts: 0	bytes: 0 ]
> >>         [ dequeued pkts: 4392109	bytes: 1258595132 ]
> >>         [ budget: 0	target qdelay: 10.00 msec	update
> interval:100.00 msec ]
> >>         [ flow control: 2	feedback: 2	stalls: 2	failed: 0 ]
> >>         [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
> >>         [ flows total: 0	new: 0	old: 0 ]
> >>         [ throttle on: 0	off: 0	drop: 0 ]
> >>
> >>
> >>
> >>
> >>    and my OpenWrt router:
> >>
> >>    root@router:~# cat /sys/kernel/debug/ieee80211/phy1/ath9k/xmit
> >>                                BE         BK        VI        VO
> >>
> >>    MPDUs Queued:             4933        120       595     47628
> >>    MPDUs Completed:          2765        331      1045    110627
> >>    MPDUs XRetried:           2792         30       381       216
> >>    Aggregates:            4053416     109096     11152         0
> >>    AMPDUs Queued HW:            0          0         0         0
> >>    AMPDUs Completed:     29761018     931822    280598         0
> >>    AMPDUs Retried:         484203      23327      4543         0
> >>    AMPDUs XRetried:          8606        149       754         0
> >>    TXERR Filtered:             97          7        32        37
> >>    FIFO Underrun:               0          0         0         0
> >>    TXOP Exceeded:               0          0         0         0
> >>    TXTIMER Expiry:              0          0         0         0
> >>    DESC CFG Error:              0          0         0         0
> >>    DATA Underrun:               0          0         0         0
> >>    DELIM Underrun:              0          0         0         0
> >>    TX-Pkts-All:          29775181     932332    282778    110843
> >>    TX-Bytes-All:        672115293 1008162267 199579558  20417055
> >>    HW-put-tx-buf:               8          8         8         8
> >>    HW-tx-start:          21266021     570626    256944    110799
> >>    HW-tx-proc-desc:      21266026     570629    257004    110839
> >>    TX-Failed:                   0          0         0         0
> >>
> >>
> >>    Summary packet numbers:
> >>    AC	Laptop
> >>    BE:		 41792980	29775181
> >>    BK:		   4392109	    932332
> >>    VI:		   1081254	    282778
> >>    VO:		     171322	    110843
> >>    Total:	 47437665	31101134
> >>
> >>
> >>    So my status quo is that all four AC are used with the fraction of
> >> AC_VI+AC_VO at
> >>    100*(1081254+ 171322)/47437665 = 2.6 % (laptop)
> >>    100*(282778 + 110843)/31101134 = 1.3 % (router)
> >>
> >>    This is with relative high streaming media usage.
> >>
> >>
> >>    Best Regards
> >>    	Sebastian
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>> On 11/7/19, 4:12 PM, "Sebastian Moeller" <moeller0@gmx.de> wrote:
> >>>
> >>>   Hi Greg,
> >>>
> >>>
> >>>> On Nov 7, 2019, at 23:44, Greg White <g.white@CableLabs.com> wrote:
> >>>>
> >>>> Sebastian,
> >>>>
> >>>> I agree that this isn't rocket science.  In the existing WiFi systems that
> >> we're discussing, there are 16 DSCPs that get mapped to AC_VI, and 16
> >> DSCPs that get mapped to AC_VO.   No one polices any of them in
> residential
> >> WiFi networks!  There is nothing that prevents anyone from writing an
> >> application today that sends bulk traffic marked as CS7 (a value that the
> IETF
> >> considers to be reserved).
> >>>
> >>>   	[SM] Sure, but thanks to ISP often bleaching DSCPs there currently is
> >> very little in and outgoing traffic that actually maps to anything but AC_BE,
> >> you propose to change that in a major way, with your attempt at making
> NQB
> >> end to end (with one end potentially being in a close data center with an
> SLA
> >> allowing for NQB survival). Just because no one has massively abused this
> so
> >> far, is NOT a justification to do so now.
> >>>
> >>>
> >>>>
> >>>> I believe that the reason that RFC 8325 simply wrings its hands over this
> >> issue, as opposed to solving it, is that A) it is a *really* hard problem to
> solve
> >> in an unmanaged network, and B) while it is certainly a problem in theory,
> >> there is no evidence that it is a real problem in practice.
> >>>
> >>>   	[SM] The problem is that there is simply no data, and interpreting this
> >> as there is no problem is neither solid science nor engineering. If you have
> >> measurements showing that this is no problem with the expected traffic
> >> rates with the NQB marking, please feel free to post them to the list or as
> >> PM.
> >>>
> >>>>
> >>>>
> >>>> Blocking the IETF from assigning NQB the 0x2A value does *nothing* to
> >> prevent an application from using 0x2A (or any of the other 31 code points
> >> that you are concerned about) for *any* purpose that the application
> >> developer sees fit, it does *nothing* to prevent a network operator from
> >> using 0x2A for NQB traffic, and it does *nothing* to help solve the main
> issue
> >> that you are concerned about.
> >>>
> >>>   	[SM] It will keep one expected major source of DSCP marked traffic
> >> on a sane(r) policy. Most users and applications do not bother paying with
> >> dscps so the current amount of abuse is limited (and if I configure my
> internal
> >> skype and ssh applications to even use AC_VO I can control their activity
> and
> >> usage much better than I can traffic rushing in from the internet). Sure I
> can
> >> re-map 0x2A to a sane value on ingress to my network, but that is not
> going
> >> to help that much if my neighbors do not do this, and their APs start
> hogging
> >> all tx_ops on the shared channel.
> >>>
> >>>>
> >>>> If you want to solve this problem, my suggestion is that you start a new
> >> draft proposing a technology that will holistically protect WiFi networks
> from
> >> all potential DSCP abuses.
> >>>
> >>>   	[SM] First rule of holes, put the shovel away when you find yourself
> >> inside one. Here, I am not concerned so much in fixing all wifi AC abuse
> and
> >> more in giving my best to avoid this unfortunate and undesirable
> condition
> >> getting worse.
> >>>
> >>>
> >>>
> >>>   Sebastian
> >>>
> >>>
> >>>
> >>>>
> >>>> Greg
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 11/7/19, 3:00 PM, "Sebastian Moeller" <moeller0@gmx.de> wrote:
> >>>>
> >>>>  Greg,
> >>>>
> >>>>> On Nov 7, 2019, at 22:11, Greg White <g.white@CableLabs.com>
> >> wrote:
> >>>>>
> >>>>> Sebastian,
> >>>>>
> >>>>> In the interest of moving this forward and not going in circles,
> >>>>
> >>>>  	[SM] My impression is not that we going in circles, it is a rather slow
> >> road to understanding and accepting the properties and limitations of
> wifi's
> >> unfortunate prioritization scheme in conjunction with your intended use
> of
> >> the NQB dscp. Me shutting up, would not change the underlaying facts
> that
> >> need to be considered here if the issue is to be solved.
> >>>>
> >>>>
> >>>>> I think you summarized your position as: "To be explicit, I do not
> object
> >> on principle to using AC_VI or even AC_VO as long as this does not eat
> >> significantly into the tx_ops for AC_BE, the current draft improves  in that
> >> direction. Would it be possible to make this point even stronger?"
> >>>>>
> >>>>> In my view, as long as the applications that we're recommending to be
> >> marked NQB are no more bandwidth intensive than video conferencing
> (the
> >> applications that the IETF already recommends be marked with a DSCP
> that
> >> maps to AC_VI), then we have achieved what is needed.  Do you agree?
> >>>>
> >>>>  	To state the obvious, "no more bandwidth intensive than video
> >> conferencing" is virtually meaningless as it will give very little guidance on
> >> acceptable either single flow nor aggregate NQB traffic share or absolute
> >> bandwidth (yes rfc8325 is also pretty silent on this, but "look mum, the
> other
> >> guys are doing it too" is not the best of defenses IMHO). I realize that this
> is
> >> an issue for you as you explicitly target NQB as requiring no prioritization
> or
> >> rate-limiting, I get that; but I believe that on wifi since you effectively
> >> propose to use a prioritization system you really really should require
> rate-
> >> limiting.
> >>>>
> >>>>  rfc8325, section 8.2:
> >>>>  "The wireless LAN presents a unique DoS attack vector, as endpoint
> >>>>     devices contend for the shared media on a completely egalitarian
> >>>>     basis with the network (as represented by the AP).  This means that
> >>>>     any wireless client could potentially monopolize the air by sending
> >>>>     packets marked to preferred UP values (i.e., UP values 4-7) in the
> >>>>     upstream direction.  Similarly, airtime could be monopolized if
> >>>>     excessive amounts of downstream traffic were marked/mapped to
> >> these
> >>>>     same preferred UP values.  As such, the ability to mark/map to these
> >>>>     preferred UP values (of UP 4-7) should be controlled.
> >>>>
> >>>>     If such marking/mapping were not controlled, then, for example, a
> >>>>     malicious user could cause WLAN DoS by flooding traffic marked CS7
> >>>>     DSCP downstream.  This codepoint would map by default (as
> >> described
> >>>>     in Section 2.3) to UP 7 and would be assigned to the Voice Access
> >>>>     Category (AC_VO).  Such a flood could cause Denial-of-Service to not
> >>>>     only wireless voice applications, but also to all other traffic
> >>>>     classes.  Similarly, an uninformed application developer may request
> >>>>     all traffic from his/her application be marked CS7 or CS6, thinking
> >>>>     this would achieve the best overall servicing of their application
> >>>>     traffic, while not realizing that such a marking (if honored by the
> >>>>     client operating system) could cause not only WLAN DoS, but also IP
> >>>>     network instability, as the traffic marked CS7 or CS6 finds its way
> >>>>     into queues intended for servicing (relatively low-bandwidth)
> >> network
> >>>>     control protocols, potentially starving legitimate network control
> >>>>     protocols in the process."
> >>>>
> >>>>  To me this clearly indicates that the achievable wifi rate betwnn AP and
> >> each station needs to be taken into account when considering which
> fraction
> >> of > AC_BE traffic is acceptable. So very much incompatible with your goal
> of
> >> having endpoints set the NQB dscp based on their own best assessment
> of
> >> traffic type without some sanitization at the AP level (only the AP will
> have a
> >> reasonable chance of predicting immediate achievable rates with some
> >> confidence, neither endpoints nor intermediate low latency queue
> enabled
> >> AQMs have sufficient knowledge to judge what traffic rate is acceptable
> for
> >> AC_VI). I consider it to be quite unfortunate that rfc8325 has no
> references
> >> to research on real-world data on the consequences of actually following
> >> through with its recommendations, nor that it has robust
> recommendations
> >> of recommended maximal fractions of the achievable rate each AC should
> be
> >> constrained to.
> >>>>
> >>>>  All of this is not really rocket science, and the obvious solution,
> >> following both the principle of least surprise and a "first, do no harm"
> maxim
> >> is to select the NQB dscp such that the unfortunate default DSCP to AC
> >> mappings keep NQB marked traffic in the AC_BE queue, UNLESS the AP is
> >> NQB-aware in which case the AP should be mandated to at least reliably
> >> avoid starvation of ACs.
> >>>>  The amount of back and forth seems to indicate that this is not an
> >> outcome you consider desirable.
> >>>>
> >>>>
> >>>>  Sebastian
> >>>>
> >>>>>
> >>>>> -Greg
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 11/5/19, 1:58 AM, "Sebastian Moeller" <moeller0@gmx.de>
> wrote:
> >>>>>
> >>>>> Hi Greg,
> >>>>>
> >>>>>
> >>>>>> On Nov 5, 2019, at 01:28, Greg White <g.white@CableLabs.com>
> >> wrote:
> >>>>>>
> >>>>>> Hi Sebastian,
> >>>>>>
> >>>>>> Interoperability with existing WiFi equipment is an important aspect,
> >> since WiFi latency can be considerable. By default, many existing APs only
> >> support 4 priority queues, and thus it is not possible to meet all of the
> >> requirements of the NQB PHB (at least in this default configuration).
> >>>>>
> >>>>> 	[SM] I agree the question is how to deal with that "impedance
> >> mismatch".
> >>>>>
> >>>>>> Nonetheless, it is possible to utilize two of the four queues in order
> >> to meet some of the requirements, and thus provide some of the
> benefits of
> >> the NQB PHB.
> >>>>>
> >>>>> 	[SM] Unless you opt for selecting AC_BK for the NQB traffic, for most
> >> users the value of NQB will be mostly in the priority boost on wifi and the
> >> resulting air-time access advantage (which results in both lower latency
> and
> >> potentially higher bandwidth).
> >>>>>
> >>>>>> With proper configuration and/or policies, this can be done safely.
> >>>>>
> >>>>> 	[SM] Sure, I am concerned about the status quo wich does not entail
> >> "proper configuration and/or policies", and hence I believe the NQB
> special
> >> treatment on WIFI should be opt-in and not "opt-out" (in quotes as most
> >> endusers will not be able to opt-out). For thid reaon I believe that the
> >> proposal to use a code point that by default is mapped to AC_BK is the
> only
> >> correct solution (as a bonus it seems that such a code point also has a
> better
> >> chance to survive transit over the internet). NQB-aware APs then simply
> >> treat that NQB-codepoint however they want. If for example a priority
> boost
> >> is desired such an AP can easily implement the required rate-limiting so
> that
> >> AC_BE traffic does not get starved out. In short, I fully agree that special
> >> treatment requires "proper configuration and/or policies" and the
> desirable
> >> strategy if that can not guaranteed should be "do no harm".
> >>>>>
> >>>>>> The final SHOULD is intended to address your concern about
> >> prioritization (since it results in segregation without prioritization).
> >>>>>
> >>>>> 	[SM] Ah, in that case the AP needs to be be NQB aware anyway,
> >> would it then not be better to use an appropriate scheduler/AQM in front
> of
> >> the AC_BE queue and keep all traffic in the same priority class? The
> >> disadvantage of setting AC_VI to the same EDCA values as AC_BE is then
> that
> >> applicatons that expect an airtime access boost from using AC_VI will not
> get
> >> it any more (not necessarily a deal-breaker but certainly unexpected
> enough
> >> to merit clear communication of that side-effect).
> >>>>>
> >>>>>> Absent this requirement (or the ability to comply with it
> >> operationally), the operator would need to consider (and perhaps limit)
> >> which applications are allowed to be marked as NQB.  This aspect isn't
> >> discussed in the draft, but I will add it based on your input.
> >>>>>
> >>>>> 	[SM] Great! I would guess the safest would be to have the NQB-
> >> aware scheduler in an AP apply some (proportional) rate-limiting if NQB
> >> traffic is getting preferential air-time access.
> >>>>>
> >>>>>>
> >>>>>> Network operators understand the value of segregating NQB traffic
> >> on WiFi links, and will almost certainly select a DSCP in practice that
> achieves
> >> that goal.
> >>>>>
> >>>>> 	[SM] That is exactly part of my concern with the default mapping to
> >> AC_VI approach, I expect that very quickly a lot of traffic will utilize the
> AC_VI
> >> queue potentially starving normal AC_BE traffic in the process.
> >>>>>
> >>>>>> Assigning a different DSCP in this draft would do nothing to prevent
> >> them from doing so.
> >>>>>
> >>>>> 	[SM] Sure, but is that really a good justification for proposing a DSCP
> >> with known side-effects? As far as I am concerned an RFC should propose
> >> sane defaults and hope for the best.
> >>>>>
> >>>>>> Instead, what we need to do is clearly articulate how to make best
> >> use of the existing WiFi tools, and how to avoid conflicts.
> >>>>>
> >>>>> 	[SM] I believe the last two are mutually exclusive...
> >>>>>
> >>>>>>
> >>>>>> In existing RFCs, the IETF already recommends that video
> >> conferencing applications mark their traffic as either AF4x or CS4, all of
> which
> >> get mapped to AC_VI.  The remaining language in the NQB draft describes
> >> sparser flows than these.
> >>>>>
> >>>>> 	[SM] as an implementer I read "relatively low data rates", without
> >> further guidance I have very little intuition what to use as reference.
> Could
> >> this be made more explicit? This is orthogonal to the question whether
> such
> >> a limit should be enforced in any way, here the question really is about
> >> getting a feel what is considered acceptable for NQB treatment.
> >>>>>
> >>>>>>
> >>>>>> Based on your comments, I attempted to remove all text that could
> >> be interpreted as recommending that high-data-rate traffic be marked
> NQB.
> >>>>>
> >>>>> 	[SM] Thanks, as long as the aggregate NQB traffic is relative sparse
> >> compared to the available WiFi bandwidth (or the number of tx_ops)
> most of
> >> my WiFi concerns get less and less relevant. To be explicit, I do not object
> on
> >> principle to using AC_VI or even AC_VO as long as this does not eat
> >> significantly into the tx_ops for AC_BE, the current draft improves  in that
> >> direction. Would it be possible to make this point even stronger?
> >>>>>
> >>>>>> It appears that I missed one instance (in the Introduction it gives
> >> "interactive voice and video" as an example). Aside from this (which I can
> >> correct), I think the draft currently recommends that NQB only be used
> for
> >> sparse traffic.  That said, the section where this guidance is intended to be
> >> given is still lacking in specificity, and poses some open questions that may
> >> need to be addressed in a subsequent revision.
> >>>>>
> >>>>> 	[SM] Sounds great. Now this then cycles back to one of the other
> >> open topics, "enforcement". Ideally NQB-aware APs should monitor both
> >> queues and re-assign flows between them based on flow-behavior in
> >> relation to time-variant bandwidth experienced by that flow.
> >>>>>
> >>>>> Best Regards
> >>>>> 	Sebastian
> >>>>>
> >>>>>>
> >>>>>> Best Regards,
> >>>>>> Greg
> >>>>>>
> >>>>>>
> >>>>>> On 11/4/19, 3:25 PM, "tsvwg on behalf of Sebastian Moeller"
> <tsvwg-
> >> bounces@ietf.org on behalf of moeller0@gmx.de> wrote:
> >>>>>>
> >>>>>> Regarding https://datatracker.ietf.org/doc/draft-ietf-tsvwg-
> >> nqb/?include_text=1
> >>>>>>
> >>>>>> 7.3.  WiFi Networks
> >>>>>>
> >>>>>>   WiFi networking equipment compliant with 802.11e generally
> >> supports
> >>>>>>   either four or eight transmit queues and four sets of associated
> >> EDCA
> >>>>>>   parameters (corresponding to the four WiFi Multimedia Access
> >>>>>>   Categories) that are used to enable differentiated media access
> >>>>>>   characteristics.  Implementations typically utilize the IP DSCP field
> >>>>>>   to select a transmit queue, but should be considered as Non-
> >>>>>>   Differentiated Services-Compliant Nodes as described in Section 4
> >> of
> >>>>>>   [RFC2475].  As a result this document discusses interoperability with
> >>>>>>   WiFi networks, as opposed to PHB compliance.
> >>>>>>
> >>>>>>   As discussed in [RFC8325], most existing implementations use a
> >>>>>>   default DSCP to User Priority mapping that utilizes the most
> >>>>>>   significant three bits of the DiffServ Field to select "User
> >>>>>>   Priority" which is then mapped to the four WMM Access
> Categories.
> >> In
> >>>>>>   order to increase the likelihood that NQB traffic is provided a
> >>>>>>   separate queue from QB traffic in existing WiFi equipment, the
> >> 0x2A
> >>>>>>   codepoint is preferred for NQB.  This would map NQB to UP_5
> >> which is
> >>>>>>   in the "Video" Access Category.
> >>>>>>
> >>>>>>   Systems that utilize [RFC8325], SHOULD map the NQB codepoint to
> >> UP_5
> >>>>>>   in the "Video" Access Category.
> >>>>>>
> >>>>>>   In order to preserve the incentives principle, WiFi systems SHOULD
> >>>>>>   configure the EDCA parameters for the Video Access Category to
> >> match
> >>>>>>   those of the Best Effort Access Category.
> >>>>>>
> >>>>>>
> >>>>>> [SM] This last section is puzzling: if the wifi system configures AC_VI
> >> with EDCA parameters that match the AC_BE parameters, AC_VI ceases
> to
> >> be different from AC_BE, in that case picking a codepoint that
> automatically
> >> maps to CS0 and hence to AC_BE  seems much safer, simpler and straight
> >> forward to me.
> >>>>>> Especially since essentially none of the millions deployed WiFi APs
> out
> >> there will a) have this configured like proposed already and b) none of the
> >> consumer APs I know actually allow to easily adjust EDCA parameters at
> all. I
> >> guess I must be missing something and would be delighted to be shown
> why
> >> the proposed text is the right thing.
> >>>>>> My take on this still is, if NQB traffic is sufficiently sparse using AC_VI
> >> can be justified, but without any rate limits this has the potential of being
> >> quite unfair to concurrent APs on the same channel (as well as the
> >> neighboring channels that overlap with the selected).
> >>>>>> I do not want to sound alarmist, but given the number of cable-ISP
> >> WiFi-APs (as indicated by a SSID containing the ISPs name) in my city, I
> >> believe making sure that those APs will not basically start hogging most
> >> airtime seems the prudent thing to do. If there are sufficient backstops in
> >> place (like rate limiting or automatic down-marking if the traffic is not
> sparse
> >> enough) to avoid the described situation, I am all for it.
> >>>>>>
> >>>>>> The text probably should also openly discuss that in WiFi/WMM the
> >> four available queues by design have different priorities, and by moving
> NQB
> >> out of the default AC_BE while leaving QB flows in there, this effectively
> runs
> >> against  the following text in the draft: "The NQB queue SHOULD be given
> >> equal priority compared to queue-building traffic of equivalent
> importance."
> >> (leaving alone the question how an AP or a station is supposed to
> measure
> >> importance)
> >>>>>>
> >>>>>>
> >>>>>> Sebastian
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >