Skip to main content

Specifying New Congestion Control Algorithms
draft-ietf-ccwg-rfc5033bis-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Martin Duke , Gorry Fairhurst
Last updated 2023-09-25
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ccwg-rfc5033bis-00
CCWG                                                        M. Duke, Ed.
Internet-Draft                                                Google LLC
Obsoletes: 5033 (if approved)                          G. Fairhurst, Ed.
Intended status: Best Current Practice            University of Aberdeen
Expires: 24 March 2024                                 21 September 2023

              Specifying New Congestion Control Algorithms
                     draft-ietf-ccwg-rfc5033bis-00

Abstract

   The IETF's standard congestion control schemes have been widely shown
   to be inadequate for various environments (e.g., high-speed networks,
   wireless technologies such as 3GPP and WiFi, long distance satellite
   links) and also in conflict with the needed, more isochronous,
   behaviors of VoIP, gaming, and videoconferencing traffic.  Recent
   research has yielded many alternate congestion control schemes that
   significantly differ from the IETF's congestion control principles.
   Using these new congestion control schemes in the global Internet has
   possible ramifications to both the traffic using the new congestion
   control and to traffic using the currently standardized congestion
   control.  Therefore, the IETF must proceed with caution when dealing
   with alternate congestion control proposals.  The goal of this
   document is to provide guidance for considering alternate congestion
   control algorithms within the IETF.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 March 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Duke & Fairhurst          Expires 24 March 2024                 [Page 1]
Internet-Draft              New CC Algorithms             September 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Document Status . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Guidelines  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Minimum Requirements  . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Evolution of RFC5033bis . . . . . . . . . . . . . . . . . . . . .  13
     Since draft-scheffenegger-congress-rfc5033bis-00  . . . . . . .  13
     Since RFC5033 . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document provides guidelines for the IETF to use when evaluating
   suggested congestion control algorithms that significantly differ
   from the general congestion control principles outlined in [RFC2914].
   The guidance is intended to be useful to authors proposing alternate
   congestion control and for the IETF community when evaluating whether
   a proposal is appropriate for publication in the RFC series and for
   deployment in the Internet.

   This document updates the similarly titled [RFC5033] that was
   published in 2007.  Since then, multiple congestion control
   algorithms were developed outside of the IETF, including at least two
   that saw large scale deployment: Cubic [HRX08] and BBR [BBR-draft].

Duke & Fairhurst          Expires 24 March 2024                 [Page 2]
Internet-Draft              New CC Algorithms             September 2023

   Cubic was documented in a research publication in 2007 [HRX08], and
   then adopted as the default congestion control algorithm for the TCP
   implementation in Linux.  It was already used in a significant
   fraction of TCP connections over the Internet before being documented
   in an informational Internet Draft in 2015, being published as an
   informational RFC in 2017 [RFC8312] and then as a proposed standard
   in 2023 [RFC9438].

   BBR is developed as an internal research project by Google, with the
   first implementation contributed to Linux kernel 4.19 in 2016.  It
   was described in an IRTF draft in 2018, and that draft is regularly
   updated to document the evolving versions of the algorithm
   [BBR-draft].  BBR is widely used for Google services using either TCP
   or QUIC [RFC9000], and is also largely deployed outside of Google.

   We cannot say now whether the original authors of [RFC5033] expected
   that developers would be somehow waiting for IETF review before
   widely deploying a congestion control algorithm over the Internet,
   but the examples of Cubic and BBR teaches us that deployment of new
   algorithms is not in fact gated by publication of the algorithm as an
   RFC.  Nevertheless, guidelines are important, if only to remind
   potential inventors and developers of the multiple facets of the
   congestion control problem.

   The guidelines in this document are intended to be consistent with
   the congestion control principles from [RFC2914] of preventing
   congestion collapse, considering fairness, and optimizing the flow's
   own performance in terms of throughput, delay, and loss.  [RFC2914]
   also discusses the goal of avoiding a congestion control "arms race"
   among competing transport protocols.

   This document does not give hard-and-fast requirements for an
   appropriate congestion control scheme.  Rather, the document provides
   a set of criteria that should be considered and weighed by the
   developers of congestion control algorithms and by the IETF in the
   context of each proposal.  The high-order criteria for any new
   proposal is that a serious scientific study of the pros and cons of
   the proposal needs to have been done before a proposal is considered
   for publication by the IETF or before it is deployed at large scale.

   After initial studies, we encourage authors to write a specification
   of their proposals for publication in the RFC series to allow others
   to concretely understand and investigate the wealth of proposals in
   this space.

