Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, classification

[Greg White <[e-mail]>]

See below [GW2].

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


Hi Greg,


[GW] As a mandatory requirement, I think DSCP is the only thing that is needed. I will change that sentence to:
" A node supporting the NQB PHB MUST support the ability to configure the DSCPs that are used to identify QB and NQB traffic of equivalent importance."


[RG] That means multiple DSCPs may be classified for NQB? I'm not sure whether it is necessary to have a statement, that many DSCPs are classified for default forwarding. The latter is a behaviour I'd expect if it is to be a default. Omitting the default part, the sentence you propose is also correct (by what it expresses) in the following way?
"A node supporting the NQB PHB MUST support the ability to configure classification of NQB DSCP and MAY (RG...SHOULD, if you prefer) additionally support the ability to configure classification of other DSCPs for the NQB PHB." (which I think is what most implementations support anyway, I think)

[GW2] It sounds like there are 3 points to reach agreement on here.  First, since the NQB DSCP (45) is only a recommended value, I think it is important that the statement be clear that equipment must not hardcode that value. I think your wording ("configure classification of NQB DSCP") is ambiguous, so I want to stick with something similar to what I wrote above (e.g. "configure the DSCP used to identify NQB traffic").  Secondly, the draft mentions cases where a network operator might wish to classify multiple DSCPs into the NQB queue.  I would prefer a MUST there as well, but I could live with a SHOULD if a MUST is objectionable.  If you can live with a MUST, then the requirement statement can be pretty concise.  On the third topic of Default traffic, note that my sentence above doesn’t mention Default, it mentions QB traffic that is of equivalent importance to NQB traffic. The preceding statement in the draft provides a recommendation that this be 0 ("A node supporting the NQB PHB SHOULD treat traffic marked as Default (DSCP=0) as QB traffic having equivalent importance to the NQB-marked traffic."). I am aware of some large networks that use a different DSCP than 0 for the traffic that is of equivalent importance to NQB.  Also in theory, a network operator could have multiple importance classes, and within each of those importance classes, they could implement a QB queue and an NQB queue.  So, for both of those reasons, I think it is useful that the "equivalent importance" DSCP(s) be configurable.  I could live with a SHOULD here if there was a strong objection to it being a MUST.  Do you object to a MUST?

 

Please confirm or correct.


Regards,


Ruediger




-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Dienstag, 7. Februar 2023 00:03
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 5.1 Primary Requirements, classification


Good catch. See inline [GW].


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




Hi Greg,




5.1. Primary Requirements




4th para:
A node supporting the NQB DSCP MUST support the ability to configure the classification criteria that are used to identify QB and NQB traffic of equivalent importance.




I'd think a node supporting the NQB _PHB_ MUST be able to classify NQB traffic? Or is this draft only about assigning a DSCP to some kind of traffic?


[GW] You are right. It should say "PHB" not "DSCP".




Please further specify what is meant by "the classification criteria that are used to identify QB and NQB traffic of equivalent importance." - criteria is plural. I expect classification on the NQB DSCP. What are the other criteria?


[GW] As a mandatory requirement, I think DSCP is the only thing that is needed. I will change that sentence to:
" A node supporting the NQB PHB MUST support the ability to configure the DSCPs that are used to identify QB and NQB traffic of equivalent importance."










Regards,




Ruediger












-----Ursprüngliche Nachricht-----
Von: tsvwg <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> Im Auftrag von [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
Gesendet: Donnerstag, 12. Januar 2023 01:34
An: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]> <mailto:[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/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;>




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> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html&gt;>




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> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15&gt;>








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