Subject: [AVT] Datagram Control Protocol (DCP)

From: Mark Handley <[email-masked]>
Date: Mon, 16 Jul 2001 14:48:52 -0700

We've submitted a set of Internet Drafts to the ID archive on DCP,
which is a proposal for an unreliable transport protocol for unicast
traffic that integrates congestion control and connection
setup/teardown semantics.  Like TCP and UDP, DCP runs directly over
IP.  I've included the intro from the DCP spec below - the full spec
can be found at:

  http://www.aciri.org/kohler/dcp/

The reason for this mail is to act as a heads up.  We envisage that
RTP over DCP would be a fairly natural option for unicast streaming
media, although clearly there's a little overlap in functionality
between DCP and RTP (especially when it comes to sequence numbers).

Anyway, comments and suggestions would be very welcome!

Cheers,
	Mark

-------

1.  Introduction

    This document specifies the Datagram Control Protocol (DCP).  DCP
    provides the following features:

    o An unreliable flow of datagrams, with acknowledgements.

    o A reliable handshake for connection setup and teardown.

    o Reliable negotiation of options, including negotiation of a
      suitable congestion control mechanism.

    o Mechanisms allowing a server to avoid holding any state for
      unacknowledged connection attempts or already-finished
      connections.

    o An optional mechanism that allows the sender to know, with high
      reliability, which packets reached the receiver.

    o Congestion control incorporating Explicit Congestion Notification
      (ECN) and the ECN Nonce, as per [RFC 2481] and [WES01].

    o Path MTU discovery, as per [RFC 1191].

    DCP is intended for applications that require the flow-based
    semantics of TCP, but which do not want TCP's in-order delivery and
    reliability semantics, or which would like different congestion
    control dynamics than TCP.  Similarly, DCP is intended for
    applications that do not require the features of SCTP [RFC 2960]
    such as sequenced delivery within multiple streams.

    The sort of applications which could make use of 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.

    To date most such applications have used either TCP, with the
    problems described above, or used UDP and implemented their own
    congestion control mechanisms (or no congestion control at all). The
    purpose of DCP is to provide a standard way to implement congestion
    control and congestion control negotiation for such applications.
    One of the motivations for DCP is to enable the use of ECN, along
    with conformant end-to-end congestion control, for applications that
    otherwise would be using UDP.  In addition, DCP implements reliable
    connection setup, teardown, and feature negotiation.

    A DCP connection contains acknowledgement traffic as well as data
    traffic.  Acknowledgements inform a sender whether its packets
    arrived, and whether they were ECN marked. Acks are transmitted as
    reliably as the congestion control mechanism in use requires,
    possibly up to completely reliably.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Michael Thomas <[email-masked]>
Date: Sat, 21 Jul 2001 09:20:31 -0700 (PDT)

> between DCP and RTP (especially when it comes to sequence numbers).

Mark,

Are you aware of the "unreliable" SCTP work? If
so, how does it differ since SCTP seems to fit the
criteria you list above?

	     Mike