2.7.3 Datagram Congestion Control Protocol (dccp)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. 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-02-18


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: 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
Apr 05  Working group last call on User Guide
May 05  Revise charter
Jul 05  Revise user-guide


  • draft-ietf-dccp-ccid2-08.txt
  • draft-ietf-dccp-ccid3-09.txt
  • draft-ietf-dccp-spec-09.txt
  • draft-ietf-dccp-tfrc-voip-01.txt

    No Request For Comments

    Current Meeting Report

    DCCP Minutes, IETF-62
    Datagram Congestion Control Protocol WG (dccp)
    Monday, March  7 at 1300-1500
    CHAIR: Aaron Falk (falk@isi.edu)
      - Agenda Bashing
      - WG Status, Aaron Falk
      - Review of IETF Last Call/IESG review comments on DCCP spec, CCID2, 
          CCID3,  Aaron Falk
      - Planned non-editorial changes to spec, ccid, Eddie Kohler
      - DCCP User Guide update, Tom Phelan
      - TFRC for Voice over IP, Sally Floyd
      - Presentation on Rate-Adaptive Voice Codecs, 
          Magnus Westerlund
      No changes
      Note: the meeting is being unicast streamed
      Aaron Falk (AF) spoke about general status.  The milestones were
      reviewed.  The WG has completed the DCCP specs and CCIDs.  He asked
      what the future direction would be, now that the core work was done
      (this was not discussed, since there was no time left at the end of
      the session).
      DCCP Spec has passed IESG review with small changes.
      The DCCP user guide is still not complete. This may be too early to
      publish.  We need implementations and feedback to drive the guide
      document and also get contributions to this document.
      Note that VoIP mode for TFRC is not yet converged - there are still
      things to be changed and updated. Sally will present results later,
      feedback awaited from the AVT community (not necessarily today).
      Collin Perkins (CP): There could be feedback on VoIP mode on
      Wednesday in the AVT WG.
        Sally accepts the invitation to talk in the AVT WG.
      AF: Could you also encourage the AVT list members to review the documents
      and give feedback to DCCP?  We should not prejudge what is (not)
      acceptable for AVT. 
      Allison Mankin (AM) (AD for DCCP): There is not so much
      communication between the two communities as I would have
      liked. There are other documents that speak about Congestion Control
      (CC), the H.264 spec (RFC 3984) says a lot about congestion control
      - but was not (as far as I know) reviewed by the CC folks in the
      IETF (due to time constraints). Please be aware of the need for
      cross fertilisation...
      CP: The codec supports various rates - but these are not explicit CC
      functions. There is no CC work in AVT. We can send pointers.
      The list of Last Call comments on the DCCP Spec is available at the
      ID-Tracker.  The comments from the IESG were reviewed.
      One of the comments related to the procedure for defining extensions
      to CCIDs.  What does this mean?
        AM: (expanding on her tracker comments) It means that if you do an
        experimental CCID, then you can do experimental extensions. If a
        CCID is Standards Track - do not add IANA allocations to add
        experimental features. If you need to do experimental work, just
        do the work in the lab using the experimental allocation of
        numbers.  When you're ready, you can go and get a standards track
        document created. This separation means the CC Standards Track
        RFCs are well understood.
        Eddie Kohler (EK): This makes me think this is the right thing.
        But, TCP was extended experimentally a number of times...
        AM: If we do experimental work we need to make a whole CCID
        algorithm experimental. TCP is different and harder to
        modularise. Standards Track DCCP CCIDs are a module, which must be
        a standard. A "flakey" new module is a different CCID.
        EK: As long as this is an understood change of practice, I am
      The text needs to say that new protocol extensions must go through
      IESG review, but need not be standards track. Transport protocols
      require tight control of extensions to CC methods.  Why?
        AM: This makes sure that the extension MUST be an IETF document,
        not one from other standards bodies.
        EK: But the spec quoted RFC2434.
        AM: In that case, the text must be correct.  However, we must fix
        the potential loop-hole. Note "approved by the IETF" is not the
        same as "reviewed by the IESG".  This is protection against folks
        outside the IETF extending DCCP in unsafe ways.
    Eddie presented a set of changes including: 
        Extra options with invalid lengths are ignored s/invalid/nonsensical/
        48-bit sequence numbers
        Loophole on CC could cheat by repeated changing of CCID.
        Receiver rate change.
        Timespan measurement units.
    CCID2 and CCID3 also have minor changes.
    Eddie promised to post the changes to the list.
    Tom talked about the current content, the API-centric approach and the
    options. He asked what should be done to make this go forward?  There
    are issues with completing the document given the current lack of
    deployment and the need for applications expertise.
      EK: I like the user guide, but... the important thing is that the
      document should be kept alive, pending implementation or
      AF: The "DCCP Problem Statement" ID had a similar role, in that it
      was written as a tool for discussion, then frozen.
      EK: The Problem Statement ID died. It was not published. The User
      Guide needs to be published.
      AF: The Problem Statement could still be published (and people do
      want to understand where the decisions came from).
      Sally Floyd (SF): Publication of the Problem Statement would be
      good. I will help publish.
      AF: I will take this up with Allison (DCCP's responsible Area
    TP: The current document will be updated and I will issue rev -04.
      AM: Is there some material that is current and could be ready to
      publish?  Then we could take the User Guide as a later, more
      detailed, document that could be published? What would an
      appropriate title be?
      AF: "Application concerns about DCCP" perhaps?
      TP: Splitting out these concerns could be done pretty easily.
      AF: I'll take this as an action. Tom can you make a sample abstract
      for the new document and send it to the DCCP list.
      TP: Yes.  I'll also refresh the User Guide draft to keep it alive. 
      draft-ietf-dccp-tfrc-voip-01.txt (not in ID archive at the time of
      the meeting)
    Sally reviewed her previous talk (TFRC with a basis of byte/sec rather
    than pps). TFRC assumes a packet size of 1460B.  The VoIP change takes
    into account protocol headers for small packets and specifies a
    minimum interval between packets.  There was some work still to be
    evaluated, which appeared in -01 of the draft.
    She discussed simulation results, and noted that at very high
    congestion, a VoIP flow receives more capacity than TCP.  This is
    because TCP can not send multiple packets per RTT in high congestion,
    but TFRC can send many small packets in one RTT.  Should we use a new
    method for processing loss events at high rates of loss?
    Modified results were presented describing a small packet mode.  There
    are still issues - do networks behave differently with small packet
    congestion and does this have an impact?  There were many router
    behviours.  It may be easier for a router buffer queue to hold a small
    packet, alternatively packet buffers may be large and queuing may be
    irrespective of packet size, routers could do byte counting and that
    may set which packets are dropped.  There are many combinations and
    If Active Queue Management (AQM) in byte mode, then the modified TFRC still
    gets much more of its share.
      AF: Is that result independent of TFRC?
      SF: Yes - but 2 big packets could become 30 packets in TFRC.
      AF: That's because of the packet size?
      EK: What about a TFRC that is not in VoIP mode, that uses small
      EK: What's the order which is worst (TCP, TFRC, TFRC-VoIP)?
      SF: ??
      SF: We assume a transport protocol does not know what routers are
      doing. So we can't assume packets are dropped due to pps / bytes
      sent, drop rate not necessarily and indication of level of
    The TFRC-VoIP mode ID should be stable by the next IETF.
    Collin Perkins (CP): So this looks like a reasonable thing to
    do... But, let's not call this VoIP, because it does not solve all the
    problems for VoIP.
      SF: Call it "Small-packet mode"?
      AF: We started this work to solve VoIP mode.
      CP: It does help VoIP. But this rate of packet loss would make VoIP
      SF: We don't define how VoIP is carried on the Internet. We don't
      say best effort is good, etc. We just say, if VoIP wishes to use
      Best Effort, it should use CC.
      CP: No one objects to CC for VoIP.  In fact, the need for CC is
      written into the RTP specs.  I just note that VoIP with 50% loss is
      unusable.  If you get more than a certain loss rate, then it is
      better to drop the connection.
      SF: The application can decide to drop the flow, if it wishes.  It's
      not necessary for all applications using this CCID to do this.  You
      could also make a new CCID that dropped connections above a certain
      packet loss rate.
      CP: Working at 50% packet loss rate is not a priority for VoIP.
      EK: The figure is not 50%, but 20%.  Keep in mind, however, that
      regular TFRC is 5 to 10 times worse.
      SF: The transport protocol should still ensure the maximum rate is
      controlled. This is true of all applications.
    Magnus Westerlund (MW): I want to understand the formula for header
    size - the top line in the slide refers to the "true packet size" -
    what is this value?
      SF: This is DCCP payload value size.
      MW: Ah, that's was not clear to me.
      AF: A worked example in the draft would add clarity
      SF: Yes, we could add that.
    Question: The slide also mentions the number of 1460B, as a maximum
    payload size.  This size is not fixed, we now have core routers (e.g.,
    in Abilene) that use much bigger MTUs!
      SF: We could use PMTUD to determine the real size.
      SF: It's not clear what we need to do in this case.
      AF: The same issue applies to IPv6.
      SF: This is described in the spec.
    Question: The rules also specify a minimum packet spacing of 10ms - Is
    this necessarily a good number?  Higher rate codecs also exist (even
    unusual VoIP ones at 700 kbps).  Is the limit reasonable?
      SF: There are a range of apps. Some networks are limited in
      bytes/sec some pkts/sec.  The number you have (10 ms) is fine, but
      this number makes it VoIP only.  VoIP-mode is mainly targeted at
      MW: A minimum spacing of 10ms is valid for many real media codecs. 
    SF: The draft will be revised soon.
    Magnus spoke about codecs from the viewpoint of AVT WG.  A total delay
    of 200-400ms is typical for whole delivery path.  This has
    implications on codecs.  (see slides)
    Codecs may be categorised as: Narrowband - Wideband - Variable
    sampling rate.  Frame lengths can be either fixed or sample based, but
    RTP payloads can also have several speech frames per packet.  Speech
    may be active (or non-active).  RFC3389 describes Comfort Noise (CN),
    that may be sent during inactive periods (AMR has a SID frame for
    comfort noise).  The rate at which comfort noise is sent varies (and
    is usally a fraction of the size of normal voice codec frames).
      TP: What is the frequency between CN packets? (I have see a lot of
      variability reported.)  AMR sends one CN of size 5B per 8th frame.
      This can vary.
      TP: It could be seconds between frames or could be 1/8 (e.g. SID in
      Steve Casner (SC): There were even some systems that could send a CN
      every frame... although this is an unusual requirement.  He
      described the EVRC, SMV codec in 3GPP2 CDMA networks (between 8.55
      and 0.8 kbps).
      TP: The media frame would need two frames per RTP packet.  - Sally,
      this is an implication for TFRC VoIP mode? Can you reduce the same
      bit rate, but keep the same packet rate (?)
        SF: Yes.
      TP: So I could keep the same frame, and drop the coding rate, and
      stay in TFRC-VoIP mode. Codecs change bit rate, not packet rate.
      CP: This is a big thing - you can change packet size, not spacing of
      SF: VoIP was designed for applications with a fixed spacing.
      AM: Do people really send a separate payload type for CN? - Is this
      MW: I can't comment on specific codecs.
      SC: This was motivated for codecs that did not have payload formats
      for CN (e.g. some high rate codecs). The overhead for changing
      between payload formats is not that high.
      TP: We do support CN using the CN RTP payload type.
      ??: Broad voice uses 5ms codecs.
      CP: This was a main motivation for this codec, but not sure how
      appropriate this is to VoIP(?)
    Most codecs can do some type of adaptive change to bit rate. There is
    a "user" cost in performing a rate switch (impact depends on codec,
    may not be noted - but a user will notice the change in voice
    quality). The higher the base quality, the more the users will
    notice. Switching to a higher codec rate may not improve user
    experience, because they notice a subsequent decrease in quality.
      TP: Realvideo allow a switch down, and a switch up. Changes in audio
      quality are very percievable (much more so than the changes in the
      AF: Is this due to the actual video quality?
      TP: The quality of video can be OK, but small.
      Stephan ?: Studies in the ITU showed that changes between
      narrow-band and wide-band voice codecs can be disturbing. Real
      systems do not do this.
      CP: Modern video codecs can also have scalability.
    You need to know the propagation delay of the path, because this also
    impacts the number of codec frames per RTP packet (loss can also be
    more significant when several packets are placed in the same RTP
    Some important questions are:
      - DCCP VoIP mode can introduce extra jitter, how much extra
        buffering at the receiver is required?
      - Voice activity (DTX) also may have an impact?
    Meeting notes taken for DCCP WG by Gorry Fairhurst
    (gorry@erg.abdn.ac.uk).  Formatting and minor tweaks by Aaron Falk


    TFRC VoIP-Mode Update
    User's Guide Update
    Rate Adaptive Voice Codecs, TFRC, and DCCP