Document: draft-ietf-dccp-ccid2-08.txt
          draft-ietf-dccp-ccid3-09.txt
Review: Michael A. Patton
Date: 2 mars 2005 


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"