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

[Greg White <[e-mail]>]

See inline [GW].

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


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)

[GW] Yes, agreed.

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. 

[GW] I also don't think we are far apart.  The *normal* case is as you described it, and I think the majority of the document aligns with that (it refers to Default traffic as being the traffic sharing resources with NQB-marked traffic).  But, if we can do so easily, I'd like to keep open the option for an operator to have multiple traffic classes (e.g. priorities) and within one or more of those classes have a QB queue and an NQB queue (with configured DSCP classifiers) if they choose. (I know some Wi-Fi implementers are considering implementing L4S Dual-Q within the Best Effort and Video Access Categories, in which case it would be reasonable to support the NQB PHB in both of those Access Categories.) In the requirements section, I had used the term "QB traffic having equivalent importance to the NQB-marked traffic" rather than explicitly calling it "Default" for that reason.  But since we don't further describe this possibility, I understand now that the text is confusing.   Since this isn't the normal case, I'd really rather not go through a lot of trouble to define it and propagate that definition throughout the document, so I'm willing to drop this if we can't describe it relatively easily (I'm sure a crafty network engineer could extrapolate and come up with this concept on their own).  Maybe we could just add a statement along the lines of "While not fully described in this document, it is possible for network equipment to implement a separate QB/NQB pair of queues for additional service classes beyond the Default PHB / NQB PHB pair. "  

[GW] Also, on terminology, I had tried to use a capital D ("Default") when referring to the DiffServ Default PHB and Default DSCP marking (CS0), and a lower-case d ("default") when referring to other meanings.  That said, I see cases where the capitalization is incorrect. I will fix these. 


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.

[GW] I see.  To break that down, the questions are:
-  how many DSCPs MUST an implementation support for purposes of classifying traffic into the NQB PHB.
-  how many DSCPs MUST an implementation support for purposes of classifying traffic into the Default PHB.

[GW] I like the idea of requiring implementations to support configurable identification of traffic to be classified into the NQB PHB via any number of DSCPs (I guess the maximum number would be 63), and by default (lowercase d) a single DSCP = 45 is configured.  But, like I said below, I am ok with mandating a single (configurable) DSCP and leaving multiple DSCP support as a SHOULD. Please let me know if you have an opinion on that. 

[GW] For identifying Default traffic, I suppose it could be argued that we don't need to place requirements here, since we're not defining the Default PHB, and RFC 2474 provides the necessary requirements.  Is that what you would argue? Or, would you be ok saying that a node supporting the NQB PHB MUST/SHOULD support configuration of multiple DSCPs to identify Default traffic?  My preference is to mandate support for configuring multiple DSCPs here too, but it isn't a strong preference. 


Regards,


Ruediger








-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Dienstag, 7. Februar 2023 19:48
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


See below [GW2].


On 2/7/23, 1:14 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,




[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]> <mailto:[e-mail] <mailto:[e-mail]>>> 
Gesendet: Dienstag, 7. Februar 2023 00:03
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
Cc: [e-mail] <mailto:[e-mail]> <mailto:[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]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[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]>> <mailto:[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]>> <mailto:[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]>> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[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;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&gt;> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/&amp;gt;&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;> <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;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html&gt;> <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html&amp;gt;&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;> <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;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15&gt;> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15&amp;gt;&gt;>
















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