Hi Alanna, Thanks! Looks good to me. I approve of this draft posted today, Dec 15.
Thanks! neal On Mon, Dec 15, 2025 at 2:05 PM Alanna Paloma <[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.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) > > 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]> > 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]> > wrote: > >> >> > >> >> Looks good to me. I approve the latest draft. > >> >> > >> >> On Wed, Dec 10, 2025 at 7:59 PM Neal Cardwell <[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.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) > >> >> > >> >> 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]> > 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>. > >> >>> (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]> > 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> 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]> > 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. > However, those are the names of "state" variables representing the "state" > of the algorithm, not the names of "states" in a state machine. > >> >>>>> > >> >>>>> --- > >> >>>>> > >> >>>>> rfc6937bis-21: > >> >>>>> Earlier measurements (in section 6 of [RFC6675]) indicate that > >> >>>>> [RFC6675] significantly outperforms [RFC6937] PRR > >> >>>>> using only PRR-CRB > >> >>>>> > >> >>>>> OLD: > >> >>>>> Earlier measurements (in Section 6 of [RFC6675]) indicate that > >> >>>>> [RFC6675] significantly outperforms PRR [RFC6937] > >> >>>>> using only PRR-CRB > >> >>>>> > >> >>>>> NEW: > >> >>>>> Earlier measurements (in Section 6 of [RFC6675]) indicate that > >> >>>>> [RFC6675] significantly outperforms the [RFC6937] version of > PRR > >> >>>>> using only PRR-CRB > >> >>>>> > >> >>>>> Rationale: IMHO the auth48 edit to use the phrase "outperforms > PRR [RFC6937]" (a) implies that PRR is only described by [RFC6937], and (b) > states that "[RFC6675] significantly outperforms PRR". Both implications > are incorrect. For (a), there are two versions of PRR: one in the old > [RFC6937] and one in the new [RFC9937], and we used the phrase "[RFC6937] > PRR" to clarify which version we are talking about. For (b), the new > version of PRR outperforms [RFC6675], which is why we are bothering to > standardize it. :-) Note that in this passage, we are discussing > differences between the [RFC6937] version of PRR and the new [RFC9937] > version of PRR. So in this context it is important to clarify that PRR is > *not* synonymous with [RFC6937]; there are two different versions of PRR: > original [RFC6937] and new [RFC9937]. [RFC6675] outperforms one variant of > the original [RFC6937] PRR, but not the new version of PRR in [RFC9937]. > To my mind, the suggested NEW text clarifies that this passage is referring > to the [RFC6937] PRR variant. > >> >>>>> > >> >>>>> --- > >> >>>>> rfc6937bis-21: > >> >>>>> response to [RFC3168] ECN > >> >>>>> > >> >>>>> OLD: > >> >>>>> response to ECN [RFC3168] > >> >>>>> > >> >>>>> NEW: > >> >>>>> response to 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]. > >> >>>>> > >> >>>>> --- > >> >>>>> > >> >>>>> Thanks! > >> >>>>> > >> >>>>> neal > >> >>>>> > >> >>>>> > >> >>>>> On Wed, Dec 3, 2025 at 3:47 AM Gorry Fairhurst < > [email protected]> wrote: > >> >>>>> On 01/12/2025 23:08, Alanna Paloma wrote: > >> >>>>>> Hi Authors and Gorry (AD)*, > >> >>>>>> > >> >>>>>> *Gorry - As the AD, please review and approve the deleted text > in Section 7. > >> >>>>> I have now read this and this is descriptive text about the > properties. > >> >>>>> > >> >>>>> I APPROVE this change, > >> >>>>> > >> >>>>> Thanks, > >> >>>>> > >> >>>>> Gorry > >> >>>>> > >> >>>>>> For context, here is the authors’ explanation: > >> >>>>>>> 6) <!-- [rfced] May we clarify "[RFC6675] 'half window of > silence'" as > >> >>>>>>> follows? > >> >>>>>>> > >> >>>>>>> Original: > >> >>>>>>> The [RFC6675] "half window of silence" may temporarily > >> >>>>>>> reduce queue pressure when congestion control does not > reduce the > >> >>>>>>> congestion window entering recovery to avoid further > losses. > >> >>>>>>> > >> >>>>>>> Perhaps: > >> >>>>>>> The "half window of silence" that a SACK-based > Conservative Loss > >> >>>>>>> Recovery Algorithm [RFC6675] experiences may temporarily > >> >>>>>>> reduce queue pressure when congestion control does not > reduce the > >> >>>>>>> congestion window entering recovery to avoid further > losses. > >> >>>>>>> --> > >> >>>>>>> We want to delete the last three sentences of this paragraph. > They got garbled and don't belong here anyhow. This restores the text as > it was RFC 6937. > >> >>>>>>> OLD: > >> >>>>>>> The [RFC6675] "half window of silence" may temporarily > reduce queue pressure when congestion control does not reduce the > congestion window entering recovery to avoid further losses. The goal of > PRR is to minimize the opportunities to lose the self clock by smoothly > controlling inflight toward the target set by the congestion control. It is > the congestion control's responsibility to avoid a full queue, not PRR. > >> >>>>>>> NEW: > >> >>>>>>> (DELETED) > >> >>>>>> See this diff file: > >> >>>>>> https://www.rfc-editor.org/authors/rfc9937-auth48diff.html > >> >>>>>> > >> >>>>>> > >> >>>>>> Authors - Thank you for your replies. We have updated as > requested. > >> >>>>>> > >> >>>>>>> We could use some advice on keywords. Can you tell us the > keywords associated with RFC 5681 and RFC 6675? > >> >>>>>> ) The keywords for RFCs 5681 and 6675 can be seen here: > >> >>>>>> > https://www.rfc-editor.org/search/rfc_search_detail.php?rfc=5681&keywords=keyson > >> >>>>>> > https://www.rfc-editor.org/search/rfc_search_detail.php?rfc=6675&keywords=keyson > >> >>>>>> > >> >>>>>>> 3) <!--[rfced] To have the abbreviation directly match the > expanded form, > >> >>>>>>> may we update this text as follows? > >> >>>>>>> > >> >>>>>>> Original: > >> >>>>>>> As a baseline, to be cautious when there may be > >> >>>>>>> considerable congestion, PRR uses its Conservative > Reduction Bound > >> >>>>>>> (PRR-CRB), which is strictly packet conserving. When > recovery seems > >> >>>>>>> to be progressing well, PRR uses its Slow Start Reduction > Bound (PRR- > >> >>>>>>> SSRB), which is more aggressive than PRR-CRB by at most > one segment > >> >>>>>>> per ACK. > >> >>>>>>> > >> >>>>>>> Perhaps: > >> >>>>>>> As a baseline, to be cautious when there may be > >> >>>>>>> considerable congestion, PRR uses its Conservative > Reduction Bound > >> >>>>>>> (CRB), which is strictly packet conserving. When recovery > seems > >> >>>>>>> to be progressing well, PRR uses its Slow Start Reduction > Bound (SSRB), > >> >>>>>>> which is more aggressive than PRR-CRB by at most one > segment > >> >>>>>>> per ACK. > >> >>>>>>> --> > >> >>>>>>> > >> >>>>>>> Yes this is good, for this paragraph only. I'm confirming that > the rest of the document will continue to use PRR-SSRB and PRR-CRB. > Correct? > >> >>>>>> ) Yes, all other instances of “PRR-SSRB” and “PRR-CRB” will > remain as is. > >> >>>>>> > >> >>>>>> --- > >> >>>>>> 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) > >> >>>>>> > >> >>>>>> Please review the document carefully as documents do not change > once published as RFCs. > >> >>>>>> > >> >>>>>> We will await any further changes you may have and approvals > from each author and *Gorry (AD) 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 1, 2025, at 11:51 AM, Matt Mathis <[email protected]> > wrote: > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Sorry, I missed reply-all. > >> >>>>>>> > >> >>>>>>> Our adjustments to you edits are inline below. > >> >>>>>>> > >> >>>>>>> On Fri, Nov 21, 2025 at 3:50 PM <[email protected]> > wrote: > >> >>>>>>> Authors, > >> >>>>>>> > >> >>>>>>> While reviewing this document during AUTH48, please resolve (as > necessary) > >> >>>>>>> the following questions, which are also in the source file. > >> >>>>>>> > >> >>>>>>> Add PRR as an official abbreviation in the title > >> >>>>>>> OLD: > >> >>>>>>> <title abbrev="Proportional Rate Reduction"> Proportional Rate > Reduction</title> > >> >>>>>>> NEW: > >> >>>>>>> <title abbrev="PRR"> Proportional Rate Reduction (PRR)</title> > >> >>>>>>> Update my email address > >> >>>>>>> OLD: > >> >>>>>>> <email>[email protected]</email> > >> >>>>>>> NEW: > >> >>>>>>> <email>[email protected]</email> > >> >>>>>>> > >> >>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that > appear in > >> >>>>>>> the title) for use on https://www.rfc-editor.org/search. --> > >> >>>>>>> > >> >>>>>>> We could use some advice on keywords. Can you tell us the > keywords associated with RFC 5681 and RFC 6675? > >> >>>>>>> Tentatively: > >> >>>>>>> OLD: > >> >>>>>>> <keyword>example</keyword> > >> >>>>>>> NEW: > >> >>>>>>> <keyword>loss recovery, SACK, self clock, fast retransmit, fast > recovery</keyword> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 2) <!-- [rfced] "Reno" is not used in RFC 5681, except in > titles in the > >> >>>>>>> References section. Please review and let us know if/how this > citation > >> >>>>>>> should be updated. Note that there are multiple occurrences of > this > >> >>>>>>> throughout the document. > >> >>>>>>> > >> >>>>>>> Original: > >> >>>>>>> Congestion control algorithms like Reno [RFC5681] and > CUBIC [RFC9438] > >> >>>>>>> are built on the conceptual foundation of this self clock > process. > >> >>>>>>> --> > >> >>>>>>> No changes to the citation for Reno [RFC 5681] here or > elsewhere. Many other documents that use this citation. > >> >>>>>>> > >> >>>>>>> Reno was the genesis of modern Internet congestion control, and > as such it is the foundation of RFC 5681 and nearly all work in ICCRG, > CCWG, and much of TCPM. However, Reno was never properly described in any > documents, as a proposed standard or otherwise. If it had been, RFC 5681 > (and all of its predecessors) would almost certainly be described as > updating Reno. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 3) <!--[rfced] To have the abbreviation directly match the > expanded form, > >> >>>>>>> may we update this text as follows? > >> >>>>>>> > >> >>>>>>> Original: > >> >>>>>>> As a baseline, to be cautious when there may be > >> >>>>>>> considerable congestion, PRR uses its Conservative > Reduction Bound > >> >>>>>>> (PRR-CRB), which is strictly packet conserving. When > recovery seems > >> >>>>>>> to be progressing well, PRR uses its Slow Start Reduction > Bound (PRR- > >> >>>>>>> SSRB), which is more aggressive than PRR-CRB by at most > one segment > >> >>>>>>> per ACK. > >> >>>>>>> > >> >>>>>>> Perhaps: > >> >>>>>>> As a baseline, to be cautious when there may be > >> >>>>>>> considerable congestion, PRR uses its Conservative > Reduction Bound > >> >>>>>>> (CRB), which is strictly packet conserving. When recovery > seems > >> >>>>>>> to be progressing well, PRR uses its Slow Start Reduction > Bound (SSRB), > >> >>>>>>> which is more aggressive than PRR-CRB by at most one > segment > >> >>>>>>> per ACK. > >> >>>>>>> --> > >> >>>>>>> > >> >>>>>>> Yes this is good, for this paragraph only. I'm confirming that > the rest of the document will continue to use PRR-SSRB and PRR-CRB. > Correct? > >> >>>>>>> (Changes as above) > >> >>>>>>> OLD: > >> >>>>>>> As a baseline, to be cautious when there may be > >> >>>>>>> considerable congestion, PRR uses its Conservative > Reduction Bound > >> >>>>>>> (PRR-CRB), which is strictly packet conserving. When > recovery seems > >> >>>>>>> to be progressing well, PRR uses its Slow Start Reduction > Bound (PRR- > >> >>>>>>> SSRB), which is more aggressive than PRR-CRB by at most > one segment > >> >>>>>>> per ACK. > >> >>>>>>> > >> >>>>>>> NEW: > >> >>>>>>> As a baseline, to be cautious when there may be > >> >>>>>>> considerable congestion, PRR uses its Conservative > Reduction Bound > >> >>>>>>> (CRB), which is strictly packet conserving. When recovery > seems > >> >>>>>>> to be progressing well, PRR uses its Slow Start Reduction > Bound (SSRB), > >> >>>>>>> which is more aggressive than PRR-CRB by at most one > segment > >> >>>>>>> per ACK. > >> >>>>>>> 4) <!--[rfced] To avoid awkward hyphenation of an RFC citation, > may we > >> >>>>>>> rephrase the latter part of this sentence as follows? > >> >>>>>>> > >> >>>>>>> Original: > >> >>>>>>> Since [RFC6937] was written, PRR has also been adapted to > perform > >> >>>>>>> multiplicative window reduction for non-loss based > congestion control > >> >>>>>>> algorithms, such as for [RFC3168] style Explicit Congestion > >> >>>>>>> Notification (ECN). > >> >>>>>>> > >> >>>>>>> Perhaps: > >> >>>>>>> Since [RFC6937] was written, PRR has also been adapted to > perform > >> >>>>>>> multiplicative window reduction for non-loss-based > congestion control > >> >>>>>>> algorithms, such as for Explicit Congestion Notification > (ECN) as > >> >>>>>>> described in [RFC3168]. > >> >>>>>>> --> > >> >>>>>>> Yes this is good. As above. > >> >>>>>>> OLD: > >> >>>>>>> Since [RFC6937] was written, PRR has also been adapted to > perform > >> >>>>>>> multiplicative window reduction for non-loss based > congestion control > >> >>>>>>> algorithms, such as for [RFC3168] style Explicit Congestion > >> >>>>>>> Notification (ECN). > >> >>>>>>> > >> >>>>>>> NEW: > >> >>>>>>> Since [RFC6937] was written, PRR has also been adapted to > perform > >> >>>>>>> multiplicative window reduction for non-loss-based > congestion control > >> >>>>>>> algorithms, such as for Explicit Congestion Notification > (ECN) as > >> >>>>>>> described in [RFC3168]. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 5) <!--[rfced] To improve readability, may we add parentheses > in this > >> >>>>>>> sentence? Please review and let us know if thus suggested update > >> >>>>>>> retains the intended meaning. > >> >>>>>>> > >> >>>>>>> Original: > >> >>>>>>> In recovery without SACK, DeliveredData is estimated to be > >> >>>>>>> 1 SMSS on receiving a duplicate ACK, and on a subsequent > partial or > >> >>>>>>> full ACK DeliveredData is the change in SND.UNA, minus 1 > SMSS for > >> >>>>>>> each preceding duplicate ACK. > >> >>>>>>> > >> >>>>>>> NO we want a different change Perhaps: > >> >>>>>>> In recovery without SACK, DeliveredData is estimated to be > >> >>>>>>> 1 SMSS on receiving a duplicate ACK (and the change is in > SND.UNA on > >> >>>>>>> a subsequent partial or full ACK DeliveredData), minus 1 > SMSS for > >> >>>>>>> each preceding duplicate ACK. > >> >>>>>>> --> > >> >>>>>>> OLD: > >> >>>>>>> In recovery without SACK, DeliveredData is estimated to be > >> >>>>>>> 1 SMSS on receiving a duplicate ACK, and on a subsequent > partial or > >> >>>>>>> full ACK DeliveredData is the change in SND.UNA, minus 1 > SMSS for > >> >>>>>>> each preceding duplicate ACK. > >> >>>>>>> NEW: > >> >>>>>>> In recovery without SACK, DeliveredData is estimated to be > >> >>>>>>> 1 SMSS on each received duplicate ACK (i.e. SND.UNA did > not change). > >> >>>>>>> When SND.UNA advances (i.e a full or partial ACK) > >> >>>>>>> DeliveredData is the change in SND.UNA, minus 1 SMSS for > >> >>>>>>> each preceding duplicate ACKs. > >> >>>>>>> New edit, XML line 331, second paragraph of section 6.2. (This > is a revision of an rfc-editor change.) > >> >>>>>>> OLD: > >> >>>>>>> (signed) change in SACK. > >> >>>>>>> NEW: > >> >>>>>>> signed change in quantity of data marked SACKed in the > scoreboard. > >> >>>>>>> > >> >>>>>>> 6) <!-- [rfced] May we clarify "[RFC6675] 'half window of > silence'" as > >> >>>>>>> follows? > >> >>>>>>> > >> >>>>>>> Original: > >> >>>>>>> The [RFC6675] "half window of silence" may temporarily > >> >>>>>>> reduce queue pressure when congestion control does not > reduce the > >> >>>>>>> congestion window entering recovery to avoid further > losses. > >> >>>>>>> > >> >>>>>>> Perhaps: > >> >>>>>>> The "half window of silence" that a SACK-based > Conservative Loss > >> >>>>>>> Recovery Algorithm [RFC6675] experiences may temporarily > >> >>>>>>> reduce queue pressure when congestion control does not > reduce the > >> >>>>>>> congestion window entering recovery to avoid further > losses. > >> >>>>>>> --> > >> >>>>>>> We want to delete the last three sentences of this paragraph. > They got garbled and don't belong here anyhow. This restores the text as > it was RFC 6937. > >> >>>>>>> OLD: > >> >>>>>>> The [RFC6675] "half window of silence" may temporarily > reduce queue pressure when congestion control does not reduce the > congestion window entering recovery to avoid further losses. The goal of > PRR is to minimize the opportunities to lose the self clock by smoothly > controlling inflight toward the target set by the congestion control. It is > the congestion control's responsibility to avoid a full queue, not PRR. > >> >>>>>>> NEW: > >> >>>>>>> (DELETED) > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 7) <!--[rfced] FYI - We found free access versions of these > references in > >> >>>>>>> the ACM Digital Library and added DOIs and URLs to these > references. > >> >>>>>>> > >> >>>>>>> Current: > >> >>>>>>> [Flach2016policing] > >> >>>>>>> Flach, T., Papageorge, P., Terzis, A., Pedrosa, > L., Cheng, > >> >>>>>>> Y., Karim, T., Katz-Bassett, E., and R. > Govindan, "An > >> >>>>>>> Internet-Wide Analysis of Traffic Policing", > SIGCOMM '16: > >> >>>>>>> Proceedings of the 2016 ACM SIGCOMM Conference, > pp. > >> >>>>>>> 468-482, DOI 10.1145/2934872.2934873, August > 2016, > >> >>>>>>> <https://doi.org/10.1145/2934872.2934873>. > >> >>>>>>> > >> >>>>>>> [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>. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> [IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. > Ghobadi, > >> >>>>>>> "Proportional Rate Reduction for TCP", IMC '11: > >> >>>>>>> Proceedings of the 2011 ACM SIGCOMM Conference > on Internet > >> >>>>>>> Measurement Conference, pp. 155-170, > >> >>>>>>> DOI 10.1145/2068816.2068832, November 2011, > >> >>>>>>> <https://doi.org/10.1145/2068816.2068832>. > >> >>>>>>> > >> >>>>>>> [Jacobson88] > >> >>>>>>> Jacobson, V., "Congestion Avoidance and > Control", > >> >>>>>>> Symposium proceedings on Communications > architectures and > >> >>>>>>> protocols (SIGCOMM '88), pp. 314-329, > >> >>>>>>> DOI 10.1145/52325.52356, August 1988, > >> >>>>>>> <https://doi.org/10.1145/52325.52356>. > >> >>>>>>> > >> >>>>>>> [Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. > Anderson, > >> >>>>>>> "TCP Congestion Control with a Misbehaving > Receiver", ACM > >> >>>>>>> SIGCOMM Computer Communication Review, vol. 29, > no. 5, pp. > >> >>>>>>> 71-78, DOI 10.1145/505696.505704, October 1999, > >> >>>>>>> <https://doi.org/10.1145/505696.505704>. > >> >>>>>>> > >> >>>>>>> [VCC] Cronkite-Ratcliff, B., Bergman, A., Vargaftik, > S., Ravi, > >> >>>>>>> M., McKeown, N., Abraham, I., and I. Keslassy, > >> >>>>>>> "Virtualized Congestion Control (Extended > Version)", > >> >>>>>>> SIGCOMM '16: Proceedings of the 2016 ACM SIGCOMM > >> >>>>>>> Conference pp. 230-243, DOI > 10.1145/2934872.2934889, > >> >>>>>>> August 2016, < > http://www.ee.technion.ac.il/~isaac/p/ > >> >>>>>>> sigcomm16_vcc_extended.pdf>. > >> >>>>>>> > >> >>>>>>> --> > >> >>>>>>> > >> >>>>>>> Thank you, Free access is goot! > >> >>>>>>> > >> >>>>>>> 8) <!-- [rfced] Some author comments are present in the XML. > Please confirm > >> >>>>>>> that no updates related to these comments are outstanding. Note > that the > >> >>>>>>> comments will be deleted prior to publication. > >> >>>>>>> --> > >> >>>>>>> Yes, We got that. > >> >>>>>>> > >> >>>>>>> 9) <!-- [rfced] Abbreviations > >> >>>>>>> > >> >>>>>>> a) FYI - We have added expansions for the following > abbreviations > >> >>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > each > >> >>>>>>> expansion in the document carefully to ensure correctness. > >> >>>>>>> > >> >>>>>>> Content Delivery Network (CDN) > >> >>>>>>> Forward Acknowledgment (FACK) > >> >>>>>>> Recent Acknowledgment Tail Loss Probe (RACK-TLP) > >> >>>>>>> Consistent use of CDN, FACK and RACK-TLP are good. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> b) Both the expansion and the acronym for the following term > are used > >> >>>>>>> throughout the document. Would you like to update to use the > expansion upon > >> >>>>>>> first usage and the acronym for the rest of the document? > >> >>>>>>> > >> >>>>>>> round-trip time (RTT) > >> >>>>>>> -->Note that "round-trip time" is only used for the very high > level description of PRR. A round trip, as marked by an event (the arrival > of an ACK, rather than the passing of time), is correct and not abbreviated > RTT. No changes. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 10) <!--[rfced] Throughout the text, the following terminology > appears to > >> >>>>>>> be used inconsistently. May we update each to the form on the > right? > >> >>>>>>> > >> >>>>>>> Fast Retransmit > fast retransmit > >> >>>>>>> limited transmit > Limited Transmit > >> >>>>>>> --> > >> >>>>>>> No changes please: The capitalized terms are proper names and > used to refer to the algorithms themselves. Lower case is used in running > prose to refer to packets triggered by the algorithms. e.g. the fast > retransmit is the packet triggered by the Fast Retransmit algorithm. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 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. > >> >>>>>>> > >> >>>>>>> Note that our script did not flag any words in particular, but > this should > >> >>>>>>> still be reviewed as a best practice. > >> >>>>>>> --> > >> >>>>>>> > >> >>>>>>> We concur. Inclusivity is important. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Thank you. > >> >>>>>>> > >> >>>>>>> Alanna Paloma and Sandy Ginoza > >> >>>>>>> RFC Production Center > >> >>>>>>> > >> >>>>>>> End of markups, and Thank You! > >> >>>>>>> > >> >>>>>>> On Nov 21, 2025, at 3:46 PM, [email protected] wrote: > >> >>>>>>> > >> >>>>>>> *****IMPORTANT***** > >> >>>>>>> > >> >>>>>>> Updated 2025/11/21 > >> >>>>>>> > >> >>>>>>> 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/rfc9937.xml > >> >>>>>>> https://www.rfc-editor.org/authors/rfc9937.html > >> >>>>>>> https://www.rfc-editor.org/authors/rfc9937.pdf > >> >>>>>>> https://www.rfc-editor.org/authors/rfc9937.txt > >> >>>>>>> > >> >>>>>>> Diff file of the text: > >> >>>>>>> https://www.rfc-editor.org/authors/rfc9937-diff.html > >> >>>>>>> https://www.rfc-editor.org/authors/rfc9937-rfcdiff.html > (side by side) > >> >>>>>>> > >> >>>>>>> Diff of the XML: > >> >>>>>>> https://www.rfc-editor.org/authors/rfc9937-xmldiff1.html > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Tracking progress > >> >>>>>>> ----------------- > >> >>>>>>> > >> >>>>>>> The details of the AUTH48 status of your document are here: > >> >>>>>>> https://www.rfc-editor.org/auth48/rfc9937 > >> >>>>>>> > >> >>>>>>> Please let us know if you have any questions. > >> >>>>>>> > >> >>>>>>> Thank you for your cooperation, > >> >>>>>>> > >> >>>>>>> RFC Editor > >> >>>>>>> > >> >>>>>>> -------------------------------------- > >> >>>>>>> RFC 9937 (draft-ietf-tcpm-prr-rfc6937bis-21) > >> >>>>>>> > >> >>>>>>> Title : Proportional Rate Reduction > >> >>>>>>> Author(s) : M. Mathis, N. Cardwell, Y. Cheng, N. > Dukkipati > >> >>>>>>> WG Chair(s) : Yoshifumi Nishida, Michael Tüxen > >> >>>>>>> > >> >>>>>>> Area Director(s) : Gorry Fairhurst, Mike Bishop > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 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> please leave a > message if you must call. > >> >>>>>>> > >> >>>>>>> > >> >>>>> > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
