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

From: Yoshifumi Nishida via Datatracker <[email-masked]>
Date: Sun, 20 Dec 2020 04:31:46 -0800

Reviewer: Yoshifumi Nishida
Review result: On the Right Track

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

Summary: This document needs clarifications on some points.

I might miss something, but I have concerns on the proposed logic.
Because it seems that it doesn't exactly follow exponential backoff requirement
in rfc8961 and it's possible to become more aggressive than normal backoff
algorithm in some cases.

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.

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.

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.

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'?

Thanks,
--
Yoshi