Overview
This series explains how UCCL-Tran separates GPU payload movement from transport policy in large ML clusters. It traces the RDMA and GPUDirect boundary, diagnoses flow collisions, incast, loss, and NIC heterogeneity, then follows multipath, receiver-driven control, selective recovery, and application results. The evidence supports a conditional case: software control helps when workload-specific mismatches exist and CPU, signals, topology, and direct GPU-memory access can support it; it is not a universal hardware replacement.
Learning outcomes
- UCCL-Tran moves selected transport decisions—path choice, congestion response, and recovery—into software while keeping bulk GPU data movement on the NIC/GPU path.
- Its strongest gains occur when coordinated ML traffic collides on paths, converges on hot receivers, or suffers costly recovery; more bandwidth alone does not remove those mismatches.
- UC offers a useful offload and control balance; RC is a compromise, while UD and SRD expose more control at the cost of packetization, reassembly, or integration work.
- Reported speedups depend on topology, NIC, workload, CPU budget, signals, and direct GPU-memory access; same-rack results show near-parity when the targeted mismatch is absent.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What does UCCL-Tran move from hardware into software?
UCCL-Tran moves selected transport policies—path selection, congestion control, and loss recovery—into software, while the NIC and GPU continue to move and process bulk payloads. The exact division depends on RC, UC, UD, or SRD capabilities.
When does UCCL-Tran outperform a hardware transport?
UCCL-Tran is most likely to outperform when ML traffic creates path collisions, receiver incast, costly retransmission, or connection pressure that the fixed hardware policy handles poorly. Reported gains depend on the tested topology, NIC, message pattern, and CPU budget.
Does UCCL-Tran require the CPU to carry GPU payloads?
No. With a direct GPU-memory path such as GPUDirect RDMA, the CPU handles work requests, control metadata, and transport state while the NIC moves payloads between the network and GPU memory. UD or non-RDMA paths can add packetization or copying costs.
How should UCCL-Tran's reported speedups be interpreted?
They should be read as conditional results, not a universal ranking: the largest gains address specific collisions, incast, or hardware boundaries, while same-rack tests without those mismatches are close to hardware transport. Application results are smaller and workload-specific.