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
• @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:
• MAX_PROB
• probNative
• AGING
• T_RES
• packet.uflow
• qprotect()
• fill_bucket()
• pick_bucket()
• ATTEMPTS
• pkt_sz
• calProbNative()
• CRITICALqL_us
• MAXTH_us
• CRITICALqL
• CRITICALqLSCORE
• 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
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
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
Invalid transitions of the IP-ECN field are defined in section 18 of the
Classic ECN specification [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].
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/
