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

Yoshifumi Nishida via Datatracker <noreply@ietf.org> Sun, 20 December 2020 12:31 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3FA3A0FB0; Sun, 20 Dec 2020 04:31:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yoshifumi Nishida via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: core@ietf.org, draft-ietf-core-fasor.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160846750677.2364.7100486944014136268@ietfa.amsl.com>
Reply-To: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Sun, 20 Dec 2020 04:31:46 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/Rw3QVh3PAyhDOYad2MDVcLtm0_4>
Subject: [Tsv-art] Tsvart early review of draft-ietf-core-fasor-01
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Dec 2020 12:31:47 -0000

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