[ih] Why did DCCP fail to gain traction?

[Bless, Roland (TM)]

Hi Lars and all,

thanks for the confirmation of my assessment.

One additional reason I forgot in my previous mail:
many multimedia streams often do not scale continuously
and linearly in throughput, but rather in discrete steps
of corresponding different quality levels. Therefore, it
is often quite application-specific (and/or codec-specific)
how a multimedia stream sender (or receiver) reacts to
congestion. Moreover, although DCCP offered the
possibility of defining and using different congestion
control algorithms, it probably did not reduce
the app developer burden because one has to
implement this scaling logic/behavior anyway
at the application layer; using DCCP underneath
would rather only complicate things with its
own congestion control loop...

Moreover, streaming of stored media mainly uses
HTTP (also due to the benefit of being
able to reuse the existing caching/CDN infrastructure)
and DASH is more receiver-controlled and thus
quite different to the DCCP model.

Regards,
  Roland

On 07.10.26 at 10:49 Lars Eggert wrote:
> 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
>