[tsvwg] Re: TSVWG Shepherd question and comments concerning publication request for NQB

[Sebastian Moeller <[e-mail]>]

Hi Gorry,

On 4 November 2024 17:43:57 CET, Gorry Fairhurst <[e-mail]> wrote:
>Editor(s),
>
>While preparing the publication request for NQB, I enclose the following comments and questions.
>
>Best wishes,
>Gorry
>
>--------------------------
>
>1. Please could you as an editor confirm that this document isconsistent with the Technical Errata for RFC8325, and that they have read thart erratum:
>
>https://www.rfc-editor.org/errata/rfc8325 <https://www.rfc-editor.org/errata/rfc8325<https://www.rfc-editor.org/errata/rfc8325<https://www.rfc-editor.org/errata/rfc8325&gt;>
>
>
>2. All authors: No IPR disclosures are known to have been submitted. Please individually confirm that all authors havedeclared all known IPR, according to the IPR rules for the IETF.
>
>
>3. All authors: Please individually confirm that you are content foryour name to appear when this is published as an RFC.
>
>
>4. Writeup:
>
>The WG has rough consensus on the use of this codepoint, and the chairs note that ar least one person (Sebastian Moeller) was not content with this allocation based on the methods defined in this I-D, noting concerns about the potential impact on deployed equipment that does not comply with the new spec.

More predicted and expected impact, and less potential/unlikely impact. 

>
>ID NiTs: These have been checked, the writeup will need to note:
>
>[NOTE: A section references the obsoleted RFC2598 instead of itsreplacement RFC3246, because the former contains the description ofEF performance.]
>
>
>5. Please remove Sebastian Moeller from the Acknowledgements section.

Thanks.

> Inote “he doesn’t wish to contribute to the work”.

This is an odd way of phrasing my request, I already did contribute quite a some time and effort to this ID. I do not want to be associated with the current ID as my effort essentially has been ignored and rejected based on pure thought experiments. That is not well described as "does not want to contribute", puzzled how you end up summarizing it this way...

