Last Call Review of draft-ietf-tcpm-rfc3782-bis-
review-ietf-tcpm-rfc3782-bis-secdir-lc-yu-2011-11-24-00

The Security Considerations section of this document says:

   [RFC5681] discusses general security considerations concerning TCP
   congestion control.  This document describes a specific algorithm
   that conforms with the congestion control requirements of [RFC5681],
   and so those considerations apply to this algorithm, too.  There are
   no known additional security concerns for this specific algorithm.

I believe this assessment is accurate.

Editorial:

I found it really confusing where Section 4 appears to directly copy
text from RFC 3782 with no fixups of section references and step
numbers.  For example, 4.1 refers to a Step 1B of Section 3.  There is
no Step 1B in this document, and the relevant section is actually
Section 3.2.  Also, Section 4.2 refers to a Step 1A of Section 3, when
it probably means Step 2 of Section 3.2 of RFC 5681.

In Appendix B, first paragraph:

   In [RFC3782], the cwnd after Full ACK reception will be set to
   (1) min (ssthresh, FlightSize + SMSS) or (2) ssthresh.  However,
   there is a risk in the first logic which results in performance
   degradation.  With the first logic, if FlightSize is zero, the
   result will be 1 SMSS. This means TCP can transmit only 1 segment
   at this moment, which can cause delay in ACK transmission at receiver
   due to delayed ACK algorithm.

The phrase "first logic" sounds awkward, and should probably be "first
option", to align with the wording in Section 3.2.

In Appendix B, end of second paragraph:

   Even if window size is not small,
   loss of ACK packets or receive buffer shortage during fast recovery
   can also increase the possibility to fall into this situation.

should probably end with "...can also increase the possibility of
falling into this situation."

In the third paragraph of Appendix B:

   The proposed fix in this document ensures that sender TCP transmits
   at least two segments on Full ACK reception.

I initially couldn't determine exactly what changes in this document
achieve the purported fix, but I'm not an expert at TCP.  The text in
step 3 of Section 3.2 of this document is substantially the same when
describing the Full ACK behavior, and the prescribed options for
resetting the value of cwnd looked the same as in RFC 3782 until I
carefully compared them side by side.  Perhaps more clearly
identifying the change, using text like:

   The proposed fix in this document, which sets cwnd to at least
   2*SMSS if the implementation uses option 1 in the Full ACK
   behavior, ensures that sender TCP transmits at least two segments
   on Full ACK reception.

would be better.