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

[Greg White <[e-mail]>]

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