Code change:
I think this is the tip of a larger iceberg, and I'd suggest we'd need to go deeper, if the IETF now thinks they may produce specs in this space. As I recall (others may add to the list), there are challenges to be considered by a proponent/IETF, which include: 1. Does the proposal rely on technologies specified by other Forums/SDOs? 2. Does the IETF have sufficient experience of the DC requirements and to review the proposals? 3. Does the proposal include experience of interoperability between different implementations? or a plan for this? 4. Does the DC traffic share resources with Internet traffic? 5. Specifically: does the method to be used between DCs or only within DCs? - How is this usage scoped? And what happens when the protocol is bridged across an Internet path? One or more of these has in the past thwarted progress towards adoption in the IETF, can we say something about this?
Do you want to take a shot at it? Do we need a completely different section about DC algorithms?
OK, it might be good to keep some version of this as a guidance for evaluating general-purpose protocols in datacenters, AND have a totally different section for DC-specific algorithms.
From IETF 119: Data centers with really small RTTs should be discussed as a special case
NAME We need to be specific about what we mean by datacenter (e.g. Hadoop queries), please give some details about the data center scenarios that we want to take into account NAME Typically you see proposals that rely on the fabric doing non-internet-y things, often there's combined implementation with the data plane, so we need to be specific there. Also saw some presentations this week about non-ethernet fabrics, need to describe what you see from your fabric and what you can then do from a congestion control perspective. NAME Some spillover from IPPM, doesn't work on public internet and not intended to. Number of things being deployed today, massive clusters, 100,000 endpoints constantly talking to each other. Special congestion controllers are very much needed. Trying to keep CPU/GPU non-idle all the time. We need something that is fast within 1-2 RTTs, doesn't matter if done on endpoints, NICs, switches.
There are sets of specific network characteristics; some of this relies on non-IETF specs and it would help to know the interop requirements between implementations and also what the coexistence requirements are for other flows.
Approving this text - LGTM, I propose to move the additional context on data centres to a separate issue, and resolve in a small separate PR against Section 2 & 3.

Related discussion:
text: writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. <ins> 5.9. Data centers are characterized by very low latencies (< 2 ms).  Many workloads involve bursty traffic where many nodes complete a task at the same time.  As a controlled environment, data centers often deploy fabrics that employ rich signalling from switches to endpoints.  Furthermore, the operator can often limit the number of operating congestion controls. For these reasons, data center congestion controls are often distinct from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 6. This document does not represent a change to any aspect of the TCP/IP