Datagram Congestion Control Protocol (DCCP)
draft-ietf-dccp-spec-13

IANA Comments:
Upon approval of this document the IANA will reassign protocol number 33 to DCCP.  The IANA will also create 8 new number registries including initial allocations in those registries.

[Ballot comment]
This is a very well-written and comprehensive specification.  There seems to be one thing missing that I think would improve the specification of DCCP over IPv6 -- an indication of when DCCP should send reachability confirmations as described in RFC 2461 (and, perhaps more importantly, when it should not).

Appendix E.1 of draft-ietf-ipv6-2461bis-02.txt describes how TCP would know when to send (and not to send) this type of confirmation, and could be used as a guide.  However, I think that this determination might be a bit more complicated in DCCP, due to its more complex set of acknowledgement (and acknowledgement or acknowledgement) options.

[Ballot discuss]
Section 18 says:
  >
  > Applications desiring hard security should use IPsec or end-to-end
  > security of some kind.
  >
  The term "hard security" is ambiguous.  This should be replaced with
  a list of the security services.  I assume that integrity,
  authentication, confidentiality, and access control are the security
  services that are "hard."  Alternatively, the following rewording
  is acceptable:
  >
  > Systems or applications desiring security services provided by
  > cryptographic mechanisms should use IPsec or an end-to-end
  > security protocol such as TLS.

[Ballot discuss]
On the IANA Considerations - read the comment on the ccid specs first.  Although it would/will
be nice to have DCCP extensions contended by multiple parties, the RSVP, SIP and other cases
argue that the protocol loses if it is not reviewed centrally.  2434's IETF Consensus policy term
is not even clear enough to ensure IETF review, so this Discuss is a request to change some language:

    19.2, 19.3, 19.4
    OLD
        IETF Consensus policy, which requires RFC publication (not necessarily
        standards-track).
    NEW:
        IETF Consensus policy, requiring an IETF RFC publication with IESG
        review, though it need not be standards track.

This part of my Discuss will also hold a token till IANA assures us they are clear on a review
of the dccp spec and have no questions.  I think* the registry/sub-registries look implementable...

-----------

[Ballot comment]
Reviewed by Scott Brim, Gen-ART

No objection.

What's to object to?  OK, I admit that as I was going through it, it
felt good to be reading a protocol spec done in rigorous classical
style, and as I got near the end I spent less time on detail, so I
might have missed something. 

One thing I might investigate if I had a couple days to think about it
would be the overall architecture of the protocol, because it has
accumulated a lot of features.  Sometimes when a protocol develops a
lot of options you can make it better by organizing it along a
different dimension.  However, considering the people who have worked
on DCCP I don't believe I would find any new breakthroughs.

[Ballot discuss]
Section 18 says:
  >
  > Applications desiring hard security should use IPsec or end-to-end
  > security of some kind.
  >
  The term "hard security" is ambiguous.  This should be replaced with
  a list of the security services.  I assume that integrity,
  authentication, confidentiality, and access control are the security
  services that are "hard."

[Ballot comment]
In section 6.6.8: s/limitiations/limitations/

  In section 18, a few pointers other places in the document where
  denial-of-service protection is discussed would be helpful.

  In section 18.1 where bit error impacts are discussed, it might
  be helpful to also point to SRTP.

  In section 20: s/codesigned/co-designed/

WG Chair Writeup for DCCP Spec - 20041201


  1.a) Have the chairs personally reviewed this version of the ID and
        do they believe this ID is sufficiently baked to forward to the
        IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

This document has received a great deal of review, appropriate for a
new transport protocol.  I believe the reviews have been adequately
deep and broad.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

I don't feel that additional particular review is necessary at this time.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it, etc.  If your issues have been discussed in the WG and the
        WG has indicated it wishes to advance the document anyway, note
        if you continue to have concerns.

There has been some discussion on the DCCP mailing list about whether
DCCP is an appropriate protocol for real-time multimedia applications
to use.  This disagreement is really about the use of a particular
CCID with certain applications and has not been about the functions or
capabilties of the core protocol.  (The comment has been made that the
protocol should not progress to PS until it has been demonstrated that
one application can successfully use the protocol.  There seems to be
no wg support for this strategy.)