Duke & Fairhurst          Expires 24 March 2024                 [Page 3]
Internet-Draft              New CC Algorithms             September 2023

2.  Document Status

   Following the lead of HighSpeed TCP [RFC3649], alternate congestion
   control algorithms are expected to be published as "Experimental"
   RFCs until such time that the community better understands the
   solution space.  Traditionally, the meaning of "Experimental" status
   has varied in its use and interpretation.  As part of this document
   we define two classes of congestion control proposals that can be
   published with the "Experimental" status.  The first class includes
   algorithms that are judged to be safe to deploy for best-effort
   traffic in the global Internet and further investigated in that
   environment.  The second class includes algorithms that, while
   promising, are not deemed safe enough for widespread deployment as
   best-effort traffic on the Internet, but are being specified to
   facilitate investigations in simulation, testbeds, or controlled
   environments.  The second class can also include algorithms where the
   IETF does not yet have sufficient understanding to decide if the
   algorithm is or is not safe for deployment on the Internet.

   Each alternate congestion control algorithm published is required to
   include a statement in the abstract indicating whether or not the
   proposal is considered safe for use on the Internet.  Each alternate
   congestion control algorithm published is also required to include a
   statement in the abstract describing environments where the protocol
   is not recommended for deployment.  There may be environments where
   the protocol is deemed _safe_ for use, but still is not _recommended_
   for use because it does not perform well for the user.

   As examples of such statements, [RFC3649] specifying HighSpeed TCP
   includes a statement in the abstract stating that the proposal is
   Experimental, but may be deployed in the current Internet.  In
   contrast, the Quick-Start document [RFC4782] includes a paragraph in
   the abstract stating the mechanism is only being proposed for
   controlled environments.  The abstract specifies environments where
   the Quick-Start request could give false positives (and therefore
   would be unsafe to deploy).  The abstract also specifies environments
   where packets containing the Quick-Start request could be dropped in
   the network; in such an environment, Quick-Start would not be unsafe
   to deploy, but deployment would still not be recommended because it
   could cause unnecessary delays for the connections attempting to use
   Quick-Start.

   For authors of alternate congestion control schemes who are not ready
   to bring their congestion control mechanisms to the IETF for
   standardization (either as Experimental or as Proposed Standard), one
   possibility would be to submit an internet-draft that documents the
   alternate congestion control mechanism for the benefit of the IETF
   and IRTF communities.  This is particularly encouraged in order to

Duke & Fairhurst          Expires 24 March 2024                 [Page 4]
Internet-Draft              New CC Algorithms             September 2023

   get algorithm specifications widely disseminated to facilitate
   further research.  Such an internet-draft could be submitted to be
   considered as an Informational RFC, as a first step in the process
   towards standardization.  Such a document would also be expected to
   carry an explicit warning against using the scheme in the global
   Internet.

   Note: we are not changing the RFC publication process for non-IETF
   produced documents (e.g., those from the IRTF or Independent
   Submissions via the RFC-Editor).  However, we would hope the
   guidelines in this document inform the IESG as they consider whether
   to add a note to such documents.

3.  Guidelines

   As noted above, authors are expected to do a well-rounded evaluation
   of the pros and cons of proposals brought to the IETF.  The following
   are guidelines to help authors and the IETF community.  Concerns that
   fall outside the scope of these guidelines are certainly possible;
   these guidelines should not be considered as an all-encompassing
   check-list.

   (0)  Differences with Congestion Control Principles [RFC2914]

      Proposed congestion control mechanisms should include a clear
      explanation of the deviations from [RFC2914].

   (1)  Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].

      Proposed congestion control mechanisms should be evaluated when
      competing with standard IETF congestion control [RFC2581],
      [RFC2960], [RFC4340].  Alternate congestion controllers that have
      a significantly negative impact on traffic using standard
      congestion control may be suspect and this aspect should be part
      of the community's decision making with regards to the suitability
      of the alternate congestion control mechanism.

      We note that this bullet is not a requirement for strict TCP-
      friendliness as a prerequisite for an alternate congestion control
      mechanism to advance to Experimental.  As an example, HighSpeed
      TCP is a congestion control mechanism that is Experimental, but
      that is not TCP-friendly in all environments.  We also note that
      this guideline does not constrain the fairness offered for non-
      best-effort traffic.

      As an example from an Experimental RFC, fairness with standard TCP

