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
