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

[[e-mail]]

Hi Greg,

I'm ok with text about
-  One DSCP being classified as NQB (MUST)
-  other DSCPs can be classified for NQB PHB too (a MUST would refer to a configurable option...the statement shouldn't require classification of multiple DSCP for NQB, it requires a classification option)

Text related to classification of what is likely QB traffic.
- this traffic is to be forwarded by default PHB, I think
- but "default resources" are configured to be fairly shared by an NQB queue and a QB/default-configured-Queue ( terms default traffic / Default / default-forwarding appear often in draft NQB)
- a set of DSCPs is classified for the overall default resources (NQB and QB)
- a subset of these DSCPs is classified for NQB.
- I'd expect traffic marked by DSCPs which are are forwared by default resources, but which are not classified for NQB, to be forwarded by a default PHB. RFC 2474 also requires that: Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior.
(- many networks remark traffic with unrecognized DSCPs to DSCP 0 / default prior to being forwarded to an access scheduler, and in that case it is just DSCP 0 which is forwarded by the default scheduler)

If this is wrong and there's a QB PHB and not just a default PHB, the draft should provide text explaining that. But I'd be surprised if we were lying far apart on this issue. 

Your original sentence read ....MUST support the ability to configure the DSCPs that are used to identify QB and NQB traffic.... It is unclear to which situation(s) the plural "DSCPs" refers. That's why I started this. Could be
- one DSCP NQB, one DSCP default
- many DSCP NQB, one DSCP default
- one DSCP NQB, many DSCP default
- many DSCP NQB, many DSCP default.

Regards,

Ruediger
 



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

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