Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 3.3. Relationship to L4S - new marking concept

[[e-mail]]

Most likely we talk past each other. You are referring to the good case of a friendly app programmer, and I agree, that is a reasonable idea. 

I'm referring to the app programmer pursuing the biggest advantage for his app by being standards compliant where that is advantageous, i.e. an app-programmer cherry-picking features from L4S and NQB (including TCP prague requs) to optimize app throughput without obviously ignoring both standards simultaneously. To me, a standards track document must offer text how an access provider reliably fends off traffic of this kind (working detection and working mitigation). That latter part is at least incomplete and I don't think it addresses traffic marked DSCP NQB and ECT (1).

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Dienstag, 7. Februar 2023 19:45
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 3.3. Relationship to L4S - new marking concept

Maybe we are not understanding each other.  You wrote:

- Sender and receiving terminal complying with TCP prague requirements
- NQB traffic marked DSCP NQB & ECT (1), bandwidth hunting

If I'm understanding you correctly, that is not the situation that is intended to be allowed by the statement in the draft, so maybe the statement in the draft isn't as clear as it could be.


The situation that was intended by the statement in the draft would be:

- Receiving terminal complying with the Prague requirements. 
- Sender complying with ALL of the Prague requirements AND with ALL of the NQB sender requirements, and marking its packets as DSCP NQB & ECT(1).

So, an example could be a real-time application which has a maximum codec rate of (e.g.) 1 Mbps, but can reduce its codec rate below 1 Mbps in response to CE-marks.

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. 


-Greg



On 2/7/23, 1:35 AM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


Greg, as long as draft NQB is not having precise requirements how NQB traffic is limited to a low overall percentage at an access - and it never offered these so far (already the scope informs the reader, NQB can be implemented without rate policing) - marking traffic by DSCP NQB and ECT (1), combined with TCP prague requirements opens a path to starvation of competing QB traffic. 
I do not accept "the application programmer will solve the problem" as a solution. I have had experiences with app programmers creating solutions for low latency low loss low jitter queues in the past.


I'm having an issue with that. I'd like to see data proving me wrong, the following test scenario:
- NQB without rate policing and without shaping at the access
- Sender and receiving terminal complying with TCP prague requirements
- NQB traffic marked DSCP NQB & ECT (1), bandwidth hunting
- Receiving terminal attached to WiFi with QB as AC_BE and NQB AC_Vi
- competing QB traffic present
- option 1: L4S scheduling present
- option 2: native NQB (absolutely no L4S capabilities on the access).
- one scenario to be tested is NQB fills the pipe, QB starts after NQB has reached steady state.


Regards,


Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Dienstag, 7. Februar 2023 01:16
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 3.3. Relationship to L4S - new marking concept


I don't see it that way. That statement explicitly says that the application would need to comply with the NQB sender requirements in order to be so marked. If a flow is application-limited to less than 1% of typical path capacity, but also supports (per the IETF guidance reiterated in NQB) a congestion control or circuit breaker mechanism that only comes into play on very low speed links, why would we want to forbid that such an algorithm be compliant to the Prague requirements from RFC9331? 


-Greg






On 2/3/23, 1:12 AM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:




Hi Greg,




3.3. Relationship to L4S
Last para:
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.




This is completely new. A native NQB scheduler doesn't support L4S and an app developer or a CDN sending NQB DSCP & ECT(1) marked traffic can't reliably detect that. By this text, bandwidth hunting TCP transport is made NQB compliant (although earlier text of the NQB draft seems to exclude exactly these) . Please update the doc in all sections where this new marking concept has an impact and provide a discussion on the treatment and properties of TCP traffic marked by DSCP NQB and ECT (1) in a native NQB scheduler. This includes security.




Regards,




Ruediger












-----Ursprüngliche Nachricht-----
Von: tsvwg <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> Im Auftrag von [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
Gesendet: Donnerstag, 12. Januar 2023 01:34
An: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-15.txt








A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.




Title : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services Authors : Greg White Thomas Fossati Filename : draft-ietf-tsvwg-nqb-15.txt Pages : 25 Date : 2023-01-11




Abstract:
This document specifies properties and characteristics of a Non- Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB PHB is to provide a separate queue that enables smooth, low-data- rate, application-limited traffic flows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building flows.








The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;>




There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html&gt;>




A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15&gt;>








Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts