Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection - Requirements and example ref

[[e-mail]]

Hi Greg,

I'm sorry, if my English may have caused misunderstandings. So I reply and try to reformulate:

- I agree with you, that the requirements I ask for should not include the exact mechanism and algorithm as specified for DOCSIS
- however I expect the requirements provided by a standard to be sufficient to allow for compatible implementations and operation; to be more clear, algo's and mechanisms may be different, but externally observable behaviour is identical (or compatible, as IETF puts it, but in the case of scheduling that is better described by statistically equivalent behaviour).
- and to me, a specification for this behaviour is missing in major parts for NQB (I don't object to having it as an RFC as is, but it's not ready for standards track, I think).

If you look at EF as a comparison, the specification there neither is limited to a particular scheduling behaviour, nor to particular rate limiting mechanism. Still the required properties are specified in a way allowing implementers and operators to develop and qualify, respectively,  products of different vendors without having to create additional requirements:

- The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. 
- It 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 configured minimum rate MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration).
 - If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter).
- This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration).

Please provide a set of requirements for NQB, which allow operators and implementors to develop and validate standard NQB deployments in an objectively verifiable manner, which behave compatible (statistically equivalent). I'm not out for writing call's for tender containing detailed specifications of the specifications missing in draft NQB.

Regards,

Ruediger



-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Sonntag, 12. März 2023 01:19
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Section 5.2. Traffic Protection - Requirements and example ref

Hi Ruediger,

I disagree.  I think it is important to allow for product differentiation in this space, and to specify the requirements essentially as they are: that the goal is to identify traffic flows that are causing queue delay in the NQB queue and remove them. Recall that in Internet service deployments, this function provides one of the main disincentives to mis-marking of non-compliant traffic as NQB.  Alignment around very specific requirements could result in applications exploiting limitations in the defined approach.  We provide the current DOCSIS algorithm (and the IPR is royalty-free) as an example, but we should not stand in the way of others proposing other algorithms, or making improvements to the DOCSIS algorithm, as long as the goal is to protect the forwarding behavior of compliant flows.

-Greg





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


Hi Greg,


Section 5.2. Traffic Protection


To me, one of the features which might add value to am NQB PHB as compared to EF as specified by Van Jacobsen et al. could be a queue protection. The draft offers a reference to an IPR protected ID, https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html#I-D.briscoe-docsis-q-protection <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html#I-D.briscoe-docsis-q-protection>. My personal view is, unless draft NQB defines generic requirements for a queue protection, which can be implemented without having to deploy the IPR protected ID. The text of section 5.2 is insufficient to do so. 


As an example for text where I'd assume you can find some generic requirements (including requirements language), please have a look at


Data-Over-Cable Service Interface Specifications DOCSIS® 3.1 MAC and Upper Layer Protocols Interface Specification
CM-SP-MULPIv3.1-I24-221019


https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=b13a1ebb-93de-4bda-b13d-e96186ac5671 <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=b13a1ebb-93de-4bda-b13d-e96186ac5671>


or via https://www.cablelabs.com/specifications/search?currentPage=1&query=&category=DOCSIS&doctype=Specifications&content=false&archives=false&subcat=DOCSIS%203.1 <https://www.cablelabs.com/specifications/search?currentPage=1&amp;query=&amp;category=DOCSIS&amp;doctype=Specifications&amp;content=false&amp;archives=false&amp;subcat=DOCSIS%203.1>
should the above one not work.


There see Annex P.3 Microflow Categorization, especially section P.3 Microflow Categorization


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