Skip to main content

Last Call Review of draft-ietf-rmcat-scream-cc-11

Request Review of draft-ietf-rmcat-scream-cc
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-10-23
Requested 2017-10-09
Authors Ingemar Johansson , Zaheduzzaman Sarker
I-D last updated 2017-10-14
Completed reviews Opsdir Last Call review of -12 by Tina Tsou (Ting ZOU) (diff)
Genart Last Call review of -11 by Joel M. Halpern (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Request Last Call review on draft-ietf-rmcat-scream-cc by General Area Review Team (Gen-ART) Assigned
Reviewed revision 11 (document currently at 13)
Result Almost ready
Completed 2017-10-14
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


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

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, 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 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, is the new cwnd limited by the variable
    min_cwnd as stated in the text, or the constant MIN-CWND as shown in the