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

Greg White <g.white@CableLabs.com> Thu, 07 November 2019 22:59 UTC

Return-Path: <g.white@CableLabs.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 7FF471208CA for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 14:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.com
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 EyvpmXq7EAWd for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 14:59:03 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790101.outbound.protection.outlook.com [40.107.79.101]) (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 4BA7F12085B for <tsvwg@ietf.org>; Thu, 7 Nov 2019 14:59:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FkeI7/JY3MOSOyKUx+gb0NovmUecgZE+tXQQbQ+HGWAzTaqaEZegAjvh4sl61ClxI6xTsS8WEoUsztptjXSwMXmcxRyMt6e2hMjw+M1uBIyln7Z7tvRGKln1It32tDOTtaoYpfFEtZHKegFSrv+s/ETYLNQYKjh0ItL6nkWSGnmFiTg5TCQMvK9bSn7co5eVIostpPrTUlDPM+cX1xDItU8nHYpkp7vh445se5PeaswXINzQj0WYC9jUbtTAvEBTnNnbSFJds2/XEGKHFusRVdx/2FiiGY7bGbglwqxE8DY4U9dAGln5h5Vjk4IOMnNbAwS3FwdRsdq2jIu7Dd0qLg==
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=N5Ytxa5GZ9GcccW5SHyc6pF0qlXPR8CFg8HmbfSkHcc=; b=d/B9BOBdZP28v3p4oNRR8/SFb5QKId5Da8bDW2x+koUWVOtP83wlKkjdgH+VQC81L+7qNsZye1PxLsk+WduzZjqdBCP/q50ECt4YFIJQW7sqU64gaDStFX/iz1rNLhil0M6Fva8MRvB8loJX332pnjT2e6w0vbNSX4PtMX2sdgmCWdxGNtE16/xWKagLE0jAy8CZcp037jQKynPO1HFldS6Fl2jV4FrZQPe5tziiEQPaC8Nq+y00XZMQmEeWKYR4T3JiwnvgwwZk0qWHuS9MA9NBrseMz79/ViKwAE3i37s/KW8ceyZrPrZHi1FZVoGEKPRy3/i0DBjTX7lbOMEUfQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N5Ytxa5GZ9GcccW5SHyc6pF0qlXPR8CFg8HmbfSkHcc=; b=BtmBuhu7PMd/l21RPh0ysu61Fo4D8T0PEk0Cn++eVWw0zaAxWd4BoDQqvfkxJEEAgrdVf5/70cvHB9wKRhi+wv6ANDCyzASumHXr0kO6a2BBcDG3VLBjpDeJ+FZ9jwoVf1a3tT7wKokz5volYD72W18X+bgWZECrU6IRkRYmzS4=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4478.namprd06.prod.outlook.com (52.135.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Thu, 7 Nov 2019 22:59:00 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::cd06:3025:a8a3:f4bd]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::cd06:3025:a8a3:f4bd%6]) with mapi id 15.20.2408.024; Thu, 7 Nov 2019 22:59:00 +0000
From: Greg White <g.white@CableLabs.com>
To: Dave Taht <dave@taht.net>, Sebastian Moeller <moeller0@gmx.de>
CC: tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [tsvwg] draft-ietf-tsvwg-nqb, more questions
Thread-Index: AQHVk165eBM5r7+4T0OsGmssaWIedad7Q86AgAED3YCAA3w6gIAAgvKAgAAG3nz//5QXAA==
Date: Thu, 7 Nov 2019 22:59:00 +0000
Message-ID: <434B2C9C-4236-4163-BA79-07E44C135ADA@cablelabs.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> <87lfsrfhon.fsf@taht.net>
In-Reply-To: <87lfsrfhon.fsf@taht.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [2620:0:2b10:22:19f9:821c:a410:a105]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 93986131-8153-4bd0-f65d-08d763d61430
x-ms-traffictypediagnostic: SN6PR06MB4478:
x-microsoft-antispam-prvs: <SN6PR06MB4478E97655B90A29309FA1C4EE780@SN6PR06MB4478.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(396003)(376002)(136003)(346002)(189003)(199004)(51914003)(6486002)(6506007)(58126008)(5660300002)(229853002)(66946007)(66556008)(66446008)(64756008)(66476007)(2906002)(86362001)(14444005)(6116002)(6512007)(76116006)(91956017)(14454004)(7736002)(71200400001)(8936002)(71190400001)(46003)(8676002)(25786009)(486006)(76176011)(6436002)(256004)(316002)(446003)(110136005)(102836004)(36756003)(2616005)(11346002)(33656002)(81166006)(476003)(99286004)(81156014)(305945005)(4326008)(478600001)(6246003)(186003)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4478; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 9bvtPrkHVbLumElb5sXWaAtQSy02VuLo0GWIRtjbvdLX2gF/2+N8WRU9VrDFryhKsAbxkK/1hllhduBCFSxWHeJ3MsqFFw6Bubc/PtjGtT96ta6Yau2E5oGUlv2o3+9ScllZOFRW/udI0TMVPqhemHZraeeql/VTk20y9E5nhT9XADIJOIcD3Eqr7BcSwZUKyyfkG/JFFzXHT1AOOW88LZgyIu6PDoaPenDkJvI6rE1V8kA5H7U4xRIupregkXwUYJ6JjnfB6HbiSyXt3IybZdCR/PzoYqHXtnT1qQtp81yffxhzLdcHyYHMXZ8cF+7YWRaxufz0AA7EoZmLXZ2k/WpzgcGSRs3xbHImQ6dWf+/iwHWkrYzFsaMqmAMxSRxVJ74Esay2EsXhwQlLc8nWCO5+UieTU6cfbyS6IPnBGXNw8kZo+t9jSIxHHq29aY95
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <ECE3C4B0329D804FBD090A5DE39F448D@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93986131-8153-4bd0-f65d-08d763d61430
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 22:59:00.8199 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OTbA8UgJZAq0L7cjRfsVt5tkQz4B/hyWig45nxnZW7gUH+csx8wgprhyCIAJoaYU9m44EIM3ewmgZo5RHMohmQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4478
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/i-0RFpwh7ulFiHwjVIRYSnlBcdc>
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: Thu, 07 Nov 2019 22:59:06 -0000

