Skip to main content

Early Review of draft-ietf-core-fasor-01

Request Review of draft-ietf-core-fasor-01
Requested revision 01 (document currently at 02)
Type Early Review
Team Transport Area Review Team (tsvart)
Deadline 2020-12-21
Requested 2020-11-23
Requested by Marco Tiloca
Authors Ilpo Järvinen , Markku Kojo , Iivo Raitahila , Zhen Cao
I-D last updated 2020-12-20
Completed reviews Tsvart Early review of -01 by Yoshifumi Nishida (diff)
We believe the document is now stable but the authors have requested reviews from people on the Transport Area due to their domain competence.
Assignment Reviewer Yoshifumi Nishida
State Completed
Request Early review on draft-ietf-core-fasor by Transport Area Review Team Assigned
Posted at
Reviewed revision 01 (document currently at 02)
Result On the Right Track
Completed 2020-12-20
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 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'?