Duke & Fairhurst          Expires 24 March 2024                 [Page 5]
Internet-Draft              New CC Algorithms             September 2023

      is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed TCP) and
      using spare capacity is discussed in Sections 6, 11.1, and 12 of
      [RFC3649].

   (2)  Difficult Environments.

      The proposed algorithms should be assessed in difficult
      environments such as paths containing wireless links.
      Characteristics of wireless environments are discussed in
      [RFC3819] and in Section 16 of [Tools].  Other difficult
      environments can include those with multipath routing within a
      connection.  We note that there is still much to be desired in
      terms of the performance of TCP in some of these difficult
      environments.  For congestion control mechanisms with explicit
      feedback from routers, difficult environments can include paths
      with non-IP queues at layer-two, IP tunnels, and the like.  A
      minimum goal for experimental mechanisms proposed for widespread
      deployment in the Internet should be that they do not perform
      significantly worse than TCP in these environments.

      While it is impossible to enumerate all the possible "difficult
      environments", we note that the IETF has previously grappled with
      paths with long delays [RFC2488], high delay bandwidth products
      [RFC3649], high packet corruption rates [RFC3155], packet
      reordering [RFC4653], and significantly slow links [RFC3150].
      Aspects of alternate congestion control that impact networks with
      these characteristics should be detailed.

      As an example from an Experimental RFC, performance in difficult
      environments is discussed in Sections 6, 9.2, and 10.2 of
      [RFC4782] (Quick-Start).

   (3)  Investigating a Range of Environments.

      Similar to the last criteria, proposed alternate congestion
      controllers should be assessed in a range of environments.  For
      instance, proposals should be investigated across a range of
      bandwidths, round-trip times, levels of traffic on the reverse
      path, and levels of statistical multiplexing at the congested
      link.  Similarly, proposals should be investigated for robust
      performance with different queueing mechanisms in the routers,
      especially Random Early Detection (RED) [FJ03] and Drop-Tail.
      This evaluation is often not included in the internet-draft
      itself, but in related papers cited in the draft.

      A particularly important aspect of evaluating a proposal for

Duke & Fairhurst          Expires 24 March 2024                 [Page 6]
Internet-Draft              New CC Algorithms             September 2023

      standardization is in understanding where the algorithm breaks
      down.  Therefore, particular attention should be paid to
      characterizing the areas where the proposed mechanism does not
      perform well.

      As an example from an Experimental RFC, performance in a range of
      environments is discussed in Section 12 of [RFC3649] (HighSpeed
      TCP) and Section 9.7 of [RFC4782] (Quick-Start).

   (4)  Protection Against Congestion Collapse

      The alternate congestion control mechanism should either stop
      sending when the packet drop rate exceeds some threshold
      [RFC3714], or should include some notion of "full backoff".  For
      "full backoff", at some point the algorithm would reduce the
      sending rate to one packet per round-trip time and then
      exponentially backoff the time between single packet transmissions
      if congestion persists.  Exactly when either "full backoff" or a
      pause in sending comes into play will be algorithm-specific.
      However, as discussed in [RFC2914], this requirement is crucial to
      protect the network in times of extreme congestion.

      If "full backoff" is used, this bullet does not require that the
      full backoff mechanism must be identical to that of TCP [RFC2988].
      As an example, this bullet does not preclude full backoff
      mechanisms that would give flows with different round- trip times
      comparable bandwidth during backoff.

   (5)  Protection Against Bufferbloat

      The alternate congestion control mechanism should reduce its
      sending rate if the round trip time (RTT) significantly increases.
      Exactly how the algorithm reduces its sending rate is algorithm
      specific.

      Bufferbloat [Bufferbloat] refers to the building of long queues in
      the network.  Many network routers are configured with very large
      buffers.  If congestion starts happening, classic TCP congestion
      control algorithms [RFC5681] will continue sending at a high rate
      until the buffer fills up completely and packet losses occur.
      Every connection going through that bottleneck will experience
      high latency.  This is particularly bad for highly interactive
      applications like games, but it also affects routine web browsing
      and video playing.

      This problem became apparent in the last decade and was not

