Looks good to me. Nice fix for the figure being too wide. Russ
> On May 27, 2025, at 4:32 PM, Neal Cardwell <[email protected]> wrote: > > 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] > <mailto:[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] <mailto:[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] <mailto:[email protected]>> >> Cc: <[email protected] <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> On Tue, May 27, 2025 at 11:33 AM Russ Housley via Datatracker >> <[email protected] <mailto:[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]
