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

[[e-mail]]

Hi Greg,

responses marked [RG] below.   Regards, Ruediger



-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Donnerstag, 6. April 2023 01:57
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-17.txt - 3.3. Relationship to L4S, classification

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?

[RG]: Yes, as by prior exchange you've mentioned that NQB traffic is classified exclusively by DSCP and default behaviour of L4S deviates related to ECT(1)/CE set. I'd suggest to add a statement: Packets marked by a DSCP which isn't classified for NQB and ECT(1) or CE set MUST NOT be classified for NQB (or MUST be classified for QB/Default treatment, as you prefer). 

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?

[RG] I couldn't find this statement in the L4S RFCs (I'm sorry, should it be in). I've checked
https://www.rfc-editor.org/rfc/rfc9332#section-2.3
https://www.rfc-editor.org/rfc/rfc9332#section-2.5.1.1

What I found was
https://www.rfc-editor.org/rfc/rfc9331#section-5.4.1.3
In the first case, if we assume that a network element provides no PHBs except the DualQ, if a packet carries ECT(1) or CE, the network element would classify it for the L4S treatment irrespective of its DSCP. And, if a packet carried (for example) the EF DSCP, the network element could classify it into the L queue irrespective of its ECN codepoint.

[RG] To remove ambiguity in the native NQB PHB case, I suggest to word as follows (note that this proposal covers all DSCPs which may be accompanied by ECT(1) and CE now): 
Packets marked with a DSCP classified for the NQB PHB and the ECT(1) or CE codepoint SHOULD be treated as if packets were marked with the DSCP alone by traffic protection.

Regards,

Ruediger




-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