Should we more strongly encourage NQB applications to implement L4S?

[gwhiteCL]

https://mailarchive.ietf.org/arch/msg/tsvwg/i4sz-cMb5MOLBCzDv47RFB0cn7g/

In some earlier emails on this topic, I had thought that this would be a non-typical case, but I am reconsidering that. I think the IETF should encourage low-data-rate NQB-compliant applications to also implement an L4S-compliant congestion response, rather than a circuit-breaker or other (non-L4S) congestion response. There are a couple of benefits to this. One is that the application can't know a priori whether the network bottlenecks support the NQB PHB, or an L4S dual-queue, or both. Complying with the superset of requirements, and marking traffic with both DSCP NQB & ECT(1) could provide it the best chance of achieving low latency. Secondly, an NQB-compliant application that implements an L4S congestion response could achieve better latency performance than one that implements a circuit-breaker or some other (non-L4S) congestion response (e.g. delay or loss based) when it finds itself in a low data rate (e.g. well below "typical path capacity") L4S-aware bottleneck.

https://mailarchive.ietf.org/arch/msg/tsvwg/qjVx4gABUWMsw0aq05x0zgHVJSA/

9. “Note that, while such flows ordinarily don't implement a traditional congestion control mechanism, they”

[GW] .... Actually, I'm still a bit uneasy with how that is presented. As I mentioned in https://mailarchive.ietf.org/arch/msg/tsvwg/i4sz-cMb5MOLBCzDv47RFB0cn7g/ I don't see why we wouldn't want to encourage ALL NQB-marked applications to also implement an L4S-compliant congestion controller. Later in this section we recommend that NQB non-compliant applications consider implementing L4S, but why not low-data rate ones too?

[GF2] I think some classes of very low rate apps will find it hard to respond to ECN - because they send too infrequently and might not be able to understand marks properly. To me, these are a good match to NQB. Anything that has many packets in flight or sends many packets/sec could be encouraged to use L4S. This should be thought through.

[gorryfair]

I also noted this response from Fred Baker, which could be useful in forming the text: " The expectation is that the other queue is a deep-buffered one carrying traditional congestion-controlled flows, so it's not unlikely that the other queue has a delay much greater than the NQB queue."

[gwhiteCL]

At the end of the paragraph in the NQB sender requirements section that talks about the need for congestion response, I added the statement: "One way that an application marking its flows as NQB can handle this is to implement a low latency congestion control mechanism as described in [RFC9331]." This is in: https://github.com/gwhiteCL/NQBdraft/commit/60b17cceeb0227d65d14d14a2126b4a03774562f

[gwhiteCL]

https://github.com/gwhiteCL/NQBdraft/commit/66d386fc7f62819137a86f3bcea878e30e805e72 : s/flows/traffic in the sentence added by https://github.com/gwhiteCL/NQBdraft/commit/60b17cceeb0227d65d14d14a2126b4a03774562f