RE: [dccp] Protocol Action: 'Datagram Congestion Control Protocol(DCCP)' to Proposed Standard

["Phelan, Tom" <tphelan at sonusnet.com>]

Hi Eddie,

Yes, and now all we have to do is get it through the RFC editor :-).

Tom P.

> -----Original Message-----
> From: dccp-bounces at ietf.org [mailto:dccp-bounces at ietf.org]On Behalf Of
> Eddie Kohler
> Sent: Wednesday, August 03, 2005 5:21 PM
> To: 'dccp' working group
> Cc: Aaron Falk ((E-mail)); Sally Floyd; Mark Handley; Allison Mankin
> (E-mail)
> Subject: Re: [dccp] Protocol Action: 'Datagram Congestion Control
> Protocol(DCCP)' to Proposed Standard 
> 
> 
> Yeah!!!!!!!!!!!!!  Thanks all so much!!!!
> 
> Eddie
> 
> 
> On Aug 3, 2005, at 7:13 AM, The IESG wrote:
> 
> > 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.
> >
> >
> >
> 
> 
>