[tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

[Greg White <[e-mail]>]

Hi Christian,

I hope that this addresses your concerns.

My responses marked [GW2] (and yours [CH2]).

-Greg


On 5/31/24, 8:06 PM, "Christian Huitema" <[e-mail] <mailto:[e-mail]>> wrote:

On 5/31/2024 4:28 PM, Greg White wrote:
> [CH] The correct assumption is that NQB traffic should be subject to
> exactly
> the same AQM processing as any other path. If it want to be treated as
> ECT(0), it should set these bits, and it should in fact react to
> excessive EC marking by somehow reducing throughput.
> 
> [GW] I don't agree with the first sentence as it is written. Could you
> clarify what you mean? But (unless I'm misunderstanding you), the second
> sentence is in line with what the draft expects:https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-4.1-2 <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-4.1-2&nbsp;&nbsp;> I don't know why you are specifically referring to ECT(0) here, so perhaps I'm not getting your point.


[CH2] I am always getting mixed up between ECT(0) and ECT(1). I meant, "if 
traffic wants to be treated as part of the low priority queue is L4S, it 
really should use the ECT marking specified by L4S."

[GW2] If, in the above, you meant to type "as" instead of "is", then I agree and there is no change needed in the draft.  If you actually meant "is" then I agree with that as well, but it has nothing to do with the NQB draft.  Keep in mind that RFC9331 provides certain rules that a sender needs to comply with in order to mark traffic as ECT1.  I assume you aren't saying that applications should be allowed to ignore those rules. The choice to aggregate low-data-rate NQB-compliant non-L4S traffic into a shared queue with arbitrary data-rate L4S traffic is one that can be made by the network operator/implementer (see below). It is intended to be possible to make that choice, and in fact that is the choice made in Low Latency DOCSIS, now successfully being field trialed in the US.

[CH2] More to the point, I think a lot of the pushback that you are seeing 
comes from a bit of overreach in your draft. You are making two correct 
requirements: that deployments that support your draft operate as you 
specify; and that deployments that do not support your draft treat the 
traffic the same as default marking. But then, you are also making the 
requirement that L4S deployments that do not specifically support your 
draft still process your DSCP code point and move traffic to the low 
latency queue. That's overreach, amounting to an update of the L4S spec. 
I don't think that you can do that.

[GW2] If that is the reason for your pushback, then I think we can resolve it very quickly, because it is wrong!  The NQB draft does not make any requirement (or even any recommendation) that an L4S deployment classify NQB into the low latency queue!  A network node could support just the NQB PHB, or it could support just the L4S DualQ, or it could support both. RFC9331 discusses the latter case in https://www.rfc-editor.org/rfc/rfc9331.html#section-5.4.1.1. RFC9332 discusses it here: https://www.rfc-editor.org/rfc/rfc9332#section-2.3-3 and here: https://www.rfc-editor.org/rfc/rfc9332#section-2.5.1.1  The NQB draft provides its side of this in the first paragraph of section 3.3.  

[GW2] The only update to L4S requirements is the statement:
"L4S network functions SHOULD treat packets marked with the NQB DSCP and ECT(1) or CE the same as packets marked with the Default DSCP and the same ECN value. Here, L4S network functions means the L4S Network Node functions (Section 5 of [RFC9331]), and any mechanisms designed to protect the L4S queue (such as those discussed in Section 8.2 of [RFC9330])."

[GW2] In other words, L4S nodes shouldn't handle "L4S+NQB" packets (DSCP45 && (ECT1 || CE)) any differently from "L4S+Default" packets (DSCP0 && (ECT1 || CE)). This recommendation *only* applies to nodes that support both NQB and L4S.  Since when is it overreach to provide such a clarification to an already published RFC?  If your argument is that we haven't listed RFC9331 and RFC9330 as being Updated by this draft, point taken, we probably should.


[CH2] I think that the whole section 3.3 should be removed, because you cannot 
change the specification of L4S that way. You could progress a separate 
draft for "support of NQB in L4S", but it should be a joint effort 
between you and the L4S team, something that both teams jointly agree.

[GW2] With all due respect Christian, this *was* a joint effort. Section 3.3 exists because TSVWG members had asked that the intersection of NQB and L4S be explicitly discussed in the NQB draft, and I agree with this.  The text in section 3.3 was drafted with substantial input and consultation with Bob Briscoe and Koen DeSchepper (and others in TSVWG).  And, as a co-author of both RFC9330 and 9332, I consider myself part of the "L4S team" anyway!


-- Christian Huitema