Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 4.2. Aggregation of the NQB DSCP with other Diffserv PHBs

[Greg White <[e-mail]>]

Hi Ruediger,

Sorry for the delay in getting back to this.  I'm not sure that the scenario you describe aligns with the philosophy of the NQB PHB.  What you are describing sounds to me like the EF PHB.  With EF, the goal is a guarantee (or very high probability) of low/bounded latency for a groomed subset of traffic in a controlled environment.   NQB on the other hand is intended to provide "statistically better loss, latency and jitter" (as compared to the Default queue) for Best Effort Internet traffic on Access Network segments. With Internet traffic, there is no option to implement admission control, there are no trusted senders, and there are very few known properties. So, we are relying on creating appropriate incentives such that mis-use is minimized, and we are recommending mechanisms to shed load and minimize degradations when overload conditions inevitably occur.   The Queue Protection mechanism implemented in the NQB PHB in DOCSIS equipment, in simple terms, aims to maintain a low queuing delay by selectively redirecting traffic from the flows that are causing a queue to form (only when they are causing it) and not redirecting traffic from the flows that aren't causing the queue.  To restate my point, this is different from EF, where (in my understanding) there is an expectation of trust and control over DSCP markings at the sender, and overload is either prevented via admission control protocols (either you get service or you get a "busy signal") or traffic conditioning introduces delay and loss to all flows equally. 

I tried to recognize in the draft that in many networks there may exist traffic that is carried as Best Effort today (i.e. no SLA), but that is largely compliant with the NQB sender requirements, though it is not marked with the recommended DSCP.  In that case, aggregation of such traffic into the NQB PHB might be a good option (for a network operator that wishes to provide good Best Effort performance) rather than aggregating it into the Default queue. It certainly wasn't my intent to describe how an operator can build something like an SLA service using the NQB PHB (which sounds like what you are asking for).  But even setting that aside, this is a controversial topic, and one which network operators need to carefully consider before implementing.  I think the recommendations in section 5 of https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-01.html provide good rationales as to why we should be careful encouraging operators to pick and choose which applications get access to the NQB PHB and which ones don't.  Introducing multi-field classification seems to me like it crosses that line, whereas aggregating additional DSCPs seems (to me) safer, since the application has presumably chosen to mark its traffic with a non-default DSCP under an expectation that the network would treat it differently.   But, I recognize that others could have different views.  

-Greg



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


Hi Greg,


I'm ok with emphasizing operator responsibility rather than, let's say, node responsibility. Without going to details by this mail, it might make sense to add text related to multifield classification, rather than DSCP based classification only (if it is about forwarding other classes by NQB PHB and the traffic offered by these classes isn't reliably NQB). Low loss and low jitter result from keeping the actual load rate below scheduler bandwidth. If just the DSCP is used for classification and all trust is based on the NQB DSCP only, traffic conditioning may have different requirements as compared to multifield classification, where the operator tries to ensure that a trusted sender creates traffic with known properties for access configurations of known properties, and then forward it by the NQB queue. Example: the NQB scheduler has a transmit rate of 25 Mbit/s (or more) and a broadcast stream of known and controlled origin offers 6-8 Mbit/s, then that may work (for a limited number of broadcast flows). To add, the same operator may offer accesses with an NQB scheduler of 5 Mbit/s under some circumstances. The operator wouldn't classify any broadcast traffic for NQB for the latter.


If the above scenario is something you'd like to address by "classifying other classes for the NQB PHB" (or whatever headline you prefer), then I'd appreciate text explaining that. What worries me is, the text as is seems to propose classification based on DSCP only. 


Regards,


Ruediger


-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]>> 
Gesendet: Montag, 13. Februar 2023 19:25
An: Geib, Rüdiger <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Betreff: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - 4.2. Aggregation of the NQB DSCP with other Diffserv PHBs


Thanks Ruediger, see [GW2] below.




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




Thanks, I agree to a). The open point, comments [RG]:




b) In this last paragraph, draft NQB adds the service classes Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video (CS3) as eligible to be forwarded by an NQB PHB, as compared to EF and Voice Admit only as specified by RFC9332. Please provide text explaining, why Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video (CS3) are not queue building in draft NQB (standards track), while they seem to be queue building in RFC9332 (experimental).




