Current Meeting Report
Jabber Logs

2.8.3 Datagram Congestion Control Protocol (dccp)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. 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 Protocol (dccp)
Thursday, November 21 at 0900-1130

CHAIR: Aaron Falk <>
Notes: Spencer Dawkins 


0. Agenda Bashing -  Aaron Falk

1. Working Group Status - Aaron Falk

2. Discussion of changes to DCCP protocol spec -  Mark Handley

3. Should we continue down the path of the current DCCP protocol spec?  
open discussion, moderator: Aaron Falk

4. A few words on the relationship between TFRC and DCCP - Sally Floyd

5. Discussion of initial draft of DCCP User Doc - Damon Lanphear

6. Implementation Reports

7. Other Issues

8. Close


0. Agenda Bashing -  Aaron Falk

  No changes noted.


1. Working Group Status -- Aaron Falk

  We've WG last-called the problem statement, revved the protocol spec, and 
published a first-draft user's guide.

  We're humming directions on the protocol spec today.  The mailing list has 
been quiet - too quiet.  Are people following the work?

Comment: The authors have not published what they where doing and what 
changes they where performing to the mailing list.

  Where are the implementations? There are implementations, but they are 
implementations of earlier drafts (the spec has changed) and haven't been 
tested against each other.  Are they being maintained?


2. Discussion of changes to DCCP protocol spec -- Mark Handley

  Quite a few changes since Yokohama - rewrite of Challenge, change of 
Reset format, "buffer closed" signaling.  TCP-friendliness isn't an 
explicit goal any more - the focus is on "IETF-standardized" 
congestion control mechanisms to allow for future, non-TCP congestion 

  Challenge allows DCCP-level mobility and loss of sequence number 
synchronization. The old mechanism didn't work (darn!).  Challenge source 
address must be expected address. Have discussed stronger 
mechanisms, looking for feedback that this is needed in the base spec (and 
this looking will happen on the mailing list).

  Reasons have been added to the Reset packet. There are some reasons that 
the other endpoint can't do anything about, but it's good to know what the 
reason was - and some reasons do have reasonable responses.

  Buffer Closed Drops option has been dropped in favor of Buffer Close.

  We discovered an ambiguity where packets might be dropped in a receive 
buffer, but possibly after control information was extracted.  To 
resolve this ambiguity, the philosophy is "If you ACK a packet as 
'received', you MUST deliver it to the application unless it's 
explicitly dropped due to application intervention."

  Good progress, mechanisms are stabilizing, corner cases being nailed 
down. We still need implementation experience, and we still need to do RTP 
over DCCP - do we? Is two sequence spaces too much overhead?

Q: Have you considered UDP extensions such as UDP-lite? 

   A: We do have a partial checksum in DCCP. Could you see if this meets the 
needs of UDP-lite applications?

Q: Assuming DCCP is wildly successful, what about header 

   A: DCCP isn't too different from other transports, so this should be 
doable.  Carsten: when you design protocols, please assume that there will be 
header compression, so don't go crazy squeezing bits.

Q: The real question of RTP over DCCP is motivation.  If the service is the 
same when things work, there's no motivation to move to DCCP.  
Applications prefer not to care about congestion, especially when 
there's no congestion most of the time.  You're going to have to force 
applications to care about congestion, and nobody is actually working on 
forcing applications to care.

   Sally: the other carrot for DCCP is ECN, if people find ECN useful.  
Under heavy load, maybe routers would stop doing ECN for UDP, assuming that 
the applications won't respond anyway?

   Mark: another benefit is explicit set-up/tear-down for NATs and other 

Q: VoIP applications has very periodic sending rate. How is the 
congestion control (TFRC) going to handle this?

   Mark: Could use TFRC bitrate as limit for the application. If keeping 
within the limit the application can be allowed to decide its sending 

Q: How would applications actually use congestion controlled flows?  They 
don't understand how to adapt codecs, etc.


HUM: Should we continue to develop the spec in this working group?


Aaron: time to hum this protocol direction (right direction? Something 
better? Go home?)

Q: Shouldn't DCCP be an experimental protocol? 

   A: not in the charter - we're supposed to be doing a 
standards-track protocol.  

   Allison (Transport Area Director): the goal is to go to Proposed 

Q: DCCP needs a different API - too much interaction for sockets.

   A: User Guide talks about an example API, but a real API spec isn't in 