Dave,

Thanks for these thoughts.  I agree that a better solution for NQB is to have the WiFi devices *actually* support the NQB PHB (or support fq_* if that is what you prefer), as opposed to putting NQB traffic into a separate Access Category.   That is essentially the default recommendation of the draft (i.e. support the actual requirements in the draft), even though it doesn't explicitly mention WiFi in that context.  This discussion is more about interoperability with existing WiFi gear that does not support the PHB.   

BTW, our experiments have shown that .11ac implementations actually do a pretty good job at implementing WMM (some better than others).  But I've heard anecdotally about older gear that suffers from priority inversions, etc.

-Greg


´╗┐On 11/7/19, 3:25 PM, "Dave Taht" <dave@taht.net> wrote:

    
    I'm not sure if I should weigh in here or not. A couple notes...
    
    802.11e was seemingly a good idea in 2004, when men were men, APs
    scarce, and txops limited to about 3000/sec.
    
    802.11n added packet aggregation, and 802.11ac added ever more
    dense encodings to wedge even more data into that txop...
    
    but the limiting factor for wifi - particularly in dense environments
    with a range of standards being broadcast remains that fatal 3000
    txops/sec - and while that's a little mitgated by mu-mimo and with
    wifi 6 in ofdma mode made MUCH better, having to be backward compatible
    elsewhere still messes things up.
    
    furthermore, in 802.11n the VO queue cannot aggregate. 700usec lost
    on a single packet.
    
    Use of the VI queue was often buggy in 802.11n chipsets at least as
    far back as 2014 when I last poked into it. The main tested paths
    have generally been BE, BK, and to a small extent VO.
    
    I've got plenty of data showing that it's in general better (from the
    AP's standpoint) to well multiplex and fully fill as best as possible
    just the BE queue for each station, to ignore 802.11e, and to try to
    manage the max txop size in BE in proportion to the load.
    
    We pointed to that result in "ending the anomaly".
    
    and 802.11e scales ever more badly to ever more devices.
    
    From the stations standpoint, it can be (if lightly used) to still
    use the 802.11e stuff, but that should at best be sparingly used.
    
    Some (mostly enterprise) wifi routers do fiddle with the edca params
    some, in particular it does make sense at higher workloads to clamp the
    size of txops to stations are allowed to transmit (via the beacon), and
    I wish more wifi routers did that.
    
    But trying to actively use the 802.11e priorities at this late date,
    not huge on it. Twiddling edca extensively seems like an especially bad idea.
    
    That said, I've been meaning to dig up my old work on the subject,
    look at it in light of modern conditions, but given that most of
    my aircaps still see some wireless-g APs helping mess up things up,
    don't think I have huge reasons to change my current take on it.
    
    I guess my core takeway I'd like people to think about is txops/sec
    relative to how much data can be stuffed into a txop, in the real world,
    rather than trying to make 802.11e do anything useful.