2.8.3 Datagram Congestion Control Protocol (dccp)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional DCCP Web Page

Last Modified: 2005-11-09


Thomas Phelan <tphelan@sonusnet.com>
Lars Eggert <lars.eggert@netlab.nec.de>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>


Gorry Fairhurst <gorry@erg.abdn.ac.uk>

Mailing Lists:

General Discussion: dccp@ietf.org
To Subscribe: dccp-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/dccp/index.html

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

- 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
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
include example APIs, an applicability statement, or other forms of
guidance about appropriate usage of DCCP.

Goals and Milestones:

Done  Publish summary of required protocol functions/requirements
Done  Decision to build on proposed DCCP protocol, alternate protocol, or quit and go home
Done  Detailed review of spec and CCIDs
Done  Public design review at IETF meeting
Done  Working group last call for spec and CCIDs
Done  Submit DCCP spec for IESG/IETF review to be Proposed Standard
Done  Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard
Done  Complete WGLC draft-ietf-dccp-problem-xx as Informational
Nov 2005  Complete WGLC draft-ietf-dccp-tfrc-media-xx as Informational
Dec 2005  Revise charter
Jun 2006  Revise charter
Jun 2006  Complete WGLC draft-ietf-dccp-tfrc-faster-restart-xx as Experimental
Jun 2006  Complete WGLC draft-ietf-dccp-tfrc-voip-xx as Experimental
Jun 2006  Complete WGLC draft-ietf-dccp-user-guide-xx as Informational


  • draft-ietf-dccp-ccid2-10.txt
  • draft-ietf-dccp-problem-03.txt
  • draft-ietf-dccp-ccid3-11.txt
  • draft-ietf-dccp-spec-11.txt
  • draft-ietf-dccp-tfrc-voip-02.txt
  • draft-ietf-dccp-tfrc-faster-restart-00.txt
  • draft-ietf-dccp-tfrc-media-01.txt

    No Request For Comments

    Current Meeting Report

    Datagram Congestion Control Protocol WG (dccp)
    THURSDAY, 10th November 2005 at 13:00-15:00
    CHAIRS: Lars Eggert 
            Tom Phelan  
    Notes by Gorry Fairhurst .
    I. The agenda was bashed by the chairs.
    II. Status of Internet-Drafts
    The set of drafts below are now done and with the RFC Editor:
            draft-ietf-dccp-spec-11 (Proposed Standard)
            draft-ietf-dccp-ccid2-10 (Proposed Standard)
            draft-ietf-dccp-ccid3-11 (Proposed Standard)
            draft-ietf-dccp-proble-03 (Informational)
    There is currently no IANA registry for DCCP numbers. The authors need
    to talk to IANA about this. Allocation procedure will be the same as
    for UDP.
    The following WG drafts are active:
            draft-ietf-dccp-user-guide-03 (Expired)
    Gorry Fairhurst: Can we make sure the whole WG is aware of the small
    change to the Spec that resulted from the formal method review?
    The Chairs suggested that Eddie Kohler sends an email, reminding the
    group of the change made to draft-ietf-dccp-spec-11 since WGLC (already
    sent to the list).
    III. State of the WG
    Gorry Fairhurst has taken the job of WG Secretary for DCCP.
    IV. Implementation status (Lars Eggert)
    There are two actively maintained DCCP implementations. Both are based
    on the original Lulea code. The WG is interested to hear of other
    IV-1 DCCP Implemenation on NetBSD (Yoshifumi Nishida)
    Current implementations exist for Net BSD 2.0 and Free BSD 5.4. An
    OpenBSD implementation is under development. The work is based on Free
    BSD from Lulea, and supports CCIDs 2,3. Some interop tests have been
    performed with Linux, which discovered some issues (Feature
    Negotiation, Elapsed Time Option). Feedback was requested on the
    implementations. For more information see:
    Randall Stewart: The Kame project will finish in April, will the DCCP
    implementation continue?
    Yoshifumi: It will continue.
    V.  Status of WG Drafts
    V-1 TFRC Media (Tom Phelan)
    The draft had been updated based on comments received including
    comments from Colin Perkins. No additional comments were received from
    the dccp list. The authors asked if this I-D was ready for WGLC.
    Colin Perkins: Have you implemented any of the things in the I-D?
    Tom Phelan: No.
    Colin Perkins: Maybe you should, before progressing this to WGLC.
    Chair: Can people read and commit to a short review?
    Sally Floyd: Implementation means a lot.
    Tom Phelan: I will talk to implementors.
    Colin Perkins: Implementation also requires some effort.
    Steve Casner: If you think it is done, then we could start a WGLC and
    ask for comments, but say that the WGLC will not conclude until
    implementations are achieved.
    Chair: We will come back to this at next IETF.
    V-2 DCCP Users Guide (Tom Phelan)
    After discussions in Paris, and production of the media guide I-D. The
    current I-D now lacks content. The authors now recommend that this is
    placed on hold awaiting more experience.
    Gorry Fairhurst: One slight problem is that this is a WG item that is
    out of date. It would be good for the authors to rev. the I-D to
    reflect the WG plans for the I-D.
    Tom Phelan: I'll take this as an action, and remove the stuff that is
    no longer relevent.
    Tom Phelan: The actual new text will take more time, and needs inputs
    from implementors.
    Chair: There is still time within the milestone, so this is OK. Offers
    of help are appreciated.
    V-3 TFRC VoIP Mode (Sally Floyd)
    Sally presented results following what was presented to the DCCP WG in
    Paris. The conclusion was that the results for small packets were OK.
    There is a wide range of buffer handling in routers. There was also
    some evidence (from using the tbit tool with web servers) that in many
    routers, small and large packets are dropped equally.
    Matt Mathis: How much better is TCP with small packets, rather than big
    Sally: Significant, TCP with large segments does not do well when used
    over a path with byte-drop RED.
    ?: What is the x-axis?
    Sally Floyd: Byte drop rate, sending flows and recording the rate (all
    separate experiments).
    Magnus Westerlund: It seems that above 6 kps, the various CC schemes
    all behave the same. (i.e. the fair-share is less than 10 kbps).
    Sally Floyd: Yes. The performance is only different when highly
    congested (10% or above). VoIP-TFRC presents no difference when
    congestion is low.
    Tom Phelan: This data does not show the performance of competing flows.
    Sally Floyd: There are other simulations that do. These were in earlier
    version of the draft.
    Colin Perkins: The presented data is for a 40 B header. This is not
    what we expect for RTP using TFRC. How critical is the size of the
    Sally Floyd: I think the header size is not sensitive (even with
    tunnels it is within a factor of 2).
    Colin Perkins: OK
    Tom Phelan: The RTP header is counted in the user payload.
    Colin Perkins: I really think we need to change the name of the draft.
    Sally Floyd: "TFRC with small packets" is fine for me.
    Chair: Who has read the draft (same as in Paris)?
    Chair: Is the I-D ready for WGLC for publication as Experimental?
    The humm showed some people thought it was ready to go to WGLC.
    Colin Perkins: Can we see the final draft first, before we make this
    Sally Floyd: OK, we will do one more rev.
    WG: After this I-D is ready, we can take this to the list.
    VI. Discussion on next steps for DCCP (Lars Eggert)
    Milestones need to be updated, based on the new work accepted in
    IETF-63. The  Next Steps for the DCCP WG will switch focus from
    specifying DCCP to enabling use of DCCP. There are a set of
    presentations on this topic. Another issue is that interop testers have
    also reported that NAT traversal needs to be described, and could be
    another I-D.
    VI-1 RTP over DCCP (Colin Perkins)
    Some signaling is needed before the RTP media flows can start (e.g.
    using SIP or RTSP).
    RTCP information sent with the RTP over UDP. SDP has a need to identify
    the protocol type - and this implies some work to support DCCP.
    Tom Phelan: Why is the list of supported types for DCCP different for
    TCP than DCCP?
    Colin Perkins: Some of these still need to be registered for TCP and
    Jonathon Lenox: There was some discussion the AVT list that some
    combinations do not make sense, e.g. AVPF used with TCP.
    Magnus Westerlund: It makes sense to have feedback with all of these.
    We need AVPF, even if we do not need the full set of functions
    (including congetsion control).
    Colin Perkins: AVPF can request application retransmission, etc. If it
    conflicts, DCCP should take priority.
    Steve Casner: Can DCCP congestion control compete with mechanisms at
    the RTP level?
    Colin Perkins: Unlikely that this is an issue, but there is potential.
    DCCP also needs a service code attribute added to SDP. Is this
    assignment one per application or for all RTP traffic? I propose we use
    service codes for each application. The flows can all use a common RTP
    port, and the service codes are used to differentiate the flows at the
    Tom Phelan: Yes, one per application.
    Colin Perkins: RTP is a class of applications. We need a port registry
    for DCCP.
    Magnus Westerlund: RTCP feedback interval should be a minimum of 5
    seconds. Some environments send much more.
    Colin Perkins: Congestion control should take precedence over RTCP
    scaling rules. If the session bandwidth changes - different in two
    directions, this may be trouble, and one party can time out.
    Steve Casner: For a 2 party session, you can disable scaling.
    Steve Casner: RTCP provides receiver monitoring, but so also does DCCP.
    If you do not use it for lip-synch, do you need to send it?  Does it
    duplicate functionality in DCCP?
    Colin Perkins: Not entirely, we need to think about the rules.
    Magnus Westerlund: We should think about scenarios for conferencing
    applications (star topology with a central node).
    Colin Perkins: Yes, see later in the presentation.
    Jim G: I find this work quite relevant.
    Chair: Do the people in the room think we should do this in the DCCP WG?
    (20 people for/ No people against)
    VI-2 ADDCONF in SCTP (Randal Stewart)
    Randal described the approach used in SCTP for moving an established
    flow between end-host addresses. Authentication mechanisms had been
    introduced to prevent hi-jacking of connections in SCTP. Is this
    suitable for DCCP mobility?
    VI-3 DCCP and Mobility? (Pasi Sarolahti)
    Pasi presented slides describing single-homed (simpler) and multi-homed
    approaches. It should be possible to follow the lessons learned in
    SCTP. Mobility adds new functions (an advantage to DCCP), but also adds
    complexity. The proposal is to make DCCP Mobility an experimental
    option, where implementers could decide whether to support it.
    VI-4 Does DCCP bring advantages? (John Lockley)
    John motivated the case for deploying DCCP, based on the advantages of
    good mobility support.
    Mobility also brings strange impacts on congestion control (reordering,
    loss, significant change in rate, etc). This can cause complications to
    real-time applications, and DCCP would benefit from being more agile.
    There is also a lot of work in the Internet areas: SHIM layers, HIP,
    multi-homing. The focus is different, and work also needs to consider
    transport issues and congestion control.
    Sally Floyd: There is some work on congestion control that can work
    across changes in path characteristics.  One example is QuickStart in
    the TSWVWG WG (draft-ietf-tsvwg-quickstart-01.txt).
    John Loughney: Is QuickStart for DCCP defined?
    Sally Floyd: This is not described in the I-D, but it is mentioned in
    an appendix of the I-D. The detail would need a seperate I-D.
    ?: It could also be useful in cases where you wish to use both IPv4 and
    Jonathon Lenox: If the aim is to keep an existing session at a server,
    when a client moves, then the protocol (i.e. server socket) will
    normally be the same. It is hard for an application to keep a session
    across multiple network protocols.
    ?: No, it's just a socket issue.
    Pasi Sarolahti: How much does this effect the base DCCP spec.?
    Lars Eggert: Is this an option? - or does it require changes to the
    DCCP base spec.?
    Pasi Sarolahti: This needs investigation. The feature-negotiation may
    be useful.
    Tom Phelan: I think it can be added as an option.
    Colin Perkins: I was one who argued against mobility in the base
    specification (based on the complexity), but as an extension, I would
    support this.
    Tom Phelan: Is there energy and expertise to do this in the DCCP WG?
    Will people write I-Ds?
    Pasi Sarolahti: I will work on it, details need thought, may make an
    I-D for IETF-65.
    Bob Briscoe: I can volunteer Loiuse Burness as a reviewer.
    Lars Eggert: Who in the room would support this as a Charter Item?
    (10 people for/No people against)
    VI-5 DTLS (Eric Rescola)
    Eric presented DTLS, an adaption of TLS to work with a datagram stream
    (and using the initialisation vector defined in TLS1.1). The base spec
    is in RFC-Ed queue, and there is an implementation in OpenSSL. There
    are likely to be some issues with using this with DCCP: Need to merge
    the handshaking to reduce latency; Retransmission of DTLS with CC needs
    to be considered. I'd be interested to work on a draft, but need a DCCP
    volunteer. Would there be volunteers to work on this from the transport
    Jonathon Lenox: I understand use-case for DCCP. What are the deployment
    use cases?
    Eric Rescorla: It provides a security method. It is an alternative to
    Magnus Westerlund: Can we integrate this with the initial handshake,
    during the feature negotiation phase (e.g. to know who is connected).
    Could we combine with feature negotiation.
    Eric Rescorla: Yes. This would require DCCP feature negotiation and
    that was along the line I was thinking.
    Tom Phelan: Application writers like TLS, because they get control of
    the security function.
    Chair: Who would like to see this as work within the DCCP WG?
    (10 people for/No people against)
    Chair: Who would support the work on this with Eric?
    (3 people, 1 for reviewing)
    Chair: Please email Eric if you are interested.
    VI-6 Requirements for a CCID for Interactive Media (Tom Phelan)
    The WG has two CCIDs specified, there are issues with delay-intolerant
    applications. Should the WG explore more options to better fit the
    needs of network applications?
    There has been discussion on the mailing list and I-Ds on this:
    Sally Floyd: Are you trying to write the requirements for
    commercial-grade interactive media or the range of applications that
    DCCP may work with in general?
    Tom Phelan: I'm interested in Internet Applications over the general
    Internet. TCP-friendliness needs to be consider, although fairness may
    need to be considered over longer periods.
    Bob Briscoe: I think the problem of TCP friendliness is too focussed on
    "what you get", rather than "what it costs" the network. It ought to be
    based on the congestion you experience/cause, and the time period this
    is measured matters, since it varies.
    Magnus Westerlund: The question is what is acceptable: There is much
    research here, but it may not be ready for the WG.
    Lars Eggert: This work lies in the middle of a number of groups
    including transport modeling RG, congestion RG, DCCP WG.
    Colin Perkins: I see lots of fun research, but no engineering yet.
    Sally Floyd: I could write an I-D that may take a different look at the
    problem: requirements, evaluation, cost v. benefits in sending rate
    adjustments, etc.
    Chair: This discussion will continue on the list. If there are other
    issues please do send them to the list.
    Close of meeting.


    DCCP Implementation on BSD
    TFRC Media
    TFRC VoIP Mode
    RTP over DCCP
    Requirements for CCID for Interactive Apps