[GW] In both documents the lists are provided as examples, not as exhaustive lists, nor even directly as recommendations. The RFC9332 sentence says "... an operator could ... classify ... into the L queue ... for instance ... Diffserv codepoints such as ...." So, if there are some differences in the chosen examples between the two documents I don't think it is a problem. In NQB, I based the list of examples on the information provided in Figures 1, 2 & 3 of RFC 4594 in an attempt to be consistent with prior IETF guidance, though to be honest I personally think that document is rather dated at this point. In the end, I think that a network operator would need to use their informed judgement in aggregating other DSCPs with either NQB or L4S traffic, rather than assuming that all traffic is DSCP marked according to the recommendations in RFC 4594. To that end, I'm noticing that the paragraph in NQB starts off with "Nodes that support the NQB PHB may choose to ...". We probably shouldn't put that responsibility in the hands of the node itself. It should be in the hands of the network operator to make this choice. I will change that wording. I could also add some more cautionary language that the operator would need to use their judgement as to which DSCPs are actually aggregated. Would that address your concern?




[RG] RFC9332 is experimental, it proposes Q-Protection and requires Q-Coupling and still is conservative in suggesting suitable other classes which may be classified for the L4S PHB. Draft NQB is standards track, a native NQB queue may be unpoliced, if some form of queue protection is deployed, but list more and bandwidth hungry, bursty traffic classes to be classified for a native NQB queue. Yes, I'd like to see more text, how it can be determined whether this traffic should be classified for NQB. Please also clarify, how the operator should classify this traffic - is that just by DSCP or is that MF classification (or an undefined "flow" concept), should rate control be applied? 
- please clarify, whether your list of example classes to be forwarded by the NQB PHB also indicates, that these should be forwarded by L4S PHB. I appreciate clarity to that point.
- if classes Real-Time Interactive (CS4) and Broadcast Video (CS3) are eligible to be forwarded by an NQB PHB, but not by L4S, please add text why traffic sources with properties like 4k broadcast, explained by e.g. https://www.agora.io/en/blog/what-is-video-bandwidth/ <https://www.agora.io/en/blog/what-is-video-bandwidth/> <https://www.agora.io/en/blog/what-is-video-bandwidth/> <https://www.agora.io/en/blog/what-is-video-bandwidth/&gt;>, are most likely never causing queues. 


[GW2] These are fair points, and this brings up a bigger discussion. I arguably should not have included CS3 in the list since broadcast video could be expected to be greater than 1% of typical path capacity. Real-Time Interactive is a tough one, because it includes PC/Console game state update traffic as well as video conferencing. But the bigger discussion point is that I was (probably against better judgement) pedantically following the RFC 4594 path when I created that list. Crafting this draft has been a struggle to balance maintaining consistency with the other RFCs in the Diffserv series, consistency with the way in which WG members believe Diffserv works (or should work) in an ideal Diffserv-aware world, and the way in which WG members believe DSCPs are used (or should be used) in reality today and in the future. Finding the right balance appears to be needed in order to reach WG consensus, but it is challenging to find. In my view, the descriptions of the service classes in RFC 4594 have not stood the test of time, and in real life, traffic is generally NOT marked according to RFC 4594, and is unlikely to be marked that way anytime soon (for very valid and good reasons IMO), so listing these service classes and DSCPs doesn't provide any real value for real networks. As a result, trying to build real-world guidance into a paragraph that is based on the RFC 4594 theoretical service classes and DSCPs is not likely going to work out in the end. I'd be ok scrapping any discussion of the RFC 4594 Service Classes (and DSCPs) in this section. But, I was informed that for achieving WG consensus it was important to include them. What I am thinking is maybe a path forward here would be to caveat those statements with "For networks that use the RFC4594 service classes, ...", in addition to adding the guidance that the operator needs to use their judgement and knowledge of the DSCPs in use in their network environment. Here is an attempt. Let me know if you agree with this.


