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

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

Dear Markku,

First of all, my apologies for the long delay in this response.

Thank you for taking my comments into consideration.

Please find below my inline responses:

On Thu, 16 Mar 2023 at 11:53, Markku Kojo <[e-mail]> wrote:

> Dear Carles,
>
> thank you very much for your thorough review. It is much appreciated and
> useful, although this reply comes so very late as the draft has been
> dormant for so long for various reasons. Apologies for that.
>
>
I am happy that my comments have been helpful, and no worries regarding the
delay (I have also been quite blocked recently).


> We believe we have addressed most of the suggestions in -02. In the few
> cases where we possibly did not (fully) address the suggestions we hope
> our answers and clarifications make sense and we may agree on how to
> address those cases (or if they need not to be addressed).
>
>
In my opinion, my comments have been well addressed, perhaps with only a
few pending/additional minor points, as shown below (absence of a comment
or a response means that I agree or no further action is requested from my
side).


> Please see inline some comments and answers.
>
> On Sun, 7 Feb 2021, Carles Gomez Montenegro wrote:
>
> > 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.
>
> Fair enough. Would it be better now when changed to:
>
>   "Both default RTO mechanism for CoAP [RFC7252] and the latest
>    version of CoCoA [I-D.ietf-core-cocoa] have issues in dealing
>    with unnecessary retransmissions"
>
> In order to make the text compatible with possible future versions of
CoCoA, I'd suggest something along the lines of:

NEW:
       "Both default RTO mechanism for CoAP [RFC7252] and the current
        version (i.e., as of the writing, -03) of CoCoA
[I-D.ietf-core-cocoa] have issues in dealing
        with unnecessary retransmissions"

I also think that it would be good to add some sentence at the end of the
same paragraph such as:

NEW:
        "Note that, hereinafter, any mention of CoCoA refers to its version
-03".


> > - 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
>
> Done.
>
> > - 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.
>
> Good catch.
> Hope it's better now.
>
> > - 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".
>
> I think the text is correct as it says *RTT estimation*, i.e., the
> process of making the estimate, is not available. However, it is now
> modified to read:
>   "... when the RTT estimate is not available or it cannot be updated".
>
> Hope that works better.
>
> > - 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.
>
> True, unnecessary rexmits are unavoidable with an initial RTO if the
> actual RTT is high enough. This holds for FASOR as well. But the problem
> is not alone in the inability to avoid unnecessary rexmits and take a new
> RTT sample. With CoCoA, if the RTT is high enough, the unnecessary
> rexmits are repeated for all subsequent messages because CoCoA has the
> same problem as default CoAP: it does not apply a larger, backed-off RTO
> from the previous msg exhange to the next msg exchange (which would break
> the chain of unnecessary rexmits).
>
> The new text tries to clarify this.
>
> > - 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.
>
> Agreed. This text has now been removed and replaced with the new text
> I mentioned above. Hope it works better.
>
> > - 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.
>
> Not sure where this (Page 3, last paragraph) refers to, but when we now
> mention the latest CoCoA and cite version -03, is it better (or sufficient
> to address this)?
>
> > - Section 4.1, first line: s/an CoAP/a CoAP
>
> Done.
>
> > - 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.
>
> The new text is now using FastRTO in the context of FASOR.
>
> > - Section 4.1, first paragraph: s/backup mechanisms/backup mechanism
>
> Done.
>
> > - 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.
>
> Sure, there may be periods during which no valid samples can be taken and
> the FastRTO remains unchanged. If we would use ambiguous RTT samples,
> there is always the danger of computing (badly) incorrect RTO.
>
> The most importan is to catch up with RTT increase. We think that Slow
> RTO helps there as it makes it much more likely that a new RTT sample is
> optained, if there is no loss. In case the msgs get lost, it should also
> be noted that the FC 6298 algo is notably fast in catching up with
> increased RTT once a RTT sample is finally obtained.
>
> I also think we already have this partly covered in Sec 4.4 and 4.5. Of
> course, without Retransmission Count (or corresponding token) there is
> not much to do without sacrificing the principle of using unambiguous RTT
> samples?
>

Agreed.


>
> > - End of section 4.1. What is "K"? (I wasn't able to find a definition of
> > "K" earlier in the document.)
>
> K is from RFC 6298 like RTTVAR and SRTT that we also use. It
> is now clarified that K = 4 (as in RFC 6298).
>
> > - 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.
>
> Good catch. You are right. A part of the text was written as if
> considering the case of request - piggybacked response exchanges only,
> whereas it should have considered CON - Ack exchanges. Tried to reflect
> this in the modified text.
>
> > - 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.
>
> Good point.
> Removed unnecessary/misleading "reguests". Hope it works better now.
>

IMO, it does, thanks.


>
> > - 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?
>
> We are proposing to use the default. Do you think we should
> recommend it explicitly? We briefly explain the tradeoff; having a
> much smaller factor would maybe not allow enough room for delay increase
> while a larger factor would possibly result in unnecessary conservative
> behaviour. The factor of 1.5 worked well in our experiments.
>
> I'm wondering if there might be scenarios different from yours (those
where you performed your experiments) where 1.5 might not work well enough.


> This is intended to be Experimental, so later experimentation may provide
> more information whether the current advice is still valid or maybe
> the factor should be tuned up or down.
>
>
Agreed. Perhaps some explicit text on this point might help trigger further
experimentation.


> > - Section 4.2, first paragraph, last sentence. Perhaps adding some
> forward
> > reference might help the reader?
>
> Done.
>
> > - 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.
>
> Sure, but when discussing congestion, it is one of the fundamental
> principles that a packet loss should be considered as a congestion signal
> in the first place. When it is unknown whether the loss in due to
> congestion or some non-congestion event, a sender should react as if it
> was congestion. However, in the FAST_SLOW_FAST state, FASOR deliberately
> allows for a one-shot probe with a quicker FastRTO to recover from a
> possible non-congestion related loss before using (much longer) Slow RTO
> to respond to congestion.
>
> > - Section 4.3.1, SLOW_FAST: s/transmisssion/transmission
>
> Done.
>
> > - Section 4.3.1: s/if further retransmission are/if further
> > retransmissions are
>
> Done.
>
> > - 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.
>
> Tried to clarify. Hope it is clearer now.
>

It is!


>
> > I hope this feedback can be useful!
>
> Very helpful, indeed. Thank you!
>
>
Once again, thanks for your updates and for the discussion.

Cheers,

Carles


>
> Cheers,
>
> /Markku
>
> > Cheers,
> >
> > Carles
> >
> >
>