Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!--[rfced] May the "®" be removed from the title?
We note that previous RFCs with DOCSIS in the title do not use this.
Also, on this topic, the Chicago Manual of Style says that it is
not necessary in "publications that are not advertising or sales materials".
Original: The DOCSIS® Queue Protection Algorithm to Preserve Low Latency
Suggested: The DOCSIS Queue Protection Algorithm to Preserve Low Latency
-->
2) <!--[rfced] We note that the companion document RFC-to-be 9956
(draft-ietf-tsvwg-nab-33) cites more information for Reno
and Cubic. Should citations be added here as well for
the ease of the reader?
Original:
The Classic queue is only necessary for traffic such as traditional
(Reno/Cubic) TCP that needs about a round trip of buffering to fully
utilize the link, and therefore has no incentive to mismark itself as
low latency.
Perhaps:
The Classic queue is only necessary for traffic such as traditional
(Reno [RFC5681] / Cubic [RFC9438) TCP that needs about a round trip of
buffering to fully utilize the link; therefore, this traffic has no
incentive to mismark itself as low latency.
-->
3) <!--[rfced] FYI, "us" has been updated to "µs" in three instances
where it follows numerals in comments in the pseudocode. This is
in keeping with using µs for microseconds in RFC-to-be 9956.
Original:
4000us
1000us
525 us
Current:
4000 µs
1000 µs
525 µs
-->
4) <!--[rfced] Please review and rephrase the following sentence with
regard to the clause that begins "but in the floating..." as the
sentence does not seem to parse as is.
Original:
The actual DOCSIS
QProt algorithm is defined using integer arithmetic, but in the
floating point arithmetic used in this document, (0 <= probNative <= 1).
Perhaps:
The actual DOCSIS
QProt algorithm is defined using integer arithmetic, but in the
floating-point arithmetic used in this document,
the native marking probability is between 0 and 1 (inclusive),
i.e., 0 <= probNative <= 1.
-->
5) <!--[rfced] Section 5 is titled "Rationale". Then there is a
difference between the formatting of the title of Section 5.1
(Rationale:) and the other titles. Might we update as follows?
Original:
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Rationale: Blame for Queuing, not for Rate in Itself . . 18
5.2. Rationale for Constant Aging of the Queuing Score . . . . 20
5.3. Rationale for Transformed Queuing Score . . . . . . . . . 21
5.4. Rationale for Policy Conditions . . . . . . . . . . . . . 22
5.5. Rationale for Reclassification as the Policy Action . . . 25
Perhaps A (all colons):
5. Rationale
5.1. Rationale: Blame for Queuing, Not for Rate in Itself
5.2. Rationale: Constant Aging of the Queuing Score
5.3. Rationale: Transformed Queuing Score
5.4. Rationale: Policy Conditions
5.5. Rationale: Reclassification as the Policy Action
Perhaps B (all "for"):
5. Rationale
5.1. Rationale for Blame for Queuing, Not for Rate in Itself
5.2. Rationale for Constant Aging of the Queuing Score
5.3. Rationale for Transformed Queuing Score
5.4. Rationale for Policy Conditions
5.5. Rationale for Reclassification as the Policy Action
Perhaps C (just removing as they are all subsections of "Rationale"):
5. Rationale
5.1. Blame for Queuing, Not for Rate in Itself
5.2. Constant Aging of the Queuing Score
5.3. Transformed Queuing Score
5.4. Policy Conditions
5.5. Reclassification as the Policy Action
-->
6) <!-- [rfced] We had the following questions related to the
Implementation Status section:
a) Should this section be removed per the guidance in RFC 7942
(relevant parts copied below for your convenience)?
We recommend that the Implementation Status section should be removed
from Internet-Drafts before they are published as RFCs. As a result,
we do not envisage changes to this section after approval of the
document for publication, while the document sits in the RFC Editor
queue, e.g., the RFC errata process does not apply.
This process is not mandatory. Authors of Internet-Drafts are
encouraged to consider using the process for their documents, and
working groups are invited to think about applying the process to all
of their protocol specifications.
...
This process was initially proposed as an experiment in [RFC6982].
That document is now obsoleted, and the process advanced to Best
Current Practice.
...
Each Internet-Draft may contain a section entitled "Implementation
Status". This section, if it appears, should be located just before
the "Security Considerations" section ...
...
Since this information is necessarily time dependent, it is
inappropriate for inclusion in a published RFC. The authors should
include a note to the RFC Editor requesting that the section be
removed before publication.
...
Authors are requested to add a note to the RFC Editor at the top of
this section, advising the Editor to remove the entire section before
publication, as well as the reference to RFC 7942.
b) If not, should Table 1 have some sort of title?
c) FYI - In the meantime, we have updated per your guidance on the
document intake form as follows:
Old:" and one CMTS implementation by a third manufacturer."
Current: " and several CMTS implementations by other manufacturers.”
-->
7) <!-- [rfced] Please review the following and let us know if any
further updates are necessary:
The original URLs for [DOCSIS], [DOCSIS-CCAP-OSS], and [DOCSIS-CM-OSS]
resolved to a blank search results page. We found more-direct URLs for
these CableLabs specifications and updated the references accordingly.
Note that we also updated the date for [DOCSIS-CCAP-OSS] from "21
January 2019" to "7 February 2019" to match the information provided
at that URL.
-->
8) <!-- [rfced] FYI: We updated the [BBRv3] and [SCReAM] references to
match current style guidance for references to web-based public
code repositories:
https://www.rfc-editor.org/styleguide/part2/#ref_repo -->
9) <!--[rfced] We had the following questions related to terminology used
throughout the document:
a) Several sections use "the algorithm" in an opening statement while
other sections say "The QProt algorithm". Would it be easier for the
reader to call it "The QProt algorithm" in first mentions in a section
(and use "the algorithm" thereafter in the section)? Thinking of
readers that may not read the entire RFC, but instead jump to a
section from a reference link.
b) We have updated to use the form on the right throughout. Please
let us know any objections.
IPSec / IPsec (to match RFC 4303)
flow-ID / flow ID
c) How may we make the following terms consistent throughout?
Congestion-rate vs. congestion-rate
Coupled DualQ AQM vs. Dual Queue Coupled AQM (companion uses "IETF's
Coupled DualQ AQM")
Diffserv Codepoint vs. Diffserv codepoint (companion uses Diffserv
Code Point and Differentiated Services Code Point)
flow state vs. flow-state
Native vs. native vs. "Native"
per-flow-state vs. per-flow state
queue protection vs. Queue Protection
-->
10) <!--[rfced] We had the following questions related to abbreviations
used throughout the document:
a) FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
b) We see that the companion document (draft-ietf-tsvwg-nqb-33) uses
the following abbreviations:
NQB - Non-Queue-Building
QB - Queue-Building
We see that this document only uses NQB when mentioning the Diffserv
codepoint. Can NQB be introduced earlier in the document and be used
to refer to the general concept?
c) We see that [DOCSIS] uses "Queue Protection" rather than "queue
protection". We see both the capped and lowercase versions used in
this document. May we update to simply QProt (after first expansion)
when referring to the algorithm? And/Or are there places where
capping or lowercasing this term is necessary? If not, please let us
know how we may make this consistent.
Further, is it QProt algorithm or DOCSIS QProt algorithm?
d) FYI - We have updated the expansion of DOCSIS to use hyphenation
(i.e., Data-Over-Cable) to match the use in [DOCSIS] and the companion
document. Please let us know any objections.
e) How may we expand the following abbreviations?
CE
MAC
f) We will update to use the abbreviated forms of the following after
expansion on first use (per the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev):
LL
CM
g) We note that this document uses LL queue as an abbreviation for
low-latency queue. However, we see RFC 9332 uses "low-latency (L)
queue". Please review this discrepancy and let us know if any further
updates are necessary.
Further, please note that we have hyphenated low latency when it appears in
attributive position to match its use in RFC 9330-9332.
-->
11) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the following should be updated:
native
In addition, please consider whether uses of "tradition" should be updated for
clarity. While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->
Thank you.
Megan Ferguson and Alice Russo
RFC Production Center
On Apr 6, 2026,[email protected] wrote:
*****IMPORTANT*****
Updated 2026/04/06
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP –https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
*[email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
*[email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9957.xml
https://www.rfc-editor.org/authors/rfc9957.html
https://www.rfc-editor.org/authors/rfc9957.pdf
https://www.rfc-editor.org/authors/rfc9957.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9957-diff.html
https://www.rfc-editor.org/authors/rfc9957-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9957-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9957
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9957 (draft-briscoe-docsis-q-protection-07)
Title : The DOCSIS® Queue Protection Algorithm to Preserve Low
Latency
Author(s) : B. Briscoe, Ed., G. White
