[ih] Why did DCCP fail to gain traction?

[Lars Eggert]

Roland’s recollection matches mine (used to be a chair of DCCP ~2006)

> On 5. Oct 2026, at 12:29, Bless, Roland (TM) via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Hi,
> 
> my perception was that at the time DCCP was designed,
> there was a fear that especially an increasing amount of
> multimedia streams may cause congestion problems and
> it would be better to to solve them in a single protocol
> rather than letting the application developers do it
> "somehow" (and maybe neglecting ECN support etc.).
> See also the section 2 of RFC4340
> https://datatracker.ietf.org/doc/html/rfc4340#section-2
> 
> However, given the development of WebRTC and DASH,
> people used rather their own application-specific
> congestion control mechanisms instead. For example,
> WebRTC used more fine-grained RTCP-based feedback
> (see also RFC8888) and there were other approaches
> developed in the (concluded) RMCAT WG
> (https://datatracker.ietf.org/wg/rmcat/about/) as well
> such as NADA (RFC8698) and SCReAM (RFC8298).
> 
> The reasons why DCCP had seen no real deployment are
> probably manifold, but I guess that NAT/FW traversal
> for DCCP as well as the easier development and change
> process in the user space contributed to this
> (as others noted, this also helped QUIC development and
> was a deliberate design choice).
> 
> FWIW, there has been recent work in the IETF on Multipath-DCCP
> https://datatracker.ietf.org/doc/rfc9897/
> to support a special use case for providing an MP-DCCP proxy
> inside a provider network. The idea was to also support
> QUIC and other UDP-based protocols.
> 
> So I disagree that QUIC development hindered DCCP
> deployment already,
> the work on Media over QUIC (MOQ) started only 2022.
> 
> Regards,
> Roland
> 
> On 03.10.26 at 18:26 John Kristoff via Internet-history 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.
> -- 
> 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: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20261007/7733c575/attachment.asc>