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

[Greg White <[e-mail]>]

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