Hum: The room thought we're headed down the right path.  [There was some 
confusion do to poorly framed hum questions by Aaron (sorry!).  A 
portion of the room felt that there were alternative technologies to DCCP to 
provide congestion control (notably extending SCTP).  However, there was a 
clear consensus that the working group should continue to develop the 
existing DCCP spec.]

Q: There are other protocols that meet the problem statement.  SCTP 
   A: another hum. SCTP only has one congestion control profile (TCP).  
There's no reason another variant couldn't be developed.

   Allison: except that SCTP is already very complex now.

Q: Is there a congestion profile that's NOT designed to be 
TCP-friendly?  Or significantly different from TCP?

   Sally: Actually, yes (Note-taker - apparently this is the answer to the 
SECOND question) - TFRC.

   Sally: We wanted TFRC, not just TCP, we wanted smaller headers, and we 
wanted ECN. There's functionality in SCTP that DCCP doesn't need - 
multiple streams, etc.

Comment: How long the header is doesn't make sense to worry about - use 
header compression.

Comment: This is going really fast to Proposed Standard. We did the 
problem statement and protocol specs in parallel - or maybe even the 
protocol first. We need some time to absorb this.  We need to think about 
mobility, we need to think about why we need for applications to 
establish connections, and so forth.  

   Allison: this isn't WG last call - we're asking if it's the right 

Comment: there's no technical reason why SCTP couldn't be TFRC - maybe 
architectural issues, but it shouldn't be off the table a priority.

   Allison: No engineering is ever off the table.  We're thinking about 
functional families, but people can still think about SCTP and TFRC and 
convince us.

Carsten (ROHC wg co-chair): don't worry about header SIZE, but do worry 
about header COMPLEXITY!

Comment: Some of the changes I've seen over the last two meetings are 
dealing with the reasons why SCTP is so complex - and DCCP is becoming more 

   Mark: Maybe we should separate connection setup and congestion 

Comment: We need to make sure we're not moving too quickly, because 
Proposed Standard is more important than it used to be ("de facto").

   A: We can change things in April if we have to. 

   Allison: Streaming media needs this soon/today.  It's OK to be moving 

Hum: This spec is appropriate for this working group at this time. Aaron 
couldn't express a counter-hum, due to illness!


3. A few words on the relationship between TFRC and DCCP
   Sally Floyd
  TFRC is now approved as Proposed Standard. It has gone through some 
small changes as a result of Last Call/IESG feedback, mostly removing 
information that was being exchanged and adding implementation hints.

  CCID2 and CCID3 have been reissued with new names but no changes.

Q: How does TFRC work with application-limited streams? 

   A: This hasn't been significantly looked at to date. 

   Mark: even TCP hasn't really looked at this!


4. Discussion of initial draft of DCCP User Doc
   Damon Lanphear


   Note: The User Doc is a new draft that hasn't been widely read or 
reviewed.  PLEASE READ IT.

  Version 00 is a rough draft. Damon is looking for community guidance and 
feedback, so that the document has the right structure and content.

  Implementations need to think about what DCCP facilities they expose to 
applications. Examples: post-network buffer and rate control, 
selective transmission and retransmission based on latency, latency 

  API considerations include configuration issues and connection 
establishment/termination and feature negotiation.

  Open issues: Loss signaling, kernel/user space API.  
Pragmatically, how far can we move from BSD sockets?

  Do applications find out that data may need retransmitting?  Is the DCCP 
sequence number space - and loss indications - visible to the 

  What do we do when receivers are slow?

Aaron: If you're in AVT, please share pointers to this work with that 

Q: There's minimal sample buffering - this is problematic for VoIP.

  Sally: TRFC loss rate should be visible, and I'm supposed to be 
thinking about this.

  Comment: VoIP applications are very delay intolerant, therefore any API 
should allow a possibility to send packet without any sender side 


5. Implementation Reports

  Damon has an implementation with two parts - a validation of TFRC for 
streaming media applications with discrete coding intervals, and an 
implementation of DCCP for FreeBSD, and hopes to have patches to share by 
April so people can experiment with it.

  Berkeley developed a user-space implementation based on an older verson of 
the spec which is no longer being maintained.

  Aaron: any grad students looking for a good thesis project?


6. Other Issues

   None noted.


7. Close



DCCP charter:
Mail archive:
DCCP mail list:


DCCP Specification Update
DCCP Users Guide