>
>
>---
>
>1. Feeback from the document shepherd.
>
>1a)
>
>I have a top-level request for the introduction, where I would like tosee an additional early paragraph that alerts a reader who has nocurrent plans to add NQB support but needs to know what the implicationsare for their network carrying NQB traffic. This seems like anopportunity to point to Section 4.2 and 4.4.1 very early in theintroduction.This would let people know to read about how to configure networks and nodes that do not support the NQB PHB. A mention of section 7 therewould also be useful, especially noting that this section providesguidance for interoperability with existing Wi-Fi network equipment.
>
>My suggestion would be to add something like:
>
>Sections 4 and section 7, provide guidance for operators that forward traffic marked with the NQB DSCP. Networks that do not currently implement support for the NQB PHB are decsribed in Section 4 regarding the recommended DSCP for the NQB traffic, and, in particular, Section 4.2, which provides specific recommendations for this case.  In addition, Section 4.4 provides recommendations around interconnection with networks that do support the NQB PHB.
>
>--
>
>1b)
>
>“which will mean AC_VI is at the same priority level as AC_BE. Thesechanges might not be possible on all Access Points,”
>
>I suggest addition of another case:
>
>NEW
>
>“... and in any case the requirements and recommendations in [Section 4.4.1] would apply in this situation."
>
>END
>
>---
>
>1c)
>
>OLD
>
>...leads to the conclusion that NQB non-compliant applications thatare seeking prioritization in the Wi-Fiuplink would be better off selecting one of those other DSCPs.
>
>- This could be further explained. Text suggested by David Black is below:
>
>ADD NEW AFTER
>
>This conclusion is not expected to be disturbed by network support forNQB increasing the likelihood of DSCP 45 traffic traversing networkboundaries without change to the DSCP, as that likelihood of increasednetwork boundary traversal is balanced by a likelihood of NQB trafficencountering the traffic-limiting aspects of NQB support, trafficprotection and shallow buffers, which limit the potential for abuse.
>
>END
>
>--
>
>2. Remaining  comments (editorial):
>
>---
>
>I query if this could be acceptable as: /highly unlikely to
>
>exceed/unlikely to exceed/
>
>- with the rationale that you do not need to evidence how unlikely this is.
>
>----
>
>Definitions
>
>Diffserv Code Points - please could you define DSCP when first mentioned
>
>in section 3.2.
>
>per-hop-behaviors - please could you define PHB when first mentioned
>
>in section 3.2.
>
>---
>
>“best-effort service as a complement to a Default deep-buffered best-effort service.”
>
>- It seems here a reference of some explanation that “Default” is the
>
>best effort service class might be really useful,  I suggest:
>
>OLD:
>
>as a complement to a Default deep-buffered best-effort service
>
>NEW:
>
>as a complement to a Default (see [RFC2474]) deep-buffered best-effort service
>
>END
>
>---
>
>“While this architecture is powerful and flexible enough to beconfigured to meet the performance requirements of a variety ofapplications and traffic categories, or to achieve differentiatedservice offerings, it has not been used for these purposes across theInternet....”
>
>- The original text is a hard claim that might be hard substantiate. I suggest something like
>
>NEW:
>While this architecture is powerful and flexible enough to be configured to meet the performance requirements of a variety of applications and traffic categories, or to achieve differentiated service offerings.
>
>Meeting the performance requirements of an application across the entire sender-to-receiver path involves all the networks in the path agreeing on what those requirements are and sharing an interest in meeting them. In many cases this is made more difficult since the performance "requirements" are not strict ones (e.g., applications will degrade in some manner as loss/latency/jitter increase), so the importance of meeting them for any particular application in some cases involves a judgment as to the value of avoiding some amount of degradation in quality for that application in exchange for an increase in the degradation of another application.
>
>END
>
>---
>
>I quibble:
>
>“reserved bandwidth other than any minimum bandwidth that it shareswith Default traffic.”
>
>- This isn’t so much about bandwidth as capacity for a flow, although Isee the two terms used interchangeably with preference varying. I’dprefer capacity here if that seems good to you.
>
>OLD:
>bandwidth
>
>NEW:
>
>capacity
>
>END
>
>---
>
>“The NQB PHB is therefore intended for the prevalent situation wherethe performance requirements of applications cannot be assured across
>
>the whole sender-to-receiver path, and as a result, applicationscannot feasibly place requirements on the network. ”
>
>- Perhaps true, could the editors please consider to remove the word  “prevalent”?
>
>OLD:
>
>intended for the prevalent situation
>
>NEW:
>
>intended for the situation
>
>END
>
>---
>
>“of fair allocation of bandwidthbetween the QB and NQB queues (Section 5).”
>
>- Is this also capacity rather than bandwidth? (you may like to checkother uses of the word also).
>
>OLD:
>
>allocation of bandwidth between
>
>NEW:
>
>allocation of capacity between
>
>END
>
>---
>
>- I suggest a para break in the middle of 3.3, before “NQB networkfunctions SHOULD” to separate the normative statement.
>
>- I also suggest a para break before “In nodes that support both the NQB
>
>PHB and L4S”.
>
>---
>
>“Here, NQB network functions means the traffic protection”
>
>OLD:
>
>means
>
>NEW:
>
>refers to
>
>END
>
>---
>
>“Here, L4S network functions means..”
>
>OLD:
>
>means
>
>NEW:
>
>refers to
>
>END
>
>---
>
>In section 3.4.
>
>- I suggest a para break before “In nodes that do not”.
>
>- This sentence is long, and parsable, but is not an easy read, pleaseconsider breaking into more than one sentence.
>
>---
>
>“Microflows that are marked with the NQB DSCP SHOULD align with thedescription of behavior in the preceding paragraphs in this section.”
>
>- I am not happy with this RFC21198 usage. Why the word SHOULD?
>
>- I argue that the flows that conform with this description areRECOMMENDED to use this, and that there is no “SHOULD” (or exceptions to
>
>the should), it’s simple fact that these are the subset of flows thatare recommended. I sugges the editors delete the word" SHOULD":
>
>OLD:
>
>DSCP SHOULD align with
>
>NEW:
>
>DSCP align with
>
>END
>
>---
>
>“In both cases, the result could be thatexcess traffic is discarded or queued separately as default traffic..”
>
>- I think this ought to be clarified that it refers to the “microflow's”excess traffic, not the aggregate.
>
>OLD:
>
>excess traffic is
>
>NEW:
>
>excess traffic belonging to the microflows is
>
>END
>
>---
>
>I am not happy with this statement here:
>
>“At the time of writing, it is
>
>believed that 500 kbps is a reasonable upper bound on instantaneous
>
>traffic rate for a microflow marked with the NQB DSCP on the
>
>Internet.”
>
>-please remove or cross-reference tothe section where the caveat is discussed for this.
>
>---
>
>“ do not support the NQB PHB should only”
>
>- please could you can we avoid ‘should’ here and say ‘ought to’ or justsay “SHOULD”, to avoid people asking if this was some unclear requirement?
>
>---
>
>Section 4.3
>
>- When I read this section it looks like it might be a new set ofmachinery, but I think that was not intended. I would suggest adding asentence at the very start of the section that says something like
>
>NEW:
>
>TheDifferentiated Services model provides flexibility for operators tocontrol the way they choose to aggregate traffic marked with a specificDSCP.
>
>END.
>
>---
>
>“it is RECOMMENDEDthat the operator of the upstream domain implement the followingsafeguards before delivering traffic into a non-DS-capable domain.”
>
>- So reading in pedantic mode, this doesn’t clearly identify WHAT isrecommended.
>
>... Placing the next two paras as numbered bullets would be astep to making it clear there are one of two recommended methods toprovide this safeguard.
>
>---
>
>OLD:
>
>It should be noted that a
>
>NEW:
>
>Note that a
>
>END
>
>---
>
>“In the case that a traffic policing function or a rate shaping function”
>
>... if we can structure this better (e.g. indented), I’d really like to
>
>see a para break before this to clearly separate the points.
>
>“ A traffic policing function SHOULD”
>
>- and also before this para, this allows the reader to separatepolicing/shaping from other things.
>
>---
>
>Some RFC2119 statements need to be complete:
>
>“This SHOULD be adjusted based on anyknowledge of the local network environment that is available.”
>
>OLD:
>this
>
>NEW:
>
>the limit for NQB traffic
>
>END
>
>---
>
>“For the NQB PHB to succeed,”
>
>- The word succeed is odd.
>
>OLD:
>
>succeed
>
>NEW:
>
>to become widely deployed
>
>END
>
>---
>
>“This includes thecommon practice in residential broadband networks of re-marking”
>
>- Do we really need /common/. The sentence is true, irrespective of how
>
>common this is or was.
>
>OLD:
>
>common practice
>
>NEW:
>
>practice
>
>END
>
>---
>
>In 7.3.2, please could you add:
>
>NEW:
>
>[XXX RFC Editor please replace RFCXXXX with this RFC number whenpublished XXX]
>
>END.
>
>---
>
>10. Security Considerations
>
>- Please insert one sentence at the start explaining the securityconsiderations relate to the potential to impact the capacity available orlatency experienced by other flows that share a bottleneck on the path.
>
>---
>
>- Please replace this I-D: [I-D.cardwell-iccrg-bbr-congestion-control]with the WG adopted version in CCWG.
>
>---
>
>- The words “sink” and “source” are used just once, in other places thewords used are sender and receiver. Is this intentional? or could thesecases use sender and receiver?
>
>OLD:
>sink
>
>NEW:
>
>sender
>
>END
>
>OLD:
>
>source
>
>NEW:
>
>receiver
>
>END
>
>---
>
>
>
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.