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

[[e-mail]]

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 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?

[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/, are most likely never causing queues. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Greg White <[e-mail]> 
Gesendet: Donnerstag, 9. Februar 2023 22:22
An: Geib, Rüdiger <[e-mail]>
Cc: [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]>" <[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>
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]>> 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