[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dccp] Review of DCCP congestion control 3



Hi,

Comments on draft-ietf-dccp-ccid3-03.txt
----------------------------------------

B1. The short copyright statement is missing between status of this doc
and abstract.

B2. Abstract contains contradicting information with CCID2. Both CCIDs
claim that they are suitable for streaming media. I think a little bit
more direction about this can be given.

B3. The allowance that one may update the TFRC to current
standardization level without CCID3 update, is that safe? Secondly I
dislike when one use normative language in an introduction chapter.

B4. Section 1: Please place the RFC 2119 part in a conventions chapter.

B5. I think that usage scenario or rather applicability statement for
this CCID should be more elaborate. Further trying to capture the
behavior that can be expected and possible suitable applications.

B6. Section 3, second paragraph: The window counter is not describe
below, it is described in a later section. Why not point directly at
that so one does not need to question where it will be.

B7. Section 4. Why not put in references to the correct sections for the
different options in the bulleted list?

B8. Section 4.3. In the first part it mentions the a receiver should
occasionally acknowledge the receivers acks. This is later rehashed in
more details. Could you restructure this so that the details are
included directly on what occasionally means.

B9. Section 5, third paragraph: this reference CCID2 for how to return
the ECN nonce sum. Is this not covered in enough detail in the DCCP spec
itself? If not this is maybe where it should be explained.

B10. Section 6, last sentence and paragraph before 6.1. I think the
usage of Option Error is the wrong error message. Why not define
something more relevant, like "Unfulfilled CC requirement"?

B11. Section 6.3: How does a receiver calculate the rate that should be
entered here? How to calculate bps is tricky. If packets only arrive
during the second half of the ack interval should the rate be calculated
over the whole time period or only over the actual arrival period.
Please provide a normative calculation for this.

B12. Section 6.5: How do a receiver calculate the inverse loss event
rate. Please provide description or reference. I have seen that it
somewhat explained in section 6.7, however I believe this to be the
wrong place. How to weight the average needs to be specified.

B13.  Section 6.7, paragraph 3 & 4 of page 13: I think the explanation
of how to derive the loss events values is hard to understand. Please
try to better explain the text and an example could also help make it
more easier to understand. For example I guess that the left edge is the
lowest in modulo arithmetic sequence number that was received in the
flight of non-marked/lost packets, not the first as written.

B14. Copyright and IPR sections are missing.


Best Regards


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


_______________________________________________
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