Subject: [tsvwg] Your NQB presentation

From: Sebastian Moeller <[email-masked]>
Date: Thu, 21 Nov 2019 22:12:55 +0100

Dear Greg, dear list,

I just had the opportunity to watch the video of your presentation. Just a quick note that I very much appreciated the balanced, concise and unbiased presentation of the PHB and the open issues.

Regarding code points, I had proposed 0x2E since it is the "sum" of 0x6 and CS5, so I saw a cute "symmetry" there, but since it is is taken already (and I agree the goal should be for NQB to be ideally unambiguous end to end) I am fine with 0x2A for the case when AC_VI is known to be safe to use.

Best Regards
	Sebastian

---

From: Greg White <[email-masked]>
Date: Fri, 22 Nov 2019 01:29:43 +0000

Sebastian, all,

I had a discussion with David Black on the subject of DSCP and he proposed a resolution that perhaps addresses the main concerns that have been expressed.

The proposal (David, feel free to jump in if I've misstated anything) is to select the 0x2A code point, and add two requirements to address the WiFi safety concern:  

An ISP node that supports the NQB PHB and serves residential users MUST have the ability to re-mark NQB traffic as default, and MUST do so by default.

(precise wording to be smithed) 

I think that this achieves the same end result as selecting a low-valued code point - it ensures that operators will need to actively decide to pass the 0x2A codepoint through to their residential customers.

In addition to these two MUSTs, we need some clear and concise informative text that discusses the WMM safety concern.

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.

-Greg

On 11/22/19, 5:13 AM, "Sebastian Moeller" <[email-masked]> wrote:

    Dear Greg, dear list,

    Best Regards
    	Sebastian

---

From: "Black, David" <[email-masked]>
Date: Fri, 22 Nov 2019 01:47:59 +0000

> The proposal (David, feel free to jump in if I've misstated anything) is to select
> the 0x2A code point, and add two requirements to address the WiFi safety
> concern:
> 
> An ISP node that supports the NQB PHB and serves residential users MUST have
> the ability to re-mark NQB traffic as default, and MUST do so by default.
>
> I think that this achieves the same end result as selecting a low-valued code
> point - it ensures that operators will need to actively decide to pass the 0x2A
> codepoint through to their residential customers.

That’s a reasonable summary, and indeed, the word "residential" will almost certainly need some wordsmithing attention.

The basic idea is that a default configuration that bleaches NQB traffic places the responsibility for the effects of not bleaching on whomever changed that default configuration - we can't prevent people who are determined to shoot themselves in the foot from accomplishing that goal ;-).   With careful wordsmithing, this will also cover end-user-purchased/provided ISP interface equipment because it'll come with that same default configuration if NQB is supported.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Greg White
> Sent: Thursday, November 21, 2019 8:30 PM
> To: Sebastian Moeller; tsvwg IETF list
> Subject: Re: [tsvwg] Your NQB presentation
> 
> 
> [EXTERNAL EMAIL]
> 
> Sebastian, all,
> 
> I had a discussion with David Black on the subject of DSCP and he proposed a
> resolution that perhaps addresses the main concerns that have been expressed.
> 
> The proposal (David, feel free to jump in if I've misstated anything) is to select
> the 0x2A code point, and add two requirements to address the WiFi safety
> concern:
> 
> An ISP node that supports the NQB PHB and serves residential users MUST have
> the ability to re-mark NQB traffic as default, and MUST do so by default.
> 
> I think that this achieves the same end result as selecting a low-valued code
> point - it ensures that operators will need to actively decide to pass the 0x2A
> codepoint through to their residential customers.
> 
> In addition to these two MUSTs, we need some clear and concise informative
> text that discusses the WMM safety concern.
> 
> 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.
> 
> -Greg
> 
> 
>     I just had the opportunity to watch the video of your presentation. Just a quick
> note that I very much appreciated the balanced, concise and unbiased
> presentation of the PHB and the open issues.
> 
>     Regarding code points, I had proposed 0x2E since it is the "sum" of 0x6 and
> CS5, so I saw a cute "symmetry" there, but since it is is taken already (and I
> agree the goal should be for NQB to be ideally unambiguous end to end) I am
> fine with 0x2A for the case when AC_VI is known to be safe to use.
> 
> 
>     Best Regards
>     	Sebastian

---

From: Michael Welzl <[email-masked]>
Date: Fri, 22 Nov 2019 10:38:42 +0800

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

“all?” / ALL would contradict with at least one measurement study. See:
https://www.sciencedirect.com/science/article/pii/S0166531619300203 <https://www.sciencedirect.com/science/article/pii/S0166531619300203>
(where at least the ARK nodes count as “residential”), and references therein.

Cheers,
Michael

---

From: Greg White <[email-masked]>
Date: Fri, 22 Nov 2019 03:18:21 +0000

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?

-Greg

From: tsvwg <[email-masked]> on behalf of Michael Welzl <[email-masked]>
Date: Friday, November 22, 2019 at 10:38 AM
To: tsvwg IETF list <[email-masked]>
Subject: Re: [tsvwg] Your NQB presentation

Just as a data point,

“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

---

From: Michael Welzl <[email-masked]>
Date: Fri, 22 Nov 2019 15:42:04 +0800

Hi,

> On Nov 22, 2019, at 11:18 AM, Greg White <[email-masked]> wrote:
> 
> Hi Michael, 
>  
> To be clear, I think the specific situation we’re talking about is where a residential ISP allows DSCPs marked by 3rdparties 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?

Because the number of "home network" nodes that we had available was so small, we didn’t categorize the end hosts in our results but decided to lump them together, focusing on the behavior per AS in our study. This lumped data, for the direction that you’re interested in (from a server to a client) is shown in Figure 2, c and d.

I’m cc’ing Runa, my co-author who worked with this data. Runa, do you happen to know how many of the ARK nodes were able to receive an unchanged DSCP value from the other end?

A side note: if the DSCP would really ALWAYS be bleached for residential customers, then this work would also only apply to business environments:
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18 <https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18>

Cheers,
Michael

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 22 Nov 2019 09:42:46 +0100

Hi Greg,

> On Nov 22, 2019, at 04:18, Greg White <[email-masked]> wrote:
> 
> Hi Michael, 
>  

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