Subject: [dcp] draft DCP charter for discussion

From: Aaron Falk <[email-masked]>
Date: Tue, 04 Dec 2001 18:15:03 -0500

All-

Below I've enclosed a draft working group charter for a working group to
develop the DCP protocol. This charter has been agreed to by the Transport
Area Directors, the draft authors, and myself.  However, it's important to
be clear that at this moment DCP is only a BoF, it requires IESG approval
to create a working group.  

To that end we'll be discussing this charter in Salt Lake City.  The IESG
will be looking for indications from the community regarding whether this
work is considered worthwhile and whether there is a critical mass of
interested folks willing to support working group activities (e.g.,
writing, reviewing, implementing, etc). 

Comments on the drafts and charter are encouraged at this time.

--aaron

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

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

_______________________________________________
dcp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcp

---

From: Craig Partridge <[email-masked]>
Date: Tue, 04 Dec 2001 20:05:55 -0500

Well help me out here.  It seems to me that the protocol, as described,
is an oxymoron.  I.e., without a closed loop there's no flow control
and if the protocol is a true unreliable packet flow (e.g., UDP) there's
no loop.

So, I ask, is the plan for UDP with acks?  (I.e., the packet may not get
there, but if it does, the sender hears about it).  Or are we talking
something wilder?

Craig

---

From: Stephen Casner <[email-masked]>
Date: Tue, 4 Dec 2001 19:23:36 -0800 (PST)

On Tue, 4 Dec 2001, Aaron Falk wrote:

> develop the DCP protocol.
...
> formal functional requirement exploration begins.

It seems to me that there might be at least a third possible outcome
which is that the functional requirement validation leads to the
conclusion that creating a protocol at this point in the functionality
space should not be done.  I'm not saying that is the outcome to
expect, but to be intellectually honest, it should be included.

							-- Steve

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 06 Dec 2001 13:18:46 -0800

so what is the relationship between DCP and the "congestion control 
building blocks"/"congestion manager" approach that was all the rage a few 
IETFs ago?

TFRC is a cross-pointer, but it seems a lonely one...

              Harald

---

From: Mark Handley <[email-masked]>
Date: Thu, 06 Dec 2001 17:33:08 -0800

>building blocks"/"congestion manager" approach that was all the rage a few 

I think fractionally less than the relationship between TCP and CM.

You could implement TCP in such a way that it used CM.  Similarly you
could implement DCP in such a way that it used CM.  But you don't have
to in either case.

However, while TCP essentially has only one type of congestion control
feedback, DCP is more flexible - the feedback type and CC dynamics can
depend on the negotiated CCID.  Thus while you could use a CM to share
congestion state between TCP flows and/or DCP flows that use TCP-like
dynamics.  And you could use a CM to share congestion state between
DCP flows using TFRC feedback and dynamics.  But I wouldn't like to
speculate on how you'd share congestion state between a flow using
TCP-like feedback and dynamics, and one using TFRC feedback and
dynamics.

I don't think that the existence or non-existence of a CM greatly
affects the design of a protocol like DCP, although of course with
would impact the implementation.

Cheers,
	Mark