Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard

["Joel M. Halpern" <[e-mail]>]

For peoples information, DCCP is now approved for publication as a PS.

Yours,
Joel

>From: The IESG <[e-mail]>
>To: IETF-Announce <[e-mail]>
>Date: Wed, 03 Aug 2005 10:13:54 -0400
>Subject: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to 
>Proposed Standard
>
>The IESG has approved the following document:
>
>- 'Datagram Congestion Control Protocol (DCCP) '
>    <draft-ietf-dccp-spec-11.txt> as a Proposed Standard
>
>This document is the product of the Datagram Congestion Control Protocol
>Working Group.
>
>The IESG contact persons are Allison Mankin and Jon Peterson.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-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.
>
>Â  Â  Â  Â  *Â  Â  Working Group Summary
>
>There is a strong working group consensus to develop this protocol.
>The applicability of DCCP to interactive real-time multimedia flows has
>been somewhat controversial in the working group.  The DCCP protocol
>specification has been developed with just two initial congestion control
>profiles, companions to this publication, draft-ietf-dccp-ccid2, and
>draft-ietf-dccp-ccid3.  However, the modular nature of the protocol
>enables the core specification to be completed while work proceeds
>on congestion control profiles for interactive real-time applications.
>There is clear and strong support for applying DCCP to non-realtime
>streaming and growing interest in other applications as well.
>
>
>Â  Â  Â  Â  *Â  Â  Protocol Quality
>
>DCCP has received extensive transport and cross-disciplinary review.
>Written "expert reviews" were conducted by Eric Rescorla (a security
>expert), Magnus Westerlund (a multimedia expert and AVT wg chair), and
>Greg Minshall (a TCP expert), generating many detailed comments and
>substantive improvements in the protocol.  The expert review was
>followed by a working group "design review" at IETF-57 where the
>working group and invited experts -- Magnus Westerlund (multimedia),
>Steve Bellovin (security), and Rob Austein (architecture) -- walked
>through the spec in detail resulting in additional comments and
>substantive changes.  Additionally, formal modeling was performed
>showing that DCCP is deadlock-free.  The protocol is as mature as is
>possible without significant implementation experience.  The three
>known implementations were started early in the life of the
>specification and one (from ICIR) resulted in some relatively major
>changes to the spec.  Recently, it has become known that Kame FreeBSD
>contains an implementation of DCCP, albeit not matching the final
>version of the spec.  It is expected that feedback from implementors
>and users will result in further improvements and revisions.
>
>The IESG review of the specification was done by Allison Mankin.
>The WG Chair shepherd was Aaron Falk.
>
>
>_______________________________________________
>IETF-Announce mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ietf-announce