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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 9 Feb 2018 14:58:37 +0100

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.

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 12 Feb 2018 13:33:22 +0000

> @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 sta…

Done!

- - Jaime Jiménez

> On 9 Feb 2018, at 15.58, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi authors!
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 12 Feb 2018 22:12:17 +0100

Thanks!

> Am 12.02.2018 um 14:33 schrieb Jaime Jiménez <[email-masked]>:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 15 Feb 2018 13:39:12 +0100

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) <[email-masked]>:
> 
> Thanks!
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Feb 2018 15:58:55 -0800

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

Hi Mirja,

as you can see, we opted for making a small update (we could have communicated this earlier).

We have prepared

	https://tools.ietf.org/html/draft-ietf-core-cocoa-03

with some reactions to your (and Wesley's) comments; diff is in

	https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt

Details below.

The authors believe that -03 is now ready for IETF last call.

Grüße, Carsten

Fixed (in abstract, too).
Really, I’d like to get CoAP on the “does not need to be expanded” list, though.
(Oops, the reference got lost in -03; added in the editors’ draft on https://github.com/core-wg/cocoa .)

>>>> congestion control scheme work in a safe manner.)“

Gone.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-3

>>>> 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 inst…

We made it more explicit that we are using the same variables and calculations as RFC 6298 (which the reader indeed needs to be familiar with).
(And fixed the formulas to be less confusingly spaced.)

https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-5

>>>> 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…

Done (in a similar way).

Lower down in…
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-5

>>>> Why is that a MUST and why 255s?

255 s is a convenient 8-bit value that fits well with the time scales of CoAP.  I think the point here is that if you discard data about worse-than-default RTO too quickly, then you don’t get all of the congestion control benefits of CoCoA in worse-than-default environments.  The MUST just was a very conservative precaution against lazy implementers.  Clearly, this number needs to scale with the RFC 7252 Section 4.8 transmission parameters (see also Laurent Toutain’s new timescale draft), so we do indeed have a bit of a bug here.

In
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-6
we tried to be a bit more explicit about the goals and a bit less draconian about the specifics (SHOULD instead of MUST).  The recommendation of 255 s (for the default Section 4.8 CoAP parameter set) stays in, but there is additional information that should help an implementer do the right thing when there are different timescales.
Alternative timescales haven’t really been tried a lot, so trying to nail this down to specific numbers here would be premature.

(CoRE WG: The reduction from MUST to SHOULD is the only technical change in -03 relative to -02.
Please check whether you are comfortable with this.)
 
>>>> 5) I would consider to have section 5 before section 4,

That didn’t work well for us.
After all Section 5 is only about Non-Confirmables, these are one specific case that requires additional considerations (we are not getting measurements back), but is based on the estimator of 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.“
>>>> 

We put some of this in the introduction, see
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-2
(The big blue block lower down).

>>>> 6) Maybe consider to integrate Appendix B into the body of the document. I think that would actually help the reader.

We actually like it clearly separated.  We have a few forward references; we hope that people can skip forward along those easily if they prefer code over text (I certainly do).