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

[Carsten Bormann <[e-mail]>]

On Feb 15, 2018, at 04:39, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> 
> Hi authors,
> 
> do want to make another update before I start IETF last call, or should I start it right away?
> 
> Mirja

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

>>>> 
>>>> --------------------------
>>>> 
>>>> Mostly editorial comments:
>>>> 
>>>> 1) First sentence in sec 1, maybe: 
>>>> s/The CoAP protocol/The Constrained Application Protocol (CoAP) [RFC7252]/

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 .)

>>>> 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.)“

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

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 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.“

Done (in a similar way).

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

>>>> 4) sec 4.3 "It MUST be kept for at least 255 s.“
>>>> 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.“
>>>> 
>>>> 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.“

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).