Hi Bob and *Eliot,
Thanks for your replies and the updated XML file.
*Eliot - Based on your past message, we are assuming that you have seen and
approve the addition of text to the Terminology section and Section 5.4 that
were highlighted in Bob’s diff file and approve them as Stream Approver (if
not, please let us know).
We have removed the Copyright Material section in accordance with your replies
and made the so/therefore updates requested and updated based on some other
replies in email or the XML file.
As regards the use of monospace for the following, we would simply follow
author preference (monospaced is not required, but we would aim for consistency
throughout). So please let us know what (if anything) you’d like to do
anything to these or leave as is:
• MAX_PROB
• probNative
• AGING
• T_RES
• packet.uflow
• qprotect()
• fill_bucket()
• pick_bucket()
• ATTEMPTS
• pkt_sz
• calProbNative()
• CRITICALqL_us
• MAXTH_us
• CRITICALqL
• CRITICALqLSCORE
• NBUCKETS
Further note on the point above, please confirm use of AGING rate vs. aging
rate in text appears as desired.
We believe that the following remain as outstanding issues that we will await a
reply from Greg prior to updating:
-(r) in the title
-DOCSIS URL issue
-the “Two New Issues” from Bob’s initial email
-further updates related to the capping of Queue Protection and Congestion-rate
Note: related to "Regarding 'Congestion-rate', from the experience of other
RFCs, throughout I capitalized this as a term defined in the Terminology
section (similar to legal contracts). But I'm happy not to, given this one is
unambiguous whatever its case.” The RPC suggests not over-capitalizing nouns
(even those defined in the Terminology section). If it is the case that a term
is defined and the authors want it to have a special meaning when capped versus
not, we would suggest including text in the Terminology section that describes
that. Sounds like that is not the case here, so we’d recommend lowercasing.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9957.txt
https://www.rfc-editor.org/authors/rfc9957.pdf
https://www.rfc-editor.org/authors/rfc9957.html
https://www.rfc-editor.org/authors/rfc9957.xml
The diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9957-diff.html
https://www.rfc-editor.org/authors/rfc9957-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9957-auth48diff.html
https://www.rfc-editor.org/authors/rfc9957-auth48rfcdiff.html (side by side)
Please review carefully as we do not make updates once the document is
published as an RFC.
The AUTH48 status page is available here:
https://www.rfc-editor.org/auth48/rfc9957
The AUTH48 cluster information is available here:
https://www.rfc-editor.org/auth48/C350
Thank you.
Megan Feguson
RFC Production Center
> On Apr 9, 2026, at 3:18 AM, Independent Submissions Editor (Eliot Lear)
> <[email protected]> wrote:
>
>
> On 09.04.2026 11:08, Bob Briscoe wrote:
>> Eliot, see inline, in orange tagged [BB]
>>
>> On 09/04/2026 08:16, Independent Submissions Editor (Eliot Lear) wrote:
>>> Hi Bob,
>>> I've looked over your edits. Here are a few comments:
>>> • queue protection is not a proper name and should not be capitalized
>>> unless it's in some sort of heading that demands capitalization. Similar
>>> for "congestion-rate" and others. This also has implications for NQB.
>>> Adding a note of the sort you did indicates that you really don't want to
>>> rely on capitalization to mean anything special: it just makes the document
>>> harder for the reader to understand (yeah, I'm the reader in this case).
>> [BB] Surely Queue Protection **is** a proper name. It's the name of the
>> algorithm that is the subject of the draft.
>
> Ok, are we being consistent in using either QProt or Queue Protection. I
> like the former for the algorithm. Using case as a differentiator is NOT a
> good idea.
>
>> If in lowercase it would also be valid as 'the activity of protecting
>> queues' (as in the first line of the abstract). Nonetheless, I notice that
>> I've left some instances in lowercase which I should have uppercased. But I
>> won't change anything further until we agree. Indeed, this exchange makes me
>> think that we need to change all uppercased instances to QProt (except the
>> first as an expansion of the abbreviation).
>>
>> Regarding 'Congestion-rate', from the experience of other RFCs, throughout I
>> capitalized this as a term defined in the Terminology section (similar to
>> legal contracts). But I'm happy not to, given this one is unambiguous
>> whatever its case.
> It is up to you. I'm not going to stand on my head on any of these points.
>
>>
>> You say 'and others', but I think all the other terms that are capitalized
>> are used as initialisms, so they never appear in the text, except on first
>> use as a capitalized expansion.
>>
>>> • I think the document reads better when you stick to English phrasing,
>>> and so "Rational for" to me reads better.
>> [BB] Did you see my reasoning against the rfced's "option B" in the rfced
>> comments within the XML? Pasted here for your convenience:
>>>> <!--[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
>>>>
>>>> [BB] I prefer A - they're more brief.
>>>> B doesn't work, because or the two for's in 5.1.
>>>> C relies on reading through sequentially, which few people do these days.
>>>>
>>>> I've edited the XML accordingly
>>>> -->
>>
> I see what you are saying. Another possibility: just remove the term
> "Rational" in the subsections since it's in the heading.
>
>
>>> • I personally dislike sentences that begin with "So", as it is a bit
>>> too informal, even for our series. So could you take a second look at
>>> that? (Sorry I missed that the first time around).
>> [BB] I'm happy to change some instances to "Therefore", where logical
>> progression needs to be implied. But, in other instances, where the meaning
>> was closer to "Consequently", I'd rather leave it as "So", or sometimes
>> "Then". Would you agree to the following?:
>> Low queuing delay depends on hosts sending their data smoothly, ....
>> Therefore, low-latency queuing is something hosts create themselves, ...
>>
>> ...policy might need to be changed in the future. So, where hardware
>> implementation is being considered, it would be advisable to implement the
>> policy aspects in firmware or software...
>>
>> Then, the memory can be recycled for packets from other flows that arrive
>> in-between. Then, only queue-building flows hold flow state persistently.
> s/Then,/Thus/?
>>
>> In this way, the queuing score accumulates the size of each arriving packet
>> of a flow but scaled by the value of probNative (in the range 0 to 1) at the
>> instant the packet arrives. Therefore, a flow's score accumulates faster •
>> the higher the degree of queuing and • the faster the flow's packets arrive
>> when there is queuing.
>>
>> The algorithm stores the flow's own ID in its flow state. So, when a packet
>> of a flow arrives, the algorithm tries up to ATTEMPTS times to hash to a
>> bucket, looking for the flow's own ID.
>>
>> This would roughly double the ratio of qdelay to CRITICALqL, which is
>> compared against the CRITICALqLSCORE threshold. Therefore, the threshold
>> would have to be roughly doubled accordingly.
>>
>> However, whether or not some traffic is in a VPN, the queue delay threshold
>> (CRITICALqL) will be no more likely to be exceeded. Therefore, conditioning
>> ejection on actual harm helps reduce the chance that VPN traffic will be
>> ejected by the QProt function.
>>
>> During such an attack, the coupled marking probability will have saturated
>> at 100%. Therefore, to hold a bucket, the rate of an attack flow needs to be
>> no less than ...
>>
>> The required attack force scales linearly with the number of buckets,
>> NBUCKETS. Therefore, if NBUCKETS were doubled to 64, twice as many...
>>
> Yup.
>
>>> • For Figure 2, while I prefer brevity, in this case, consider "A More
>>> Complex Scenario".
>> [BB] OK.
>>
>>> • I don't understand why you moved and indented and premarked a
>>> paragraph " |".
>> [BB] Because the parenthetical paragraph (starting "Note that") broke the
>> logical flow between the para above and the para that I moved up (starting
>> "Figure 4 explains this approach graphically."). Also, the rfced's style
>> guide encourages us to consider using the <aside> element for parenthetical
>> stuff like this.
>>
>> Cheers
>>
>>
>> Bob
>>
>>
> thanks, Bob.
> Eliot
>>> Please consider these points.
>>> Thanks,
>>> Eliot
>>> On 09.04.2026 00:41, Bob Briscoe wrote:
>>>> 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 Briscoe http://bobbriscoe.net/
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe http://bobbriscoe.net/
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
