Re: [tsvwg] draft-ietf-tsvwg-nqb-17.txt - 3.3. Relationship to L4S, classification

[Greg White <[e-mail]>]

Hi Ruediger,

In the case of a dual-queue node that supports both NQB and L4S, traffic with DSCP Default and ECT(1)|CE is classified into the "L/NQB" queue.  If the node only supports NQB (i.e. it doesn't support L4S) then traffic marked with DSCP Default and ECT(1)|CE would be classified into the Default queue.   Is that the part that you would like written more clearly?

Related to that, the statement that traffic marked with both codepoints (DSCP NQB and ECN L4S) be "treated the same as packets marked with either codepoint alone" is ambiguous in the case that those two types of "either codepoint alone" traffic are treated differently.  In addition to "NQB-only" nodes, there are several potential situations where this could happen.
1. The expectation is that the "re-marking/traffic policing function designed to protect unmanaged networks (as described in Section 4.4.1)" is a function that only is applied to NQB DSCP traffic (since it could be given high priority in a non-compliant network) and would not apply to DSCP Default L4S traffic. 
2. In LLD (for example) the traffic protection function applies to ALL traffic that is classified to the "L/NQB" queue, and to me this makes sense. But, we don't mandate that in this draft (or in RFC9332), and I'm not sure that we should mandate it.  RFC9330/9332 allow that L4S traffic could be subjected to traffic protection, so it is certainly envisioned.  But, I'm not confident that we have a strong rationale to mandate it (RFC9330/9332 are much weaker on the need for such a function for L4S traffic). So, this raises another potential case where "treated the same as" is ambiguous.    
3. RFC9330 section 8.2 offers a range of ways in which L4S traffic could be policed (a broader range than we describe in NQB), so it is possible that a dual-queue NQB/L4S node (or network) would implement a different mechanism for policing of L4S traffic than for NQB traffic. 

In this regard, Bob's original suggested text "SHOULD NOT be subject to less stringent policing than they would with either codepoint alone" is probably better, even though it uses a bit less precise language. Any thoughts on this?

-Greg





On 4/5/23, 6:30 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Greg,


after having settled the question related to DSCP classification for NQB, there's another issue, I'd prefer the draft to be clear about (or more explicit, as you prefer):


3.3. Relationship to L4S


Applications that comply with both the NQB sender requirements in Section 4.1 and the L4S "Prague" requirements in Section 4 of [I-D.ietf-tsvwg-ecn-l4s-id] could mark their packets both with the NQB DSCP and with the ECT(1) value. Packets marked with both the NQB DSCP and the ECT(1) codepoint SHOULD be treated the same as packets marked with either codepoint alone by the traffic protection function (defined in Section 5.2) and by any re-marking/traffic policing function designed to protect unmanaged networks (as described in Section 4.4.1).


From the second statement, the impression is raised that the NQB traffic protection might handle traffic with ECT(1) alone. To me that seems to imply, that traffic with DSCP Default and ECT(1) is classified for the NQB queue. I'd prefer the draft to be explicit about to the classification of DCSP Default traffic with ECT(1) and CE codepoints as either NQB or QB.


Regards, 


Ruediger