Re: [core] AD review of draft-ietf-core-cocoa-02

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi authors,

do want to make another update before I start IETF last call, or should I start it right away?

Mirja



> Am 12.02.2018 um 22:12 schrieb Mirja Kuehlewind (IETF) <[e-mail]>:
> 
> Thanks!
> 
>> Am 12.02.2018 um 14:33 schrieb Jaime Jiménez <[e-mail]>:
>> 
>>> @Jaime: could you please update the shepherd-write to reflect that I’m the responsible area director and maybe provide one additional sentence to explain why informational is the right indented status!
>> 
>> Done!
>> 
>> - - Jaime Jiménez
>> 
>>> On 9 Feb 2018, at 15.58, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
>>> 
>>> Hi authors!
>>> 
>>> I reviewed the document and think it is ready for IETF last call. Find below a couple of mostly editorial notes that came to my mind while reviewing the document. Please let me know if you’ll like to address (if at all) any of these comments with an update before I start IETF last call, or if I should start the last call immediately with this version!
>>> 
>>> @Jaime: could you please update the shepherd-write to reflect that I’m the responsible area director and maybe provide one additional sentence to explain why informational is the right indented status!
>>> 
>>> Thanks!
>>> Mirja
>>> 
>>> --------------------------
>>> 
>>> Mostly editorial comments:
>>> 
>>> 1) First sentence in sec 1, maybe: 
>>> s/The CoAP protocol/The Constrained Application Protocol (CoAP) [RFC7252]/
>>> 
>>> 2) The following note is not necessary:
>>> "(Note that the present document is itself informational, but it is
>>>  discussing normative statements about behavior that makes the
>>>  congestion control scheme work in a safe manner.)“
>>> 
>>> 3) The formatting with (1) and (2) is a bit confusing in the equations in section 4.2.; maybe you can add some more space there. Further I really find it confusing that you directly use RTO instead of RTT here and then just later explain that you use an K of 1. I would rather explain that first an maybe even use RTT_weak and RTT_strong instead of E_
>>> 
>>> 4) I find the heading of section 4.2.1 a bit confusing and the whole section a bit hard to read as you didn’t really introduce the „new“ backoff calculation yet. Maybe you can actually move some of the discussion (about initial values and K) in the previous subsection and call this ubsection something like „Backoff calculation“ and then maybe add one sentence that explains what RFC6298 does, e.g. „In [RFC6298] the RTO is increased exponentially with a factor of 2 if the RTO timer expires.“
>>> 
>>> 4) sec 4.3 "It MUST be kept for at least 255 s.“
>>> Why is that a MUST and why 255s?
>>> 
>>> 5) I would consider to have section 5 before section 4, to give the reader a better idea that the calculated RTO is used to define the sending rate (which is the actually congestion control part of the spec). I think it would also be good to give a high-level (1-2 sentences) overview of the congestion control principle in the intro, e.g. CoCoA calculates the retransmission time-out (RTO) based on the estimated RTT with and without loss and limits the sending rate (for non-confinable packets) to 1/RTO. By taking retransmissions (in a potentially lossy network) into account when estimating the RTT, this algorithm reacts to congestion will a lower sending rate.“
>>> 
>>> Also this sentence in section 5.1 could be helpful information in the intro already: "Assuming that the RTO
>>>  estimation in CoCoA works as expected, RTO[k] should be slightly
>>>  greater than the RTT[k], thus CoCoA would be more conservative.“
>>> 
>>> 6) Maybe consider to integrate Appendix B into the body of the document. I think that would actually help the reader.
>>> 
>>> 
>> 
>