I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rmcat-scream-cc-11
Reviewer: Joel Halpern
Review Date: 2017-10-14
IETF LC End Date: 2017-10-23
IESG Telechat date: 2017-10-26

Summary: This document is almost ready for publication as an experimental RFC.

The reviewer hopes that the problem noted here are due to his mis-reading.

Major issues:
     The description of "a" after the pseudocode in section 4.1.2 states that it is positive when qdelay is increasing, and negative when qdelay is decreasing.  However, a is the ratio of two evaluations of the function R with different lags.  And R is defined as the sum of products of entries in the history vector.  The history elements (qdelay_fraction_avg) are always positive.  So the terms in R are always positive.  So a is always positive?

Minor issues:
     There appears to be something odd with the mathematical expression for the autocorrelation function R or its usage.  As written, with lag k the function uses N-k terms.  Which means that if the qdelay stays perfectly constant, a will be N-1/N rather than 1 (i.e. 0.95).  If this is intentional, it would be good to say so.

     What does the text in section 3.1 reading "It is however necessary that they [ sender and receiver] use the same clock frequency" mean?  Times are exchanged.  Frequencies are not.  Is this intended to be a statement about resolution?  it appears to describe something that is not visible to the protocol.  As such, what happens if the requirement is not met and the failure is not detected?"

    max_bytes_in_flight appears in the pseudocode in section 4.1.2.2, but does not appear in the list of state variables earlier in the document.

Nits/editorial comments: 
    In the pseudocode in section 4.1.2, is the variable "a" really "a_t"?

    In section 4.1.1.2 in the definition of min_cwnd, should there be a note about the (admittedly unlikely) case where 2*MSS is less then MIN_CWND?

    In the last paragraph of 4.1.2.2, is the new cwnd limited by the variable min_cwnd as stated in the text, or the constant MIN-CWND as shown in the pseudocode?