Re: [secdir] secdir review of draft-ietf-tcpm-rfc3782-bis-03

["Henderson, Thomas R" <[e-mail]>]

Tom, thank you for providing helpful comments.  I've posted a version -04 document just now with the revisions.  Responses inline below.

> -----Original Message-----
> From: Tom Yu [mailto:[e-mail]]
> Sent: Tuesday, November 22, 2011 11:00 PM
> To: [e-mail]; [e-mail]; draft-ietf-tcpm-rfc3782-
> [e-mail]
> Subject: secdir review of draft-ietf-tcpm-rfc3782-bis-03
> 
> 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.

These references have been fixed, thanks.

> 
> 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.

Improved as you suggested.

> 
> 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."

Improved as you suggested.

> 
> 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.

I improved this along the lines of your above suggestion.