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 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-10

Chair(s):
Aaron Falk <falk@isi.edu>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
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.

SCOPE

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
APR 03  Publish DCCP protocol as proposed standard (including applicability statement)
APR 03  Publish TCP equivalent congestion profile as proposed standard
APR 03  Publish TCP Friendly Rate Control congestion profile as Proposed Standard
JUN 03  Publish document providing guidance to users of DCCP as an Informational RFC.
Internet-Drafts:
  • - draft-ietf-dccp-ccid2-01.txt
  • - draft-ietf-dccp-problem-00.txt
  • - draft-ietf-dccp-ccid3-01.txt
  • - draft-ietf-dccp-user-guide-00.txt
  • - draft-ietf-dccp-spec-01.txt
  • No Request For Comments

    Current Meeting Report

    DCCP meeting notes
    March 19th, 2003
    IETF-56
    
    
    ============================================
    
    Notes taken by Aaron Falk <falk@isi.edu> and Gorry Fairhurst 
    <gorry@erg.abdn.ac.uk>.  Presentations available at 
    http://www.isi.edu/~falk/dccp/ until the IETF-56 proceedings are online.
    
    
    ============================================
    
    Chair's Summary - Aaron Falk <falk@isi.edu>
    
      Introduction
        Other possible applications: pwe3, nfsv4, tls, ipfix
        Plans for a detailed protocol review
        Would like to do a public design review (at July 2003 IETF)
        Some implementations in Summer 2003
    
      Schedule
        The April milestones are not going to be met!
    
      Suggested new schedule for comment:
        December 2003 - Publish specs
        February 2004 - Publish user guide
        - to be confirmed with AD (no objection from AD or group to the
          proposed schedule) 
    
      Open issues the group needs to close: 
        Header only checksum (UDPLite)
        Mobility
    
      Open issues the group doesn't need to close:
        RTP optimizations (for future rev)
        Long, fat network performance(for future rev)
        TFRC changes (will be handled elsewhere)
        
    
    ============================================
    
    DCCP Spec Status - Eddie Kohler
    
      - ISSUE: will link layers support partial checksums?
    
        - a: 3Gwireless links
    
        - Allison: there's a mode in GSM & UMTS (not deployed yet) with a 
    no-error checking option & a partial checksum for audio.  A large 
    deployment of these links.  (Some say this is a bad engineering 
    decision but it remains a fact.)  So we should check this, and try to 
    write up a list of known links that need this, can support this, and how 
    they work.
    
          There is an argument that this could be a bad tradeoff in 
    radio/link design that will not be repeated in network designs in the 
    future.
    
        - Charles Moinia: I work with fiber channel.  We have strong 
    end-to-end CRCs at application layer and, so, are agnostic to the use of 
    partial checksums at transport.
    
    
        - ???: Don't know of wireless links that exist that do this. It seems 
    like these discussions are different to UDPLite, or are they the same?
    
          - Eddie Kohler, EK: The issues are the same.
    
        - Michael ??: most links do full packet checksums.   However, some 
    links want to send error-ed information. 
    
        - Stuart Bryant: Some PWE3 services operate at high bit rate and there 
    may be too much expense in doing full checksums, they'd prefer to keep 
    processing to a minimum. 
    
        - Mark Handley, MH: 
    
          1. Packets get corrupted in routers, links aren't the only place 
    errors occur.
    
          2. Dccp naturally separates congestion and corruption.
    
          3. This is easy to do in transport, costs only four bits, has 
    minimal complexity.  It enables wireless folks to tailor links to work with 
    separated congestion & corruption.
    
          - Allison: The need for UDPLite needs to be documented.
    
          - Sally: open research issue is how transport protocols respond to 
    links with heavy corruption
    
        - Mark: (authentication): Authentication is a big deal, for some 
    services. AH will work with or without the support of a DCCP checksum over 
    the payload, since the IPSEC AH header protection is so much stronger than 
    the DCCP packet checksum. DCCP may therefore use either partial or full 
    protection - AH still provides strong coverage.
    
        - Colin Perkins: The usefulness of AH depends on what the intended 
    purpose is,
    
        - Colin Perkins: There's also the idea of 
    application-layer security, e.g.  Secure RTP work. This also raised 
    issues in this area of applications-level security.
    
        - Allison: DCCP needs to provide plenty of structured 
    considerations and justification on this topic.  Including guidelines to 
    designer about why this feature is there and what it's used for.  Also, 
    need a guideline about authentication.  Actually, the 
    authentication issue may cause this feature to be blocked in the IESG.
    
        - Mark: The DCCP editors are not religious on this issue.  DCCP just 
    provides an easy way to do it.  However, we'd remove this feature if it 
    would cause the protocol to block.
    
        - Randy Presun: I'm trying to understand authentication issue.
    
          - Mark: DCCP would do authentication and application would reject 
    error-ed payload.
    
          - Colin: That depends on what you are authenticating.  You may just 
    want to authenticate the sender, not the payload (which works with 
    partial header checksums).
    
          - Allison: partial checksum may render MAC useless (as in SRTP) [Ed: I 
    lost this comment.]
    
          - Eddie: One solution is to insist that IPsec use requires 
    disabling partial checksum.
    
    	- Colin: not sure about this, there may be applications where you 
    wouldn't want to / need to do that.
    
        - Gorry: if you want to authenticate the whole packet, just disable 
    partial checksums.
    
        - Jose Rey: Other networks also exist which could provide a link 
    service that does not necessarily employ a frame CRC. The UMTS network has 
    the possibility to deliver possibly corrupted payloads.  This feature is 
    currently unused.
    
        - ??: Endpoints may not know if IPsec is in use, e.g., tunnel mode, so 
    one can't rely on IPsec authentication.
    
        - Julije: Are checksums end-to-end?
    
          - Eddie: Yes.  We'll add a sentence to the spec saying checksum is 
    e2e, not hop-by-hop.
    
        - ??: some link layers try a few times and give up.  one _could_ say try a 
    few times and send error-ed.
    
        - Mark: send examples of links and apps which would use this to the 
    mail list.
    
      - ISSUE: Error-ed link bit
    
        - Mark: This bit must only a hint that errors might occur.  Errors can 
    still occur regardless of whether bit is set.
    
        - Gorry: Is there a link CRC? Eddie: yes.
    
        - Gorry: Not protecting the destination address raises the issue about 
    what you are delivering to the Network receiver - and where in the 
    network it may end up by accident. I think we must protect the header.
    
          - Eddie: Good point (this proposal appears dead).
    
        - Julije: It's bad to have transport mess with IP layer (in 
    corruption allowed bit).  propose asking IP layer to add a bit for this 
    reason. [something else...?]
    
          - Eddie: need to bring this up on list
    
      - ISSUE: proposal to change 4 bit CSlen field to one bit.
    
        - Colin: You may want variable checksums to, say, cover the RTP 
    header which can be variable if it goes through a mixer.
    
        - Mark: I can imagine a lot of applications which might want their 
    headers protected.  The question is: is it worth spending three bits for 
    this purpose?  Complexity is also a consideration.
    
          - Eddie: API might specify an RTP header is covered by the 
    checksum, whatever length.
    
        - Colin: I feel there are uses for the four bits of control over 
    checksum.
    
      - ISSUE: Welzl option to checksum only payload.  The motivation was that 
    UDPLite wanted to cover the next level protocol headers.  There is a use for 
    this, it is good for higher layer headers to be protected - A mask, 
    allowing arbitrary bits to be protected, is not probably useful.
    
        - Colin: I agree with proposal not to adopt this option; we can get all 
    we need with the four bits.
    
        - Mark: I like this option.  It provides a general purpose 
    mechanism for passing known corrupt packets to the upper layer.
    
        - Colin: It adds a lot of overhead.  And, the apps which could use this 
    are delay sensitive.
    
      - ISSUE: NATs changing ports, etc
    
        - Aaron: STUN, TURN can find ports.
    
        - Colin: but those tools only work in restricted cases.
    
        - Eddie: We don't want to rely on deployment of these 
    technologies.
    
      - ISSUE: Purpose-Built Keys
    
        - Aaron: anyone here following this topic?
    
          - Yogesh: The send working group is using a similar mechanism.  
    There is a problem with PBK in the computational cost of generating both 
    keys.
    
      - ISSUE: NATS
    
        - Aaron: The issue is really not "NATS can't change seq numbers" but 
    "middleboxes..."  There are other boxes out there besides NATS that 
    change sequence numbers.
    
      - ISSUE: RTP Interactions
    
        - Mark: There was a long discussion at the previous meeting about 
    header size.  The size, was often not critical, since critical links would do 
    there own link-layer compression. We should avoid making the transport more 
    complex and hence making link compression harder.
    
      - ISSUE: Long, Fat Networks (LFNs)
    
        - Mark Allman: Do you require TCP friendliness?   
    
          - Eddie: No.  For a while DCCP should be based on TCP.  But there is no 
    long term need.  The spec says to follow IETF standards.
    
        - Allman: Is using seq number size based on TCP friendliness the right 
    thing to do?
    
          - Eddie: This can be addressed in an option...
    
          - Mark: we have no idea about how to do congestion control with 
    these massive windows; but don't want to close the door on future 
    optimizations.  if we need to do cc with million packet sized windows, 
    we'll need to solve this problem. but may just have MB sized packets.  At 
    this point, the problem is not well-defined. 
    
        - Colin: The assumption appears to be that seq numbers are used only for 
    retransmissions and loss information but some apps may want to use them for 
    FEC control which may have a very large window size.  This is really a 
    research idea and probably not an issue but we should think about 
    whether 24 bits is enough.
    
          - Eddie: This is the same concern as having data from an old 
    connection showing up...
    
          - Mark: One can always do epoch counters at application.  Need to 
    compromise between low overheads and very high end problem.  At high end 
    problem you can always add overhead.
    
    	- Colin: The high end isn't that high compared to what people are doing 
    today.  I'm concerned about the bandwidth limits DCCP may be imposing.  I'm 
    doing gigabit streams today.
    
        - ISSUE: LFN Solution List
    
          - Comment: Slow rate apps don't need epoch option, any wraps in seq 
    num space happened longer than 2 minutes; so epoch option is 
    unnecessary overhead and may not want to do it.
    
        - ISSUE: Fragmentation -- Fragmentation was previously brought up as a WG 
    discussion. In summary, the conclusion is to rely on IP 
    fragmentation.
    
          - Colin: Shouldn't we do P-MTU discovery?
    
            - Eddie: This is about supporting moronic applications which may be 
    overly simple and may not want to use PMTU information for request.
    
    	- Mark: If you know you have a large amount of data, do PMTU 
    discovery.  If the application wants to send just a little bit more than 
    will fit into the current segment, then it's not an issue.
    
    	- Eddie: We can't mandate P-MTUD b/c of bad firewalls.
    
      - ISSUE: Shall we use the reserved bits to carry the CCID?
    
        - Mark: I think this is a good idea. One down-side is that this makes it 
    hard for the link to compress this field, since it is in the DCCP 
    header. The ROHC processing may work on a packet-by-packet basis without 
    knowing any negotiated fields.
    
        - Eddie: We'll hear about compression issues later.
    
        - Eddie: There may be too many header parameters open for 
    negotiation. We may need to reduce this, by making some mandatory - to 
    discuss this on the list.
    
      - ISSUE: TFRC & codecs
    
        - Mark: Should TFRC (CCID=3) actually be required to send at the 
    specified rate?  The dynamics issues, etc need to be identified to know the 
    space for implementation. We should add some text.
    
    
    ============================================
    
    Nit Summary for CCID2 and CCID3 - Sally Floyd
    
      - DCCP should track TCP, e.g., in High Speed TCP
    
      - Appropriate Byte Counting
        
        - Allman: I am not quite clear. Are these byte-based things not being 
    used in CCID2?
    
          - Sally: Yes, but we do need to think on a case-by-case basis how 
    these carry forward in DCCP (which is packet-based).
    
      - Mark: There was a question on list which CCIDS are mandatory.  Any 
    feedback?
    
        - Eddie: What's the purpose of a mandatory ccid?
    
        - Sally: So that any receiver can talk to any sender.
    
        - Eddie: Hmm, not sure we can promise feature this in feature 
    negotiation
    
          - Mark: good point, needs careful wording
    
        - Eddie: This is not always needed. A small device may wish to 
    implement just one CCID.
        
        - Mark: If you implement DCCP as a stack, then you must provide the 
    standard set, and we wish to have a fall-back position.  Suggestion that we 
    can amend the spec to include the simplest (single application) case.
    
          - Eddie: CCID1 is another candidate for the fall-back case.
    
    
    ============================================
    
    DCCP Compression Profile for ROHC - Julije Ozegovic
    
      Presentation on ROHC activity considering DCCP header. There are issues in 
    DCCP header design that would improve ROHC processing <see slides>. The aim 
    is to get compression as good as for RTP/UDP.
    
      One optimization suggestion is to change DCCP, so that it can be more 
    easily compressed.
    
      - Mark: (on the proposal for making ACKs part of generic header) Making 
    ACKs a part of the base header raises other issues.  There could be a 
    difference in the packet length for congestion control - you can't take 
    into account that the packet may be shorter on the link in question. ...
    
      - Mark West: I don't see why ACKs need to go into header.  Treat the 
    headers as separate headers but make pieces part of the same context.  The 
    DCCP spec shouldn't need to accommodate; it's more of an issue for ROHC.
    
      - Lars Erik (ROHC wg chair) - ROHC is not currently chartered to do DCCP 
    header compression. Currently doing TCP compression work and looking at 
    generic methods.
    
      - Lars Erik - the natural place to do this work is in ROHC with DCCP 
    participation.
    
        - Mark: Document authors should be on both lists.
    
    
    ============================================
    
    Implementation Reports - Aaron Falk
    
      - Implementations expected by ICIR, Sun, RealNetworks, Deval Mehta (note to 
    list), and Vladimir Moltchanov of Nokia
    
    
    ============================================
    
    Other Issues?
    
      - Mark: If we removed the UDPLite functionality, we could expand the 
    sequence number field to 32 bits, assuming we also use the reserved 
    value. I think we made the correct choice to use CSLen in the header. Are 
    there other views?
    
        - Collin Perkins: I think we did make the right choice. But, I worry 
    that there are not enough bits to cover the range of (higher layer 
    protocol) header length we need to protect
    
        - Eddie: The CSLen field is in 32-bit words, you can get quite a lot of 
    coverage for the current range of CSLen.
    
        - Collin Perkins: Aha, OK.
    
        - Eddie: I'd rather have CSLen than sequence number.
    
        - Mark: I get the impression that no-one is really pushing for more 
    bits in the sequence number so current design seems OK.
    

    Slides

    None received.