2.8.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:

       Additional DCCP Web Page

Last Modified: 2003-08-25

Chair(s):
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.


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
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
Internet-Drafts:
  • - draft-ietf-dccp-ccid2-03.txt
  • - draft-ietf-dccp-problem-00.txt
  • - draft-ietf-dccp-ccid3-03.txt
  • - draft-ietf-dccp-user-guide-00.txt
  • - draft-ietf-dccp-spec-04.txt
  • No Request For Comments

    Current Meeting Report

    DCCP meeting, IETF57, Vienna
    
    
    Chair: Aaron Falk
    Notes: Gorry Fairhurst
    
    
    Technical design review
    
    ----------------------------------------
    ------------------------------------
    
    
    Meeting Objectives & Rules 5 min
    Presentation by Aaron Falk (AF)
    Introduced purpose of meeting, in particular, he urged people present to
    look for:
        Faulty Assumptions
        Poor Design Decisions
        Unnecessary Functions
        Implementation / Deployment risks.... etc
    
    
    slides 
    http://www.icir.org/kohler/dcp/ietf57/aaron-ietf57.pdf
    
    ----------------------------------------
    ------------------------------------
    
    
    Charter Review 5 min
    Presentation by Aaron Falk
    
    ----------------------------------------
    ------------------------------------
    
    
    Spec Review 40 min
    Eddie Kohler (EK) reviewed the spec (not the CCIDs).
    slides: 
    http://www.icir.org/kohler/dcp/ietf5
    7/eddie-ietf57-spec.pdf
    
    ----------------------------------------
    ------------------------------------
    
    
    Expert Reviewer Comments 10 min
    Presentation by EK
    slides: eddie-ietf57-reviews.pdf
    
    
    A summary of the comments from the expert reviews forwarded to the wg 
    mailing list.  Expert reviewers were
    
    
    GM = Greg Minshall (transport)
    ER = Eric Rescorla (security)
    JR = Jonathon Rosenberg (multimedia)  
         (Jonathan's review has not been received yet)
    
    
    Design Reviewers:
    SB = Steve Bellovin(Security design reviewer)
    RA = Robin Austein (Architecture design reviewer)
    MW = Magnus Westerlund (Multimedia design reviewer)
    
    
    
    ----------------------------------------
    ------------------------------------
    
    
    Discussion 45 min
    
    
    SIGNALLING CHANNEL
    -----------------
    
    
    Henning Schulzrinne (HS): Have you considered the potential use of 
    addresses by DCCP as a flow-id in an NSIS environments? - This may 
    prevent some things being done.
    
    
      Here are some questions:
    
    
      1) connection identification? - is this TCP-Like?
    
    
      EK: YES
    
    
    HS: This makes some of the nice things in NSIS no longer possible.  I 
    thought the idea of DCCP was end-to-end signalling with congestion 
    control - but in NSIS you don't know what the next hop is (like you do when 
    one uses RSVP, and get a PATH message). So if you have a protocol that 
    sends a packet into blue yonder, and it is intercepted, then you can 
    short-cut the transition to the next hop .
    
    
      2) What is the minimum number of messages before I can send data?
    
    
    EK: Zero messages, there is no delay required you can send with the 
    setup.  Three messages for many other connections (e.g.  if you don't want to 
    use the connection setup messages)
    
    
    SECURITY
    --------
    
    
    ER: It occurs to me that you may need to be worried about sequence 
    numbers as a security issue. The HMAC solution I proposed in the review is a 
    strawman with much better security, it's probably too costly, but I'd 
    encourage a look at other solutions.
    
    
      A design could have an implicit high-order sequence number word (never 
    sent), that is combined with the signalled number. (This approach is 
    similar to use in ESP). This is much better that what is now in DCCP, but 
    not as good as HMAC (which is hard to beat).
    
    
    SB: Currently one security assumption is that you can see part of the 
    stream, but it is unlikely for someone else to see the beginning with the 
    initial connect request. This isn't necessarily a good assumption to use for 
    your security model.
    
    
      DCCP performs an identification exchange where the sequence number isn't 
    expected.  .....
    
    
      Even if the connection nonce were sent on all packets, that doesn't give us 
    better performance, so that wouldn't really help.
    
    
    EK: The model is the same as TCP's: there is some protection if you see 
    data packets, but not the control exchange - but this isn't 
    necessarily to be expected.
    
    
    MW: Some apps will use nonce exchange out of band. Ideally, nonces need a 
    signalling path which you can secure, i.e. a separate channel between 
    sender and receiver over which you can send the nonce from A to B 
    without other systems seeing it.
    
    
      A & B know they are talking to each other when they get the 
    request/response messages.
    
    
    MORE SIGNALLING
    ---------------
    
    
    Jonathan Rosenberg: (JR) Use of DCCP for feature negotiation of 
    parameters seems odd. There are other ways to do this, and some 
    applications may in any case prefer these other mechanisms. One example is to 
    use a secondary signalling channel (like SIP) There are still denial of 
    service attacks possible.
    
    
    EK: A separate signalling channel is not necessarily bad.  We have 
    thought about this.  But, if you use a separate channel, then the 
    application must then take all the stuff from the signalling channel then 
    the application then has to move the data between the two channels, and 
    this add complexity to the application.
    
    
    Mark Handley (MH): We could also consider RTSP rather than SIP for 
    signalling the information. In the development of RTSP there was a strong 
    push to use this for data. We chose not to do it this way. If DCCP had been 
    around, we could use a more reliable mechanism to deliver this setup 
    information.  DCCP provides a better basis.  The other option is use TCP for 
    the signalling (or even for everything). But, then we don't have DCCP.
    
    
      SIP does something different and has extra functions, it may be suited to 
    some cases.
    
    
    JR: The drawback is you pay for the overheads using RTSP/SIP.
    
    
      MH: In DCCP, you can piggyback this control data on the first  packet.
    
    
      JR:  OK.
    
    
    COMPLEXITY
    ----------
    
    
    Dave Crocker: The diligence, thoroughness,and clarity of presenting this 
    here to people is great. I noticed in the list of reviewers, was there a 
    feedback on routing?
    
    
      AF: Yes, the reviewers are in two parts (see both lists).
    
    
    Dave Crocker: I thought this was just adding congestion control (CC) to UDP - 
    It seems we have introduced 8 features into DCCP, only 2 are related to 
    congestion control.
    
    
      The option setup is particularly chatty. DCCP is in a TCP mode, it has a 
    lot of features, it is a connection protocol, not really a 'datagram' 
    protocol.  You have complexity. Do you need this much complexity?
    
    
      The answer will be yes in some cases, and no in other cases. This 
    increases technical risk. It's a wonderful set of experimental work. But is 
    it deployable in the near-term?  If you can find a way more in line with 
    congestion control for UDP, then you would get a more compelling need for 
    this and earlier adoptions.
    
    
      If you could build it this with this more limited, initial goal, you 
    could add some of the other features later. I'd like to see this made 
    simpler - that would be really helpful for much greater utility.
    
    
    EK: To understand the consequences, should we try to throw out 
    connection setup and termination?  It would be an interesting design 
    exercise to examine this.  One way would be to rethink the design. We 
    could do this and send it on the list and figure out what we had left and 
    whether it was useful.
    
    
    MH: We didn't set out to develop a complex protocol, we looked at all the 
    options and all the things we needed to do, and found we had designed 
    this.
    
    
    CHECKSUMS
    ----------
    
    
    HS: 1. DCCP has inherited the same TCP/UDP checksum (i.e. standard 
    internet checksum). Some other newer protocols have made different 
    choices, think of SCTP as an example.
    
    
    HS: 2. What about congestion control and fragmentation ?
    
    
    EK: Generally the DCCP design assumes use of PMTUD.  An application can 
    request that PMTUD is not used, unless CCID says not ­i.e. unless this 
    violates the CCID design basis.
    
    
    MH: We'd like advice on checksums. Checksums are easy to compute. If you 
    want to do a NAT then DCCP is similar to UDP, and makes this job easy. Is 
    this a weak reason?
    
    
    HS: I was thinking of a more traditional CRC.
    
    
    MH: We'd like advice!
    
    
    HS (clarified afterwards): Code re-use across protocols is not a strong 
    argument for inheriting a checksum; I doubt that it takes place in 
    practice and that a checksum is a major issue - it's just one 
    subroutine
    
    
      I don't have strong evidence but I believe where performance matters that 
    modern strong checksums (CRC and maybe the that were mentioned during the 
    IAB plenary, I think, something like UMAC or PMAC, but I probably didn't 
    catch the names correctly) are not appreciably less efficient than good ol' 
    16-bit sum. This should certainly not be taken as 'obvious' - somebody 
    needs to find out based on publications or such.
    
    
      I should note that SCTP uses CRC32. RFC 3309 contains a lot of related 
    references.
    
    
    EK: Incremental checksum update is possible with current choice, and not 
    with a CRC.
    
    
    CONNECTION ESTABLISHMENT
    ------------------------
    
    
    MW: If you use RTSP you'd need multiple channels.  Connection 
    establishment is an important feature for DOS prevention.
    
    
    SERVICE NAMES
    -------------
    
    
    Colin Perkins (CP): Cost of processing.  DCCP adds a service name, does 
    this make it worse when you want to implement in an operating system.  
    Experience for RTP is that building big servers can be problematic.  Does a 
    service name make it harder for implementers?
    
    
    EK: We'd expect each port to have a name.  So this is a one word lookup, you 
    don't need it once connection is started.
    
    
    RECEIVER DROP STRATEGIES
    ------------------------
    
    
    Steve Casner (SC): You suggest that an over-loaded receiver drops 
    packets from the head of the receive queue.  Often this is the right thing to 
    do.  There are other cases where this may not be the right response. Don't 
    use a fixed assumption.
    
    
    EK: A DCCP API may present options to the application.
    
    
    MH: We intended you could do either from the front or back of the queue 
    depending on what the application wants.
    
    
    FIXED VS. VARIABLE PACKET SIZES
    -------------------------------
    
    
    SC: You say you need different CCs for constant vs. variable packet 
    sizes.  But, you can't assume one regime or the other - you may 
    actually have a combination.
    
    
    DOS PROTECTION
    --------------
    
    
    CP: In the presentation you said there were DOS attacks with mobility. What 
    are the DCCP mechanisms concerning this.
    
    
    MH: The primary method is the sequence number check. There are many 
    issues.
    
    
    MOBILITY
    --------
    
    
    CP: I'm surprised you included mobility support in DCCP.  There are other 
    places in the stack where you can do this.  It would seem this could be 
    done via the application or by mobile IP.
    
    
    EK: There were comments about this on the slides in the reviewer 
    comments.  The basic reason is application level solutions are hard.
    
    
    HS: You may need to redo this, if the address changes. The cost at the 
    application level is hard.
    
    
    MH: It is heavyweight to do this above DCCP. There are three design 
    options:
    
    
      (i) You can do above the transport level- this is heavy.
    
    
      (ii) Do this in transport - light (at least for DCCP, not looked at TCP 
    case)
    
    
      (ii) Do this below transport - 2 problems - you can¹t assume 
    mobility; IPv4 mobility is not optimal. Mobile IP doesn't give very 
    optimal mobility for delay-sensitive apps.
    
    
      DCCP gives more optimal solution - but doesn't solve all the problems
    
    
    CP: Not sure of the mobility use case. Often may have a non-DCCP channel in 
    addition to the DCCP one - that would also be needed.
    
    
    COMPLEXITY (AGAIN)
    -----------------
    
    
    Lixia: What is the fundamental goal/job of the protocol? Do we need all of 
    these considerations?
    
    
    Sally Floyd (SF): My goal was to adding congestion control to UDP that 
    multimedia apps can use with ECN .  It also adds congestion control on the 
    reverse path. Partial checksums also desirable to tune congestion 
    control response. DCCP is not a next generation congestion control.
    
    
    Lixia: I said next generation of transport - not just CC.
    
    
    SF: This not just a matter of adding CC - other issues appear, these are 
    documented in the IDs, so we have learned much.
    
    
    MH: If you look at the features you need to do, so you can implement CC 
    there's more than you may first think. In fact, the world has moved on, 
    middboxes, security,etc are also important issues.
    
    
      In some ways TCP is simpler in its ACK policy. You can't use 
    cumulative ACKs with congestion control if you don't have full 
    reliability.
    
    
    AF: Need to close out this part of the discussion.
    
    
    ER: When you move the connection between hosts do you reset the CC 
    parameters?
    
    
    EK/MH: YES.
    
    
    
    ----------------------------------------
    ------------------------------------
    ---------------------------
    
    
    Reviewer Feedback 10 min
    
    
    Steve Bellovin:
    Some random thoughts....
    No real-time attacks....
    
    
    - 12B for the header may be a lot - have you looked at header 
    compression?
    
    
    - There are security issues with partial header - discussed more in 
    UDP-Lite particularly the impact with ESP (see latest draft).
    
    
    - Same worries about sequence number checking
    
    
    - Things are different from a security point of view because you choose to 
    work with packets rather than streams, may be easier to exploit?
    
    
    - May want the API to pass down a pre-shared out-of-band secret with HMAC, to 
    act as a starting nonce?
    
    
    - The service name bother me - this could be dangerous it presents 2 
    things with the same meaning port + name.  Once you have two ways of doing 
    it, you need two checks, or they can exploited.  An example is an 
    Operating system that treat low-numbered ports as privileged - but 
    midboxes don't do quite same thing (e.g. they open based on service 
    name)- can this be exploited?  appropriate actions need to be defined.
    
    
    - Mobility?  Some security may help?
    
    
    - Need to think about stream protocols
    
    
    - Middlebox may be hard to setup (it will make life harder with 
    connection lookup - an index value in the header would save the work)
    
    
    - Multihomed hosts, mobility is worth retaining for this.
    
    
    ---
    
    
    Rob:
    
    
    - I was not as scared about the overall size of protocol as some people 
    said.  A lot is to do with congestion control, and this takes up a big part 
    of the TCP specs too.
    
    
    - This reminds me of  "Chaosnet" which uses service names  like this.
    
    
    - It would be more minimal and Middlebox friendly if we have a 16 bit 
    checksum.  It would also be easier to use normal ports. Don¹t agree with HS 
    on the cheap CRC implementation, since anything not like UDP is likely to be 
    more hard for a middlebox to adopt.
    
    
    - The feature negotiation: is "very California", lots of talk... does it 
    need to be like this?
    
    
    - Slow-down [at the receiver] is under specified (too much left to be 
    guessed).  TCP algorithms have to guess what the other end wants, we need to 
    be explicit.
    
     
    - The sequence number space seems small. I know this is measured in 
    packets not bytes, but still this is not a big space, do we have to be so 
    careful with bits?
    
    
    - I am underwhelmed by mobility, partial checksums
    
    
    - Current specification of data request exchange has lots of optional 
    things - this would be really nice if they were to be fixed.
    
    
    ----
    
    
    Magnus Westerlund:
    
    
    - How do we get this deployed in the face of NATs?
    
    
    ---
    
    
    SB: Multihomed hosts are important. It would be good to keep the 
    mobility feature for this reason alone. I think it is useful.
    
    
    
    ----------------------------------------
    ------------------------------------
    
    
    
      Closeout ­ Next steps 5 min
    
    
    AF: Would like to track these ideas and changes. a version tracker would be 
    good.
    
    
    Today is  EK's  birthday!
    
    
    ----------------------------------------
    ------------------------------------ 

    Slides

    Datagram Congestion Control(DCCP) Design Review
    Datagram Congestion Control Protocol (DCCP) Spec Walkthrough
    DCCP Written Reviewer Comments
    Comments heard today
    Next Steps