Duke & Fairhurst          Expires 24 March 2024                 [Page 7]
Internet-Draft              New CC Algorithms             September 2023

      discussed in the Congestion Control Principles published in
      September 2002 [RFC2914].  The classic congestion control
      algorithm [RFC5681] and the widely deployed Cubic algorithm
      [RFC9438] do not address it, but newly designed congestion control
      algorithms have the opportunity to improve the state of the art.

   (6)  Fairness within the Alternate Congestion Control Algorithm.

      In environments with multiple competing flows all using the same
      alternate congestion control algorithm, the proposal should
      explore how bandwidth is shared among the competing flows.

   (7)  Performance with Misbehaving Nodes and Outside Attackers.

      The proposal should explore how the alternate congestion control
      mechanism performs with misbehaving senders, receivers, or
      routers.  In addition, the proposal should explore how the
      alternate congestion control mechanism performs with outside
      attackers.  This can be particularly important for congestion
      control mechanisms that involve explicit feedback from routers
      along the path.

      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] (Quick-Start).  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.

   (8)  Responses to Sudden or Transient Events.

      The proposal should consider how the alternate congestion control
      mechanism would perform in the presence of transient events such
      as sudden congestion, a routing change, or a mobility event.
      Routing changes, link disconnections, intermittent link
      connectivity, and mobility are discussed in more detail in
      Section 17 of [Tools].

      As an example from an Experimental RFC, response to transient
      events is discussed in Section 9.2 of [RFC4782] (Quick-Start).

   (9)  Incremental Deployment.

      The proposal should discuss whether the alternate congestion
      control mechanism allows for incremental deployment in the
      targeted environment.  For a mechanism targeted for deployment in
      the current Internet, it would be helpful for the proposal to

Duke & Fairhurst          Expires 24 March 2024                 [Page 8]
Internet-Draft              New CC Algorithms             September 2023

      discuss what is known (if anything) about the correct operation of
      the mechanism with some of the equipment installed in the current
      Internet, e.g., routers, transparent proxies, WAN optimizers,
      intrusion detection systems, home routers, and the like.

      As a similar concern, if the alternate congestion control
      mechanism is intended only for specific environments (and not the
      global Internet), the proposal should consider how this intention
      is to be carried out.  The community will have to address the
      question of whether the scope can be enforced by simply stating
      the restrictions or whether additional protocol mechanisms are
      required to enforce the scoping.  The answer will necessarily
      depend on the change being proposed.

      As an example from an Experimental RFC, deployment issues are
      discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start).

4.  Minimum Requirements

   This section suggests minimum requirements for a document to be
   approved as Experimental with approval for widespread deployment in
   the global Internet.

   The minimum requirements for approval for widespread deployment in
   the global Internet include the following guidelines on: (1)
   assessing the impact on standard congestion control, (3)
   investigation of the proposed mechanism in a range of environments,
   (4) protection against congestion collapse, and (8) discussing
   whether the mechanism allows for incremental deployment.

   For other guidelines, i.e., (2), (5), (6), and (7), the author must
   perform the suggested evaluations and provide recommended analysis.
   Evidence that the proposed mechanism has significantly more problems
   than those of TCP should be a cause for concern in approval for
   widespread deployment in the global Internet.

5.  Security Considerations

   This document does not represent a change to any aspect of the TCP/IP
   protocol suite and therefore does not directly impact Internet
   security.  The implementation of various facets of the Internet's
   current congestion control algorithms do have security implications
   (e.g., as outlined in [RFC2581]).  Alternate congestion control
   schemes should be mindful of such pitfalls, as well, and should
   examine any potential security issues that may arise.

Duke & Fairhurst          Expires 24 March 2024                 [Page 9]
Internet-Draft              New CC Algorithms             September 2023

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.1.  Normative References

   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
              Control", RFC 2581, DOI 10.17487/RFC2581, April 1999,
              <https://www.rfc-editor.org/rfc/rfc2581>.

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, DOI 10.17487/RFC2914, September 2000,
              <https://www.rfc-editor.org/rfc/rfc2914>.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000,
              <https://www.rfc-editor.org/rfc/rfc2960>.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340,
              DOI 10.17487/RFC4340, March 2006,
              <https://www.rfc-editor.org/rfc/rfc4340>.

   [RFC5033]  Floyd, S. and M. Allman, "Specifying New Congestion
              Control Algorithms", BCP 133, RFC 5033,
              DOI 10.17487/RFC5033, August 2007,
              <https://www.rfc-editor.org/rfc/rfc5033>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5681>.

7.2.  Informative References

   [BBR-draft]
              Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
              Jacobson, "BBR Congestion Control", Work in Progress,
              Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
              control-02, 7 March 2022,
              <https://datatracker.ietf.org/doc/html/draft-cardwell-
              iccrg-bbr-congestion-control-02>.

