2.7.2 Datagram Congestion Control Protocol (dccp)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.icir.org/kohler/dcp/ -- Additional DCCP Web Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

Aaron Falk <falk@isi.edu>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: dccp@ietf.org
To Subscribe: dccp-request@ietf.org
In Body: (un)subscribe
Archive: www.ietf.org/mail-archive/working-groups/dccp/current/maillist.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 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:
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
Sep 03  Working group last call for spec and CCIDs
Oct 03  Working group last call on User Guide
Nov 03  Submit DCCP spec for IESG/IETF review to be Proposed Standard
Nov 03  Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard
Dec 03  Submit User Guide for IESG/IETF review to be Informational RFC
  • - draft-ietf-dccp-ccid2-05.txt
  • - draft-ietf-dccp-ccid3-05.txt
  • - draft-ietf-dccp-user-guide-01.txt
  • - draft-ietf-dccp-spec-06.txt
  • - draft-ietf-dccp-ccid3-thin-00.txt
  • No Request For Comments

    Current Meeting Report

    Datagram Congestion Control Protocol (dccp) working group
    March 4, 2004
    IETF-59 Seoul, South Korea
    Minutes taken by Ted Faber.
    Slides for all talks are available at
    Jabber log is available at
       Status & Chair's Remarks (Falk)
       Spec Update (Handley)
       Summary of mailing list thread on DCCP, real-time, and CBR
       DCCP User Guide update (Phelan)
    Chair's remarks (Aaron Falk)
      Since last meeting there has been an energetic discussion of
      congestion control versus real-time applications, an update of the
      User Guide draft, and a (hopefully) final polish on the DCCP
      specification and CCID documents.
      The current status of the working group is that the spec and CCIDs
      are ready for WGLC (however they require thorough reading since many
      editorial changes have been made); the User Guide needs feedback
      from the community: is the new direction (describing services as
      opposed to APIs) acceptable?  useful?  Also, there are a handful of
      ideas that have come up over the last several months that may be
      taken on as new work items.
      Before the next IETF, we hope to take the spec and CCIDs to WGLC,
      update the User Guide, and update the charter.  Here is a proposed
      - IETF-59:  Review Spec, CCID changes
      - Mar 04:   WGLC for spec, CCIDs 
      - Apr 04:   Publish user-guide-02
      - May 04:   Revise wg charter 
      Several possible new charter items have been proposed.  They are
      listed below with the folks who've agreed to author an initial
      draft.  (It's necessary to identify an author is before adding
      something to the charter.)
            - Faster start after idle (Eddie Kohler)
            - CCID-3 thin (Eddie Kohler)
            - TFRC-PS (Sally Floyd - to be published in tsvwg but will
              require a CCID) 
            - TFRC supporting apps w/limited rate flexibility (mjh)
            - 8 packet/RTT initial sending rate (Eddie)
    Spec Changes (Mark Handley presenting for Eddie Kohler)
      Spec changes include organizational changes and cleanups spotted by
      reviewers.  Event processing has been clarified.  There were many
      simplifications discussed at IETF in Minneapolis.  The most
      significant changes have already been discussed on the mailing
      A new state was added, Part Open, to handle a possible deadlock.
      Event processing text was made explicit through the use of
      pseudocode (much more comprehensive than the state diagram, which is
      necessarily incomplete).  Text on sequence number validity cleaned
      up and ambiguities removed.  Changed protocol for Sync packets to
      avoid some possible problems.  Spec now discusses probabilities of
      sequence number collisions for regular and extended number spaces.
      Recommend using extended sequence numbers for windows greater than
      100 packets.  Clarifications added on forward compatibility
      including removing the "Ignored" option.  Empty Change and Confirm
      options added to allow one end to query the option state of the
      Open issues status from IETF-58.
        - #NDP: removed in favor of NDP count option
        - ID and Challenge: removed for Sync and SyncAck
        - DataDropped requirements in CCID 3: since the problem is in the
          receiver rather than in the network, the draft now suggests
          manipulating Xrecv to indirectly limit the transmit rate
          Discussion on DataDropped:
          - Magnus Westerlund: seems to indicate that this kind of data
            drop is not congestion related.  The right answer is: do nothing.
          - Mark: the options of ignore or treat as network congestion are
            both too extreme, this allows a more gentle response.
          - Magnus: could this be a valid response for corruption?
          - Sally: I believe the text says "drop in receive buffer".  You
            don't want to send data that you know is going to be dropped.
            We think this will also be useful to deal with corruption.
            However, using DataDropped for corruption is open issue - this
            is a hook for the future.
          - Mark: packets are serving no useful purpose, so we felt we
            needed to do something, although the response is not as urgent
            (as for network congestion).
          - Magnus: I suggest adding more drop codes and define these
            responses remove special cases.
          - Sally: Not something to talk about here.  Corruption/
            congestion may be uncorrelated, maybe not.  Need to think
            about that, but this current systems is not a bad start.
            Gentle reduction.
          - Mark: Yes, this is a placeholder but a reasonable start.
          - Colin Perkins: Could use receive window for flow control.
            I.e., no receive window, no flow control -- this seems close
            to that.
          - Mark: have to think about it
        - Packet sizes: want to avoid people gaming packet sizes.  Not
          clear how well this works, added weasel words.  implementations
          can check.  Flag of a possible issue.
        - Payload checksum: use SCTP CRC-32c
          Discussion on Checksums
          - Colin Perkins: I understand why you switched to the CRC-32c
            checksum, but I'm concerned that it is expensive in terms of
            bandwidth overhead.
          - Mark: you don't have to use it.
          - Colin: Wireless environments will use it and it's particularly
            expensive for them.
          - Mark: separate header from rest.  OK, that's an issue.
          - Colin: You may need 2 types of checksums.
          - Mark: Apps which can tolerate loss may not care about
          - Eddie: It's only 6 bytes overhead.
          - Colin: Can be pushed out 8 bytes with padding.  Yes? That
            would be twice the Internet checksum overhead?  It may not be
            a problem but we need to be careful.
          - Mark: We just can't sort out all these issues before we get
            some deployment experience.  Go try it.  Adding a checksum is
          - Eddie: And you don't have to use it.
          - Tom Phelan: The purpose of different checsksums is to provide
            different strengths of protection.  So, having both use the
            Internet checkksum would be redundant (and defeat the intent).
          - Mark: Having two coverages does have uses, e.g., to detect
            non-congestion errors.  You may really want a stronger
            checksum, too.  Mostly strong checksums are for when there's
            no link layer help.  
          - Tom Phelan: Agree, if you only have one extra checksum, it
            *should* be stronger.
        - Service Code wildcarding: addressing Bellovin security issue.
          Solution was to remove wildcarding.
          Discussion on Service Code Wildcarding
          - Falk: what flexibility are you giving up by dropping
          - Mark: Nothing useful.  A server listening on port w/o
            specifying service name now requires service code.  A client
            cannot specify connection w/o knowing what service is there.
            Allowins wildcard was a workarounds because we expected it
            would be difficult to get service codes, but we now believe
            that getting service codes should be fairly easy so that
            should be OK.
          - Falk: Suppose I have a client wants to talk Real version or QT
            version and a server that will take either.
          - Mark: The appropriate service code must be acquired that
            out-of-band and that's OK
          - Tom Phelan: Adding admin overhead is OK.  Since ports added
            overhead, so service codes are OK.
          - Eddie: Servers can talk multiple protocols and at most service
            will fail one to another.
          - Colin: One thing vendors will do is mux on the same port.
            E.g., muxing RTP and RTCP.  What does this buy us?  Compared
            to potential for abuse.
          - Mark: This makes the client's intent much more explicit.  It's
            important for security to have explicit intent.  Therefore,
            fewer firewall heuristics are required.  This approach allows
            fine, detailed description of what is transferred.  The
            existing port space is insufficient; there aren't enough ports
            for fine grained registration.  You don't want to put large
            numbers in every packet.
          - Colin: That seems OK.  Although, I'm concerned that people
            could lie about Service Codes to get through firewalls.
            Having a separate code lets you manipulate server.
          - Colin: You can multiplex multiple services on one port.
            Horrible, but can do it.
          - Mark: Server port irrelevant.  It's OK to have many things on
            same server port. 
          - Colin: Doesn't this make the firewall's job harder?
          - Mark: No, explicit data makes firewalls easier.  They can
            specify the specific rules they want (using service codes)
            instead of relying on a rough estimate (by using port
          - Colin: I still don't see the gains, but servers will multiplex
            services on same port
          - Mark: we just don't agree.  Talk later.
        - Only trivial changes to CCIDs 
        - James Kempf: Lots of discussion about ID/locator separation at
          this IETF.  The mobility support in DCCP looks like that stuff.
          Are there conflicts??
        - Mark: The timing was poor for DCCP mobility support.  We don't
          know which (or whether any) mobile IP solution will prevail and
          so we'll assume they fail.  While we hope not, however the DCCP
          mobility approach is a lightweight mechanism, so we can
          deprecate it if something better comes along.
        - James: The DCCP approach doesn't work if both ends are moving.
        - Mark: Yes, this is a known shortcoming.
        - Magnus: Mobility is a big security hole via sniffing and
        - Mark: If you are concerned about sniffing, use IPsec.
        - Falk: DCCP is only required  to be as secure as TCP
        - Magnus: I believe the mobility feature should be moved out of
          the spec and made an optional extension to avoid the security
        - Mark: Disagree.  You can turn mobility support off and it would
          be hard to add as an extension.
        - Eddie: Agree with Mark.
        - James: This is a similar problem to Mobile IP binding update:
          there's a protocol in MIP that will avoid a DOS here (lying
          about move destination) there may be an IESG issue here (since
          it affects multiple protocols).  Can this be used to DoS an
          innocent 3rd party?
        - Mark: Yes.  But only if you can snoop nonce exchange
        - James: Is the nonce used directly?
        - Mark: yes
        - Anders Clements: Any thoughts on how to cross NATs?
        - Mark: NATs will need to become DCCP-aware.  We acknowledge that
          this is a long term solution.
        - Anders: Is DCCP over UPD to avoid blocking by NATs a crazy idea?
        - Mark: Yes
        - Colin: Suppose you set up connection to yourself, observe the
          nonce exchange, and redirect the stream to some unsuspecting 3rd
        - Mark: This may be a problem.  I need to think about that.
      - Future work
        - TFRC for apps that can't directly change sending rate.
        - Specs assume that CCIDs assumes data will be sent appropriately
        - What about fixed rate or discretely variable rate apps?  Try
          using TFRC as reference rate and stay within a factor of 2 and
          use DCCP as policing mechanism.  May be issues when there are
          only a few flows.  Need some research.  Unlikely to be socially
          bad, but may not always be fair.
       Additional Discussion
          - Magnus: How useful is sequence number transition
          - Mark: had a fair amount of debate on this.  It's preferable to
            pick the right sequence number space at the beginning of a
            connection.  However, flows without knowledge of net conditions
            (which includes most flows) would like to be able to switch.
            I'm not terribly happy with the current solution but we
            couldn't find anything better.
    DCCP issues from mailing list (Sally Floyd)
      Some quotes from recent list messages:
      - "Real Time apps have no interest in being 'fair'.
      - "Don't expect people like XXX to be happy with the 'you must fit
        in to TCP's view of the world' when most of their real-time
        applications are already being good citizens (by not sending 'all
        they can' when they don't have to)." [Referring to a
        silence-suppressed, CBR, 4 Mbps video stream!]
      - "Maybe some codecs of today, which were designed assuming a QoS
        enabled network, cannot make use of TFRC or DCCP."
      - "TCP is broken.  Nowhere is it written that TCP = best effort."
      Background assumptions (ours):
      - DCCP and best-effort traffic: DCCP with best-effort service does
        not necessarily meet the needs of all apps.  In fact, best-effort
        service does not necessarily meet the needs of all apps.  DCCP is
        intended to solve the best-effort problem, not the QoS problem. We
        believe that in the long run DCCP offers better performance than
        UDP to applications (e.g., ECN, NAT traversal, etc.)
      Why do flows have to be bothered with CC?  RFC 2914 provides 2
      reasons: prevent congestion collapse and share fairly w/TCP.  IETF
      will not standardize non CC-ed transport protocols.
      Why Slow start?  CBR app writers don't want slow start after idle
      periods or ever.  Why?: "We're sending at a low rate so why bother?"
      Idle periods: "We're benefiting the network by going idle, why
      penalize us by forcing slow start after a quiet period?"  "Our
      traffic is more financially valuable to ISPs so congestion rules
      don't apply" "TCP must be fixed [to be friendlier to CBR apps]"
      Current CCID 3 specifies 4 pkts initial window and possibility of 8
      small packets in the future.  DCCP would drop packets in excess of 4
      sent by a CBR application.
      As for best-effort traffic with higher initial rates rates?  Sally's
      view: explicit router feedback is needed. See, e.g., the Quick-Start
      expired ID (draft-amit-quick-start-02.txt).  You could make this
      Sending rate is limited to grow no faster than doubling in a RTT.
      This topic was triggered by mention in user-guide to double your
      send rate to avoid TCP from 'stealing' your BW and to avoid slow
      start after idle.  This suggestion was based on an incorrect
      understanding of TCP.  TCP's send rate is determined by loss, not by
      maximum send rate.  Nevertheless, it is recognized that the
      doubling-limit poses a constraint for bursty apps, instant-on apps,
      and silence suppression.  But relaxing this constraint remains a
      topic for research.
      A connection that has started and gone idle knows a little more about
      the network conditions than a brand-new connection.  There has been
      a proposal sent to the list for a "Faster Start" after idle.  The
      proposal is for an initial rate of 8 pkts/RTT, followed by
      quadrupling of the send rate each RTT until the previous rate is
      reached or a drop or a mark are received.  This proposal has not
      been tested or fully evaluated and needs more investigation.
      Implementation experience regarding slow-start problems will help
      guide and motivate this work.
      Finally, there are concerns about applications with fixed (or very
      limited flexibility in) send rates.  There is a proposal to allow a
      DCCP sender to send up to twice the "allowed" sending rate.  To do
      this would require a new CCID and further work.
      Questions?  Comments?
      - Wolfgang Beck: SIP has a mechanism to include RSVP.  We have
        implemented SIP with a probing phase.  Would this work for DCCP?
        DCCP would signal a reference rate then go on with signaling.
        Would this be a solution for initial slow-start as a kind of
      - Sally: use padded data to build up rate and go?  Sounds viable.
      - Falk: It seems you could do it w/o SIP or RSVP.
      - Mark: Yes, you could use DCCP-Sync pkts to do that.
      - Sally: Hmm, would the packet size difference cause a problem?
        Slow starting with small packets, then going to large application
      - Magnus: Can you pad an ack?
      - Sally: Yes. 
    DCCP Users Guide (Tom Phelan)
      There's a new revision of User Guide and the big question is what to
      do next.  The "user" in the user guide is the application.  Unlike
      the previous version, it is not an API document.  Sections include:
      - Choosing a CCID
      - 2 App stories - streaming media probably not ready
      - Shorter section on gaming.
      - Stupid DCCP tricks - misc features
      - Security section
    Controversies in guide (according to Tom)
      Fast restart is assumed to be in there.
      Training period in strategy 3 - padding the network as discussed before.
      - Falk: fast restart is probably not coming anytime soon.  Suggest
        removing that assumption.
      Stream switch
      Variable rate media: just can't support rate variations like the
      10x difference between I-frames and ??-frames.
      - Falk: a sender can smooth these bursty codecs right?
      - Tom: you need to ramp up in a frame time
      - Falk: I was talking about smoothing the rate variation
      - Tom: going from a static frame to a busy frame is a sharp change
      - Sally: The fundamental assumption here is that real-time media
        users with cheap service use best-effort at the cost of extra
        delay, while people willing to pay would not use best-effort.
      - Magnus: Can avoid big swings through the right choice of codec,
      - Tom: Agrees that most codec can be adapted, but maybe not today's,
        especially MPEG-4.
      - Mark: There are fundamentally two types of codecs: H.261 and
        H.263.  One sends close to constant bit rate, in the absence of
        drastic content changes.  The others have different frame sizes,
        e.g., MPEG-4.  The latter is not intended for interactive use.
        Perhaps the issue we are talking about stems from a mismatch
        between codec and application.
      - Falk: you said the video is not changing on the smoother codec
      - Mark: there are smoothing/quality degradation tricks in the
        interactive codecs.
      - Tom: There's a similar statement in the user-guide.  Your point is
        good - some codecs adapt better than others.
      - Mark: No - if you want to meet interactive constraints, you need a
        codec that produces smooth traffic, or with non-interactive codecs
        that use buffering to smooth their output.
      Stream padding: always try to send - pad when necessary. removed the
      doubling of rate.  (This was based on bad assumptions, see Sally's
      TFRC with self-limiting sources.  Desperately in need of
      Restart after idle for games?  Will it work?
      - Falk: Do we know whether gaming people are using RTP or raw UDP?
      - Tom: We don't have much information, but it appears they are using
      More apps?  What's missing?
    The section on "Stupid DCCP tricks" discusses specific guidance on
    how a DCCP application should use some of the features in DCCP.
      - Colin: In my opinion, this version of the User Guide is more
    Closing Discussion
    - Colin: Are there any implementations?
    - Falk: There are some implementation info on Eddie's page.  Not clear
      how close they are to the current version of the spec.  A fairly
      full featured version was developed at ICIR over the summer but the
      spec has changed a bit since then.
    - Mark: Most implementations are lagging.
    - Colin: would like implementations before going to Proposed Standard
    - Falk: Implementations are not a requirement for  PS (but are a good thing)
    - Colin: I still feel we need implementations


    DCCP Spec Updates
    DCCP: Issues From the Mailing List
    DCCP User Guide