Re: [dccp] Review of DCCP congestion control 3

[Sally Floyd <floyd@icir.org>]

Magnus -

Many thanks for the feedback.

>Hi,
>
>Here is my comments to CCID2 (draft-ietf-dccp-ccid2-03.txt) so far.
>
>A1. The short copyright statement is missing between status of this doc
>and abstract.

Will do.

>A2. Section 1.2, Second paragraph of bullet 2, last sentence: Regarding
>the verification of the ECN NONCE on the ACK subflow. The sender can't
>verify this, and I don't see a reason for the receiver to check this. So
>please clarify if you mean that the receiver should not verify the ACK
>flow?

Will do.  We do mean that there is no reason for the receiver to
verify the nonces on the ACK flow, so we will clarify.  (Because
the sender is acting directly on the information about congestion
on the ACK path, it would be complex, I think, to try to devise a
mechanism for the receiver to verify that the sender wasn't cheating
about the congestion control for the reverse-path traffic.)

>A3. Section 1.2, Bullet 6: How does the sender estimate the round-trip
>time? Do it use a ACK based method or does it utilize the
>timestamp/timestamp echo functionality.

The sender generally uses an ACK-based method to estimate the round-trip
time, although a Timestamp option would also be acceptable. We will
clarify.

>A4. Are the intention of the document to use only a single space between
>sentences? Otherwise there a number of inconsistent places, including at
>least one place where there are three spaces before a sentence within a
>paragraph.

Different co-authors had different styles.  We will fix.

>A5. Section 3, last paragraph. I get the feeling that this paragraph
>actually belongs in section 1.

We agree. We will probably move it into the new "Application Requirements"
section, which is currently Section 7 and may become Section 1.1.

>A6. How is the behavior of this CC in regards to the packet size. My
>basic feeling is that it penitialize packet rate rather then bytes
>transmitted. Please elaborate on this as it seems important information
>for an application developer.

Penitialize?  CCID2 is optimized for a sender that generally
sends MSS-sized packets, and we definitely should elaborate on this.

>A7. The applicability statement in the introduction should be very
>complete to simplify for application developers to decided on what CCID
>they should use.

We added an applicability statement, Section 7, in response to
reviewer feedback.  We will add a pointer to this from the Introduction
(or move it to Section 1.1).

>A8. Section 4, page 9, third paragraph: "Third, it is at least two for a
>congestion window of four or more packets." I recommend to reformulate
>the sentence to "Third, it is two or larger for a congestion window of
>four or more packets."

We are redoing this sentence.

>A9. Section 4.3, second paragraph: In the first sentence, what is meant
>with datagram? This sentence does not make sense as currently written.

We just meant a standard data packet from the sender.  We will clarify.

>A10. End of draft: The draft is missing copyright statement and IPR
>statement.

Will do.

>A11. Section 1, the recommendation to track development. Is that
>possible and safe?

About tracking TCP development?   I think it is possible and safe,
but it might need a little more thought and clarification,
and documentation.

- Sally (and Eddie)

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html