Re: [tsvwg] Your NQB presentation

[Sebastian Moeller <[e-mail]>]

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.

	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. 

	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