Subject: [tsvwg] NQB & Label DSCP clarification (was RE: DSCPs and L4S: Label DSCP)

From: "Black, David" <[email-masked]>
Date: Wed, 2 Jun 2021 02:32:07 +0000

Jonathan's basically got it right.  Here's a bit more clarification on the NQB DSCP(s):

> * Specifically, I don't think the current proposed behaviour of the DSCP Label is what was requested in the NQB draft.
> I think the latter seeks codepoints that can work end-to-end, and wouldn't be remarked at DiffServ domain edges. I'm not sure whether NQB traffic would therefore be counted as L4S?
> 
> David Black's wording permits the use of other DSCPs to explicitly include or exclude traffic from the L queue.  I think this is compatible with parallel use of NQB. 
Correct - one or both of the NQB DSCPs could be used to indicate the alternate L4S semantics of the ECN field for NQB traffic.

> You may be right that this consideration excludes the NQB DSCP from use as the Label DSCP.
Yes, although that might be better stated as:

	The NQB DSCP(s) would not be the only DSCP(s) that indicate L4S semantics of the ECN field.

The NQB draft already anticipates use of L4S with NQB - that should not require any changes for the Label DSCP approach.

Thanks, --David

-----Original Message-----
From: Jonathan Morton <[email-masked]> 
Sent: Sunday, May 30, 2021 10:31 AM
To: Gorry Fairhurst
Cc: Black, David; [email-masked]
Subject: Re: [tsvwg] DSCPs and L4S: Label DSCP

[EXTERNAL EMAIL] 

> On 30 May, 2021, at 2:20 pm, Gorry Fairhurst <[email-masked]> wrote:
> 
> * This proposed approach is/was already possible for an operator/network using DiffServ without any IETF specification using an Experimental or Local Use DSCP from Pool 2.  One key aspect of the proposed re-design is to require assignment of a specific Pool1/3 DSCP or set of DSCPs to  identify L4S traffic. It seems highly unlikely the IETF will want to standardise a large set of DSCPs.

I think this is consistent with the initial use of a Pool 2 DSCP.  Discussion of whether an allocation in the other pools is warranted can take place later, with the benefit of field experience.

> * I expect the proposed experiment will not be attractive to people who are already using a set of DSCPs (e.g. to ensure traffic is queued/mapped in a way that reduces the latency of WiFI, MPLS and other subnets). How would such a DSCP assignment consider methods that expect some DSCPs to be mapped to lower latency treatments that are below IP? Is that OK?

I doubt that the set of DSCPs in use on any single network precludes the temporary allocation of one more for experimental purposes.  If that is an actual concern, let the concerned speak up for themselves.

> * Specifically, I don't think the current proposed behaviour of the DSCP Label is what was requested in the NQB draft. I think the latter seeks codepoints that can work end-to-end, and wouldn't be remarked at DiffServ domain edges. I'm not sure whether NQB traffic would therefore be counted as L4S?

David Black's wording permits the use of other DSCPs to explicitly include or exclude traffic from the L queue.  I think this is compatible with parallel use of NQB.  You may be right that this consideration excludes the NQB DSCP from use as the Label DSCP.

> * l can see the proposal could be used to defer the assignment of the ECT(1) codepoint, and would postpone any decisions about the need to obsolete the current ECT(0) usage - perhaps this is good for those who are focussed on other proposals, but is this delay to allow more experiments what is also wanted by others?

No comment.

 - Jonathan Morton