On Thu, Feb 27, 2025 at 12:46 AM <rfc-edi...@rfc-editor.org> wrote:
> Authors and *AD, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!--[rfced] *ADs - As this document obsoletes RFC 5033, should it be > added to BCP 133? We have updated as such; please let us know > any objections. --> > No objection. > > > 2) <!--[rfced] While we understand RFC 5033 was published > with some of the text we are questioning below, the questions and > edits are aimed at making the text as correct and useful to the reader > as possible. Please review carefully. > > In addition, this document is in the current RFC format (a major change > was made in 2019), so various updates have been made in the source file. > Details are here: https://www.rfc-editor.org/pubprocess/how-we-update. > --> > > > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. > --> > > > 4) <!--[rfced] Might this update to the Abstract be of interest? It > attempts to reduce redundancy and reorganize the sentences > slightly. > > Original: > > This document replaces RFC 5033, which discusses the principles and > guidelines for standardizing new congestion control algorithms. It > seeks to ensure that proposed congestion control algorithms operate > without harm and efficiently alongside other algorithms in the global > Internet. It emphasizes the need for comprehensive testing and > validation to prevent adverse interactions with existing flows. This > document provides a framework for the development and assessment of > congestion control mechanisms, promoting stability across diverse > network environments. It obsoletes RFC5033 to reflect changes in > the congestion control landscape. > > Perhaps: > > RFC 5033 discusses the principles and guidelines for standardizing > new congestion control algorithms. This document obsoletes RFC > 5033 to reflect changes in the congestion control landscape by > providing a framework for the development and assessment of > congestion control mechanisms, promoting stability across diverse > work environments. This document aims to describe ways that > proposed congestion control algorithms can operate both without > harm and efficiently alongside other algorithms in the global > Internet. It emphasizes the need for comprehensive testing and > validation to prevent adverse interactions with existing flows. > --> > > > 5) <!-- [rfced] We note that [HRX08] states it was published in 2008. May > we update the text below accordingly? > > Original: > CUBIC was documented in a research publication in 2007 [HRX08], and > was then adopted as the default congestion control algorithm for > the TCP implementation in Linux. > > Perhaps: > CUBIC was documented in a research publication in 2008 [HRX08], and > was then adopted as the default congestion control algorithm for > the TCP implementation in Linux. > > --> > > > 6) <!--[rfced] Would one of the following suggestions be agreeable in > order to clarify this document's journey? > > Original: > It was already used in a significant fraction of TCP connections over > the Internet before being documented in an Informational > Internet-Draft in 2015, published as an Informational RFC in 2017 as > [RFC8312] and then as a Proposed Standard in 2023 [RFC9438]. > > Perhaps A: > It was already used in a significant > fraction of TCP connections over the Internet before being published as an > Informational RFC in 2017 as [RFC8312] and then as a Proposed > Standard in 2023 [RFC9438]. > > Perhaps B: > It was already used in a significant fraction of TCP connections over > the Internet before being documented in an Internet-Draft with the > intended status of Informational in 2015, published as an > Informational RFC in 2017 as [RFC8312], and then published as a > Proposed Standard in 2023 [RFC9438]. > --> > > > 7) <!--[rfced] Note that we have removed "IRTF" from the following text. > It doesn't appear to us that an IRTF RG adopted this draft (we > see the first two versions as individual submissions and the last > as an IETF document). Please review. > > Original: > It was described in an IRTF Internet-Draft in 2018, and that > Internet-Draft is regularly updated to document the > evolving versions of the algorithm [BBR-draft]. > > Current: > It was described in an Internet-Draft in 2018, which has been > regularly updated to document the evolving versions of the algorithm > [BBR]. > --> > > > 8) <!-- [rfced] May we update the third bullet below for consistency with > the other bulleted items? > > Original: > > Nevertheless, a specification for a congestion control algorithm > provides a number of advantages: > > * It can help implementers, operators, and other interested parties > develop a shared understanding of how the algorithm works and how > it is expected to behave in various scenarios and configurations. > > * It can help potential contributors understand the algorithm, which > can make it easier for them to suggest improvements and/or > identify limitations. Furthermore, the specification can help > multiple contributors align on a consensus change to the > algorithm. > > * A specification that is accessible to anyone can circumvent the > issue that some implementers may be unable to read open source > reference implementations due to the constraints of some open > source licenses. > > Perhaps: > > > Nevertheless, a specification for a congestion control algorithm > provides a number of advantages: > > ... > > * It can help (by being accessible to anyone) to circumvent the issue > that > some implementers may be unable to read open-source reference > implementations due to the constraints of some open-source licenses. > > --> > > > 9) <!--[rfced] Might this update reduce redundancy? > > Original: > Evidence of results is normally considered by the working group in > deciding if a specification is ready for publication and ought to be > documented in any request for the working group to publish the > specification. > > Perhaps: > Any request for a working group to consider a specification for > publication ought to document evidence of results. > > --> > > > 10) <!--[rfced] May we make this update for accuracy/clarity? > > Original: > Publication might occur without multiple implementations if a single > implementation is widely used, open source, and shown to have > positive impact on the Internet, particularly if the target status is > Experimental. > > Perhaps: > A congestion control algorithm without multiple implementations > might still be published as an RFC if a single implementation is > widely used, open source, and shown to have a positive impact on > the Internet, particularly if the target status is Experimental. > --> > > > 11) <!--[rfced] Please carefully review our updates to Section 3.2. As > much of this section is about RFCs themselves and the publication > process, we have made a number of changes to attempt to improve > clarity and to align the style of terminology with past RFCs and > in-house guidance on such topics. Please let us know any > objections or further updates to be made. --> > > > 12) <!--[rfced] This text left us wondering what happens to algorithms > that are not targeted at general use? What status can they seek? > Perhaps further info would be helpful to the reader? > > Original: > Congestion control algorithms without empirical evidence of > Internet-scale deployment MUST seek Experimental status, unless they > are not targeted at general use. > > > --> > > > 13) <!--[rfced] In the following, we assume that RFC 4614 should remain as > the cited document even though it has been obsoleted. > Please note that we have added mention of the obsoleting document > as well as an Informative References entry for the ease of the > reader. > > Original: > Section 4 of [RFC4614] provides other examples of extensions that were > considered experimental when the specification was > published. > > Current: > Section 4 of [RFC4614] provides other examples of extensions that were > considered experimental when the specification was > published (note that [RFC4614] has since been obsoleted by > [RFC7414]). > --> > > > 14) <!-- [rfced] For readability, may we update this sentence as follows? > > Original: > In evaluating a new proposal for use in a controlled environment, > the IETF needs to understand the usage, e.g., how the usage is > scoped to the controlled environment, whether the algorithm will > share resources with Internet traffic, and consider what could > happen if used in a protocol that is bridged across an Internet > path. > > Perhaps: > In evaluating a new proposal for use in a controlled environment, > the IETF community needs to understand the usage (e.g., how the usage is > scoped to the controlled environment), whether the algorithm will > share resources with Internet traffic, and what could > happen if used in a protocol that is bridged across an Internet > path. > > --> > > > 15) <!--[rfced] Does the suggested text capture your intended meaning? > > Original: > Instead, the community will use these evaluations as an input when > considering whether to progress the proposed algorithm. > > Perhaps: > Instead, the community will use these evaluations as an input when > considering whether to progress the proposed algorithm specification > in the publication process. > --> > > > 16) <!-- [rfced] We were unable to find "Reno" explicitly mentioned in RFC > 5681 as seen in the text below: > > Original: > > The standards-track Reno [RFC5681] and CUBIC [RFC9438] > congestion control algorithms send at progressively higher rates > until a First-In First-Out (FIFO) buffer completely fills... > > However, it does appear in RFCs 5681 and 6582 in the reference > below. Should the reference to RFC 5681 be adjusted to [FF96]? [FF96] > is now available at this URL: > https://dl.acm.org/doi/10.1145/235160.235162 > > From RFC 5681: > > [FF96] Fall, K. and S. Floyd, "Simulation-based Comparisons of > Tahoe, Reno and SACK TCP", Computer Communication Review, > July 1996, ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. > > From RFC 6582: > > "For the typical implementation of the TCP fast recovery algorithm > described in [RFC5681] (first implemented in the 1990 BSD Reno > release, and referred to as the "Reno algorithm" in [FF96])..." > > > --> > > > 17) <!-- [rfced] FYI - We have reworked the text below into a bulleted > list for ease of the reader and updated to use didactic > caps. Please review and let us know any objections. > > Original: > > Among the AQM techniques that might have an impact on a proposed > congestion control algorithm are Flow Queue CoDel (FQ-CoDel) > [RFC8290]; Proportional Integral Controller Enhanced (PIE) [RFC8033]; > and Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332]. > > Current: > > Some of the AQM techniques that might have an impact on a proposed > congestion control algorithm include: > > * Flow Queue CoDel (FQ-CoDel) [RFC8290]; > > * Proportional Integral controller Enhanced (PIE) [RFC8033]; and > > * Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332]. > > --> > > > 18) <!-- [rfced] We note that ECT is most often expanded to "ECN-Capable > Transport (ECT)" (as was done in normative reference RFC 9902). > Would you like to update this expansion to match the usage in > RFC 9902? > > Original: > A proposed congestion control algorithm that sets one of the two > Explicit Congestion Transport (ECT) codepoints in the IP header can > gain the benefits of receiving Explicit Congestion Notification (ECN) > Congestion Experienced (CE) signals from an on-path AQM [RFC8087]. > > Perhaps: > A proposed congestion control algorithm that sets one of the two > ECN-Capable Transport (ECT) codepoints in the IP header can gain the > benefits of receiving Explicit Congestion Notification-Congestion > Experienced (ECN-CE) signals from an on-path AQM [RFC8087]. > > --> > > > 19) <!-- [rfced] FYI - For readability, we have reformatted the text below > to read as a bulleted list. Please review and let us know any objections. > > Original: > > As an example from an Experimental RFC, performance with misbehaving > nodes and outside attackers is discussed in Sections 9.4, 9.5, and > 9.6 of [RFC4782]. This includes discussion of misbehaving senders > and receivers; collusion between misbehaving routers; misbehaving > middleboxes; and the potential use of Quick- Start to attack routers > or to tie up available Quick-Start bandwidth. > > Current: > > As an example from an Experimental RFC, performance with misbehaving > nodes and outside attackers is discussed in Sections 9.4, 9.5, and > 9.6 of [RFC4782]. This includes discussion of: > > * misbehaving senders and receivers; > > * collusion between misbehaving routers; > > * misbehaving middleboxes; and > > * the potential use of Quick-Start to attack routers or to tie up > available Quick-Start bandwidth. > > > --> > > > 20) <!-- [rfced] We had the following additional questions related to > references and citations in the document: > > a.) [BUFFERBLOAT] Would you like to use the following URL for this > reference (as this URL has a DOI and an open access PDF)? > > https://dl.acm.org/doi/10.1145/2063166.2071893 > > b.) FYI - We have added the following RFCs to the Informative > References section, as they are included in the text but were not > cited as references. > > RFC 9293 > RFC 4340 > RFC 9260 > RFC 9000 > RFC 8257 > > --> > > > 21) <!--[rfced] Note that we have cut the "Evolution of RFC5033bis" > section. Generally, change logs only exist in published RFCs in > obsoleting documents as a "Changes Since RFC ####" section, which > highlights the substantive changes that took place between the > last published RFC and this one (i.e., mentions errata addressed or > a security consideration that has changed, etc.). If the section > should be kept, may we suggest something like: > > Perhaps: > Changes Since RFC 5033 > > * Harmonized the "proposed congestion control algorithm" > > * Examined BCP 14 keywords and consistency with other RFCs > > * Added text on constrained environments/limited domains and circuit > breakers and aligned with other RFCs > > * Added discussion of real-time protocols, short flows, AQM response, > multipath transports > > * Listed properties of wired networks > > * Added sections addressing IoT and Multicast (noting this is out of > scope) > > * Rewrote the "Document Status" section > > * Added improved first sentence of Abstract and Introduction > > * Reorganized central sections of the document > > * Added QUIC, other congestion control standards > > * Added wireless environments > > * Aligned motivation for this work with the CCWG charter > > * Refined discussion of Quick-Start > > * Included updated text suggested by Dave Taht > > * Added criterion for bufferbloat > > * Mentioned CUBIC and BBR as motivation > > --> > > > 22) <!--[rfced] We note that there are a number of instances in which an > algorithm or a proposed algorithm takes on human abilities. > Please review the text with this in mind and let us know if any > updates should be made. Some examples below (not exhaustive): > > Original: > A proposed congestion control algorithm SHOULD explore... > > Perhaps: > A proposal for a congestion control algorithm SHOULD explore... > > Original: > A proposed congestion control algorithm ought not to presume... > > Perhaps: > Authors of a proposed congestion control algorithm ought not to presume... > > Original: > A proposed congestion control algorithm MUST clearly explain any > deviations from [RFC2914] and [RFC7141]. > > Perhaps: > A proposal for a congestion control algorithm MUST clearly explain any > deviations from [RFC2914] and [RFC7141]. > --> > > > 23) <!-- [rfced] FYI - We have added expansions for abbreviations upon > first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please > review each expansion in the document carefully to ensure > correctness. > > Explicit Congestion Notification (ECN) > Multipath TCP (MPTCP) > > --> > > > 24) <!-- [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. --> > > > Thank you. > > RFC Editor/kf/mf > > > *****IMPORTANT***** > > Updated 2025/02/26 > > 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 > > * rfc-edi...@rfc-editor.org (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). > > * auth48archive@rfc-editor.org, 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, > auth48archive@rfc-editor.org 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/rfc9743.xml > https://www.rfc-editor.org/authors/rfc9743.html > https://www.rfc-editor.org/authors/rfc9743.pdf > https://www.rfc-editor.org/authors/rfc9743.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9743-diff.html > https://www.rfc-editor.org/authors/rfc9743-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9743-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9743 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9743 (draft-ietf-ccwg-rfc5033bis-08) > > Title : Specifying New Congestion Control Algorithms > Author(s) : M. Duke, G. Fairhurst > WG Chair(s) : Eric Kinnear, Reese Enghardt > > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
