DCTCP
/ DEE-see-TEE-see-PEE /
Classic TCP learns the road is congested only by crashing — it speeds up until a packet is lost (an overflowing buffer drops it), then sharply backs off. That works on the wide-area Internet, but in a datacenter, where you want microsecond-scale latency, waiting for a buffer to actually overflow before reacting fills queues, adds delay, and causes the incast collapses described elsewhere. DCTCP is a congestion control that instead reads early warning signs and slows down gently and proportionally, before the buffer ever spills — like easing off the gas when traffic starts to thicken rather than waiting to rear-end the car ahead.
Concretely, DCTCP (Data Center TCP) relies on Explicit Congestion Notification (ECN). Switches are configured to mark passing packets with an ECN flag as soon as the queue length crosses a low threshold — not when the buffer is full, but when it merely starts to build. The receiver echoes these marks back. Here is the key difference from classic TCP: ordinary TCP treats a single congestion signal as 'cut my window in half,' but DCTCP estimates the FRACTION of packets that were marked over a window and reduces its sending rate in proportion to that fraction. A little congestion means a small reduction; heavy congestion means a large one. The result is that senders settle at a rate that keeps switch queues short and stable, so latency stays low and there is buffer headroom to absorb bursts.
Why it matters: DCTCP (from a 2010 paper) became the template for modern datacenter transports because it directly targets the metrics that matter inside a building — low and predictable latency, short queues, and resistance to incast — rather than just maximizing bulk throughput. Honest caveats: DCTCP needs ECN-capable switches and a consistent low marking threshold across the fabric, so it is a within-datacenter protocol, not something to run across the public Internet; and because it reacts so differently to congestion, DCTCP does not share a bottleneck fairly with classic loss-based TCP, so the two should not be mixed on the same path. It is one of a family of latency-focused datacenter congestion controls, with later schemes (like ones using precise per-packet delay or in-network signals) pushing the idea further.
A switch is set to mark ECN once its queue passes 60 packets. Under light load few packets are marked, so DCTCP senders barely slow. As several flows ramp up and the queue grows, the fraction of marked packets rises, and each sender trims its rate proportionally — so the queue stabilizes at a short length instead of overflowing, keeping latency low.
React to the fraction of ECN marks, not to a single loss.
DCTCP is a datacenter-only protocol: it assumes ECN-marking switches with a low, consistent threshold, and it does not coexist fairly with classic loss-based TCP on a shared bottleneck. Do not run it across the public Internet.