Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
draft-ietf-dccp-ccid3-11

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    dccp mailing list <dccp@ietf.org>, 
    dccp chair <dccp-chairs@tools.ietf.org>
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

Ballot Text

        *    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.

RFC Editor Note