2.8.3 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 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-01

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-04.txt
  • - draft-ietf-dccp-problem-00.txt
  • - draft-ietf-dccp-ccid3-04.txt
  • - draft-ietf-dccp-user-guide-00.txt
  • - draft-ietf-dccp-spec-05.txt
  • - draft-ietf-dccp-ccid3-thin-00.txt
  • No Request For Comments

    Current Meeting Report

    Datagram Congestion Control Protocol WG (dccp) Monday, November 10 at 1530-1730 ================================ CHAIR: Aaron Falk <falk@isi.edu> Minutes taken by: Gorry Fairhurst <gorry@erg.abdn.ac.uk> Slides at: www.icir.org/kohler/dccp/ietf58 Note from Agenda: As we are planning to have a working group last call (WGLC) after IETF-58 for the spec, CCID-2, and CCID-3, this meeting is the time to raise any showstoppers. We'll spend most of the meeting discussing changes that occurred to the spec as a result of the reviews we held over the summer. AGENDA Agenda bashing,, schedule, discussion, etc 10 min Design Review Followup 60 min Open issues Changes made No change needed CCID-3 Thin discussion 15 min User Guide 15 min ============================================================== 0. Agenda bashing <no agenda changes> ------------------------------- 1. WG management stuff CHAIR'S COMMENTS Most of the activity in the working group since the IETF-57 (in Vienna) has been focused on addressing issues raised in the review process which included expert reviews and a design review presentation in Vienna. The current priorities for the working group are a) get the spec and CCIDs to working group last call (wglc), and b) start in earnest on the User Guide. The current revision of the spec (-05) incorporates a lot of new text and may design changes as a result of review comments. These changes have generated additional comments and review. So, it is unlikely that the next rev will be ready for wglc. Nor is it likely that the document will be settled in November, as our current milestones state. Additionally, the User Guide has not been revised since October 2002. Therefore, the schedule for the working needs to change. (The issue of the User Guide will be addressed later.) The current milestones (agreed to at the Vienna meeting) are: CURRENT SCHEDULE Sep-Nov 03 Incorporate review and implementation feedback into spec Oct 03 Collaborate with avt wg on API IETF-58 Prepare for WGLC Nov 03 WGLC for spec, CCIDs Dec 03 WGLC on User Guide The new proposed (& more detailed) schedule pushes wglc out another month (ambitious but possible), adds some additional revisions in, and gives a plan for the User Guide. PROPOSED SCHEDULE IETF-58 Collaborate with avt wg on API IETF-58 Prepare for WGLC Nov 03 Revise spec, CCIDs Dec 03 WGLC for spec, CCIDs Dec 03 Publish user-guide rev1 Feb 04 Publish user-guide rev2 Mar 04 WGLC on User Guide This will be sent to Allison, our Area Director, for approval and posting on the charter web page. It's important to keep in mind that the priority is producing a quality spec and, therefore, the schedule may slip out if additional time is needed to get adequate review or resolve new issues. Nevertheless, WGLC is an important milestone and has the added benefit of encouraging broad and serious review. So, we're going to stick with this plan for the time being and make coarse corrections as necessary. Discussion: Mark Handley (MH): Wednesday AVT WG meeting will talk about the API, do attend. Colin Perkins (CO): This seems time scale seems remarkably tight. AF: We have everything on the table. CP: Have you allowed sufficient time for ideas to percolate? Is one week sufficient time to let people comment? MH: There are some fairly significant wording changes needed - which will be out in a week's time. This second one week review period is about the clarity of the document. - Adding extra time doesn't create extra reviewers! This schedule may be OK. AF: Do you want to suggest a change to the schedule? CP: If you can get a handle on this, its OK. ------------------------------------------------------------------------ -------------------- 2. Open issues that need to be resolved before WG Last Call (by Eddie Kohler (EK)) Datagram Congestion Control Protocol Specification http://www1.ietf.org/internet-drafts/draft-ietf-dccp-spec-05.txt Feature negotiation - used to be "California style", now negotiations have been stream-lined into one exchange. No simultaneous negotiation. Extended sequence numbers. DCCP-Sync to reduce cost of attack. Discussion: CP: Thinking about the recovery from loss - Is this a case where you have to wait for a round trip time? And so, what do you do with the data that is sent? EK: The reason for the sync is because you saw a lot of loss, so yes this loss will continue during the re-sync. CP: Do you have to buffer data while a DCCP Sync is sent? EK: You don't have to buffer at the receiver after a Sync. The packets may, or may not, be accepted. CP: Looking at the figure on the slide, DCCP-A (right) receives data with a bad sequence number, and then... EK: This is dropped. CP: That's fine. MH: This data must be dropped to ensure DoS prevention, but an implementation could decide to keep it, and use it later. EK: That's not in the Spec. CP: If everything is working, you *may* want to buffer it, and then later use it. "Mandatory option" added. EK: This is a strange term! Greg White: Is it better to call this a "required option"? EK continued to review Open Issues: - Moved many SHOULDs to MUSTS - More info on DCCP-Reset and Ignored - CCID-specific Reset Reasons - removed language saying DCCP spec would automatically follow TCP & TFRC Open Issues # Non-Data-Packets, NDP EK: keep it? drop it? reduce it to 1 bit? The goal is to make DCCP sequence numbers useful to applications. However, there are problems with ambiguity and interest by apps. Recommendation is to make NDP a feature. EK: Does anyone want to use the NDP value? Magnus Westerlund (MW): Most applications implement a sequence number, why can't we allow this in DCCP providing it for future applications builders? EK: We can , but it's not necessarily what they want. The required framing is not so clear, applications may send multiple chunks and want to number each of them, some chunks may be more/less important. It's a good argument to have the feature, but its not clear all applications will use it. MH: A new application might like to have the sequence numbers present. For RTP, this is a non-issue, it uses it own numbering space. For other generic applications, this could be good. The argument is good for making it available. It would seem for applications that it would be better to have a segment number space for only data packets, but this hard for DCCP the way it is designed. The current proposal seems to be as close as optimal for applications. CP: An application may want to use the DCCP sequence number, because it cares about the number of bits in its own headers. EK: The advantage of the NDP option is it is not required for most data packets - it occurs on non data packets themselves, plus one following data packet after a burst of non-data packet(s). MH: This moves the sequence number space out of the DCCP base header and in to the non data packet header. CP: This is probably Ok, but it needs thought. EK: This came about, from stealing one bit for the X field and lead to questioning the usefulness of the remaining 3 bits ad a NDP count. CP: Yes - 3 bits is not much use for this, so we should do something else. Connection identification nonces Replaced by sync and new mobility ID. Need to look at the security issues of move and check this is OK. There's a potential attack where an application grows a large window using small packets, and then switches to large packets. In fact, simulation shows this may not be as beneficial to the application as it may seem. Data Dropped & TFRC and CCID-3 Signals "I dropped this packet because my receive buffer is full," Sender should slow down. There's an open question of how to do in TFRC? Author's recommendation: recommend a decrease in rate to sender. Packet Sizes CCID specified in packets, not bytes. But applications determine how long packets are. An app may build up a large window by sending small packets then changing to large packets. Author's recommendation: Observe that packet size attacks don't win in the long run. Plan to remove packet size limit but add text that implementations check for packet size gaming. Payload Checksum and link CRCs To be discussed with Gorry Fairhurst and others, but not a core issue. I think we know what we need to decide, but first is it useful? Tom Phelan (TP): Payload checksum option: Applications would usually choose the partial coverage, because they really want to just do their own action on the payload. A check other than the 1s complement is good, that is, one stronger than the Internet check would be better. EK: An application may want to receive a packet that's got a good header, but also know whether the payload is good or bad. Application can use this data (and utilize the signal -if it wishes). The congestion control procedure can also know the data got there, and avoid the "cost" of a loss event, even if there was a payload error. MH: The payload coverage decouples the congestion control from the application response. The rationale of choosing the Internet checksum for the DCCP header (main checksum) isn't the same case for the payload checksum. A different checksum (e.g. following SCTP, is quite possible). TP: A stronger checksum is better for this. Stuart Bryant: If we use DCCP for PWE with partial coverage and want to implement this for the switch fabric, the hardware can only see the first few bytes of each packet and really would not want to have the cost of the payload coverage checksum. EK: It's an option only, you don't need to use the Payload Checksum option - it's an *optional* option. Voice over IP Issues Dave Oran (DO): So the title of the slide says VoIP, rather than multimedia. VoIP only exchanges very small chunks of data. For VoIP, i can choose to double the packet sending rate (in bytes per second), by simply using bigger packets. SF: TFRC is specified for a source with packets of only the same size. A new spec would be required to specify fixed sending rate and variable packet size. DO: So, it's not really VoIP? - the choice of 120B v 240B VoIP payload is an easy choice for a VoIP codec. Counting packets to control a low bandwidth application is weird? EK: This is for lots of applications - not just VoIP. TP: Changing the packetisation rates also reduces the average packet rate. Increasing the packetisation rate also reduces the bytes per second for the same codec (since there are less overhead bytes/sec). ------------------------------------------------------------------------ -------------------- 3. Review of fixes for problems that were identified in design review (by EK) Partial checksums EK: Should the checksum coverage unit by 8 byte or 32 bit chunks? CP: 8 bytes is really bad. Considering the AMR codec format for RTP (the main use), 8 bytes is too much! EK: Is 56 bytes enough? CP: I think so, I will check. Q: For video codecs it *may* need more! EK: Why? How much? Q: Don't know! EK: Can anyone who has *any* views or knowledge, please tell the list? Checksum type (Internet vs. HMAC/UMAC/whatever) ID authors believe internet checksum is good. Data Dropped - ID authors say the data is received. Is endpoint congestion, still congestion? - ID authors do not believe so. - Data Dropped (original comment from Greg Minshall) Semantics of packet receipt should be different. Do you ack when packet goes into receive buffer or to app? Authors disagree: endpoint drops should not be treated as congestion. May mention possibility of treating buffer loss as congestion in draft. MH: if you do, don't mess up congestion control calculations for RTT. Mobility ID authors wish to keep this. Sequence number security Looked at, and kept. DCCP CCID-3 Thin http://www1.ietf.org/internet-drafts/draft-ietf-dccp-ccid3-thin-00.txt A simple DCCP with TFRC designed for lightweight implementation processing, all features are fixed, ACKs are fixed format. Should we allow ECN (and NONCE verification)? Mike Luby (ML): What is the target device? Why would someone use this instead of the full spec? EK: Simple devices that do not want to do a full implementation or use an implementation where this is hard. e.g. Mobile devices. ML: So you took out mobility? Which is what small mobile devices probably need! MH: A disadvantage is that to do this, all DCCP servers would need to support this, This requires alternate code implementations to support the 3-thin profile. EK: That is fair. However, it's not as hard as making a new CCID! MH: Should we review all the things that will need code-path changes? - These may need much more thought, and if we do this we could make the design simpler. ------------------------------------------------------------------------ -------------------- 4. CCID-3 Thin discussion, hum on making it a wg product.. AF: Should this be a WG item? EK: We should take this on - we heard comments from people who feared complexity. This would be a simple mechanism for devices that do not wish to use other CCIDs TP: I was finding it hard to get people to implement this in DSP chips! We need this so that it could be used! AF: What are the devices? - Mobile? TP: Large voice devices that have to handle lots of connections. AF: Who would like to implement this? Response: few (2) AF: Who would like to do any CCID? Response: few (2) AF: Who should take this on as a WG item? Response: lots (24) AF: Who not? Response: few (2.5) MH: Even if this is a WG item, we can evaluate this later if it is a bad idea. AF: But I'd like to see this WG wound up soon! AF: Eddie you mentioned several issues that may require further IDs in the talks (where there 3 things?) Do they need more IDs? EK: Issue 1: Can you send below or above a TFRC rate? - Could be done. EK: Issue 2: During slow start or after slow start can you send more after an idle period (e.g. more than twice)? - Research. Probably not one I would choose to do. EK: Issue 3: Variable packet sizes. MW: I don't think CCID3-thin should be done now. I think the WG is busy, and should do its work. The point is that we now know this can be done, we can come back to this later. AM: TSVWG would like someone to work on variable size TFRC - This is within vision, but good research. Now is a good time to do this. There's no reason to finish straight away. But, we also do not need to do it here! AF: Could it be done somewhere else? AM: Yes, TSVWG could do it. Especially since we now have time, given TCP will be handled by a separate WG. MH: We don't have to close WGs, because this needs to be done. They can work on the job until its finished. AF: We want to think carefully, before we start accepting all new work items under the current charter. MH: DCCP work should be done here, not somewhere else! AF: Right. SF: On Issue 3: Variable packets is a good topic, and has been on my list of things I'd want to do for some time, and I'll work on this. On Issue 2: It's research. On issue 1: It's not a big deal - its a change to the CCID. AM: CCID3-Thin: How hard is it to get a user profile? Figure out who wants to use it? How do we do this? AF: So, should we defer adding it as a WG item? - Writing CCID3Thin was a good thought experiment, and we learned it can be done. If we leave it for a moment, then we can leave it as open, while we work on the other things. EK: CCID3-Thin is a simple draft that does not require much work, it's within scope. We can do it here. We could do several, if we need for different use cases. Q: Should we take it on as a WG item with a long-term schedule? AM: I worry now about several versions of 3Thin - That sounds like you will be introducing interoperability problems. EK: We don't expect 100's of profiles, it could be a small number. AM: It's still risky, options are problematic. We have had bad experience of profiling anything in the telephony space - usage profiles have not been good - Adopting it today is not good, let's think about how to express the task and come back to this. Bob Braden (BB): I am deeply impressed by the way DCCP is a swiss-army knife of a protocol. RSVP was hard to sell because it was too complicated, let's not do that again. Think about this ID as a proof that a sensible subset exists. TP: I would not like to see a whole bunch of 3Thin profiles. We need one. MH: I'm agnostic on adopting this. I can think of reasons for not: (i) It requires state machine changes - several profiles could wreck the design of a DCCP server - a good reason for not doing too many. (ii) CCID4-Thin could be just on the horizon - variable sized support may be needed. Its a good case to wait, EK: I hear it is good to look at this, at least to think about it. - No decision taken to adopt this. ------------------------------------------------------------------------ -------------------- 5. User Profile (Tom Phelan) Suggestions on what the user guide should look like. Inputs requested: scenarios; which CCIDs to use; etc. AM: Thank you for this contribution!! AF: How many people are following the WG mailing list and drafts? Response: ~two dozen AF: How many people will be Seoul at next IETF? Response: ~one dozen ------------------------------------------------------------------------ Meeting closed at: 17:18 ==============================================================


    Datagram Congestion Control (DCCP) working group
    DCCP Nonissues
    DCCP Open Issues
    DCCP Resolved Issues
    DCCP CCID 3-Thin
    DCCP User Guide