Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is) - objective verification

[[e-mail]]

[RG] Please confirm: your response is to say, that the authors of NQB deem the traffic protection to be sufficiently specified for multiple, functionally compatible implementations by the following: 
- identify flows that are inconsistent
- either re-mark those flows/packets as Default and reclassify them to the QB queue or discard the offending traffic. 
- SHOULD be implemented in an objective and verifiable manner, basing its decisions upon the behavior of the flow rather than on application-layer constructs. 
- RECOMMEND to base decisions on the detection of actual queuing, 
- employing hysteresis could be advantageous
- maintain some sort of flow state. 
- The traffic protection function MUST be designed to fail gracefully in the case that the flow state is exhausted.

[RG] I personally wouldn't expect two vendors to offer me implementations compatible by functionality, as draft NQB doesn't specify what a flow is or could be. And even if "flow" was specified to some basic level, I doubt that two different implementers come up with the same method for objective verifiable manner, producing identical results by function. I don't expect all implementations to be identical, but I expect a standard to standardize behaviour. 

[RG] As an example, I pick EF. The only functional requirement there is a simple rate-limit, if PQ or the like is deployed. The authors don't specify how the rate limit is implemented, they however clearly specify the function:
- the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter).
- Traffic that exceeds this limit MUST be discarded. 
- This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator

[RG] Crisp, clear, and verifiable REQUIRED functionality, without defining exact mechanisms. I suggest that the authors specify the "traffic protection" of NQB by requirements in a way as EF does specify how an EF compatible rate limiter works.

[RG] I take it as support of my feedback that even scheduler experts and contributors to TSVWG come back by questions to the NQB authors, see

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

https://mailarchive.ietf.org/arch/msg/tsvwg/nfiZC5LKHnZkJbmfa0LH-nYp9-c/ 



-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Sonntag, 12. März 2023 01:05
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection (text as is)

See [GW].

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


<snip>
- draft: Such a function SHOULD be implemented in an objective and verifiable manner, basing its decisions upon the behavior of the flow rather than on application-layer constructs.
<snip>

Objectively verified against which requirements (a requirement which can be verified is, e.g.: a sending rate SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate).
The draft doesn’t contain neither a specification, nor a definition, what a flow is, and it doesn't determine requirements on flow rates, which can be verified. All it offers is descriptive text to the latter.

[GW] The statement is that the implementation should be both objective and verifiable, which it then clarifies to mean that it bases its decisions on flow behavior rather than on *what* a flow is. The immediately preceding sentence defines the "function" as being one that can identify flows that are inconsistent with the sender requirements in Section 4.1.    So, what we're trying to get at is that the decision to take action SHOULD be driven by these objective aspects, and that it SHOULD be possible to verify that this is the case (presumably by introducing flows with different behavioral characteristics, or I suppose by inspecting source code).   I think it is important to state this. 



-----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