Genart last call review of draft-ietf-rmcat-scream-cc-11

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

 



Reviewer: Joel Halpern
Review result: Almost Ready

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?





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]