Datagram Control Protocol BOF (dcp) Tuesday, December 11 at 1700-1800 ================================== CHAIR: Aaron Falk 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