Re: [tcpm] Heads up on the upcoming WGLC for COCOA

["Scharf, Michael (Nokia - DE/Stuttgart)" <[e-mail]>]

Hi all,

I have read draft-ietf-core-cocoa-01 as a contributor to TCPM, in particular since TCP documents are mentioned therein. Please find below my comments. Note that I have not followed discussions on this document and I also do not monitor the CoRE mailing list, i.e., I may lack some context. If topics have been discussed already, I apologize for that.

I wonder if this document is already ready for WGLC. There is missing text, and to me the alorithm is not very well motivated. A formal issue is the explicit violation of the BCP RFC 8085 but this is more something for the IESG to care about.

If the document should continue to use an algorithm contradicting RFC 8085, I think Appendix B should be in the document.

I have not read Appendix A. An algorithm like the one mentioned in Appendix A IMHO requires comprehensive simulation and empirical evaluation to ensure it is robust in all possible corner cases. This may be a topic e.g. for ICCRG. In my option, either evidence should be included or referenced in the document, or the Appendix A should be removed. It seems to me that Appendix A could be moved to another draft without impacting the rest of this document.


Major issues:

- Abstract: The abstract does not explain well the actual content of the document. For instance, it does not mention that an RTO algorithm is described in the document.

- Abstract: The abstract should mention that the document is informational.

- Section 3: I think the area of applicability should be better explained. As far as I can see, the document focuses on low-bandwidth and high-latency links. This is probably a relevant application scenario for CoAP. However, I wonder if the mechanism would be equally well applicable to other transports built for constrained network, see e.g. the "IoT" work in 4G/5G. I am not sure if they have the same delay characteristics. Also, the document seems to assume later "naturally lossy networks"; this is not generally true in the Internet. All in all, it really would make sense to explicitly spell out for what environments the algorithms have been designed.

- Section 4: Somewhat related, I think at the beginning of Section 4 a better description is needed for the design rationale of the algorithms, e.g., on underlying assumptions on the absolute values of delays. The current draft basically presents an algorithm without much discussion on the design choices, and whether alternatives would exist. For instance, I believe that the document implicitly assumes that delays/RTT can be larger than 1s. Such assumptions should be spelt out. 

- Section 4, Section 4.2, and Section 4.2.2: Indeed, BCP RFC 8085 defines "Latency samples MUST NOT be derived from ambiguous transactions." As far as I understand, this document explicitly violates the IETF concensus on RFC 8085. Whether this is acceptable from a process perspective probably needs IESG discussion. From a formal perspective, at minimum, I would expect this deviation to be mentioned very explicitly in the introduction and at the beginning of Section 4. I'll comment below on some technical aspects.

- Section 4.2 and in particular 4.2.1: This document should use a terminolgy like "differences to the algorithm in RFC 6298". Using the term "modification" is confusing. This (informational) document does not *modify* RFC 6298 or the algorithms therein.


Minor issues:

 - I find the title "CoAP Simple Congestion Control/Advanced" confusing. To me the terms "simple" and "adanced" don't fit together very well. If the objective is to use the acronym "CoCoA", this could be better explained, e.g., in the abstract.

- Section 1: I think "(See Abstract.)" should be replaced by actual text. As mentioned separately, IMHO the abstract does not well describe the document neither.

- Section 1 and 2: I would avoid that a long-lasting document refers to "minutes of the IEFT 84 CoRE WG meetings". I think a document should be reasonably self-contained, in particular in the introduction. I also think that some content of Section 2 would well fit into the introduction. But this may be a personal preference of me.

- Section 3: As already mentioned, if "aggregate congestion control (Appendix A) is not yet supported by research", I wonder why not to move this to a separate document and publish that other document once there is research. In any case, the term "cloud side" in that paragraph is not well defined and the use case assumed here is not clear to me.

- Section 4: "This is based on the usual algorithms for RTO estimation [RFC6298]". RFC 6298 describes the standardized TCP algorithm; I think "usual" is not a precise characterization as some TCP stacks may not exactly follow RFC 6298.

