Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: proposal is appropriate for publication in the RFC series and for deployment in the Internet. <del> This document obsoletes the similarly titled RFC5033 that was published in 2007 as a Best Current Practice to evaluate proposed congestion control algorithms as Experimental or Proposed Standard RFCs. </del> <ins> This document obsoletes RFC5033, which was published in 2007 as a Best Current Practice to evaluate proposed congestion control algorithms as Experimental or Proposed Standard RFCs. </ins> The IETF's standard congestion control algorithms have been shown to have performance challenges in various environments (e.g., high-speed <del> networks, cellular and WiFi wireless technologies, long distance satellite links) and also flows carrrying specific workloads (VoIP, gaming, and videoconferencing). In 2007, TCP was the dominant consumer of this work, and proposals were typically discussed in the Internet Congestion Control Research Group (ICCRG).  The Datagram Congestrion Copntrol Protocol (DCCP) was developed as a method for developing new congestion control algorithms for datagram traffic. Since RFC 5033 was published, many conditions have changed.  The set of protocols using these algorithms has spread beyond TCP, SCTP RFC9260, and DCCP RFC4340, to include QUIC RFC9000, RTP Media Congestion Avoidance Techniques (RMCAT) and beyond. </del> <ins> networks, cellular and WiFi wireless technologies, and long distance satellite links) and also flows carrying specific workloads (Voice over IP (VoIP), gaming, and videoconferencing). In 2007, TCP RFC9293 was the dominant consumer of this work, and proposals were typically discussed in the Internet Congestion Control Research Group (ICCRG).  The Datagram Congestion Control Protocol (DCCP) RFC4340 was developed as a method for defining new congestion control algorithms for datagram traffic. Since RFC5033 was published, many conditions have changed.  The set of protocols using these algorithms has spread beyond TCP, Stream Control Transmission Protocol (SCTP) RFC9260, and DCCP, to include QUIC RFC9000, RTP Media Congestion Avoidance Techniques (RMCAT) (e.g., RFC8836) and beyond. </ins> Some proponents of alternative congestion control algorithms now have the opportunity to test and deploy at scale without IETF review. <del> There is more interest in specialized use cases, such as data centers, and in support for a variety of upper layer protocols/ applications, e.g., real-time protocols.  Finally, the community has gained much more experience with indications of congestion beyond packet loss. </del> <ins> There is more interest in specialized use cases, such as data centers (e.g., RFC8257), and in support for a variety of upper layer protocols/applications, e.g., real-time protocols.  Finally, the community has gained much more experience with indications of congestion beyond packet loss. </ins> Multicast congestion control is a considerably less mature field of study and are not in scope for this document.  However, Section 4 of <del> the UDP Usage Guidelines RFC8085 provides additional guidelines for multicast and broadcast usage of UDP. </del> <ins> RFC8085 provides additional guidelines for multicast and broadcast usage of UDP. </ins> Congestion control algorithms have been developed outside of the IETF, including at least two that saw large scale deployment: Cubic