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

[Gorry Fairhurst <[e-mail]>]

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.

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. 
Inote “he doesn’t wish to contribute to the work”.


---

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

---