The authors and I feel that CCID3 can be modified to accommodate
real-time voice (VoIP) but support for real-time applications which
have more demanding QoS requirements (bandwidth, delay, jitter, etc)
will at least require a new CCID and may not ever be suitable for
DCCP.  We expect that experimentation with DCCP implementations will
be required to understand this issue better.  Nevertheless, I feel
that DCCP core specification is useful, mature, and is supported by
the working group.

Also, some of the more conservative AVT participants are reluctant to
move the spec out of the working group without additional "settling
time" to assess whether the spec is complete and without
contradictions or mistakes.  In my opinion there is not a consensus to
hold the spec from progressing and I believe the working group does
not have further energy to conduct detailed reviews.  Furthermore, I
think that the real feedback we want will come from implementers.

  1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There are a few vocal supporters, many quiet supporters, mostly mildly
skeptical supporters, and one noisy dissenter (who does not actually
oppose the document but does not acknowledge that DCCP may be
useful).  Again, with no operational and limited implementation experience,
some skepticism is appropriate.  It is likely that we will learn from
field experience and will revise the protocol either recycling at PS
or in the move from PS to DS.


  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize what are they upset about.

No appeals have been threatened.

  1.g) Have the chairs verified that the document adheres to _all_ of
        the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

  1.h) Does the document a) split references into
        normative/informative, and b) are there normative references to
        IDs, where the IDs are not also ready for advancement or are
        otherwise in an unclear state? (Note: the RFC editor will not
        publish an RFC with normative references to IDs, it will delay
        publication until all such IDs are also ready for publication as
        RFCs.)

a) Yes and b) No.  However, we would like to publish the core spec
with CCID2 and CCID3.  The CCIDs are in a final wg review which should
conclude December 6th.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a writeup section with the following
        sections:

        *    Technical Summary

The Datagram Congestion Control Protocol (DCCP) is a transport
protocol that provides bidirectional unicast connections of
congestion-controlled unreliable datagrams.  DCCP is suitable for
applications that transfer fairly large amounts of data, but can
benefit from control over the tradeoff between timeliness and
reliability.  TCP is not well-suited for these applications, since
reliable in-order delivery and congestion control can cause
arbitrarily long delays.  UDP avoids long delays, but UDP applications
that implement congestion control must do so on their own.  DCCP
provides built-in congestion control, including ECN support, for
unreliable datagram flows, avoiding the arbitrary delays associated
with TCP.  It also implements mechanisms for reporting loss, reliable
connection setup, teardown, and feature negotiation.  The congestion
control mechanisms are defined in Congestion Control Profile
documents, known as CCIDs.

        *    Working Group Summary

There is a strong working group consensus to develop this protocol.
The applicability of DCCP to real-time multimedia flows has been
somewhat controversial in the working group.  However, the modular
nature of the the protocol has enabled support for this core
specification while work proceeds to support real-time applications.
There is clear and strong support for applying DCCP to non-real-time
streaming and growing interest in other applications, as well.

        *    Protocol Quality

DCCP has received extensive transport and cross-disciplinary review.
Written "expert reviews" were conducted by Eric Rescorla (a security
expert), Magnus Westerlund (a multimedia expert and AVT wg chair), and
Greg Minshall (a TCP expert), generating many detailed comments and
substantive improvements in the protocol.  The expert review was
followed by a working group "design review" at IETF-57 where the
working group and invited experts -- Magnus Westerlund (multimedia),
Steve Bellovin (security), and Rob Austein (architecture) -- walked
through the spec in detail resulting in additional comments and
substantive changes.  Additionally, formal modeling was performed
showing that DCCP is deadlock-free.  The protocol is as mature as is
possible without significant implementation experience.  The three
known implementations were started early in the life of the
specification and one (from ICIR) resulted in some relatively major
changes to the spec.  Recently, it has become known that Kame FreeBSD
contains an implementation of DCCP, albeit not matching the final
version of the spec.  It is expected that feedback from implementors
and users will result in further improvements and revisions.