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

[Roman Danyliw via Datatracker <[e-mail]>]

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



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

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.

** 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/) ("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.


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