Re: [rmcat] Adam Roach's Discuss on draft-ietf-rmcat-scream-cc-12: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

Responses below.

On 10/26/17 4:01 AM, Ingemar Johansson S wrote:
> Hi
> And thanks for the review, comments inline marked [IJ]
>
> /Ingemar
>
>> -----Original Message-----
>> From: Adam Roach [mailto:[e-mail]]
>> Sent: den 26 oktober 2017 07:52
>> To: The IESG <[e-mail]>
>> Cc: [e-mail]; Martin Stiemerling
>> <[e-mail]>; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Adam Roach's Discuss on draft-ietf-rmcat-scream-cc-12: (with
>> DISCUSS and COMMENT)
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I'm confused about whether the text in this document is intended to form a
>> normative description of SCReAM. The document contains the following
>> statement:
>>
>>     Note that the pseudo code does not show all
>>     details for reasons of readability, the reader is encouraged to look
>>     into the C++ code in [SCReAM-CPP-implementation] for the details.
>>
>> This effectively states that the cited C++ code forms the normative
>> specification of the SCReAM algorithm, and that this document is a non-
>> normative companion to help understand the normative code.
>>
>> If this is the case, then:
>>
>> - The [SCReAM-CPP-implementation] reference needs to be moved from
>> "Informative References" to "Normative References",
>>
>> - The abstract and introduction need to make it much clearer that the
>> normative definition of the SCReAM algorithm is a body of C++ code rather
>> than the prose and psuedocode in this document, and
>>
>> - We need to coordinate with the RFC editor to ensure proper archival of the
>> code at [SCReAM-CPP-implementation]. At this time, github.com does not
>> meet the standards of archival quality that the RFC series is expected to
>> meet.
>>
>> If the C++ implementation is *not* the normative definition of SCReAM,
>> then the psuedocode and definitions in this document need to be complete
>> and sufficient to implement the algorithm; and, in particular, it cannot omit
>> algorithm details "for reasons of readability."
> [IJ] Understand the concern.
> The pseudocode is normative as is and the "for reasons of readability" quote is actually note needed. The C++ code reference is that as I personally like to see the real running code in order to fully understand the function, and to be able to do fast experiments.
> The C++ code contains optimizations, for instance it is not necessary to re-compute the pacing rate and the congestion window for each received ACK and that reduces complexity at very high bitrates. The code also contains optimizations for how bytes in flight is computed
> In addition there is some code to increase the stability for the cases where packets arrive in bursts at the receiving end. This occasionally happens with LTE access and the fix limits how much the congestion window can increase. The fix does not make much difference and is not critical for the function of SCReAM.
> Also there is some extra code in the congestion window update function that improves the performance at very low bitrates (less than 100kbps). Again this code is not critical for the function in SCReAM.
>
> If possible I would like to have a refence the C++ code, with the necessary changes such as removal of "for reasons of readability" and making it more clear that the pseudo code and the draft text constitute a normative specification. It is however not a MUST that the C++ code is referenced to in the draft and it cannot be completely ruled out that parts of the code can change over time, the C++ code has now also gained sufficient traction to live on its own.
>
> What do you think is the best way forward here ?

Thanks for clarifying. Assuming that the only differences between the 
psuedocode in the draft and the C++ implementation is this small list of 
optimizations, I think you'll want to replace the text I quote above 
with something more like:

"As mentioned in section 7, calculation of qdelay may benefit from 
additional optimizations for handling of very high and very low 
bitrates, and from additional damping to handle periodic packet bursts. 
Some such optimizations are implemented in [SCReAM-CPP-implementation], 
but they do not form part of the specification of SCReAM at this time."

And then add text to section 7 suggesting additional experimentation 
with qdelay calculations.

Your remaining edits look good to me. Thanks.

/a