[ih] Why did DCCP fail to gain traction?

[Brian E Carpenter]

> so it doesn't need kernel support

I don't think everbody realises how critical that is. Getting updated user-space
code deployed is a solved problem. Getting a kernel update deployed is very hard
work that needs earthquake-sized incentives applying to a few major corporations,
several open-source communities, and all operators.

As far as I can tell, DCCP was never implemented in any commercial operating
system kernel. Effectively, it was DOA.

As an example, IPv6 availability to Google clients only started hitting 50%
peaks in July 2026 (32 years after the original IPv6 announcement).

I believe that QUIC was carefully conceived to avoid this trap.

Regards/Ngā mihi
    Brian Carpenter

On 04-Oct-26 13:56, John Levine via Internet-history wrote:
> It appears that Jack Haverty via Internet-history <jack at 3kitty.org> said:
>> The question for the research community was "How do you build a
>> multi-vendor global communications system that can evolve with new
>> protocols, algorithms, and techniques, and removal of the old technology
>> that are to be replaced?"
> 
> Dunno about removal of the old stuff but QUIC is a good example of how
> protocols evolve. HTTP version 1 and 2 ran over TCP, http/3 runs over
> QUIC which is built on UDP so it doesn't need kernel support, with all
> the multiplexing and flow control in the application. They added a new
> HTTPS DNS record that browsers can query to see if a site has http/3
> support. Wikipedia says that Chrome, Edge, Firefox, and Safari have
> all supported http/3 and QUIC for several years, and about 40% of
> Google's and Facebook's web traffic now runs over QUIC.
> 
> The popular open source web server NGINX has QUIC support, which it appears
> you can enable with a one or two line configuration change.
> 
> I don't think the earlier versions of http will ever go away, but given
> that a megabyte is a rounding error in application code sizes these days
> I don't see that as much of a problem.
> 
> R's,
> John