Current Meeting Report

2.8.2 Datagram Congestion Control Protocol (dccp)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 07/02/2002

Aaron Falk <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
Description of Working Group:
The Datagram Control Protocol working group is chartered to develop and standardize the Datagram Congestion Control Protocol (DCCP). DCCP 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, DCCP aims to be a general purpose protocol, minimizing the overhead of packet header size or end-node processing as much as possible. Therefore, DCCP is as simple as possible, and as far as reasonably possible, it should avoid providing higher-level transport functionality. DCCP will provide a congestion-controlled, unreliable packet stream, without TCP's reliability or in-order delivery semantics. Additional unicast, flow-based application functionality can be layered over DCCP.


Drafts for DCCP, 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 DCCP draft is declared suitable for further work, with some areas listed for possible extension.

2) The current DCCP 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 DCCP because they are difficult or impossible to layer above it. These areas include security and multi-homing/mobility, at a minimum. The protocol will be for both IPv4 and IPv6. It will not encompass multicast. It is strictly a unicast transport.

For security, the working group will endeavor to ensure that DCCP incorporates good non-cryptographic mechanisms that make it resistant to denial-of-service attacks on DCCP connections and DCCP servers. A related topic that will be explored is whether DCCP 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 DCCP's relationship with RTP (the Real-time Transport Protocol).

Once the DCCP specification has stabilized, the WG will produce a document providing guidance to potential users of DCCP. 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 DCCP.

Goals and Milestones:
SEP 02  Publish summary of required protocol functions/requirements
DEC 02  Decision to build on proposed DCCP protocol, alternate protocol, or quit and go home
APR 03  Publish DCCP protocol as proposed standard (including applicability statement)
APR 03  Publish TCP equivalent congestion profile as proposed standard
APR 03  Publish TCP Friendly Rate Control congestion profile as Proposed Standard
JUN 03  Publish document providing guidance to users of DCCP as an Informational RFC.
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Datagram Congestion Control Working Group
IETF-54, Yokohama, Japan
Monday, July 15, 2002
Aaron Falk, notes taken by Dave Plonka and Spencer Dawkins

NOTE: These minutes only summarize the contents of the slide presentations given in the meeting. Readers will find these minutes more useful if they review the presentations. Copies may be found at


Meeting agenda:

0. Agenda Bashing (falk)

1. Charter Review (falk)
homework: DCCP Charter:

2. First milestone: Is the requirements/functional summary in the problem statement complete? (floyd)
DCCP Problem Statement:

3. Significant changes in spec (kohler)
Datagram Congestion Control Protocol:

TFRC Congestion Control Profile:

TCP-like Congestion Control Profile:

4. Open Issues (kohler, summarizing from list)

5. Implementation Reports
(none as of 7/3/02)

6. Adjourn


Meeting notes:

1. Charter Review (led by Aaron Falk):

Aaron walked through the DCCP charter including the motivation, scope, deliverables, and schedule. Additionally, the mail list has been moved from to and subscribers to the old list do not need to resubscribe.


Bob Braden: Is there a reason for not publishing the requirements summary as an informational RFC.

Aaron: There was no strong feeling that the document should *not* be published. It may be submitted as an individual submission to the RFC Editor for Informational RFC publication, however.

2. Problem Statement (led by Sally Floyd):

Sally discussed the DCCP requirements, constraints, and design rationale, all covered in draft-floyd-dcp-problem-00.txt. She solicited input on whether the problem, constraints, and requirements were correct. Aaron pointed out that the schedule requires the protocol requirements discussion to be completed by September, encouraging review and discussion of Sally's doc.


Spencer Dawkins: offered to review the RUTS bof minutes for "things that people hated about TCP" as potential requirements for DCCP.

Sally: Great idea.

3. Spec Changes (led by Eddie Kohler):

Eddie reviewed document and protocol changes since the dccp bof for the core DCCP spec. The CCID 0 spec has been killed because it was more trouble than it was worth. Input was solicited on the issues of whether the connection nonce provided more or less security than the TCP pseudo-header.

He also solicited input on the following open issues:

o It was highlighted on the mail list that there is a possible DCCP name conflict for ethereal users. Eddie could not find documentation of this and recommended not making additional name changes.

