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
tsv-art@ietf.org 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