Datagram Control Protocol BOF (dcp)

Tuesday, December 11 at 1700-1800
==================================

CHAIR:	Aaron Falk <a.falk@ieee.org>


AGENDA:

1. Formulation of requirements to be met by DCP
     a. starting from draft-kohler-dcp-00.txt
     b. users of a DCP
          streaming and interactive media needing 
          congestion control


          security services needing high DoS resistance?


          other lockstep services?


2. Possible charter


3. Sense of room about forming WG


BOF Description:
This is a discussion of the possible reasons for bringing
into existence a Datagram Control Protocol, one which
is intended for applications that require the connection
semantics of TCP and SCTP (with SCTP's anti-DoS features)
and need specialized congestion control,
but which do not want TCP's in-order delivery and
reliability semantics.


The sort of applications which could make use of a DCP are those which
have timing constraints on the delivery of data, such that reliable
in-order delivery, when combined with congestion control, is likely
to result in some information arriving at the receiver after it is
no longer of use.  Such applications might include streaming media
and Internet telephony.  Security related issues might also
define the user of a DCP service.


Mailing list:  dcp@ietf.org
To subscribe:  http://www.ietf.org/mailman/listinfo/dcp
Archive:       http://www.ietf.org/mailman/listinfo/dcp


===========================


DRAFT CHARTER: The Datagram Control Protocol (DCP)


The Datagram Control Protocol working group is chartered to develop
and standardize the Datagram Control Protocol (DCP).  DCP is a minimal
general purpose transport-layer protocol providing only two core
functions:


 - the establishment, maintenance and teardown of an unreliable packet
   flow.


 - congestion control of that packet flow.


Within the constraints of providing these core functions, DCP aims
to be a general purpose protocol, minimizing the overhead of packet
header size or end-node processing as much as possible.  Therefore,
DCP is as simple as possible, and as far as reasonably possible,
it should avoid providing higher-level transport functionality.
DCP will provide an congestion-controlled, unreliable packet stream,
without TCP's reliability or in-order delivery semantics.  Additional
unicast, flow-based application functionality can be layered over
DCP.




SCOPE


Drafts for DCP, and several associated congestion control IDs, already
exist.  The first task before the working group will be an abbreviated
functional requirement validation of those drafts.  There are two
possible outcomes: (1) The current DCP draft is declared suitable for
further work, with some areas listed for possible extension.  (2) The
current DCP draft is declared unsuitable for further work, and more
formal functional requirement exploration begins.


Prior to the final development of the protocol, the working group will
investigate areas of functionality that should be integrated into DCP
because they are difficult or impossible to layer above it.  These
areas include security and multi-homing/mobility, at a minimum.


For security, the working group will endeavor to ensure that DCP
incorporates good non-cryptographic mechanisms that make it
resistant to denial-of-service attacks on DCP connections and DCP
servers.  A related topic that will be explored is whether DCP can
be a candidate to replace UDP in the transport of security management
protocols such as IKE and JFK.


The working group will also investigate DCP's relationship with
RTP (the Real-time Transport Protocol).


Once the DCP specification has stabilized, the WG will produce a
document providing guidance to potential users of DCP.  The precise
form of this document will be determined by WG discussion, but it
might include example APIs, an applicability statement, or other forms
of guidance about appropriate usage of DCP.


WORKING GROUP MILESTONES


* Publish summary of required protocol functions/requirements


* Decision to build on proposed DCP protocol, alternate protocol, or
  quit and go home


* Publish DCP protocol as proposed standard


* Publish document providing guidance to users of DCP.


* Publish congestion profiles (as proposed standard) for canonical
  cases of:


  a) one initial window's worth of data


  b) TCP equivalent


  c) TCP Friendly Rate Control