[ih] Why did DCCP fail to gain traction?

[Jack Haverty]

In addition to technical issues, I think there was another reason for 
"failing to gain traction".  It comes down to management, or lack 
thereof, of new technology in an evolving infrastructure service.

Personally, I'm just one of billions of users of the Internet now.  But 
I was pretty heavily involved in the technology during the early years.  
  Today, my home LAN is an eclectic mix of devices, all on the 
Internet.  There are desktops and servers, running Windows, IOS, or 
Ubuntu.   There are phones, tablets, both Android and Apple systems, and 
even a few Raspberry Pis.   Several irrigation controllers and other 
home automation stuff.  Probably a bunch of things I've forgotten.  Even 
the fan in my attic is on the Internet.

I have no idea whether or not any of those devices use, or even are 
capable of using, DCCP.  DCCP is not alone - As just a user, I haven't 
heard about SCTP either, or many of the other technology that the IETF 
has documented in RFCs and placed "on the shelf" for anyone to use.  
I've heard a little about QUIC, but don't know how to tell if any of my 
devices can or do use it.  Or why they should.  I suspect most of the 
billions of Users have similar experiences.

Looking outward, I see lots of ads for new devices to attach to my LAN.  
But I can't recall ever seeing any ad that highlighted some product as 
"Supports DCCP!!".   Or "QUIC!", or "SCTP!", or even "IPv6!".  
  Companies traditionally tout the benefits of their products over the 
competition, and implement the features that their customers demand.  
For some reason that doesn't seem to happen for Internet technology.

Back in 1983, a major effort was involved to transition the existing 
ARPANET from its old technology (called NCP) to the new TCP mechanisms.  
That was accomplished on January 1, 1983, after several years of 
planning and preparing.  After that date, TCP was used everywhere, and 
NCP was no longer present anywhere.

Afterwards, we realized that such transitions were a lot of work, and 
that particular transition was greatly aided by the fact that the entire 
Internet at the time was owned and managed by a combination of ARPA and 
DCA, i.e., part of the US Department of Defense.   They were definitely 
"in charge."

We also realized that such a scheme wouldn't have the same advantage as 
the Internet grew and many more players got involved.  No one would be 
"in charge" and have the ability to orchestrate the introduction of new 
technology, as well as the removal of the older technology which it 
replaced.  Without both steps, the technical machinery would just get 
more and more complex and difficult to operate.

But no one in 1983 knew how to do that for the Internet.  It was 
possible that some lessons could be learned from the experience of the 
telephony system, which had pretty much succeeded at creating a 
multi-vendor and global voice service.   But the topic was still viewed 
as a research area, likely involving considerable research and trial and 
error to find some techniques that would work to not only introduce some 
new technology, but also to remove any old technology that was no longer 
appropriate.

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?"

As far as I can tell, that hasn't been answered yet.   It's been more 
than 40 years.  Maybe it's just not possible?

/Jack Haverty


On 10/3/26 09:46, Thomas Fossati via Internet-history wrote:
> On Sat, Oct 3, 2026 at 6:26 PM John Kristoff via Internet-history
> <internet-history at elists.isoc.org> wrote:
>> DCCP (IETF RFC 4330) is/was a relatively new transport in Internet
>> history. I don't think it ever really saw much, if any, deployment or
>> support in applications. It was removed from the Linux kernel last year.
>>
>> Was it too late, too complex, too little, or just deemed unnecessary
>> given available alternatives such as QUIC?  I don't recall seeing
>> much discussion about why it failed to gain traction and I'm interested
>> to hear what the collective wisdom of this group might have to say about
>> that.
> It failed because of an abundance of middleboxes and a lack of APIs.
> Unlike SCTP (which is similarly affected by middleboxes), it never
> found a niche where it could be safely deployed.
> Then came QUIC, which made it completely redundant.
>
> That's my rough understanding of the situation.
>
> cheers!
>
>> John
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20261003/cd6cbda8/attachment-0001.asc>