Re: [tsvwg] Your NQB presentation

Sebastian Moeller <moeller0@gmx.de> Thu, 05 December 2019 09:42 UTC

Return-Path: <moeller0@gmx.de>
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 918A91200F6 for <tsvwg@ietfa.amsl.com>; Thu, 5 Dec 2019 01:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 3qbSPdyuM0yY for <tsvwg@ietfa.amsl.com>; Thu, 5 Dec 2019 01:42:38 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DE21200A4 for <tsvwg@ietf.org>; Thu, 5 Dec 2019 01:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575538945; bh=Irf00iZvXdN7YTkgAHWRqrzbHqTZO/CgHH6OwimNzm4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=PHzP1la3NToV5FlNrls5+a9tU5RCLbv0UkRHsluJRqaKV/eWGFOAug1UBB0sJUQxP JL7p2n9agEm6XGBt8yOl4J8J/TUK9SRKMO8Wq9PP5VW0ASHWT4yjm13C8RY8KpyPd2 4lrRqaNUmD8XIxTs6tY2UpHJ3h1ggOf3d81CN+O0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpUZ4-1hxznp1ijk-00pxEh; Thu, 05 Dec 2019 10:42:25 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <MN2PR19MB4045A5AF7BDBB95EA77720BC83420@MN2PR19MB4045.namprd19.prod.outlook.com>
Date: Thu, 05 Dec 2019 10:42:23 +0100
Cc: Greg White <g.white@CableLabs.com>, tsvwg IETF list <tsvwg@ietf.org>, Michael Welzl <michawe@ifi.uio.no>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7A4F6CB-9BFA-4C0E-9C16-16B363F747CE@gmx.de>
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> <MN2PR19MB4045A5AF7BDBB95EA77720BC83420@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:8dYuiKJSTPoCT6DjVy+flmh83LsfHDwcs9KYoyTslqe0v0uXs+Z LnOU5oAkUEQqiaSyXJ2SL3ockiSXGuATcvXXnY252wyl8bAtamWS272gGTWF9yR0Y8bYPTY /cObQvycWZlB26ILq5CvZs1ceOuiUdHTQkxwYSMDr46WFwpLnBQckX0Q6kvu1dTTSAQxNxl 2MK6V5iN9rS3DOd1trbBA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Xem0IcqwWQw=:GsQUhGcgzjkh6nED2wvyF3 08XMEaEi41Udp5yo1yRojOR8ttcoe2Z3rJ0CQqDzoShMRVlYm3W/JDpJj1dUlBd0X3xtpnCWD wR7Y9PkLsNi+GRJs1KvT2DQg/UJZiE7f6PQl3A7NwAIIEOIc4216N644NeN1grtPCts/HEzq+ zyeREsSvw62mCzdWOr4P7xyJCjcodkd1lXkK3Z/M3Gr+hXtbOZ8R2UJSnjeQNKx7S0jOgu+JV PFy1/0SFkYqlNICZGZhmpBi4yosh/SzqTtpMKDZ3oZxEd6DDreycQcydALdI79Lx5K9p/ghJh oCkfzd7R+qq/5a7IDr27ak2EaXOILs8x8dMODKw/6BjBwpRNDx/YbS79Wqy3mlMZfGXOVUqqV PyEArzWIWKUAepls5NyNhgitYYSn64oZgY7+nrtJAM/v1P4FS2jk0AmZK84xDLdoH0VMICfUm Fn/PlHCSHmhRxfscldy22ylmv7K0wASttXwHxTzKXLjCZziC8MpW64xaqUAVcljlI4IOIq3At 7HA+ku/GCJuLhGD5lqT96OLntn9iV/fRSqownTWlvoZ2qDr6A4WGjfUsapMcwhKJYexJsbTdt BopUy5xmB+MC2rDGFyuqAm0TRka1nkQhvbACYPaGzenvtVlyh6erSV4fzbu1hAqMcmxSF+j+1 kojtFRN7VhJt1KQRqFvQK+/DUxDkfaZ4dymO6d+parj/5Aubr+nsgvGryztQiJEAObboQD35V kb5zqJJ42XuURSjs/D53gZBDohiVEDJCHuCcLFAC9GzQWQpwSNeooaLz4E/vyEQHMePETfsKv Y8Q5TkJZFbpIsM+OIqiGTzgTMYhUGFxU+YsHNQ4DFi2ecaHMaXSgVVPZknk3w7JYQbSCDa8ix mdkYfCMS/GCU+YdhxHeVMXMy4AenEIrAUFCqRW2j/wiOsz/cBlFOMyAPnKAmCshCYU+RP911c kmXFSGU2l4D/nNq+IpLc7aNDGPl26zxYq5HOAY+Na6bK9pUTwaMftE7ocnVtoGC60yx8MiHuh rTGHeaR8CkELU5bd1Uul47N3xPC1CdQ3grieMPCfJAyqZrtCJHqltk2GvzpmqN+OAk2wU6C8e Wi4/GXXsW9Cgw0Qz+q0lzKXs3Oo0Kn4sSJ0SeT7cdiLB9d6L8prON6oeimtp7Ac4bE26JtPQ9 U6ekhPki7mQzh7fq0qIYNqd9kUc94w3ZSxWomEkNKH6pVTmcevzQSzxr2QqWtTOMInqlaxcAb L7RCUkt7Ky5GcXFAzZh0kOU/Yo+O0qXr8U4N8gUhv12rFA7OuMHJZYlqtxm4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/l97cWbes2D71HQ3ZWpNhNrYyjls>
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: Thu, 05 Dec 2019 09:42:41 -0000

HI david,

thanks so much!

More in-line.

> On Dec 3, 2019, at 22:35, Black, David <David.Black@dell.com> wrote:
> 
> 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 ;-).

	[SM] Yes, that nicely solves most of my issues, by requiring an opt-in. 


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

	[SM] Same here, as long as NQB is opt-in most of my objections melt away, since then there is an entity that can be expected to deal with potential fall-out. I will just wait until the next revision comes up.

Best Regards
	Sebastian

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