Thanks, this version looks great to me. I approve of this draft posted today, 15th December, '25.
Best, Nandita On Mon, Dec 15, 2025 at 11:17 AM Gorry Fairhurst <[email protected]> wrote: > On 15/12/2025 19:07, Neal Cardwell wrote: > > Hi Alanna, > > Thanks! Looks good to me. I approve of this draft posted today, Dec 15. > > Thanks! > neal > > Me too, this looks good, thanks. > > I approve this draft posted today, Dec 15. > > Gorry > > On Mon, Dec 15, 2025 at 2:05 PM Alanna Paloma <[email protected]> > <[email protected]> > wrote: > > > Hi Gorry and Neal, > > Thank you for your replies. We have updated the files accordingly. > > > 2. Section 4, CURRENT: > However, note that using PRR for cwnd reductions > for the [RFC3168] variant of ECN has been observed, with some > approaches to Active Queue Management (AQM), to cause an excess cwnd > reduction during ECN-triggered congestion episodes, as noted in > [VCC]. > NEW: > However, there can be interactions between using PRR and > approaches to Active Queue Management (AQM) and ECN; guidance on the > development and assessment of congestion control > mechanisms is provided in [RFC9743]. > > - RFC-Ed: Pleaase remove the reference to [VCC] from the references > > section. > > ) FYI, we have added [RFC9743] as an Informative Reference. Please let us > know if it should be a Normative Reference instead. > > > The files have been posted here (please > refresh):https://www.rfc-editor.org/authors/rfc9937.txthttps://www.rfc-editor.org/authors/rfc9937.pdfhttps://www.rfc-editor.org/authors/rfc9937.htmlhttps://www.rfc-editor.org/authors/rfc9937.xml > > The relevant diff files are posted > here:https://www.rfc-editor.org/authors/rfc9937-diff.html (comprehensive > diff)https://www.rfc-editor.org/authors/rfc9937-auth48diff.html (all AUTH48 > changes)https://www.rfc-editor.org/authors/rfc9937-lastdiff.html (last > version to > this one)https://www.rfc-editor.org/authors/rfc9937-lastrfcdiff.html (rfcdiff > between last version and this) > > Please see the AUTH48 status page for this document > here:https://www.rfc-editor.org/auth48/rfc9937 > > We will await approval from Nandita prior to moving this document forward > in the publication process. > > Best regards, > Alanna Paloma > RFC Production Center > > > On Dec 15, 2025, at 9:50 AM, Gorry Fairhurst <[email protected]> > <[email protected]> > > wrote: > > RFC-Ed, as per my previous email, here is the consolidated change list, > > please go-ahead and apply these changes: > > 1. Section 4, CURRENT: > such as for Explicit Congestion Notification (ECN) as > described in [RFC3168]. > NEW: > such as for Explicit Congestion Notification (ECN) as > specified in [RFC3168]. > > 2. Section 4, CURRENT: > However, note that using PRR for cwnd reductions > for the [RFC3168] variant of ECN has been observed, with some > approaches to Active Queue Management (AQM), to cause an excess cwnd > reduction during ECN-triggered congestion episodes, as noted in > [VCC]. > NEW: > However, there can be interactions between using PRR and > approaches to Active Queue Management (AQM) and ECN; guidance on the > development and assessment of congestion control > mechanisms is provided in [RFC9743]. > > - RFC-Ed: Pleaase remove the reference to [VCC] from the references > > section. > > 3. Section 11.2, CURRENT: > PRR only operates > during a congestion control response episode, such as fast recovery > or response to the [RFC3168] variant of ECN, > NEW: > PRR only operates > during a congestion control response episode, such as fast recovery > or when there is a step reduction in the cwnd from the TCP ECN > reaction defined in [RFC3168]. > -END- > Gorry > (WIT AD) > > > On Dec 11, 2025, at 9:09 AM, Yuchung Cheng <[email protected]> > <[email protected]> > > wrote: > > Looks good to me. I approve the latest draft. > > On Wed, Dec 10, 2025 at 7:59 PM Neal Cardwell <[email protected]> > <[email protected]> > > wrote: > > Hi Alanna, > > Thanks! Looks great to me. > > I approve of this draft posted today, December 10. > > Everybody else, please review and chime in. > > Thanks! > neal > > > On Wed, Dec 10, 2025 at 8:01 PM Alanna Paloma < > > [email protected]> wrote: > > Hi Neal, > > The files have been updated per your request. > > The files have been posted here (please > refresh):https://www.rfc-editor.org/authors/rfc9937.txthttps://www.rfc-editor.org/authors/rfc9937.pdfhttps://www.rfc-editor.org/authors/rfc9937.htmlhttps://www.rfc-editor.org/authors/rfc9937.xml > > The relevant diff files are posted > here:https://www.rfc-editor.org/authors/rfc9937-diff.html (comprehensive > > diff) > > https://www.rfc-editor.org/authors/rfc9937-auth48diff.html (all > > AUTH48 changes) > > https://www.rfc-editor.org/authors/rfc9937-lastdiff.html (last > > version to this one) > > https://www.rfc-editor.org/authors/rfc9937-lastrfcdiff.html > > (rfcdiff between last version and this) > > Please see the AUTH48 status page for this document > here:https://www.rfc-editor.org/auth48/rfc9937 > > We will await approvals from each party listed on the AUTH48 status > > page below prior to moving this document forward in the publication process. > > Thank you, > Alanna Paloma > RFC Production Center > > > > > On Dec 10, 2025, at 3:59 PM, Neal Cardwell <[email protected]> > <[email protected]> > > wrote: > > Hi Alanna, > > I had 4 minor editing requests based on the December 3 version of > > the text: > > --- in "4. Changes Relative to RFC 6937": > > rfc6937bis-21: > using PRR for cwnd reductions for [RFC3168] ECN > > OLD: > using PRR for cwnd reductions for ECN [RFC3168] > > NEW: > using PRR for cwnd reductions for the [RFC3168] variant of ECN > > Rationale: IMHO the auth48 edit to use the phrase "ECN [RFC3168]" > > implies that there is only one version of ECN. However, there are at least > 3: classic [RFC3168], DCTCP [RFC8257], and L4S [RFC9331]. Here [RFC3168] > is intended as an adjective clarifying which flavor of ECN we are > discussing, not to indicate that ECN is only defined in [RFC3168]. > > I'd suggest using the "the [RFC3168] variant of ECN" phrase that is > > currently in Section "11.2. Fairness". > > ---- in 6.2. Per-ACK Steps > > rfc6937bis-21: > Finally, the sender uses DeliveredData, inflight, SafeACK, and > > other > > PRR state to compute > SndCnt, a local variable indicating exactly how > many bytes should be sent in response to each ACK, > and then uses SndCnt to update cwnd > > OLD: > Finally, the sender uses DeliveredData, inflight, SafeACK, and > > other > > PRR state to compute > SndCnt, a local variable indicating exactly how > many bytes should be sent in response to each ACK > and then uses SndCnt to update cwnd > > NEW: > Finally, the sender uses DeliveredData, inflight, SafeACK, and > > other > > PRR state to compute > SndCnt, a local variable indicating exactly how > many bytes should be sent in response to each ACK, > and then uses SndCnt to update cwnd > > Rationale: the phrase "a local variable indicating exactly how many > > bytes should be sent in response to each ACK" is a parenthetic or > non-restrictive clause, so AFAIK should be enclosed with commas before and > after. (Strunk & White Elements of Style rule: "Enclose parenthetic > expressions between commas".) > > --- in 8. Examples > > rfc6937bis-21: > This section illustrates the PRR and [RFC6675] algorithms > > OLD: > This section illustrates the PRR and [RFC6675] algorithm > > NEW: > This section illustrates the PRR and [RFC6675] algorithms > > Rationale: > PRR and [RFC6675] are two different algorithms. > > --- in 14.2. Informative References > > rfc6937bis-21: > [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment: > Refining TCP Congestion Control", ACM SIGCOMM > SIGCOMM1996, August 1996, > > OLD: > [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment: > Refining TCP Congestion Control", ACM SIGCOMM > > Computer > > Communication Review, vol. 26, no. 4, pp. 281-291, > > NEW: > [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment: > Refining TCP Congestion Control", SIGCOMM '96: > > Conference > > Proceedings on Applications, Technologies, > > Architectures, > > and Protocols for Computer Communications, pp. > > 281-291, > > Rationale: IMHO it's very useful/important to indicate that a paper > > is a SIGCOMM paper, so we should not drop the fact that the FACK paper was > in SIGCOMM '96 (the list of SIGCOMM '96 papers is > here:https://dl.acm.org/doi/proceedings/10.1145/248156 ). I'm suggesting the > "NEW" text for indicating the paper was in SIGCOMM '96 based on the fact > that [Hoe96Startup] was also in SIGCOMM '96; so I've just borrowed the > SIGCOMM '96 citation text from [Hoe96Startup], which looks like: > > [Hoe96Startup] > Hoe, J., "Improving the Start-up Behavior of a Congestion > Control Scheme for TCP", SIGCOMM '96: Conference > Proceedings on Applications, Technologies, Architectures, > and Protocols for Computer Communications, pp. 270-280, > DOI 10.1145/248157.248180, August > 1996,<https://doi.org/10.1145/248157.248180> > <https://doi.org/10.1145/248157.248180>. > (The confusion arises because SIGCOMM papers can be cited in two > > ways: (1) as in the SIGCOMM 'XY conference proceedings, or (2) as an issue > of ACM SIGCOMM Computer Communication Review.) > > Thanks! > > neal > > > On Wed, Dec 10, 2025 at 5:14 PM Alanna Paloma < > > [email protected]> wrote: > > Hi Matt, > > Thank you for your approval. It’s been noted on the AUTH48 status > > page: > > https://www.rfc-editor.org/auth48/rfc9937 > > We will await approvals from Neal, Yuchung, and Nandita prior to > > moving this document forward in the publication process. > > Best regards, > Alanna Paloma > RFC Production Center > > > On Dec 10, 2025, at 7:54 AM, Matt Mathis <[email protected]> > <[email protected]> > > wrote: > > I approve of the draft posed Dec 3rd. > > Everybody else, please review and chime in. > > Thanks, > --MM-- > Evil is defined by mortals who think they know "The Truth" and use > > force to apply it to others. > > ------------------------------------------- > Matt Mathis (Email is best) > Home & mobile: 412-654-7529 <(412)%20654-7529> <(412)%20654-7529> please > leave a > > message if you must call. > > On Wed, Dec 3, 2025 at 12:26 PM Alanna Paloma < > > [email protected]> wrote: > > Hi Neal and Gorry, > > Thank you for your replies. Gorry’s approval has been noted on the > > AUTH48 status page: > > https://www.rfc-editor.org/auth48/rfc9937 > > One preliminary meta-note about process: > > > https://www.rfc-editor.org/authors/rfc9937-auth48diff.html > > (all AUTH48 changes) > > FWIW, AFAICT this version does not include all auth48 changes. > > One change I noticed that it does not include is the following: > > rfc6937bis-21: > using [RFC6675] loss detection > MAY use the "pipe" algorithm as specified in [RFC6675] > > latest auth48 version: > using loss detection [RFC6675] > MAY use the "pipe" algorithm as specified in [RFC6675] > > ) To clarify, the -auth48diff file only highlights changes after a > > document has moved into AUTH48 state. The change you noted was not > highlighted in the -auth48diff file (it's now highlighted as we have > reverted our initial edit per your request) because it was made by editors > prior to the document entering AUTH48 state. > > To see all edits made, including those made before and during > > AUTH48 state, see this file: > > https://www.rfc-editor.org/authors/rfc9937-diff.html > > (comprehensive diff) > > We have updated the files per your request. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9937.txt > https://www.rfc-editor.org/authors/rfc9937.pdf > https://www.rfc-editor.org/authors/rfc9937.html > https://www.rfc-editor.org/authors/rfc9937.xml > > The relevant diff files are posted here: > https://www.rfc-editor.org/authors/rfc9937-diff.html > > (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9937-auth48diff.html (all > > AUTH48 changes) > > https://www.rfc-editor.org/authors/rfc9937-lastdiff.html (last > > version to this one) > > https://www.rfc-editor.org/authors/rfc9937-lastrfcdiff.html > > (rfcdiff between last version and this) > > We will await any further changes you may have and approvals from > > each author prior to moving forward in the publication process. > > Please see the AUTH48 status page for this document > here:https://www.rfc-editor.org/auth48/rfc9937 > > Thank you, > Alanna Paloma > RFC Production Center > > > > On Dec 3, 2025, at 6:29 AM, Neal Cardwell <[email protected]> > <[email protected]> > > wrote: > > Hi editors and co-authors, > > I had time to review the auth48 edits this morning, and have some > > proposed edits. > > One preliminary meta-note about process: > > > https://www.rfc-editor.org/authors/rfc9937-auth48diff.html > > (all AUTH48 changes) > > FWIW, AFAICT this version does not include all auth48 changes. > > One change I noticed that it does not include is the following: > > rfc6937bis-21: > using [RFC6675] loss detection > MAY use the "pipe" algorithm as specified in [RFC6675] > > latest auth48 version: > using loss detection [RFC6675] > MAY use the "pipe" algorithm as specified in [RFC6675] > > Here are a few edits I'd like to request, tweaking the edits made > > during the auth48 process: > > --- > > rfc6937bis-21: > using [RFC6675] loss detection > MAY use the "pipe" algorithm as specified in [RFC6675] > > OLD: > using loss detection [RFC6675] > MAY use the "pipe" algorithm as specified in [RFC6675] > > NEW: > using [RFC6675] loss detection > MAY use the "pipe" algorithm as specified in [RFC6675] > > Rationale: IMHO the auth48 edit to employ the phrase "using loss > > detection [RFC6675]" implies that loss detection necessarily means > [RFC6675], or is only defined in [RFC6675]. However, there are multiple > widely-deployed loss recovery algorithms (notably [RFC6675] and [RFC8985]), > and this paragraph we are specifically discussing how to adapt PRR's use > of the "inflight" quantity to both of those algorithms, and in this > sentence we are discussing how to adapt PRR's use of the "inflight" > quantity to [RFC6675] loss detection, so it's important not to imply that > loss detection is only defined in [RFC6675]. > > --- > > rfc6937bis-21: > Finally, the sender uses DeliveredData, inflight, SafeACK, and > > other > > PRR state to compute SndCnt > > OLD: > Finally, the sender uses DeliveredData, inflight, SafeACK, and > > other > > PRR states to compute SndCnt > > NEW: > Finally, the sender uses DeliveredData, inflight, SafeACK, and > > other > > PRR state to compute SndCnt > > Rationale: IMHO the auth48 edit to use "states" implies that > > DeliveredData, inflight, SafeACK are names of "states" in a state machine > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
