Section 2. Design Rationale

One DCCP design goal was to give most streaming UDP applications
   little reason not to switch to DCCP, once it is deployed.  To
   facilitate this, DCCP was designed to have as little overhead as
   possible, both in terms of the packet header size and in terms of the
   state and CPU overhead required at end hosts.  Only the minimal
   necessary functionality was included in DCCP, leaving other
   functionality, such as forward error correction (FEC), semi-
   reliability, and multiple streams, to be layered on top of DCCP as
   desired.
   Different forms of conformant congestion control are appropriate for
   different applications.  For example, on-line games might want to
   make quick use of any available bandwidth, while streaming media
   might trade off this responsiveness for a steadier, less bursty rate.
   (Sudden rate changes can cause unacceptable UI glitches such as
   audible pauses or clicks in the playout stream.)  DCCP thus allows
   applications to choose from a set of congestion control mechanisms.
   One alternative, TCP-like Congestion Control, halves the congestion
   window in response to a packet drop or mark, as in TCP.  Applications
   using this congestion control mechanism will respond quickly to
   changes in available bandwidth, but must tolerate the abrupt changes
   in congestion window typical of TCP.  A second alternative, TCP-
   Friendly Rate Control (TFRC) [RFC3448], a form of equation-based
   congestion control, minimizes abrupt changes in the sending rate
   while maintaining longer-term fairness with TCP.  Other alternatives
   can be added as future congestion control mechanisms are
   standardized.
   DCCP also lets unreliable traffic safely use ECN.  A UDP kernel
   Application Programming Interface (API) might not allow applications
   to set UDP packets as ECN capable, since the API could not guarantee
   that the application would properly detect or respond to congestion.
   DCCP kernel APIs will have no such issues, since DCCP implements
   congestion control itself.
   We chose not to require the use of the Congestion Manager [RFC3124],
   which allows multiple concurrent streams between the same sender and
   receiver to share congestion control.  The current Congestion Manager
   can only be used by applications that have their own end-to-end
   feedback about packet losses, but this is not the case for many of
   the applications currently using UDP.  In addition, the current
   Congestion Manager does not easily support multiple congestion
   control mechanisms or mechanisms where the state about past packet
   drops or marks is maintained at the receiver rather than the sender.
   DCCP should be able to make use of CM where desired by the
   application, but we do not see any benefit in making the deployment
   of DCCP contingent on the deployment of CM itself.
   We intend for DCCP's protocol mechanisms, which are described in this
   document, to suit any application desiring unicast congestion-
   controlled streams of unreliable datagrams.  However, the congestion
   control mechanisms currently approved for use with DCCP, which are
   described in separate Congestion Control ID Profiles [RFC4341,
   RFC4342], may cause problems for some applications, including high-
   bandwidth interactive video.  These applications should be able to
   use DCCP once suitable Congestion Control ID Profiles are
   standardized.