Last Call Review of draft-ietf-rmcat-scream-cc-11
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
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.
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?
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 22.214.171.124, but does not appear in the list of state variables earlier in the document.
In the pseudocode in section 4.1.2, is the variable "a" really "a_t"?
In section 126.96.36.199 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 188.8.131.52, 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?