Telechat Review of draft-ietf-core-cocoa-03
review-ietf-core-cocoa-03-tsvart-telechat-eddy-2018-03-06-00

Thank you; I'm fine with these changes.

On 2/21/2018 5:23 PM, Carsten Bormann wrote:
> Hi Wesley,
>
> Thank you for this thorough review, and apologies for the high RTT of this
email. > > We have prepared > >      
https://tools.ietf.org/html/draft-ietf-core-cocoa-03 > > with some reactions to
your (and Mirja’s) comments; diff is in > >      
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt > >> The
terminology "RTO estimate" used throughout the document is confusing to me. >>
The RTO is a solid value, not estimated, and is computed from estimates of the
>> RTT and RTT variation.  You could talk about estimating the "optimal" RTO
value >> (for some definition of optimal), but I don't think that's the case
here. >> Similarly section 4.2 is titled "Measured RTO Estimate", but RTO is
not a >> measured quantity (it is always computed).  I think this terminology
needs to >> be corrected throughout the document. > We fixed the title of 4.2
(which was indeed misleading) to “Measurement-based RTO Estimate”. > We are
using “RTO estimate” because we have three estimator processes (the weak, the
strong, and the combined one).  The result of the last estimator is used as the
actual RTO value.  But in 15 places we were trying to highlight the estimator
process and not the use the result is being put to, that’s where it says RTO
estimate. > If you have an idea how to get this result as well as avoid some of
the confusion this seems to generate, we’d like to hear it. > >> Section 3
seems important to me, but doesn't say very clearly what it means by >>
"generally applicable".  Does that mean that it could run across the Internet?
>> Does it work if there are very short or very long delays, or only ones
around >> the values mentioned in Apppendix C?  Does it work if the links are
very thin >> bandwidth?  Is it efficient when there is very high bandwidth
(e.g. Gbps >> range)?  Since there are many classes of IoT device and many
possible use >> cases, it seems important to me to be a little bit more clear
about the >> envisioned use cases, or at least the specific ones that have been
explored >> to-date, versus what hasn't been explicitly considered but might
(or might not) >> also work.  The appendix just sort of uses the word "diverse"
and mentions a >> couple link technologies, but otherwise doesn’t provide any
enlightenment. > We expanded this a bit, please see > >
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-4 > > We
did not explicitly restate the area of application of CoAP; of course CoCoA is
intended to be used with CoAP, so this is less about data center use with
Gbit/s channels, but more about the environments described in RFC 7228. > >
(Note that there are also different “efficiency” considerations here: it is not
the objective of CoCoA to fill a link.) > >> The first sentence in section 4
doesn't make much sense to me, since the >> default timeout doesn't imply any
knowledge of the RTT.  Do you mean to say >> that a more appropriate RTO can be
computed once some RTT samples are >> available?  The wording could be
clarified here. > Should be fixed now. > >> The description in the beginning of
section 4.2 says that ambiguous samples >> resulting from retransmissions are
used in the "weak" estimator, and seems to >> be saying that Karn's algorithm
is not used for filtering samples?  The >> rationale seems to be in 4.2.2, but
the text there is vague.  In general, it >> would seem to result only in a
potentially slower than necessary timeout, but >> still faster than the
default.  That seems inherently safe, and I'd think there >> could be a
stronger argument made than the current text. > We didn’t feel like attempting
to strengthen the language here, but did add a little bit of information in > >
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-03.txt#part-5 > >>
That said, the statement in this section that the rate of retries is reduced >>
does not make sense, since any time the RTO decreases, the rate of retries >>
should be increasing, with all other things considered equal? > Reduced as
compared to strong-only (as the text now states). > >> Is there sensitivity to
the weights for the EWMA?  This has been studied a bit >> for TCP, but I guess
may be different for CoAP scenarios since there are less >> samples typically,
or something? > Several weights were tried in the research.  Unfortunately,
this is less than adequately documented at this time.  It would be more
satisfying to have some documentation about choosing these weights, maybe we
can spawn some more formal research about this, but the important thing of
course is that the results do look good with the suggested weights. > >> Why is
this being targeted for just Informational rather than Experimental or >>
better?  It's mentioned as being informational in both the header and Section
>> 1.1, but I didn't notice an explanation of why the WG thinks it wouldn't be
a >> candidate for widespread use, etc.  Is there a concern that needs to be >>
described? > CoCoA is certainly intended to be the go-to implementation
strategy for all but class-1 [RFC7228] devices. > > Experimental would be fine
if we had an experiment that we want to run. > But the experiments we came up
with already were done (see Appendix A). > > The question is, of course,
whether unilateral implementation methods, to which congestion control methods
without participation of the peer such as CoCoA belong, should be informational
or standards track.  Given that the Security area does most of its
standardization work in informational documents, the line is blurry.  Outside
security, generally, what needs to be implemented for interoperability goes
into standards track, and the rest is much less well-defined.  We went for
informational because it’s possible.  Standards-Track also would work; I think
we can leave this decision to the wisdom of the IESG. > > Grüße, Carsten > >