o Should there be an (socket) API specified and, if so, in what document should it be captured? Also, while sockets will be used for connection setup and tear-down, are kernel upcalls desirable for other kernel-application communication.

Stuart Cheshire: encouraged the use of upcalls.

o Some concerns were raised at the DCCP bof that having sequence numbers in DCCP and RTP might result in enough excessive overhead that RTP applications wouldn't want to use DCCP. The sequence numbers are used for different reasons and in different ways (e.g., non-data packets in DCCP get sequence numbers which RTP would never see). There are two options: the baseline, with sequence numbers in both protocols, or encouraging a new version of RTP that uses the DCCP sequence numbers.

Jim Renkel: Should this question be in AVT WG instead of here? Seems to me RTP adaptation should be done by RTP folks in AVT.

Aaron: Multimedia streams represent a key application for DCCP. If the protocol has too much overhead (as perceived by the RTP users), we could be wasting our time building a protocol no one will use.

Steve Casner: There could be version of RTP for use on DCCP, but done later, as an optimization. At this point, the input from the RTP folks should just be used to be sure the right stuff is in DCCP. Also, the extra space cost should not overwhelming issue: 12-byte RTP overhead is even considered too much by some folks in AVT. I.e. this is a contentious issue.

Fred Baker: Primary issue isn't that apps are BW-sensitive, the primary issue is latency/jitter.

Aaron: DCCP focuses on unreliable, out of order delivery etc. and shouldn't introduce any latency other than due to congestion control.

Fred Baker: Congestion has many causes (not just things the kernel knows about). <something about Diffserv, RSVP and APIs>

Sally: DCCP is meant to be used by Best Effort as well as other traffic

Steve: be careful with the design of an API. RTP doesn't have one because it had to be flexible and integrate tightly with applications.

Melinda Shore: header size *does* matter. With tunneling and such, we're sending "voice headergrams." Active applications have been slow to develop, perhaps cc friendly transport is a good thing.

Mike Luby: TCP has average throughput inversely proportional to RTT. Have you looked at other transports which don't have this property.

Sally: a good research question and good for future consideration. And burden of proof for new congestion control mechanisms is on the proposers.

Mike Luby: This is the opp'y... perhaps a building block approach to be able to use other/ later CC mechanism for multimedia apps

Eddie Kohler: non TCP-like CC is going to take a long while in IETF

Aaron: CCIDs are separate drafts. To pursue this you could propose a new CCID.

Sally: Or perhaps that should be done in TSV WG, e.g. as a consideration of alternatives for TCP

Spencer: look at interactions between ROHC header compression and DCCP. E.g., RTP ROHC work.

o There have been several requested extensions to the protocol. The criteria for inclusion has been 'only if you can't efficiently provide it at a higher layer' to keep the protocol as simple as possible. Extensions which have been suggested, but not included, so far include flow multiplexing, fragmentation, and selective reliability.

Sunay Tripathy: Do you have a proposed application for these extensions? Strongly recommend keeping things simple.

Aaron: Multiplexing came out of the Salt Lake City BOF.

Eddie: Applications are prevented from sending larger-than-MTU packets (not true of UDP), because this toasts the congestion control interactions. There is diversity among draft authors on most of these extensions.

Melinda Shore: UDP fragmentation is a problem for cheap NATs which are stateless, because they donít know what to do with any fragment after the first fragment.

Eddie: This isnít going to be as big a problem unless a firewall has to look at the application payload. DCCP fragments will have full DCCP headers on each fragment, so this will work better across cheap NATs.

Colin Perkins: Fragmentation of a media stream wonít be useful because players canít play a fragment by itself anyway.

Eddie: Need more work on security aspects of fragmentation.

o Other issues that may not be fully baked, but that *are* in the current spec are quiescence, connection proof, and slow receiver. Feedback is welcome on these issues.

4. Implementation Reports (led by Eddie Kohler)

There are two known implementation efforts: one by Patrick McManus in the Linux kernel and one at Berkeley at user level (limited, does CCID 3), which may be moved into a kernel. Pointers on DCCP web page. Neither implements quiescence. (Neither implementers were in the room.)

5. Adjourn


Problem Statement for DCP
DCCP changes, open issues, and implemementations