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 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 please leave a message if you must call. >> >>>>>>> >> >>>>>>> >> >>>>> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
