Proposed congestion control mechanisms should include a clear explanation of the deviations from RFC2914. <del> Impact on Standard TCP, SCTP RFC2960, and DCCP RFC4340. </del> <ins> Impact on existing deployments of TCP RFC9293, SCTP RFC9260, DCCP RFC4340, and QUIC RFC9000. </ins> Proposed congestion control mechanisms should be evaluated when <del> 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. </del> <ins> competing with standard IETF congestion control RFC5681, RFC9260, RFC4340, RFC9002, RFC9438.  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.  The community should also consider other non-standard congestion controls known to be widely deployed, We note that this bullet is not a requirement for strict Reno- or Cubic- 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. When a new algorithm is deployed, the existing major deployments need to be considered to avoid severe performance degradation.  We also note that this guideline does not constrain the interaction with non-best-effort traffic. </ins> As an example from an Experimental RFC, fairness with standard TCP 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. <ins> Wireless links While the early Internet was dominated by wired links, the properties of wireless links have become extremely important to Internet performance.  In particular, congestion controllers should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. </ins> Difficult Environments. The proposed algorithms should be assessed in difficult <del> 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. </del> <ins> environments.  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. </ins> While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with