Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, dccp mailing list <firstname.lastname@example.org>, dccp chair <email@example.com> Subject: Protocol Action: 'Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control' to Proposed Standard The IESG has approved the following documents: - 'Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control ' <draft-ietf-dccp-ccid2-11.txt> as a Proposed Standard - 'Profile for DCCP Congestion Control ID 3:TFRC Congestion Control ' <draft-ietf-dccp-ccid3-12.txt> as a Proposed Standard These documents are products of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Allison Mankin and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-ccid2-11.txt
* Technical Summary The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data, but can benefit from control over the tradeoff between timeliness and reliability. TCP is not well-suited for these applications, since reliable in-order delivery and congestion control can cause arbitrarily long delays. UDP avoids long delays, but UDP applications that implement congestion control must do so on their own. DCCP provides built-in congestion control, including ECN support, for unreliable datagram flows, avoiding the arbitrary delays associated with TCP. It also implements mechanisms for reporting loss, reliable connection setup, teardown, and feature negotiation. The congestion control mechanisms are defined in Congestion Control Profile documents, known as CCIDs. The profile for Congestion Control Identifier 2, TCP-like Congestion Control, should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. The profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. * Working Group Summary The working group reached strong consensus on CCID 2 and 3, following a very detailed review of both. * Protocol Quality The mid-development review of DCCP, described in the DCCP writeup, considered the CCIDs as well. New CCID development for applications not suited by these have begun in the working group. Implementation and deployment experience with DCCP congestion control profiles are encouraged by the Transport Area. The reviewer for the IESG was Allison Mankin. The WG Chair shepherd was Aaron Falk.