[core] Review of draft-ietf-core-fasor-01

[Carles Gomez Montenegro <[e-mail]>]

Dear FASOR authors,

First of all, my apologies for providing you with this review later than I
expected. I hope it is not too late, considering that the cutoff date is
quickly approaching!

Thank you for the document. Please find below a number of comments and
suggestions:

- Section 1, first paragraph: "Both default RTO mechanism for CoAP
[RFC7252] and CoCoA [I-D.ietf-core-cocoa] have issues in dealing with
unnecessary retransmissions". CoCoA is still work in progress, and there
are ideas on the table to improve it. Perhaps some different phrasing (for
the sentence  I highlighted here) might better support future updates of
CoCoA.

- Section 1, last paragraph: s/unnecessary retransmissions that a sender
may have sent due to an inaccurate RTT estimate/unnecessary
retransmissions due to an inaccurate RTT estimate

- The RTO acronym is defined (preceded by its expanded form) twice in the
document. Also, there are instances of both "RTO" and retransmission
timeout throughout the document. Once "RTO" has been introduced, just the
acronym should probably be used.

- Page 3: "However, there are couple of exceptions when the RTT estimation
is not available". Well, the second bullet after that sentence corresponds
rather to "is not updated" than "is not available".

- Page 3: "- At the beginning of a flow where an initial RTO of 2 seconds is
used." As a reader, I am not sure if this is mentioned as a negative
aspect of CoCoA. Perhaps not, but it might be good to emphasize that
something like this is unavoidable (and, as I understand, it is the same
with FASOR), whereas the second bullet is where a problem may actually
happen.

- Page 3, last paragraph: "CoCoA being unable to take RTT samples at all".
In my opinion, "at all" is probably not the right text here, and the
phrasing used should be relative to the context of the problem mentioned.

- Page 3, last paragraph: similar to my first comment, some adaptation
might be needed for this paragraph to better support possible future
updates of CoCoA.

- Section 4.1, first line: s/an CoAP/a CoAP

- Section 4.1, third line: "normal RTO or FastRTO". I was wondering if
handling two terms for the same concept is really useful. But perhaps it
may make sense depending on the context in each instance of either term.
So feel free to proceed as you prefer.

- Section 4.1, first paragraph: s/backup mechanisms/backup mechanism

- Section 4.1, last paragraph: "FastRTO is updated only with unambiguous
RTT samples.  Therefore, it closely tracks the actual RTT of the network
and can quickly trigger a retransmission when the network state is not
dubious."  Perhaps there may be lossy intervals during which the "actual
RTT" might vary (regardless of losses), e.g. due to a change of the
physical layer bit rate, but then FASOR would not be able to collect
"actual RTT" samples during such interval... It might be interesting to
consider this situation as well. If no modification to the FASOR algorithm
is deemed necessary, then perhaps at least some discussion on this might
be useful.

- End of section 4.1. What is "K"? (I wasn't able to find a definition of
"K" earlier in the document.)

- The document assumes that responses are "acknowledgments". However,
there may be responses that do not correspond to acknowledgments at the
messages sublayer of CoAP, that still provide RTT samples. It may be good
to clarify this, since otherwise perhaps a fraction of the full set of RTT
samples may remain unused.

- The document also assumes in several instances that the message that
triggers some response/ACK/packet from the other endpoint is a "request".
Please note that there may be messages that do not carry requests which
may anyway be sent as CON messages, from which an RTT sample can be
obtained.

- Section 4.2, first paragraph. A factor of 1.5 (by default) is mentioned
at the end of the paragraph. Is there any hint on how this factor should
be set?

- Section 4.2, first paragraph, last sentence. Perhaps adding some forward
reference might help the reader?

- Section 4.3.1, FAST_SLOW_FAST: "If the request message needs to be    
retransmitted, continue by using Slow RTO for the first retransmission in
order to respond to congestion".  This text implies that it is *known*
that the retransmission is due to congestion, but it could also be due to
bad link quality.

- Section 4.3.1, SLOW_FAST: s/transmisssion/transmission

- Section 4.3.1: s/if further retransmission are/if further
retransmissions are

- Section 4.3.1, last paragraph: "if RTO expires also for that request
message". When mentioning "that request message", which one does the text
refer to? Perhaps, consider rephrasing.

I hope this feedback can be useful!

Cheers,

Carles