[tsvwg] Re: Roman Danyliw's Discuss on draft-ietf-tsvwg-nqb-30: (with DISCUSS and COMMENT)

[Greg White <[e-mail]>]

Roman, 

Thank you for your review.

Please see my responses below (marked [GW]).

-Greg

On 8/1/25, 5:46 PM, "Roman Danyliw via Datatracker" <[e-mail] <mailto:[e-mail]>> wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-tsvwg-nqb-30: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/>

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


** Section 6.2
Networks and nodes that do not support the NQB PHB ought to only
classify packets with the NQB DSCP value into the appropriate
treatment aggregate, or encapsulate such packets for purposes of
aggregation, and SHOULD NOT re-mark them with a different DSCP. This
preservation of the NQB DSCP value enables hops further along the
path to provide the NQB PHB successfully. This aligns with
recommendations in [RFC5127].


The intent of this specification appears to be describing the normative
behavior for NQB PHB for DiffServ. However, the text above appears to be
providing normative guidance to “networks and nodes that do not support NQB
PHB”. If those network elements never intended to be conformant to NQB PHB,
how can this document impose behavior on them? Is this document intended to
provide guidance to all DiffServ implementations?

[GW] All of the requirements that define normative behavior for nodes that implement the PHB are explicitly labeled in that way e.g "A node supporting the NQB PHB MUST ..." This was intentional.  This specific recommendation is almost certainly an operational one rather than a recommendation relating to implementation, but it is intended to provide guidance for operators of all Diffserv networks. It is likely that there will be networks that aren't informed by the text of this specification, and hence might not implement this recommendation, but it is only a recommendation, not a mandatory requirement.  



The alignment to the recommendations in RFC5127 appears to be from Section
4.1.3 (of RFC5127), “In addition, the class selector DSCP value should not be
changed.” Is this informational status document mandatory to implement for
DiffServ implementations? If not, then relying on it to motivate particular
behavior seems challenging.

[GW] I disagree. The motivation for our recommendation doesn't come from alignment with RFC5127, it comes from the sentence that precedes it: "This preservation of the NQB DSCP value enables hops further along the path to provide the NQB PHB successfully."  It would be challenging if our recommendation here *conflicted* with the recommendations in RFC5127.  But, since it aligns with them I don't see any issue. 



** Section 8
This document requests that IANA assign the Differentiated Services
Field Codepoint (DSCP) 45 ('0b101101', 0x2D) from the "Differentiated
Services Field Codepoints (DSCP)" registry
(https://www.iana.org/assignments/dscp-registry/ <https://www.iana.org/assignments/dscp-registry/>) ("DSCP Pool 3
Codepoints", Codepoint Space xxxx01, Standards Action) as the
RECOMMENDED codepoint for Non-Queue-Building behavior.


What does the normative phrase “… as the RECOMMENDED codepoint for …” mean in
the context of an IANA action. There is no preference information reflected in
the registry.

[GW] Agreed. I will change it to lower case "recommended". (And, to be clear, the specific registry updates come after the statement "IANA should update this registry as follows:"  The material that precedes that statement (including the word RECOMMENDED that you quoted) aren't part of the registry update.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thank you to Vijay Gurbani for the GENART review.


** Section 5.2
To prevent this situation from harming the performance of the
microflows that comply with the requirements in Section 4, network
elements that support the NQB PHB SHOULD support a "traffic
protection" function that can identify microflows or packets that are
inconsistent with the sender requirements in Section 4, and either
reclassify those microflows/packets to the QB queue or discard the
offending traffic.
…
This is the
motivation for the "SHOULD" requirement to support traffic protection
(in the previous paragraph). An NQB PHB implementation that does not
support traffic protection risks being limited to deployment
situations where traffic protection is potentially not necessary.


When is it acceptable for a NQB PHB NOT to support a “traffic protection”
function? Isn’t this critical to the approach?

[GW] An example is provided in the last sentence of the paragraph from which you drew the quotation.  Also, the last paragraph in that section describes other cases.  Regarding criticality, NQB is not intended to be a guaranteed service. In small networks, it may be sufficient (and more feasible with current equipment) to provide the PHB without traffic protection.  In such a case, it may be that mis-marked traffic is not present the majority of the time, and NQB-marked traffic thus gets a significant benefit by not being subjected to queuing latency.  The amount of degradation to NQB-marked traffic caused by the appearance of mismarked traffic would depend on the details of the situation, and it could be that occasional loss of the NQB benefit, or even occasional degradation below the performance of the QB queue would be an acceptable tradeoff for getting a significant benefit the majority of the time.  Of course, in many situations, the traffic protection approach would be the preferred implementation (hence the SHOULD).