4.3 Aggregation of other DSCPs in the NQB PHB Operators of nodes that support the NQB PHB may choose to aggregate other service classes into the NQB queue. This is particularly useful in cases where specialized PHBs for these other service classes are not provided. Candidate service classes for this aggregation would include those that carry low-data-rate inelastic traffic that has low to very-low tolerance for loss, latency and/or jitter. An operator would need to use their own judgement based on the actual traffic characteristics in their network in deciding whether or not to aggregate other service classes / DSCPs with NQB. For networks that use the <xref target="RFC4594"/> service class definitions, this could include Telephony (EF/VA), Signaling (CS5), and possibly Real-Time Interactive (CS4) (depending on data rate). In some networks, equipment limitations may necessitate aggregating a range of DSCPs (e.g. traffic marked with DSCPs 40-47, i.e., those whose three MSBs are 0b101). As noted in <xref target="sender"/>, the choice of the value 45 is motivated in part by the desire to make this aggregation simpler in network equipment that can classify packets via comparing the DSCP value to a range of configured values. 












Regards,




Ruediger




-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
Gesendet: Donnerstag, 9. Februar 2023 22:22
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 - 4.2. Aggregation of the NQB DSCP with other Diffserv PHBs




Thanks Ruediger, responses below [GW].




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








4.2. Aggregation of the NQB DSCP with other Diffserv PHBs








Last Para
Nodes that support the NQB PHB may choose to aggregate other service classes into the NQB queue....These could include Telephony (EF/VA), Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video (CS3). Or...[aggregates of] all traffic marked with DSCPs 40-47 (i.e., whose three MSBs are 0b101). 








https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification> <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification> <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification&gt;> <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification> <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification&gt;> <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification&gt;> <https://www.rfc-editor.org/rfc/rfc9332.html#name-traffic-classification&amp;gt;&gt;>
In addition, an operator could use other identifiers to classify certain additional packet types into the L queue that it deems will not risk harm to the L4S service, for instance, addresses of specific applications or hosts; specific Diffserv codepoints such as EF, Voice-Admit, or the Non-Queue-Building (NQB) per-hop behaviour; or certain protocols (e.g., ARP and DNS) (see Section 5.4.1 of [RFC9331].








a) the last paragraph of draft NQB section 4.2 describes which service classes may be forwarded by the NQB PHB, a content which a reader wouldn't expect with the headline "Aggregation of the NQB DSCP with other Diffserv PHBs". 




[GW] You are right. Most of that section covers carriage of the NQB DSCP in networks that don’t support the PHB, while the last paragraph covers aggregation of other DSCPs into the NQB PHB in a node that supports it. These are opposite cases in a sense. I'll add a subheading "4.3 Aggregation of other DSCPs in the NQB PHB" immediately before that last paragraph. That would make it easier for the reader to follow I think.












b) In this last paragraph, draft NQB adds the service classes Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video (CS3) as eligible to be forwarded by an NQB PHB, as compared to EF and Voice Admit only as specified by RFC9332. Please provide text explaining, why Signaling (CS5), Real-Time Interactive (CS4) and Broadcast Video (CS3) are not queue building in draft NQB (standards track), while they seem to be queue building in RFC9332 (experimental).




[GW] In both documents the lists are provided as examples, not as exhaustive lists, nor even directly as recommendations. The RFC9332 sentence says "... an operator could ... classify ... into the L queue ... for instance ... Diffserv codepoints such as ...." So, if there are some differences in the chosen examples between the two documents I don't think it is a problem. In NQB, I based the list of examples on the information provided in Figures 1, 2 & 3 of RFC 4594 in an attempt to be consistent with prior IETF guidance, though to be honest I personally think that document is rather dated at this point. In the end, I think that a network operator would need to use their informed judgement in aggregating other DSCPs with either NQB or L4S traffic, rather than assuming that all traffic is DSCP marked according to the recommendations in RFC 4954. To that end, I'm noticing that the paragraph in NQB starts off with "Nodes that support the NQB PHB may choose to ...". We probably shouldn't put that responsibility in the hands of the node itself. It should be in the hands of the network operator to make this choice. I will change that wording. I could also add some more cautionary language that the operator would need to use their judgement as to which DSCPs are actually aggregated. Would that address your concern?












I further note and take it for granted, that range based DSCP classification as a standards track DiffServ feature has been consented by the chairs.








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