I posted a revision 16 just now as a quick follow-up.

About revision 16:
* Revised the description and caption for the figures to try to improve
clarity.

A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-16


best,
neal
* Revised the description and caption for the figures to try to improve
clarity.

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-16

best,
neal


On Tue, May 27, 2025 at 4:21 PM Neal Cardwell <[email protected]> wrote:

> Hi,
>
> Thanks for the review!
>
> I have attempted to incorporate all of your excellent feedback in draft
> revision 15, which I just posted. The diffs between revisions 14 and 15 are
> here:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-15
>
> The draft itself summarizes the changes in revision 15, but I'm pasting
> them here as well, for easy reference:
>
> ---
> <t>About revision 15:</t>
>
> <ul>
>
> <li>Fixed the description of the initialization of RecoverFS to match the
> latest RecoverFS pseudocode</li>
>
> <li> Add a note that in the first example both algorithms (RFC6675 and
> PRR) complete the fast recovery episode with a cwnd  matching the ssthresh
> of 20.</li>
>
> <li>Revised order of 2nd and 4th co-author</li>
>
> <li>Numerous editorial changes based on 2025-05-27 last call Genart review
> from Russ Housley, including the following changes.</li>
>
> <li>Fixed abstract and intro sections that said that this document
> "updates" the experimental PRR algorithm to clarify that this document
> obsoletes the experimental PRR RFC</li>
>
> <li>To address the feedback 'The 7th paragraph of Section 5 begins with "A
> final change"; yet the 8th paragraph talks about another adaptation to
> PRR', reworded the "A final change" phrase.</li>
>
> <li>Moved the paragraph about measurement studies to a new "Measurement
> Studies" section, to address the feedback: 'The last paragraph of Section 5
> is not really about changes since the publication of RFC 6937'</li>
>
> <li>Fixed various minor editorial issues identified in the review</li>
>
> </ul>
> ---
>
> best regards,
> neal
>
>
> ---------- Forwarded message ---------
> From: <[email protected]>
> Date: Tue, May 27, 2025 at 4:15 PM
> Subject: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-15.txt
> To: <[email protected]>
> Cc: <[email protected]>
>
>
> Internet-Draft draft-ietf-tcpm-prr-rfc6937bis-15.txt is now available. It
> is a
> work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the
> IETF.
>
>    Title:   Proportional Rate Reduction for TCP
>    Authors: Matt Mathis
>             Neal Cardwell
>             Yuchung Cheng
>             Nandita Dukkipati
>    Name:    draft-ietf-tcpm-prr-rfc6937bis-15.txt
>    Pages:   26
>    Dates:   2025-05-27
>
> Abstract:
>
>    This document specifies a standards-track version of the Proportional
>    Rate Reduction (PRR) algorithm that obsoletes the experimental
>    version described in RFC 6937.  PRR provides logic to regulate the
>    amount of data sent by TCP or other transport protocols during fast
>    recovery.  PRR accurately regulates the actual flight size through
>    recovery such that at the end of recovery it will be as close as
>    possible to the slow start threshold (ssthresh), as determined by the
>    congestion control algorithm.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tcpm-prr-rfc6937bis-15.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-15
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> tcpm mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
> On Tue, May 27, 2025 at 11:33 AM Russ Housley via Datatracker <
> [email protected]> wrote:
>
>> Document: draft-ietf-tcpm-prr-rfc6937bis
>> Title: Proportional Rate Reduction for TCP
>> Reviewer: Russ Housley
>> Review result: Almost Ready
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>>
>> Document: draft-ietf-tcpm-prr-rfc6937bis-14
>> Reviewer: Russ Housley
>> Review Date: 2025-05-27
>> IETF LC End Date: 2025-06-06
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: Almost Ready
>>
>>
>> Major Concerns:  None
>>
>>
>> Minor Concerns:
>>
>> The Abstract and Section 1 say that this document "updates" the
>> experimental PRR algorithm.  This wording is confusing because this
>> document obsoletes RFC 6937.  The Abstract and Section 1 should
>> state that this document obsoletes RFC 6937.  Avoiding the use of
>> "updates" is desirable.
>>
>> The 7th paragraph of Section 5 begins with "A final change"; yet the
>> 8th paragraph talks about another adaptation to PRR.
>>
>> The last paragraph of Section 5 is not really about changes since the
>> publication of RFC 6937.  I'm not sure where this information belongs.
>>
>>
>> Nits:
>>
>> Section 5: s/(i.e. sndcnt is 0)/(i.e., sndcnt is 0)/
>>
>> Section 5: s/RTO/retransmission timeout (RTO)/
>>
>> Section 5: s/sets cwnd = ssthresh/sets cwnd to ssthresh/
>>
>> Section 5:  s/ECN/Explicit Congestion Notification (ECN)/
>>
>> Section 5: s/AQMs/ approaches to Active Queue Management (AQM)/
>>
>> Section 9: Figure 1 is too wide.  Can segment 22 be omitted?  If so,
>> the text that follows would say: "ACK#22 (not shown) carries ...".
>>
>> Section 12: s/Janey C.  Hoe/Janey C. Hoe/
>>
>>
>>
>>
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to