2.8.3 Datagram Congestion Control Protocol (dccp)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-09-07


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 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
Mar 04  Working group last call for spec and CCIDs
Apr 04  Revise user-guide
May 04  Revise charter
May 04  Submit DCCP spec for IESG/IETF review to be Proposed Standard
May 04  Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard
Sep 04  Working group last call on User Guide


  • draft-ietf-dccp-ccid2-07.txt
  • draft-ietf-dccp-ccid3-07.txt
  • draft-ietf-dccp-user-guide-02.txt
  • draft-ietf-dccp-spec-08.txt
  • draft-ietf-dccp-ccid3-thin-01.txt

    No Request For Comments

    Current Meeting Report

    Datagram Congestion Control Protocol Working Group
    Washington, DC
    November 10, 2004
    Meeting notes taken by Ted Faber
    - WG status (Aaron Falk)
    - Comments on spec from working group last call (Eddie Kohler)
    - Comments on CCID2,3 from working group last call (Sally Floyd)
    - Discussion of VoIP & TFRC (Tom Phelan, Sally Floyd)
    WG STATUS, Aaron Falk
    - WG last call for spec CCID[1 & 2].  Some bugs and nits - Eddie will
      cover.  Drafts will be recycled then week long review after.
    - New milestones - User Guide, Charter revision in Spring
    - VoIP Tom Phelan's VoIP fairness issues resulting in Sally Floyd's
      CCID3 modifications.
    - Possible new work items:
            VoIP mode for CCID3
            TFRC extensions 
                    faster restart
                    VoIP extensions
            Recommendations on padding (user guide)
      - Allison Mankin: it probably makes sense to have the TFRC
        discussions here.  However we have to make sure the right people
        are attend.
      - Eddie Kohler: should we make CCID3-thin a possible work item?
      - Tom Phelan: CCID3-thin was a really a thought exercise for VoIP.
        With the discussions on TFRC, we put it off.
      - Aaron: Hmm.  Should we combine CCID3-thin with CCID3-VoIP?
      - Tom: an interesting idea, need to think about it.
    "REVENGE OF THE DCCP SPEC", Eddie Kohler 
    Technical Changes:
      - Header Rearrangement. 
        Switch location of type/extra seqno bits.  Suggestions from last
        call: remove 24-bit seqnos; there is too much reserved space.
        Assessment: No clear gains in space compression from alternate
        header designs see list.
        An alternate header: remove 16 bits of reserved space by letting
        options start mid-word.  Out of conservatism, recommend against
        change.  Comments?
      - Feature Negotiation.
        Clear up allowing preference changes during negotiation.  Removed
        out-of-band feature negotiation due to security implications.
      - Congestion control
        - Eliminated CCID1 - "unknown CC".  Hard to justify, especially
          since it would not work for any existing CCID.
        - When is a packet "acknowlegable"?  Made clear definition.
        - Should ECN be mandatory? (from Perkins) ECN is default and
          encourage ECN.  Not mandatory.
        - Define CCID requirements (from Perkins).
        - Remove Reset Congestion state option
        - Make clear that Data Dropped state is reliable (from Falk)
        - CCIDs must have ack-based cc
      - Packet exchange
        SHOULD report 0-length data/data ack packets to app.  (This is a
        compromise from Perkins:MUST, Minshall:nothing.)  DCCP Resets have
        options processed.  Error in option processing can cause Reset to
        be sent in response to a bad reset.  Timers and backoff rates more
        explicitly defined Comments added to pseudo code - weirdness
      - Ignoring options on Data
        This fixes a DoS vulnerability from, e.g., an attacker sending
        mandatory options which are not understood by a receiver.
        Solution: mark options that change state of connection and say
        these MUST be ignored on DCCP data.  (one small exception)
          Ted Faber: suggest including reasoning for this change in the
      - Security
        Changed analysis in Security Considerations section to describing
        the number of packets required to achieve 50% attack success.
          Brian Rosen: think about avoiding data injection attack - at
          least be concerned about data injection.  A particularly
          annoying attack in multimedia is one where the attacker injects
          a single packet into a stream with profanity.
          Eddie: battling data injection attacks is all about header space
          tradeoffs.  If you use long seqnos, you can avoid the problem.
          Also some apps can deal with corruption.  No way to make it
          application independent.
          Handley: The application designer is the only one who knows
          whether they are more sensitive to header overhead or to data
          injection attacks.  So, it should really be up to them to chose
          large or small seqno space.
          Colin Perkins: The spec needs to include some rationale to
          inform application designers.
          Eddie: already there.
          Allman: Will app writer be able to understand and make informed
          Handley: The spec not place for educating app writers, it is
          read by implementors.  The API is where one puts information for
          app writers.
      - Miscellaneous changes
        Default RTT to 0.2s.  Rather have default timers too long than too
        short.  Checksum coverage tweaked.  Define units for timestamps -
        10 ms units and elapsed times - and allow multiple timestamp
        echoes.  Path MTU section rewritten collect what packets may be
        sent unfragmentable.  Updated IANA considerations section.  Max
        seqno length.
    Open Q's (No consensus):
      - Should not claim to be suitable for interactive voice, seems to be
      - Specify ICMP interactions.  Haven't done it.  Reference TCP??
      - Eddie wants to leave undone:
        * List of Service Codes 
        * Provide sample implementation of Init Cookie
        * Make a short glossary
        * Multiple service codes per port considered harmful (Not what
          users expect - more than one app listening per port?)
          Colin Perkins: sysadmins will say "you do what??"
          Allison: SCTP does this, so sysadmins understand this.  If
          *Bellovin* says it's OK, that's a strong endorsement.
            Colin: This is not my experience
          Handley: The intention of 'service codes' is to increase the
          flexibility of firewalls beyond port-based rules
            Eddie: Not all spec authors agree with Mark H.
          Colin: Training and confusion
          Randall Stewart: Firewall guys only look at ports in my
          Eddie: Expect firewall rules to port filter
        * Aggression Penalty reset considered harmful.  Consider data
          injection in this.  Discourage this, but bring out the issues.
        Aaron: An additional question I raised on the list: IPSec SPD
        proto/port #.  Does this imply a change IPSec implementations or
        spec?  Will someone carry this to them?
          Allison Mankin: IPSec almost never use ports.  Feature exists,
          Aaron: Did SCTP have problems with this?
          Allison: SCTP multihoming issues made this big draft
          Handley: Service codes do not affect IPsec.  Flow association is
          done the same way using SPI and IP addresses.
          Colin: You mean 2 application on same port?
          Eddie: You can do this with TCP.  Service codes restrict what
          TCP might do added info for firewalls.  May not go to a
          Handley-service code only world.
          Aaron: what about traffic inside a tunnel??
          Colin: IPSec needs to be aware of service codes.
          Allison: I don't think you're adding anything new.
          Colin: Don't know enough to comment on IPSec
          Aaron: (summarizing) It appears that there no implications for
          IPSec protocol changes driven by DCCP.  There may be
          implementation changes to support a new protocol (since SPDs
          index based on protocol (and IP address, port number).
      - Status: main feedback from Mark Allman, Aaron Falk.  No open
        questions.  Several clarifications summarized below.
      - Byte Counting - Why include it?  Is only at Experimental for TCP.
        A minimal version of byte counting, recommended by Mark Allman,
        will go into the revision.
      - Ack ratio - rapidly changing cwnd can cause much feature
        negotiating during congestion on forward path.  Spec now restricts
        re-negotiations to once per RTT.
      - Q: Why at most 1 RTT sample per RTT? Added clarifying text to
      - Changed minimum for sshthresh from 2 to 1.  (Probably doesn't make
        any difference.)
      - ECN - Specify that congestion window increased only for non-ECN
        marked packets.
      - Initial CWND: Clarified that the exact rules if RFC3390 apply.
      - CCID 2 masquerading as CCID1. Killed CCID1, so this is a
        non-issue.  ---
      - Feedback from Falk, Allman, Pengfei Di, Ladan Gharai, David Vos
      - CCID3 spec difficult to read.  Revised to include more text from
        RFC34448 but did not do complete rewrite.
      - Why so many ways to convey loss: Ack Vectors, Loss Intervals, and
        ECN. If only one way could be provided, it would be Ack Vectors.
        Loss Interval method is for senders that want to offload work to
        receiver. If ECN is not used Loss Event Rate is sufficient and
        still more work is done by the server.
          Eddie: agree that we need all three.  Should we require loss
          intervals in all cases?
      - Always send loss intervals is mandatory and the other 2 methods
        are optional.  Claiming no-ECN makes easier for receiver, note
        that this is a negative incentive for ECN.
          Sally: Prefer either AV or LI, but not strongly; would not
          oppose LI mandatory
          Tom Phelan: Don't like AV because it looks too much like
          reliable transport
          Colin Perkins: AVs are big.  Please don't make them mandatory. 
          Sally: now LIs are mandatory, end of discussion here.  Continue
          on the list.
      - Potential Changes moved to appendix
        * initial sending rate increase to more than 4 pkt/RTT?
        * < 1 ACK/packet when data rate is less than 1 pkt/RTT?
        * more than doubling the sending rate from one RTT to the next?
        * faster restart after an idle period?
      - Clarified a limitation on RTT computation
      - Some Loss Interval clarifications.  Add initial rate based on
        RFC3390.  What does the Loss Event Rate Option report when the
        loss event rate is zero?  Clarifies that ECN either use AV or LI,
        now changed to must use LI.
          Aaron: another revision forthcoming?
          Sally: yes, number changes and stuff we've talked about today. 
          Eddie: would like more feedback on readability.
          Sally: if there's more rewriting, Eddie will do it. :-)
      - File transfer type applications are greedy/VoIP sources aren't.
      - Simulate G711 VoIP.  Sim details on slides.  96Kbps sources
      - Dumbell topology
      - Chokepoints 1.5 Mb/s 256Kb/s 45 Mb/s
      - 1 TCP/ 1TFRC 1.5 Mb/s looks OK.
      - 6TCP /1TFRC Fair share 214K TFRC driven down to 20Kb/s (!)  CBR
        w/o TFRC flow loses packets, but throughput is OK.
      - Packet rate vs. Byte rate (Dado Colussi analysis) TFRC gives a
        packet rate - in terms of packet rates the earlier sims are
        getting their fair share of *packets*
      - VoIP mode for TFRC.  Special dispensation for small flows and bps
      - New ns gives some differences!?
        Aaron: I can't tell from the graphs whether this is adequate
        quality at the receiver or not.  Are you under-running the playout
          Tom: tough to tell
          Sally: updated some defaults in NS which may explain this
          Steve Casner: what's the delay
          Eddie: spikes would cause loss in CBR, too.
          Tom: existing systems do work
          Handley: if TFRC is sending smooth and the link is inducing
          burstiness have to smooth it out.  Otherwise, you are evaluating
          the quality of the link conditions, not the congestion control
          Aaron: Perhaps you need to measure at sender side to avoid
          interference by the link conditions.
          Sally: do you see this much burstiness because of the reverse
          path traffic?
            Tom: bursts are there with or without reverse path traffic.
        Brian Rosen: Is DCCP/TFRC inappropriate for any application?
          Tom: Streaming video should work, but not streaming audio packet
          size at issue
          Mangus Westerlund: packetization is the issue
          Handley: streaming audio should use big packets for header
          Eddie: non-real-time streaming audio makes big packets
          Colin: buffering latency is an issue - more buffering makes life
          easy.  Can't say DCCP/TFRC is unacceptable for all applications
          Tom: link delays are a big deal for real-time apps, drives need
          for small packets.
          Stefan Weger: video has variable packet sizes - how does that
          affect this analysis?  (Stuff a frame into as few packets as you
          Westerlund: buffering modeling needs to be looked at.
      - DCCP user guide impact.  VoIP mode will need to be added and w/o
        VoIP mode, no guide. :-)
        Tom: wait for VoIP?
        Aaron: are there common parts of the User Guide that can move
        forward without the VoIP issue resolved?
        Eddie: Dunno how long VoIP will take, but prefer one document
          Aaron: why?
          Eddie: a lot of strategies will be for interactive applications
        Aaron: so, is there only 1 profile of interest??
          Eddie: There are some things (API) but TFRC problems dominate document
        Aaron: packet size stuff seems to dominate
        Aaron: not a lot of help for Tom.  Interest level? Nothing to say?
        We need to give advice (the protocol has lots of knobs) and need
        the User Guide to convey that.  What goes into the document should
        come from application community, e.g., AVT folks.
          Colin: Might want to start from where we know it works.
            Aaron: for example?
            Colin: Streaming video.
        Brian Rosen: No evidence that DCCP works!  Don't think so, but
        certainly no evidence.
        Eddie: I agree wrt the user guide.  Point of user guide is to
        describe use.  No demonstrated use, tough to write a guide.  Also,
        there isn't a massive universe of implementers waiting for the
        guide.  Sorry it seems to be languishing, but I think this is the
        right speed.
        Colin: need to talk about working cases.  If none exist -> short
        Tom: API view or users' view...
        Aaron (summarizing): focus now on getting VoIP working and think
        of the Users' Guide as a place to document what we discover works.
          Tom: I'm in general agreement.  I can publish a simple revision
          to keep it the draft in the repository.
        Colin: There are easier cases than VoIP.  Demonstrating one would
        be good. 
          Brian Rosen: Want to see it work.
          Aaron: implementation proof not a requirement for working on the
        Stewart: I note that there is DCCP code in FreeBSD Kame?  Does it
        work?  If so run it.  Easy to do simple tests if the code works.
        Colin: Some people adapting media tools to be congestion aware
        Allison: VoIP is rolling along w/o congestion control.  Lots in
        play.  Also, IP video is a good spot for potential DCCP use.
        Voice is not the big issue.  Creation of a DCCP standard may drive
        Colin: DCCP can't be worse than TCP video streaming.
        Tom: sim 1-way media
        Handley: DCCP is red herring - congestion control is at issue.
        This working group can't cover the whole space, but there is
        plenty of prior work in applying CC to multimedia congestion
        control.  No one believes that DCCP solves it all.  Lots of this
        stuff is off topic.
        Rosen: Interactive video unlikely to work.  DCCP is solution w/o
        a problem
          Aaron: I don't think you are hearing what Mark just said.  He
          said there *is* prior work and that there are some other
          applications for DDCP.
          Brian: I have never seen an implementation of CC for streaming
          media that works.
          Tom: I haven't either.
          Eddie: DCCP is not the streaming media congestion protocol.
          DCCP is a thing that *might not* help anything, but I believe it
          will.  Started from abstractions to protocol is interesting and
          I think useful.
          Colin: (Again,) consider radio streams over HTTP.  I think that
          the CCIDs in DCCP are at least as good.
          Sally: agree with Colin.  I think that CCIDs work for streaming
          recorded stuff.  Exploring new things.  No one MUST use DCCP.
          Mangus Westerlund: I have implemented slow switching of media.
          Have to adapt media to available bandwidth.
          Handley: different application - Radio astronomers.  Send big
          data - no reliability, but don't kill the network.  
            Aaron: Please writeup something about this application and
            send to list.
      - NB small packet TFRC was an open issue in the TFRC spec
      - Issues for VoIP traffic
        * Small packets - fairness in pps does not result in fairness in
        * Measuring Congestion - packet loss vs. loss event rates
        * Faster restart after idle
      - VoIP: fairness in Bps.  TFRC gens packets/sec.  VoIP mode gives
        b/s with TCP flows having 1500 packet/sec.  There is an optimistic
        assumption buried here that network will continue to be limited in
        bps not pps, this may change.  (At most 1 pkt/10 ms.)
        Colin: some people doing this at 5ms packets
        Sally: might not want to support that.  Good to know.
        Sally: might want to go to a private net, too
        Tom: Who's doing this?
      - Idea
        Calculate the TCP rate from the TFRC equation with 1460 bytes and
        adjust for VoIP headers (40 bytes) (we know it's an
        approximation).  Minimum interpacket time is 10 ms.  Doesn't
        restrict anyone Want to give an incentive to not have
        unnecessarily small packets.  Generally will have to eat the 10 ms
        Aaron: can you use the actual header size?
          Sally: if you know it.
        Casner: strict interval?  Average?
          Sally: I wrote strict min, could be persuaded to get average.
        Tom: skew in the network means that to hit 10ms interpacket time,
        one will have to use longer.
          Sally: thanks for pointing this out.  I'll change it to 9ms min
          interpacket time to allow for a nominal 10ms and with some
          margin for skew.
      - Slide of sims, that show basic good results
        Colin: talking about packet sizes?
        Sally: yes
      - Congestion indication
        VoIP uses loss event as congestion indication.  NB this is packet
        loss rate.  Packet size and sending rate && burstiness affect this
        rate.  Small packets seem to be less likely to be lost than large
        packets.  Many variations.  Lots to look at.
        Colin: Sims use very large packets.  Recommend using 30 payload
        bytes per packet.
          Sally: I used Tom's 120Bpp.
      - Fast restart after idle:
        Sender knows more when restarting than when starting.  Never
        reduce the sending rate below initial window.  Quadruple up to old
        sending rate after restart.  Sally's opinion clearly fine for VoIP
        or other flows w/constrained sending rate.
      - May want to split these two ideas into separate tracks/documents. 
      - The next step: Allow TFRC to send more than twice the reported
        receive rate if allowed by send rate, rate has been sustained in
        the past no congestion in the recent past.  Justification: some
        knowledge exists.
      - Current NS-2 code has the VoIP variant and RFC3390 initial sending
        rate.  A few more updates are needed: add RFC3390 sending rates
        after idle; faster restart; overhead for packet headers.
      - Padding.
        Sally: Want to allow padding when changing video rate, but there
        are probably constraints to keep padding low.  The padding is used
        to probe for available network bandwidth before making a codec
        rate change.
        Aaron: This is open issue.  Talk.
        Mark Allman: if you are adding fast restart, should you also
        consider faster slowdown?
          Sally: yes.
        Eddie: pseudo code in draft.  Check it out.
        Dado: how do you want to change TFRC response function?
        Sally: TFRC is very optimistic in several cases.  Not much more
        aggressive than most aggressive TCP.  Current response function
        may be OK.
    CLOSEOUT, Aaron Falk
      - We've last called spec && CCIDs 
      - Next is to checks the revisions of the drafts
      - New work items:
        * CCID3-thin
        * CCID3-VoIP
        * something about mobility
        * updating TFRC with VoIP mods
      Allison: suggest sending drafts to AD review and make final fixes
      there.  Then IETF last call.
      Aaron: We still need a 1 week review period for the working group to


    Revenge of DCCP Spec
    Last Call comments and changes for CCID 2
    Last call comments and changes for CCID 3
    TFRC with Self-Limiting Sources
    TFRC for Voice: VoIP Variant and Faster Restart