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

[[e-mail]]

Hi Gorry,

as a co-author, I'm not aware of any IPR linked to this draft.

I'm content for my name to appear when this draft is published as an RFC.

Regards,

Ruediger


Von: Gorry Fairhurst <[e-mail]>
Gesendet: Montag, 4. November 2024 17:44
An: [e-mail]
Betreff: [tsvwg] TSVWG Shepherd question and comments concerning publication request for NQB

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 is consistent 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;><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 have declared all known IPR, according to the IPR rules for the IETF.



3. All authors: Please individually confirm that you are content for your 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 its replacement RFC3246, because the former contains the description of EF performance.]



5. Please remove Sebastian Moeller from the Acknowledgements section. I note "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 to see an additional early paragraph that alerts a reader who has no current plans to add NQB support but needs to know what the implications are for their network carrying NQB traffic. This seems like an opportunity to point to Section 4.2 and 4.4.1 very early in the introduction. 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 provides guidance 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. These changes 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 that are seeking prioritization in the Wi-Fi uplink 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 for NQB increasing the likelihood of DSCP 45 traffic traversing network boundaries without change to the DSCP, as that likelihood of increased network boundary traversal is balanced by a likelihood of NQB traffic encountering the traffic-limiting aspects of NQB support, traffic protection 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 be configured to meet the performance requirements of a variety of applications and traffic categories, or to achieve differentiated service offerings, it has not been used for these purposes across the Internet...."

- 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 shares with Default traffic."

- This isn't so much about bandwidth as capacity for a flow, although I see the two terms used interchangeably with preference varying. I'd prefer capacity here if that seems good to you.

OLD:
bandwidth

NEW:

capacity

END


---

"The NQB PHB is therefore intended for the prevalent situation where the performance requirements of applications cannot be assured across

the whole sender-to-receiver path, and as a result, applications cannot 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 bandwidth between the QB and NQB queues (Section 5)."

- Is this also capacity rather than bandwidth? (you may like to check other 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 network functions 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, please consider breaking into more than one sentence.

---

"Microflows that are marked with the NQB DSCP SHOULD align with the description 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 are RECOMMENDED 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 that are 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 that excess 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 to the 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 just say "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 of machinery, but I think that was not intended. I would suggest adding a sentence at the very start of the section that says something like

NEW:

The Differentiated Services model provides flexibility for operators to control the way they choose to aggregate traffic marked with a specific DSCP.

END.


---

"it is RECOMMENDED that the operator of the upstream domain implement the following safeguards before delivering traffic into a non-DS-capable domain."

- So reading in pedantic mode, this doesn't clearly identify WHAT is recommended.

... Placing the next two paras as numbered bullets would be a step to making it clear there are one of two recommended methods to provide 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 separate policing/shaping from other things.

---

Some RFC2119 statements need to be complete:

"This SHOULD be adjusted based on any knowledge 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 the common 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 when published XXX]

END.


---

10. Security Considerations

- Please insert one sentence at the start explaining the security considerations relate to the potential to impact the capacity available or latency 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 the words used are sender and receiver. Is this intentional? or could these cases use sender and receiver?

OLD:
sink

NEW:

sender

END

OLD:

source

NEW:

receiver

END


---