DCCP: Datagram Congestion Control Protocol

DCCP solved the right problem at the wrong time.

The Internet's transport layer offers two choices: TCP, which guarantees delivery but makes you wait, or UDP, which delivers instantly but doesn't care if packets drown the network. For streaming video, live gaming, and voice calls—applications where late data is worthless data—neither option fits. TCP's insistence on retransmitting lost packets creates stuttering delays. UDP's indifference to congestion makes applications that use it bad neighbors, flooding networks without restraint.

DCCP was supposed to be the third way: unreliable delivery with built-in congestion control. Send packets without waiting for acknowledgments, but back off when the network gets congested. Fast and polite. The IETF standardized it in 2006. Then almost nobody used it.

The Problem DCCP Addressed

TCP has a behavior called head-of-line blocking. When a packet goes missing, TCP stops delivering everything behind it until that packet is retransmitted and received. For a file download, this makes perfect sense—you want the complete file. For a video call, it's absurd. You're staring at a frozen frame from two seconds ago while TCP heroically retrieves data you no longer need.

UDP avoids this by simply not caring. Packets arrive when they arrive; lost packets stay lost. Applications get data immediately. But UDP provides no congestion control whatsoever. An application can blast packets as fast as it wants, regardless of network conditions. When everyone does this, networks collapse.

The responsible solution was for applications to implement their own congestion control over UDP. Most didn't. Those that did often got it wrong. The Internet needed a protocol that handled congestion control correctly by default while still providing the low-latency, unreliable delivery that streaming applications required.

What DCCP Actually Does

DCCP is a connection-oriented protocol, like TCP, but with fundamentally different guarantees. It establishes connections, tracks sequence numbers, and sends acknowledgments. But those acknowledgments don't trigger retransmissions—they measure network conditions. When DCCP sees packets disappearing, it interprets this as congestion and reduces its sending rate.

The protocol offers pluggable congestion control algorithms called CCIDs (Congestion Control IDs). Applications can choose TCP-like behavior, TCP-friendly rate control, or other mechanisms depending on their needs. This flexibility was part of DCCP's appeal: a streaming application could select congestion control tuned for its traffic patterns rather than accepting TCP's one-size-fits-all approach.

Applications receive whatever data makes it through and process it immediately. Missing packets are the application's problem to handle—perhaps by interpolating video frames or concealing audio gaps. The protocol's job is ensuring the application doesn't overwhelm the network, not ensuring perfect delivery.

Why DCCP Failed

DCCP was a well-mannered guest who arrived after everyone had already learned to bring their own wine.

The first problem was middleboxes. Firewalls, NAT devices, and load balancers had spent years learning to handle TCP and UDP. They knew nothing about DCCP. Many blocked it outright. Others mangled it. Deploying a new transport protocol meant convincing every piece of network equipment between sender and receiver to let it through—a coordination problem with no coordinator.

The second problem was operating system support. Linux had DCCP in the kernel, but often as an optional module that wasn't loaded by default. Windows support was minimal. macOS support was essentially nonexistent. Application developers couldn't assume DCCP would be available on their users' machines.

The third problem was circular: applications wouldn't use DCCP because it wasn't widely supported, and vendors wouldn't support it because no applications used it. DCCP starved in a room full of locked refrigerators.

By the time anyone might have broken this cycle, the window had closed. Streaming services had built sophisticated congestion control into their applications, running over plain UDP. The problem DCCP solved was still real, but the solution had moved elsewhere.

What Won Instead

QUIC, now the foundation of HTTP/3, solved many of the same problems DCCP addressed—and succeeded where DCCP failed. The key difference: QUIC runs on top of UDP rather than alongside it.

This architectural choice proved decisive. Every firewall, NAT device, and load balancer already knew how to handle UDP. QUIC packets looked like ordinary UDP traffic to network equipment, passing through infrastructure that would have blocked DCCP. Instead of asking the network to learn a new protocol, QUIC worked within existing constraints.

QUIC implements congestion control, avoids head-of-line blocking through multiple streams, and includes encryption by default. It provides similar benefits to DCCP—congestion-aware, low-latency delivery—while being deployable on the actual Internet rather than an idealized one.

WebRTC took a similar approach for real-time communication, implementing congestion control in JavaScript running in browsers. The solutions were messier than a clean transport protocol would have been, duplicating functionality that belonged in the transport layer. But they worked, and DCCP didn't.

The Lesson

DCCP was technically sound. It addressed a real problem with a well-designed solution. The IETF standardized it properly. Implementations existed. None of this mattered.

The Internet is not a clean slate. New protocols must navigate decades of accumulated infrastructure, each piece with its own assumptions and limitations. DCCP asked the network to change. QUIC accepted the network as it was and worked around it.

Sometimes the elegant solution loses to the pragmatic one. DCCP belongs to a category of protocols that solved problems the Internet eventually solved differently—not because they were wrong, but because being right wasn't enough.