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 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-15

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 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
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-06.txt
  • - draft-ietf-dccp-ccid3-06.txt
  • - draft-ietf-dccp-user-guide-02.txt
  • - draft-ietf-dccp-spec-07.txt
  • - draft-ietf-dccp-ccid3-thin-01.txt
  • No Request For Comments

    Current Meeting Report

    Datagram Congestion Control Protocol WG (dccp)
    Thursday, August 5, 2004 at 15:30 to 17:30
    The meeting was chaired by Aaron Falk.  Matt Zekauskas was scribe.
    1. Agenda Bashing and Milestone Update
    2. DCCP Spec
    3. Changes to CCID 2 and CCID 3
    4. CCID3-thin
    5. DCCP Mobility and Multihoming
    6. DCCP User Guide
    7. Media Friendly Rate Control
    8. Last Call Comments
    1. Agenda Bashing and Milestone Update
       --Aaron Falk
       (see slides)
       - DCCP user guide is becoming more important
       - MFRC (Media Friendly Rate Control) is new
       - The specification, CCID2 and CCID3 are all under WGLC for
         Proposed Standard since 20-July.  The WGLC is scheduled to
         conclude 20-August.
       - Milestones were all just beyond last IETF; they've been adjusted
         to the next IETF, and most are now achievable.  There has been no
         input on the milestones.
      - On CCID and real time interactive traffic
          * We need measured data to support claims being made on the
            mailing list
          * TFRC for real-time flows discussion "most heated"
      - Comments about applicability need to be in the user guide.  There
        is a new revision out, please comment!  If you have concerns,
        sending text is always appreciated.
    2. DCCP specification, version -08
       -- Eddie Kohler
    There were many little readability adjustments, which make diffs from
    the last version look large.  However, there are two big technical
    issues: Mobility and multihoming was removed, and the move to uniform
    48 bit sequence numbers (versus 24).  The latter needs the most
    review, please comment!
    The sequence numbers used to be 24 or 48 bit, via negotiation.  Since
    the recent TCP sequence number attack consciousness-raising, this has
    been revised, since with 24 bits blind reset attacks are highly
    probable.  Thus 48 bit sequence numbers are required for DCCP
    requests, although 24 bits are allowed in three cases (data, datack,
    and ack).
    Mark Allman commented that 32 bits used to be OK for TCP too.  Eddie
    responded that here "bits" means something different, you gain because
    DCCP is per packet instead of per-byte; eventually you'll need a
    timestamp.  Mark responded "or a challenge/response, or...".  Eddie
    said that was true, but it's not necessary for the next "large number"
    of years.
    Colin Perkins asked why it was OK to protect against reset, but not OK
    to protect against injection?  Eddie responded that the important case
    is a half-open connection, because that's what made the blind attacks
    bad previously.  We're trading off header size against the possibility
    of attack, and feel that the application should make the decision.  It
    is a working group question as to whether there are no applications
    that would want to save 4 bytes of header.
    Colin responded that he understands why it was done, but it makes him
    uncomfortable, and applications might use the smaller sequence number
    space without understanding the consequences.  Eddie said there was a
    section in the draft on sequence number attacks -- and he'd love
    advice on how to sharpen it: send text.  Colin felt that what was
    there was good.
    Mark agreed that what's in the current spec is about as good a
    compromise as we can achieve.  Eddie amplified on his earlier
    response: if you reset the connection, you're dead.  In the general
    case insertion attacks generate results that are annoying, but not
    fatal.  There is a difference in the magnitude of the attack on data
    versus meta-state.  If an application really cares, set the option for
    larger sequence numbers.  This seems to be a good compromise.
    Allison Mankin said she wanted to echo what Eddie just said.  In his
    review of the protocol, Steve Bellovin really downplayed the
    significance of blind data attack.  There are few that make any
    difference.  There is enough extensibility that an additional option
    can be added to increase strength; it could even be proprietary.
    Colin noted that DCCP was primarily for long-lived connections; he
    understands but still isn't comfortable.  Eddie invited him to send
    text.  Colin said he would re-read the text and forward any comments.
    Eddie spent some time on feature negotiation (see slides).  A new
    visible state was added ("unstable") to take care of a race condition.
    However, the current document has some typos; this will be remedied
    shortly.  Eddie noted that this might be reason to restart WGLC,
    although he didn't think so.
    Finally, Eddie mentioned a host of other small changes:
      * rearranged header... reserved above packet type so can have more
        packet types if needed.
        Eddie was uncomfortable with the extended seqno bit in
        middle.... and asked if there were any ideas on what else to do.
      * dccp sync: ack# not acknowledgment, because used to recover from
      * reset codes
      * options on reset are processed... you may reset a reset ...but
        there cannot be a storm.  Once a connection is killed, there are
        no more responses to reset.
      * min cksum coverage feature (willing to accept possibly corrupt
      * section on congestion state, and reset cong. state.
          mobility -> worth keeping?
    Aaron Falk: taking bait... why not move X bit to end of byte so not
    together.  Eddie said it was to keep type as a nibble, but no one
    cares about that anymore.
    Aaron asked for an example of an option in a dccp reset?  Eddie
    responded it was there in case there was a reason in future for
    conditionally resetting a connection.  He had some examples, but he
    couldn't recall on the fly.
    Aaron wondered if it was susceptible to 1/2 baked-ness of reset
    congestion state.  If the path knows something, should it always send
    that?  The effects of an option are carefully defined.  However, when
    the option needs to be sent is undefined.
    Aaron wondered if this was a general problem, although you may not
    want to solve it here.  Eddie responded that it was possible that
    there are cases when it is useful to tell the other side to reset
    state & start again. But that is not without risk.  For example, in an
    overloaded situation, 1 packet every 64 sec, this is like a "get out
    of jail free" card.  That's a shame, but is also useful.
    Tom Phelan: what do you mean by "if path changed".  Eddie said it was
    from an email conversation, someone had example from mobility.  It's
    in the draft, but he can't recall what it was... and said that we
    should probably get rid of that option.  Tom agreed.
    Magnus Westerlund said that because it's an option, we can add it
    later, even if has applicability for future.
    Sally Floyd agreed that it should be taken out of this, and put in a
    separate draft, like mobility.
    Aaron Falk said it's the right decision, it's gone.
    3. Changes to CCID 2 and CCID 3
       -- Sally Floyd
      * description of response to idle and app-limited period.  In
        essence, just explain what TCP does.
      * Detecting lost and marked acks.  If a packet is lost, the receiver
        knows it (seqno missing) but doesn't know if ack or data (assuming
        2 way traffic).  The sender knows.  When the receiver sees a loss,
        it assumes ack loss for ack ratio.  There is an added appendix to
        show what this does...  worst case is the same number of data and
        non-data packets.  even in worst case, the cost is not that bad.
      * added para on sending rate when no feedback (making it rfc3448
      * expanded discussion; packet size used in rate calculations
      * new section on response to idle and app-limited periods.
      * new text on data dropped and slow receiver (5.2) -- try to limit
        sending rate in next rtt (a bit)
      * new section outlining current research issues.
         - send fewer acks when rate low?  ok with me, but potential
           problem if a lot of acked packets
         - more than double sending rate from one RTT to next.  possible
           to relax, but...  again be careful
         - higher sending rate after idle period.  Should be more
           aggressive than after slow start, because been through slow
           start.  but how much more?
         - Initial send of 8 packets. TCP says 4 packets, at most 4k
           bytes.  It makes sense to send 8, but pace them out, and only
           if there is less than 4k sent.  However, Sally had "enough skin
           lost" getting 4 packet initial window, that someone should
           research this change.
    Sally ended with a list of possible new efforts, for the groups
      * re-invigorating quickstart
      * ccid for voip based on rfc3714 (because of IAB concerns about
        congestion control and voice traffic).  If encounter persistent
        congestion, must stop sending.  No numbers in the draft on how
        much over and how much to drop, just a principle statement.  ccid
        .. change minimum requirement to sufficient requirement.
        Something a little, but not much more, aggressive than CCID3
      * TFRC-PS, flows that adapt their packet size
    4. DCCP CCID3-lite
       -- Eddie Kohler
    This draft tries to demonstrate than although CCID3 looks heavyweight,
    you can implement a CCID that is very streamlined.  This draft is
    mostly updated based on changes to the main draft.  What is missing?
    The loss-intervals option can't be turned on (hence no ECN).
    Is this important enough work item for the group to accept, or should
    it be put off until someone wants to implement DCCP on a really small
    Aaron Falk asked if anyone cares?  If not, he is going to kill it (as
    a wg item).
    Tom Phelan noted that what drove him to do this in the first place is
    the thought of trying to sell DSP coders to implement DCCP on DSP.
    The question now is if CCID3-thin is the right one to go on diet.
    he's not sure right now, and think we ought to hold off until all the
    congestion control issues settle.
    Aaron gave the group a thought exercise: Have we learned enough from
    complexity to answer the question?  Or is it useful for the WG to
    prepare a standard that has a reduced specification?  These are two
    different goals, one of which might not require an RFC.
    Tom thought it depends on what want to do later, you can apply these
    ideas to MFRC, and have a thin version of that.
    Aaron said just call it a lightweight version of something.  Does it
    require an RFC, or just a thought experiment?  Tom thought it had to
    go to RFC eventually.  Aaron wanted to know if anyone else felt this
    Colin Perkins in a "devil's advocate" role, suggested that if there is
    an interest in the draft, why not just implement DCCP simply.  DCCP
    does not seem excessive, compared to ATM.  Aaron said that was a
    different issue; Colin thought we should consider it, it did not seem
    to be difficult.  Aaron noted that this is about a CCID, the rest is
    Eddie reiterated that it was a CCID, not all of DCCP.  However,
    this specification is also a combined simplification -- it restricts
    what a DCCP implementation can do, and what the CCID can do. For
      * no ack vectors
      * no renegotiation of options
    Mark Handley said that to the extent that this is a profile for use,
    and doesn't change specification, it is always useful to suggest
    people a way to implement a useful subset of functionality.  He thinks
    it is a useful informational draft.  As to whether main specification
    might have too much in it, that's a question for all
    protocols... people implement different subsets of features.  That's
    why there are "bakeoffs".  Just because a stripped down version is
    useful for lightweight devices, you don't want to cut out features
    that are useful for devices that are not so lightweight.
    Aaron noted that feature pruning is the kind of thing that happens
    when a draft advances from Proposed Standard to Draft Standard.  Mark
    said that you should do it then, but this is still a useful
    informational draft.  Eddie notes that it is a bit of rewrite to make
    it informational, because the draft allocates an option.  Aaron
    wondered if anything in thin that violated a MUST in the
    specification.  Eddie sad no, but it does allocate an option.
    Colin wondered if a path forward is for the base specification to be
    clearer about a minimal subset.  Eddie said there is an options table
    that shows what is optional.  But 3-thin does more than that, it
    constrains implementations.  This is so an implementation that only
    spoke thin can speak to a full - the full implementation would not
    generate a packet that violated thin rules.  This is different from
    "optionally implemented" in a specification.
    Aaron wondered if this violates "server wins"; if the client is thin
    it supersedes server rules.  Eddie said no -- if a server doesn't
    understand thin, by rules of mandatory, the server must reset.  The
    server does win - it gets what it wants or no connection.
    Tom Phelan said his drive was not that DCCP is too thick in general;
    it was for streaming media devices that are very thin.  A protocol for
    streaming media needs a thin variant, or needs to be very thin.
    Allison asked for clarification of how thin relates to negotiation -
    did it actually break the protocol?  Eddie said it does not break the
    protocol.  It restricts the operation of an endpoint, but the endpoint
    must agree to the restrictions.
    Allison wondered why we were engineering something that could happen
    naturally.  An endpoint could restrict itself anyway.  Eddie said that
    all CCID3-thin packets are valid dccp packets.  But if you only
    restrict yourself, you can't guarantee that a peer would do it.  Aaron
    said that when one found something the other side didn't support, it
    would just reset the connection.  Eddie said the point of 3-thin was
    that the implementation didn't need to bother looking for strange
    options; it's not to be a time-saver (although it does that) but it's
    an implementation saver.  You just check at the beginning of a
    Allison thought perhaps we're actually asking if we can create a kind
    of extension to negotiation mechanism -- "negotiate out of rich
    negotiation".  Asking to add vital small piece to proto that allows
    that.  You need a part of the proposed standard to do that, why you
    should do it now instead of later.  Eddie responded that this was not
    quite true; you can go to proposed standard without this, since it can
    go independently with some option number.  The "mandatory option"
    concept is all you need in DCCP.  3-thin is in the header, as the
    mandatory three-thin option.  There could be 3-thin, 3-thin2 or
    3-thin3.  Don't need to pre-specify because we have the mandatory
    Colin said he was still trying to understand the need.  Why not just
    send "no" to all options?  Eddie because the implementation of a
    3-thin client could be really simple.  Colin thought it just wasn't
    that complex.
      Aaron asked for a hum of people that thought this was a reasonable
      activity to pursue.  Mild yes.
      He asked for a hum of people that thought this should not be
      pursued.  Mild no.
      There was a big don't care.
      Aaron said to take this off line... but there are not a lot of folks
      that support at the meeting.
    5. DCCP Mobility and Multihoming
       -- Eddie Kohler
    This is a new draft, pulling material out of the main draft. (See
    Yet to be done: specify mobility secret format and encryption
    algorithms.  The security considerations section.
    The questions Eddie had for the group:
      * when we gave up on mobility in main spec, did we give up on it
      * if no,
          - this draft
          - some other approach?
    Magnus Westerlund said that considering what was said in TSVWG
    today...  multihoming device could use different dccp sessions, and
    use ICE to select.  Mobility might be better in a lower layer.  He
    didn't know what was better, but felt that's what we need to look at.
    Eddie responded that to be fair he wasn't at TSVWG, but he felt there
    is a strong case to be made for supporting in transport layer (in
    addition to, or instead of, the network layer).
    Aaron said that he saw much of what would drive a decision here to be
    things in other working groups. This is probably the wrong time to
    make a decision.  You have put together a reasonable proposal.  His
    suggestion would be to see what happens in other WG, and get rid of
    other outstanding issues before revisiting this one.
    Mark Handley thought we should keep going and see where it leads, but
    don't make decision now if RFC.  Don't stop working on this since we
    have a certain amount of stuff worked out.  He would like to get to
    the point where it was all worked out... but ietf policy to see if
    push forward into stds track.
    Aaron asked for a show of hands people interested: 2 raised their
    hand.  He said the onus is on those folks to take forward if that's
    what they want to do.
    Allison said that she sees a need for discussion.  Perhaps taking a
    couple of days sometime, looking at what everyone has envisioned for
    these services and solutions.  This would be to see what everyone has
    discovered and learned, not "how to do them in X".  There are neat
    things in this document.  Things learned and discovered are important
    to the overall architecture, and people need to pool ideas.  She's
    really happy this progress went on, and feels it could be an
    experimental RFC.
    Aaron said there are so many names for the issues on these
    topics...  how would one characterize the topic for, e.g., an IAB
    workshop?  Allison thought perhaps 'multiple addresses'.
    Aaron summarized what he heard: encouragement for the work to be done.
    It's not a WG item, but you can include the dccp list; collaboration
    with people on the list is good and worth doing.
    Allison said she would send a bibliography of pointers where to look
    for mobility work on TSVWG list, in addition to the viewgraphs from
    her talk at TSVWG.  She's not sure where the follow-up activity is
    yet; suggestions on follow-up activities is also really important, and
    please send those to the TSVWG list.
    6. The DCCP User Guide
       -- Tom Phelan
    The changes for 01 were not substantive; diff marked versions pointed
    to in draft.  (See slides.) The question is "what next".
    Aaron asked who has read?  Approximately 7 people responded.  Rather
    than flogging people for not reading it, prefer to get the existing
    set of documents through WGLC, and then flog people.  He thinks this
    is a very important document, applying DCCP to certain types of
    flows. However, without more input it has a ways to go.  We need to
    get group more involved.
    Tom agreed to postpone work until after WGLC.
    7. Media Friendly Rate Control
       -- Tom Phelan
    Tom started with background.  There were discussions on the mailing
    list about TFRC versus interactive applications.  TFRC seems
    reasonably good if not used for interactive traffic.  The MFRC draft
    is a thought experiment of what you might want to do for interactive
    applications, and to stimulate discussion.
    Tom then went through the thought process he had leading to MFRC, and
    the basics of MFRC (see slides).  Basically, let media applications
    guess the rate, and react quickly if the guess is bad.
    What are the next steps?  Based on mailing list comments:
      * restart is bigger problem than slow-start.  (agree, may add)
      * based on TFRC to make it simple.  but byte rate is better than
        packet rate for streaming media, and he'd like to investigate.
      * please help simulate
    Tom asked where is the appropriate home for this work?  DCCP says, you
    can't have congestion control work without a specification, but this
    is easy to explore.  Eddie said that what the draft intends to say is
    that CCIDs that are standardized will have IETF-approved congestion
    control.  It doesn't mean you have to standardize cong ctl first.
    However, DCCP is a congestion control protocol - can't have random
    congestion control algorithms.
    Aaron noted that the IANA rules for ccid in the draft is that there is
    a requirement to first have a congestion control document before you
    can get a CCID.
    Mark Allman said he votes for "option 3": you need to simulate first,
    see where the worst cases are.  This isn't baked yet.
    Sally said that she agreed.  However, the home for CCID could be this
    group.  Her assumption was that the place to bring it was this WG.
    Ruediger Geib said that he worked on QOS for a large provider.  He
    would transport applications using dccp, but use a different queue in
    the router.  Then, TCP friendliness is not an issue -- only require
    that DCCP flows were friendly toward themselves.  Because of separate
    queues, it would be helpful to be able to get application to reduce
    rate.  Another idea from TSVWG: use ECN.  Suggest you do
    both... losses and ECN.
    Tom said that loss or ECN marked is abbreviated by saying "loss".
    Right now draft doesn't consider ECN marking.
    Ruediger thought it would be nice to mention, not you personally do
    work.  By the way, as a provider, we view losses as bad.
    Aaron said that Mark is right.  There is research to be done.  Show
    the results in AVT and here.  If there is a ccid to be defined, this
    is the place, but that's the second step.  The first step is to figure
    out the right thing to do.
    Eddie said that a ccid draft is a useful way to work out details of
    this as proposal.  So he wouldn't mind seeing more of this draft here.
    Not that you shouldn't separate congestion control into a separate
    Tom said that he wanted a ccid draft of this as one document, a
    simulation study as another document, and to be able to continue to
    talk about it here.
    Aaron asked if anyone here wants to work on it.  No one raised hands.
    8. Last Call Comments
      -- all
    Aaron wanted to follow up on a mailing list discussion as to whether
    some or all of the drafts should go to experimental instead of
    proposed.  The charter specifies that the documents go to proposed.
    There are also issues people are raising between TFRC and real-time
    multimedia traffic.  These are issues when trying to run this traffic
    over specific CCIDs.  There is no applicability statement in any of
    the documents in last call that require people to use a specific ccid.
    DCCP is a piece of transport mechanism; we should standardize to get
    people to implement it and use it.  More CCIDs would be developed with
    experience.  Thus, he doesn't see a conflict with the fact that the
    CCIDs may not be appropriate for streaming media, and taking the
    existing documents to proposed standard.
      Colin agreed.  Get these documents out, and save the rest for later.
      Magnus thought he agreed in principle.  However, are the documents
      mature enough to go to proposed, without an implementation of the
      current spec?
      Aaron said RFC2026 does not require an implementation for proposed
      Magnus thought it would be good to have an implementation to show it
      Aaron said that we know the requirements; there are early
      implementations, we've been talking about it for two years, and
      there's been a detailed design review.  No one is raising new issues
      with the main specification mechanism.  If someone can put issue on
      table, let's discuss.  Free-floating anxiety is hard to work on.
    Magnus noted there was a new state in this version.  Aaron wanted to
    know about new mechanisms.  Eddie agreed about the new state
    (UNSTABLE), but it's for feature negotiation.  There is an existing
    state machine there.  Previously there were STABLE and CHANGING.  Now
    there are three.  However, this is not the main DCCP state machine.
      Magnus said that we haven't had one round that deals only with
      editorial comments.
      Steve Casner echoed Magnus's comments.  He doesn't dispute Aaron's
      position, but there are certain things that he's not quite certain
      about.  It seems a little less than ready for last call and send it
    Unidentified from Orange, works on 3G phone issues.  He had an
    interesting conversation with Sally.  How well does DCCP apply to a
    wireless link?  Some transport protocols cause lots of problems.  Not
    congestion - but strange behavior on radio side causes false alarms.
    Would dccp behave better in a strange or variable radio condition?
      Eddie asked for clarification: do you mean "if tcp behaves badly in
      highly variable link, will dccp also?"
      ???: Actually, if delay spikes.  We see huge delay spikes on radio
      links.  It will cause TCP to slow down, and tremendous HTTP
      problems.  Packets are not lost, but buffered in the radio link.  It
      produces a shot of high delay in short period of time.
      Mark Handley said that what would probably happen is that a decent
      CCID 3 implementation would carry on transmitting through delay.  It
      may tell the sender to back off rate, but when get feedback, it
      would go ahead.  So the answer is "yes, it should be better than
      Eddie wasn't sure, because he wasn't sure of the application.  If
      you want reliable byte stream delivery, then it's a congestion
      control concern.  You probably need CCID4/MFRC
      Aaron said that if you use CCID2 with data, you should have a big
      win over TCP if there was a delay spike.
      Sally said we should take this issue to the list.
    Colin Perkins said that he was not worried about applicability to
    particular applications, since we can develop new CCIDs if we need to.
    He's worried that we are trying to push something to proposed when
    it's not yet stable.  9 pages of significant revisions in this version
    of specification, plus the CCIDs. He thinks it is a good piece of
    work, and shaping up nicely, but is not convinced it's stable.  He's
    worried that we set it in stone too early - don't force it out.
      Sally responded that we can't expect long term stability before PS,
      look at what is happening with TCP; it's not stable.  We are trying
      to do HS-TCP because the current TCP doesn't work in a large
      congestion window environment.  Then there's the big tussle over the
      reset attack.  The work within TCPM is robust to reordering, and it
      should have been done day one.  TCP is not stable.  If we want to
      wait for the specification to be completely stable, then it will
      never happen.  Holding a bigger bar to DCCP and TFRC than TCP
      doesn't make sense.  All changes Sally presented were text- no new
      Eddie added another point: there were technical changes made to main
      specification.  However, they were all sent to the list, and
      received no replies. He will release another draft once he's done a
      full read through.  Not sure if this would address stability
      concerns of Magnus and Colin.  The authors are now talking only to
      themselves.  The draft will get stable in your perception that way.
      We need to get others to read whole document again.  The last person
      to read the whole document was Magnus...  if no one is going to do
      it again, what are we waiting for?
      Mark Handley added that he wouldn't object to delay if something
      would happen.  More reviews, for example...
    Aaron asked who has read this version of specification: about 5 hands.
    He then asked who would commit to reading this version of the
    specification; another 10 raised their hands.
      Aaron said that he expects to see typos posted to list.  If you
      can't find an error, he'll assume you haven't read.  There's another
      two weeks after the IETF in the last call.  He'll ask for more on
      the list if we need it.
      Colin thought this was unfair: people have been giving comments at
      every IETF, and there have been significant changes before each
      IETF.  Aaron asked if there had to be one IETF meeting with no
      significant comments.  Colin said the spec must be out there long
      enough to read and digest.
      Aaron said that the authors think the drafts are stable, and it is
      time for the community to look and see if it's stable.  We can do
      that now, there is no need to wait four months.
      Eddie said that the current specification has a typo or two (see his
      presentation).  He agrees that there have been technical changes in
      the last revision, but they were circulated to the list.  He would
      not feel "bashed on" to be asked to come up with new revision of the
      main specification for last call.  However, he also thinks that a
      last call on the current specification is OK.
    Randall Stewart said that he had the same opinion as Sally, having
    gone through the SCTP specification.  You're going to make mistakes.
    The only way you're going to find them is by getting people to
    implement the specification.  There will be other problems.  he
    doesn't see any harm in going to proposed; you may have to cycle at
    proposed again based on changes.  That's OK.  In the end the document
    will be much better.
    Allison talked about the IESG's interpretation of proposed standard:
      * no known flaws (so fix the bug)
      * WGLC is on a document that had changes.  We're now looking at the
        document since changes made.
      * There's no need to restart the LC, since the changes are in
        response to discussion.  They see a lot of that - the document can
        go through big changes during WGLC; what's happening now is the
        response.  She thinks it is appropriate.
      * Sometimes after IETF last call, the document gets a large change.
        They accept that.
      * There's no need to be overly conservative for proposed; we don't
        require deployment, but do require people think that the spec can
        be implemented.
    Her feeling is that it is time for IETF LC on this, and would
    encourage closure.
    Mark Allman said that he too agreed with sally; its not going to be
    perfect, it's never going to be perfect.  The document will change
    (maybe big things) as an RFC.  It's time to get a stable version that
    people can start implementing.
    Aaron ended the meeting with a charge to the WG to go forth and read
    the documents in last call.


    DCCP Spec as of Last Call
    DCCP Mobility and Multihoming
    DCCP CCID 3-Lite
    Changes in CCID 2 and CCID 3
    Media Friendly Rate Control (MFRC)
    DCCP User Guide