DCCP(Datagram Congestion Control Protocol)
- message-oriented
- transport layer protocol
Adopted from RFC 4340
Design Rationale(設計原理
One DCCP design goal was to give most streaming UDP applications
little reason not to switch to DCCP, once it is deployed.
DCCP 其中一個設計目標就是讓大多數使用UDP協定的應用程式，在DCCO建置抵定後，都沒有理由不採用之。
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.
為了達成此目標，設計DCCP協定時便考量了如何儘可能地減少封包表頭大小、狀態數目和終端主機的CPU荷負。
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.
