Megan & Alice as RFC Editors (and Greg as co-author),
Thank you for finding the errors I/we previously missed.
I've attached an XML file with all the new edits I now suggest, plus
responses to all the rfced questions within it. I've named it rfc9957b.
I've also attached HTML compiled from it and, for convenience, a
side-by-side diff relative to the draft you sent out, which I've
called rfc9957a.
Most edits have been made without explanation, presuming the
reasoning is self-explanatory.
Those edits that need an explanation follow, as well as some open
issues...
British/US English
I notice the British English spelling has been changed to US
English. We've been here before (many times). I thought the RFC
Editor allows British spelling.
So I've pushed back and reverted to British English. There are
only two words, but multiple instances of the former:
* behaviour
* judgement
Also Acknowledgements was overlooked (which is why I prefer to
revert to British, in case other potentially subtle differences
between British and US spelling or style have been missed).
I won't push back against serial commas though - I've lost that
argument before, over an earlier draft of this very document,
when Adrian Farrel was ISE (and he's of British background). I
won't push back against double quotes either. Both these
punctuation styles are used in some British style guides, so they
won't be inconsistent with British spelling.
Beyond ASCII pseudocode
I'm unsure about changing [us] to [μs] in comments in the
pseudocode. I believe the pseudocode is all still a close copy of
that in the DOCSIS specs. So, although it would be nice to break
out of the confines of ASCII, in this case I'll ask Greg to
confirm this is acceptable.
If we do break away from ASCII pseudocode, I've changed three
further cases of [μs] that were overlooked.
Also, in the text, there's an occurrence of '~=', which is an
ASCII representation of '≈'.
I have not changed this, but you might want to.
I suggest the two occurrences of '<=' are not changed to '≤',
given most programmers use and expect the former.
Open rfced comments
Except for the few cases below, I've not only proposed a solution
to each rfced question within the XML, but I've also acted on
each proposal by editing the XML accordingly:
* I haven't added the citations of Reno & Cubic that you have
suggested, but I've said I'm happy for you (the RFC Editor)
to do so.
* There is more to the '403 Forbidden' error - the one with the
URLs to DOCSIS specs that you mention in your recent email
o *@Greg* will need to look at my response to the relevant
rfced question within the XML.
* I haven't converted all occurrences of code inline in the
text to monospaced because I wasn't sure what the preferred
XML is, or whether it's necessary. I'm happy for you to to do
so. The terms I noticed (often multiple occurrences) include:
o MAX_PROB
o probNative
o AGING
o T_RES
o packet.uflow
o qprotect()
o fill_bucket()
o pick_bucket()
o ATTEMPTS
o pkt_sz
o calProbNative()
o CRITICALqL_us
o MAXTH_us
o CRITICALqL
o CRITICALqLSCORE
o NBUCKETS
Two New Issues
Mainly for *@Greg* to consider, but also the RFC Editor:
1. In § 4.2.4. "The calcProbNative() Function", I propose that we
should add the following attribution to the end of the first para:
To derive this queuing score, the QProt algorithm uses the
*same* linear ramp function, calcProbNative()*, as the Native
AQM of the Low-Latency queue in order *to normalize the
instantaneous queuing delay of the LL queue into a
probability in the range [0,1], which it assigns to
probNative. *This AQM stems from the Random Early Detection
AQM algorithm [RED93], except it depends on queue delay not
queue depth in order to be independent of link rate, and it
uses instantaneous not smoothed delay, relying instead on the
sender to smooth the congestion signals.*
Then add to informational references:
*[RED93] Floyd, S., and Jacobson, V., Random Early Detection
gateways for Congestion Avoidance, IEEE/ACM Transactions on
Networking, 1(4):397-413, August 1993.
https://ee.lbl.gov/floyd/red.html*
2. There's a sentence near the end of §5.5, which suggests that QProt
could clear the ECN field:
In these "persistent offender" cases, QProt might also
overwrite each redirected packet's DSCP*or clear its ECN
field to Not-ECT*, in order to protect other potential L4S
queues downstream.
The red text contravenes the normative requirement below from
RFC9331, so I suggest we consider deleting it.
RFC9331:
5.1. Classification and Re-Marking Behaviour
<https://www.rfc-editor.org/rfc/rfc9331.html#name-classification-and-re-marki>
Specifically, the ECT(1) codepoint MUST NOT be changed to any
codepoint other than CE, and CE MUST NOT be changed to any other
codepoint.
Below are further quotes from RFCs about not doing this:
RFC3168:
18.1.3. Disabling ECN-Capability
<https://datatracker.ietf.org/doc/html/rfc3168#section-18.1.3>
This change is to turn off the ECT codepoint of a packet. This
means that if the packet later encounters congestion (e.g., by
arriving to a RED queue with a moderate average queue size), it
will be dropped instead of being marked. By itself, this is no
worse (for the application) than if the tampering router had
actually dropped the packet. The saving grace in this particular
case is that there is no congested router upstream expecting a
reaction from setting the CE bit.
RFC9768-to-be (AccECN):
3.2.2.3. Testing for Mangling of the IP/ECN Field
<https://www.rfc-editor.org/authors/rfc9768.html#name-testing-for-mangling-of-the>
Invalid transitions of the IP-ECN field are defined in
section 18 of the Classic ECN specification [RFC3168
<https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-34.html#RFC3168>]
and repeated here for convenience:
* the not-ECT codepoint changes;
* either ECT codepoint transitions to not-ECT;
* the CE codepoint changes.
RFC 3168 says that a router that changes ECT to not-ECT is
invalid but safe. However, from a host's viewpoint, this
transition is unsafe because it could be the result of two
transitions at different routers on the path: ECT to CE
(safe) then CE to not-ECT (unsafe). This scenario could well
happen where an ECN-enabled home router congests its upstream
mobile broadband bottleneck link, then the ingress to the
mobile network clears the ECN field [Mandalari18
<https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-34.html#Mandalari18>].
Cheers
Bob
On 07/04/2026 06:46, [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
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
