[Tsv-art] Tsvart last call review of draft-ietf-bmwg-b2b-frame-03

David Black via Datatracker <noreply@ietf.org> Tue, 24 November 2020 15:26 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 5DD2A3A0D8C; Tue, 24 Nov 2020 07:26:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: David Black via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: bmwg@ietf.org, draft-ietf-bmwg-b2b-frame.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160623159725.20249.9390987464844223889@ietfa.amsl.com>
Reply-To: David Black <david.black@dell.com>
Date: Tue, 24 Nov 2020 07:26:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/41ahYzkTpOkiOgdg2MtuEktRl0A>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-bmwg-b2b-frame-03
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: Tue, 24 Nov 2020 15:26:38 -0000

Reviewer: David Black
Review result: Ready with Issues

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.

This draft updates the back-to-back frame testing procedure in RFC 2544 to take
account of experience.

The draft is in good shape, with one notable exception in Section 5.2:

   The duration of the trial MUST be at least 2 seconds, to allow DUT
   buffers to deplete.

That duration of 2 seconds has been carried forward from RFC 2544 without
change.  A 2 second duration may have been sufficient to deplete buffers in
1999, but that is no longer reliably the case.  For example, on-site
measurement of the network for the 2020 Linux Conference in Australia indicated
a  at least 1.6 seconds of buffering, as indicated by Figure 1 at
https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/,
which is slide 6 in from the complete slide deck at:
https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/
.  Experience with bufferbloat suggests that one network device was primarily
responsible.  Also, see slide 14 in that slide deck.

That 1.6 seconds measured on an actual network is entirely too close to 2
seconds for confidence that buffers will be depleted in any tested device. 
Hence, the 2 second minimum duration ought to be increased by at least a factor
of 10.  I'd suggest changing it to 30 seconds or 60 seconds as convenient round
numbers, and providing the rationale that increased buffering in WiFi devices,
e.g., home "routers," as indicated by experience with bufferbloat measurements,
is the reason for the increased duration.