Duke & Fairhurst          Expires 24 March 2024                [Page 10]
Internet-Draft              New CC Algorithms             September 2023

   [Bufferbloat]
              Gettys, J., "The Blind Men and the Elephant", IETF Blog ,
              10 February 2018,
              <https://www.ietf.org/blog/blind-men-and-elephant/>.

   [FJ03]     Floyd, S. and V. Jacobson, "Random Early Detection
              Gateways for Congestion Avoidance", IEEE/ACM Transactions
              on Networking, V.1 N.4 , August 1993.

   [HRX08]    Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly
              high-speed TCP variant", ACM SIGOPS Operating Systems
              Review, vol. 42, no. 5, pp. 64-74 , July 2008,
              <https://doi.org/10.1145/1400097.1400105>.

   [RFC2488]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
              Over Satellite Channels using Standard Mechanisms",
              BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999,
              <https://www.rfc-editor.org/rfc/rfc2488>.

   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
              Timer", RFC 2988, DOI 10.17487/RFC2988, November 2000,
              <https://www.rfc-editor.org/rfc/rfc2988>.

   [RFC3150]  Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
              "End-to-end Performance Implications of Slow Links",
              BCP 48, RFC 3150, DOI 10.17487/RFC3150, July 2001,
              <https://www.rfc-editor.org/rfc/rfc3150>.

   [RFC3155]  Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
              Vaidya, "End-to-end Performance Implications of Links with
              Errors", BCP 50, RFC 3155, DOI 10.17487/RFC3155, August
              2001, <https://www.rfc-editor.org/rfc/rfc3155>.

   [RFC3649]  Floyd, S., "HighSpeed TCP for Large Congestion Windows",
              RFC 3649, DOI 10.17487/RFC3649, December 2003,
              <https://www.rfc-editor.org/rfc/rfc3649>.

   [RFC3714]  Floyd, S., Ed. and J. Kempf, Ed., "IAB Concerns Regarding
              Congestion Control for Voice Traffic in the Internet",
              RFC 3714, DOI 10.17487/RFC3714, March 2004,
              <https://www.rfc-editor.org/rfc/rfc3714>.

   [RFC3819]  Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, DOI 10.17487/RFC3819, July 2004,
              <https://www.rfc-editor.org/rfc/rfc3819>.

Duke & Fairhurst          Expires 24 March 2024                [Page 11]
Internet-Draft              New CC Algorithms             September 2023

   [RFC4653]  Bhandarkar, S., Reddy, A. L. N., Allman, M., and E.
              Blanton, "Improving the Robustness of TCP to Non-
              Congestion Events", RFC 4653, DOI 10.17487/RFC4653, August
              2006, <https://www.rfc-editor.org/rfc/rfc4653>.

   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
              Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
              January 2007, <https://www.rfc-editor.org/rfc/rfc4782>.

   [RFC5166]  Floyd, S., Ed., "Metrics for the Evaluation of Congestion
              Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March
              2008, <https://www.rfc-editor.org/rfc/rfc5166>.

   [RFC8312]  Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
              R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
              RFC 8312, DOI 10.17487/RFC8312, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8312>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC9438]  Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
              "CUBIC for Fast and Long-Distance Networks", RFC 9438,
              DOI 10.17487/RFC9438, August 2023,
              <https://www.rfc-editor.org/rfc/rfc9438>.

   [Tools]    Floyd, S. and E. Kohler, "Tools for the Evaluation of
              Simulation and Testbed Scenarios", Work in Progress , July
              2007,
              <https://datatracker.ietf.org/doc/draft-irtf-tmrg-tools>.

Acknowledgments

   Sally Floyd and Mark Allman were the authors of this document's
   predecessor, RFC5033, which served the community well for over a
   decade.

   Thanks to Richard Scheffenegger for helping to get this revision
   process started.

   Discussions with Lars Eggert and Aaron Falk seeded the original
   RFC5033.  Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye,
   Colin Perkins, Pekka Savola, members of TSVWG, and participants at
   the TCP Workshop at Microsoft Research all provided feedback and
   contributions to that document.  It also drew from [RFC5166].

Duke & Fairhurst          Expires 24 March 2024                [Page 12]
Internet-Draft              New CC Algorithms             September 2023

   These individuals suggested improvements to this document:

   *  Dave Taht

Evolution of RFC5033bis

Since draft-scheffenegger-congress-rfc5033bis-00

   *  Renamed file to reflect WG adpotion

   *  Updated authorship and acknowledgements.

   *  Include updated text suggested by Dave Taht

   *  Added criterion for bufferbloat

   *  Mentioned Cubic and BBR as motivation

   *  Include section to track updates between revisions

   *  Update references

Since RFC5033

   *  converted to Markdown and xml2rfc v3

   *  various formatting changes

Contributors

   Christian Huitema
   Private Octopus, Inc.
   Email: huitema@huitema.net

Authors' Addresses

   Martin Duke (editor)
   Google LLC
   Email: martin.h.duke@gmail.com

   Godred Fairhurst (editor)
   University of Aberdeen
   Email: gorry@erg.abdn.ac.uk

Duke & Fairhurst          Expires 24 March 2024                [Page 13]