Understanding the algorithms is necessary but not sufficient. You need a decision framework. The right algorithm depends on your hardware, your workload, and your operational constraints.

Decision framework for practitioners

You are running NVIDIA ConnectX-7 + Spectrum-X. → Use DCQCN. It is built in, hardware-accelerated, and parameterised for exactly this fabric. Tune dcqcn_rl_ai, dcqcn_bc, ECN thresholds, and CNP DSCP. Do not attempt to run a non-native CC scheme.

You are evaluating new fabric hardware (2025+) and need to choose. → Evaluate UEC CC if your NIC vendor supports it (AMD Pensando Salina, future NVIDIA). UEC CC's 1-RTT feedback loop is a strict improvement over DCQCN's 2-RTT loop. If your switch fabric will be NPM-capable, the advantage amplifies further.

You have INT-capable switches (P4/Tofino, Broadcom Trident 4 with INT) at scale. → HPCC is worth the engineering investment. The multi-hop precision eliminates the ECN threshold tuning problem entirely. The 80-byte INT overhead is acceptable at 64 KB+ message sizes (which AI collectives use).

You are operating commodity TCP flows in a multi-rack environment (not RDMA). → TIMELY is viable if baseline RTT is >= 20 µs. It requires no switch configuration, no ECN trust setup, and works on any NIC that supports software timestamps.

You need to maximise BW at modest scale (32–256 GPUs) with minimal tuning. → Swift is theoretically optimal under incast. But without hardware NIC support, you will need to accept either a DCQCN approximation (ConnectX-7) or custom RDMA software.

The universal truth about CC algorithm selection

Every algorithm comparison eventually boils down to: how fast does the sender learn that a queue is building, and how precisely can it respond?

Signal latency:  DCQCN: 2 RTT  |  Swift: 1 RTT  |  HPCC: 1 RTT  |  UEC: 1 RTT
Signal precision: DCQCN: path   |  Swift: path    |  HPCC: per-hop |  UEC: path+hint
Hardware req:    DCQCN: CX7+Sp4 | Swift: custom   |  HPCC: INT     |  UEC: Pollara/future