Re: [tsvwg] Your NQB presentation

[Sebastian Moeller <[e-mail]>]

HI david,

thanks so much!

More in-line.

> On Dec 3, 2019, at 22:35, Black, David <[e-mail]> wrote:
> 
> Inline ...
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: tsvwg <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> on behalf of Michael Welzl
>> <[e-mail]>
>>> Date: Friday, November 22, 2019 at 10:38 AM
>>> To: tsvwg IETF list <[e-mail]>
>>> 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