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

[[e-mail]]

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]> 
Gesendet: Dienstag, 7. Februar 2023 01:16
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

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]>" <[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]>> Im Auftrag von [e-mail] <mailto:[e-mail]>
Gesendet: Donnerstag, 12. Januar 2023 01:34
An: [e-mail] <mailto:[e-mail]>
Cc: [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/>


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>


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>




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