Re: [Tsv-art] Tsvart early review of draft-ietf-core-fasor-01

[Yoshifumi Nishida <[e-mail]>]

Hi Markku,

Thanks for the very detailed response and sorry for my slow reply.

On Mon, Mar 20, 2023 at 2:34 PM Markku Kojo <[e-mail]> wrote:

>
> On Sun, 20 Dec 2020, Yoshifumi Nishida via Datatracker wrote:
>
> > In my understanding, in FAST_SLOW_FAST state, the 3rd or later RTOs can
> be
> > shorter than 2nd RTO. Similarly,  in SLOW_FAST state, 2nd or later RTOs
> can be
> > shorter than 1st RTO. For example, when slowrto = 4.0 sec and fastrto is
> 0.25
> > sec, then RTOs in SLOW_FAST state will be updated 4.0, 0.5, 1.0, 2.0
> secs,...
> > on each retransmission. But, I am not very sure if setting shorter RTO
> on the
> > later retransmissions is a good idea unless we have good knowledge on the
> > congestion status in the network. I would like to see some more
> discussions and
> > clarifications on this point in the draft.
>
> Hope that the descriptions above provide enough clarification. In
> particular, the specific low-load traffic pattern of CoAP and the items 2)
> and 3) above. And, the effectiveness of Slow RTO to clear the bottleneck
> queue from any unnecessary retransmissions that this flow potentially
> sent.
>

Thanks for the clarification. I think I got an idea.
I think it would be useful to have some contexts in 2) and 3) in the draft
so that the reader can understand the intention of the logics more clearly.
Also, I think the draft needs to clarify whether it replaces the default
timeout in COAP or it's an addition to the current mechanisms.


>
> Note also what tha draft says in Sec 4.2:
>      "Slow RTO itself is a form of back off because it includes the
>      accumulated time from the RTO back off of the previous
>      exchange."
>
> > BTW, if RTOs will be updated something like, 4.0, 1.0, 2.0, 4.0 secs in
> this
> > case, it looks better to me as it'll be conservative than normal backoff
> > algorithm. The algorithm would look setting longer RTOs in some special
> cases
> > while following backoff algorithm.
>
> We actually experimented with a variant of FASOR that did exactly this by
> starting with a two times larger FastRTO after an Slow RTO. The results
> didn't show any notable improvement in clearing up congestion but resulted
> slightly inefficient loss detection and recovery with non-congestion
> related losses. As this is intended to be published as Experimental, it is
> possible to suggest experimenting more with such variant. However,  I
> don't see much of a reason to recommend it without any evidence of
> potential problems with the current approach being too aggressive. Of
> course, if any experiments encounter any such problems it is maybe
> useful to do it, although I think it might be better to first tune the
> factor of 1.5 slightly larger.
>

OK.  Thanks for the explanation.

> Some minor comments:
> >
> > 4.1 "We call this normal RTO or FastRTO"
> >        -> How about using just one term? It seems that both terms are
> used in
> >        the doc. But, it looks a bit confusing.
>
> Tried to improve this. Now using mainly "FastRTO" but a part of the
> instances where we used normal RTO were intended to refer to both
> "normal" RFC 6298 RTO and FASOR FastRTO, so it was not that
> straightforward. Hope it is better now in this sense.
>
>

> > 4.3  It might be good if there's example diagrams here so that readers
> can
> > understand how algorithm work easily
> >
> >     "First perfom a probe"
> >       -> What is 'probe'?
>
> With "probe" we intended to indicate that the first RTO used in the
> FAST_SLOW_FAST state is exceptionally a shorter FastRTO that kinda probes
> the network faster to recover quickly in case it was a wireless loss
> (i.e., not congestion-related loss) as explained in the last para of Sec
> 4.3.1. But maybe it is better now when modified to just delete the
> "probe"?
>

Yes, the two updates above look good to me. Thank you so much!
--
Yoshi