Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
draft-ietf-dccp-ccid2-10

[Ballot comment]
The last thing to do is have public review of the re-purposing of protocol
number 33 - I need IESG consultation on the wording of the announcement
of the review, after some informal chat.

IANA Comments:
Upon approval of this document, the IANA will add value 2 to the CCID registry.
The IANA will also register the CCID 2 specific numbers (in the Reset Codes, Option Types and Feature Numbers registries)

[Ballot discuss]
This is for the IANA Considerations - this review that might have been done before the IESG
saw the document, but seemed reasonable to have in with IESG review.

The CCID documents should include the text about the motivation for their IANA codespaces
that appears in the protocol spec, section 10.3.  That said, no ccid-specific options, reset codes
or feature codes are registered, so please say that.  Because a standards track congestion control
protocol must have assured behavior, its extensions must be tightly reviewed, so the extensions
for these CCIDs have to be standards track.  Replace IETF Consensus with Standards Action
when a CCID is standards track.

[Ballot comment]
Review by Michael Patton, Gen-ART:

This is a combined review of two documents:
    draft-ietf-dccp-ccid2-08.txt
    draft-ietf-dccp-ccid3-09.txt

Summary: These drafts are basically ready for publication.


I don't have time to try and fully understand all of the implications
and details of the algorithms, but they seem basically sound.  I
primarily reviewed for GenART criteria of clarity and readability.
There were two points where I had problems in each draft, described
below.  In both drafts I thikn the first definitely needs
consideration.  The second is just a suggestion for improving the
clarity and readability...


In draft-ietf-dccp-ccid2-08.txt:

Section 6.1.2: "bound Ack Ratio below by two" that phrase isn't proper
English, and I'm not certain, but I think you meant "bound Ack
Ratio to be at least two" although it might have been "bound
Ack ratio to be at most two".  This definitely needs to be
more clearly stated.

Section 3.1: "The differences between CCID 2 and straight TCP include:
    CCID 2 applies ..."  This section reads strangely, because the
    "include:" implies a list and then the sentence ends with only one
    item.  I realized in analyzing it tat the several following
    sentences are the additional differences, but the strange
    construct is disorienting and detracts from the readability of
    this section.  I would suggest starting a new paragraph with this
    (separating the similarities from the differences in their own
    paragraphs), and the redoing either with the existing text done as
    a bullet list, or by slight rewording to eliminate the problem.
    More specifically, I offer the following two alternatives for the
    second paragraph

The differences between CCID 2 and straight TCP include:
  o CCID 2 applies congestion control to acknowledgements, a
    mechanism not currently standardized for use in TCP.
  o DCCP is a datagram protocol, so several parameters whose
    units are specified in bytes in TCP, such as the
    congestion window cwnd, have units of packets in DCCP.
  o Unreliability also leads to differences from TCP: DCCP
    never retransmits a packet, so congestion control
    mechanisms that distinguish retransmissions from new
    packets have been redesigned for the DCCP context.
    or

CCID 2 includes several differences from straight TCP.  CCID 2
applies congestion control to acknowledgements, a mechanism
not currently standardized for use in TCP.  DCCP is a datagram
protocol, so several parameters whose units are specified in
bytes in TCP, such as the congestion window cwnd, have units
of packets in DCCP.  Unreliability also leads to differences
from TCP: DCCP never retransmits a packet, so congestion
control mechanisms that distinguish retransmissions from new
packets have been redesigned for the DCCP context.


In draft-ietf-dccp-ccid3-09.txt:

In Appendix A, it says "Research and engineering will be needed ..."
which suggests that Experimental might be better than PS at this
point.  However, overall it seems to have been fairly well thought
out, so perhaps it really is sufficient for PS.  That's the IESG's
call.

In Section 6 there is a reference to "circular sequence space".  That
should probably reference a specification.  In the DNS we had problems
with some implementors not understanding a reference in the original
spec to "sequence space arithmetic" which resulted in the need for
RFC1982.  I suggest you avoid such problems with an explicit reference
here.  The description in RFC793 Section 3.3 is TCP specific, and
doesn't actually explain it in much detail (although apparently good
enough for interoperability of most TCP implementations :-).  RFC1982
has more details and even though it was written specifically with the
DNS usage, it's fairly general, so that might work.  It's probably a
bad idea to try explaining it again, so a reference to either of those
is probably best.

Typos:
------

Section 10.2: "an procedure" => "a procedure"

Section 10.3: "is less that" => "is less than"