- Section 4: "One important consideration not relevant for TCP is the fact that a CoAP round-trip may include application processing time". If the document wants to compare to TCP, it may be worthwile here to discuss the TCP delayed acks.

- Section 4.2 (and follow-up): I don't think the use of the weak estimator is well motivated. The document does not give a good explanation why using ambiguous samples is really useful, except for the observation that there have been some (small?) benefits in some studies, without looking into root causes. For instance, the weak estimator can be significantly larger than the actual network delay. Why does it make sense to increase the RTO way beyond the actual network delay in that case? Wouldn't this impact the delivery delay if a follow-up packet gets lost, and thus degrade the application performance more than needed? In what network scenarios does using ambiguous samples really help? And why does it even make sense to calculate the variance of a sample that is ambiguous? Unfortunately, there is no single set of delay and loss characteristics in the Internet that a performance study could use. Therefore, arguments on functional properties of an algorithm (e.g., in simple example scenarios) would be quite helpful.

- Section 4.2 (and follow-ups): I don't think the document addresses well how close or far away the estimates of the strong and weak estimator can be to each other. For instance, in a network without much congestion, would the weak estimator get updated if the latency in the network changes? How does the Aging according to Section 4.3 tie in in that case? Based on the document it is difficult to understand how the various different algorithms with conditional statements finally react altogether, and whether they are safe in all corner cases. It may be simpler to present the complete algorithms as a sequence of processing steps. Alternatively or in addition, some examples for simple scenarios could help to better understand what the algorithms would converge to (e.g., one example with rather low RTT samples and one with rather large ones). Such examples may not be mandatory in an RFC, but this would really be nice-to-have, IMHO.

- Section 4.2: If we assume that the weak estimator is used (see my other comments), it seems that a sender would *either* use (1) or (2), right? If so, this could be better spelt out.

- Section 4.2.1: "For RTO estimations below 1 s, the RTO for a  retransmission is multiplied by 3, while for estimations above 3 s,  the RTO is multiplied only by 1.5 (this updated choice of numbers to  be verified by more simulations)". Will the document be updated with results from more simulations prior to WGLC?

- Section 4.2.2 "In contrast to [RFC6298], this algorithm attempts to make use of ambiguous information from retransmissions.  This is motivated by the high non-congestion loss rates expected in constrained node networks,  and the need to update the RTO estimators even in the presence of loss." I believe this assumption does not generally apply to all network technologies. Several technologies have ARQ or FEC mechanisms below IP to make the rate of non-congestion loss extremely small. I think this should be discussed. It would be worthwile to expand on what benefits (if any) the weak estimator might have in networks without non-congestion loss.

- Section 4.2.2: "However, those samples are not simply combined into the strong estimator, but are used to correct the limited knowledge that can be gained from the strong RTT measurements by employing an additional weak estimator." If there is benefit, it would be useful to add an example that explains that "limited knowledge" and why such a correction could be useful.

- Section 7: Security considerations seem to be missing. I wonder about the scenario that an attacker only has temporary access to the network path. By causing some packets to be dropped, can he increase the RTOs in a large number of senders for a relatively long time, thus degrading the performance significantly?


Thanks

Michael

________________________________________
From: tcpm <[e-mail]> on behalf of Jaime Jiménez <[e-mail]>
Sent: Wednesday, April 12, 2017 14:35
To: [e-mail] WG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [tcpm] Heads up on the upcoming WGLC for COCOA

Hi CoRE WG,

this is just a heads up for the upcoming WGLC for "CoAP Simple Congestion Control/Advanced”.
https://tools.ietf.org/html/draft-ietf-core-cocoa-01

Note that there is still some discussion about whether to keep the appendixes or not, and that there is time to get other comments before WGLC.
This document has been presented multiple times and I’d like to progress with it soon, it’d be great to have it by Prague.

To ICCRG, as you now already, this was presented quite some time ago, below is the links to the session and the slides.

Session: https://www.ietf.org/proceedings/92/iccrg.html
Presentation: https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-2.pdf

Between the two sessions the main difference is the addition of the appendixes:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-01.txt

Ciao!
- - Jaime Jiménez