[ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)

Magnus Westerlund via Datatracker <noreply@ietf.org> Thu, 25 February 2021 14:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA8D3A1A5C; Thu, 25 Feb 2021 06:18:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-capacity-metric-method@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, Ian Swett <ianswett@google.com>, tpauly@apple.com, tpauly@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.26.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <161426272345.2083.7668347127672505809@ietfa.amsl.com>
Date: Thu, 25 Feb 2021 06:18:43 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/OOxUxYxtd92VZqPyKIOhz6Ymsl8>
Subject: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2021 14:18:44 -0000

Magnus Westerlund has entered the following ballot position for
draft-ietf-ippm-capacity-metric-method-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A) Section 8. Method of Measurement

I think the metrics are fine, what makes me quite worried here is the
measurement method. My concerns with it are the following.

1. The application of this measurement method is not clearly scoped. Therefore
I will assume that across the Internet measurements are possible. However in
that context I think the definition and protection against severe congestion
has significant short comings. The main reason is that the during a
configurable time period (default 1 s) the sender will attempt to send at a
specified rate by a table independently on what happens during that second.

2. The algorithm for adjusting rate is table driven but give no guidance on how
to construct the table and limitations on value changes in the table. In
addition the algorithm discusses larger steps in the table without any
reflection of what theses steps sides may represent in offered load.

3. Third the algorithms reaction to any sequence number gaps is dependent on
delay and how it is related to unspecified delay thresholds. Also no text
discussion how these thresholds should be configured for safe operation.

B) Section 8. Method of Measurement

There are no specification of the measurement protocol here that provides
sequence numbers, and the feedback channel as well as the control channel. Is
this intended to use TWAMP?

>From my perspective this document defines the metrics on standards track level.
However, the method for actually running the measurements are not specified on
a standards track level. No one can build implementation. And if the section is
intended to provide requirements on a protocol that performs these measurements
I think several aspects are missing. There appear several ways forward here to
resolve this; one is to split out the method of measurement and define it
separately to standard tracks level using a particular protocol, another is to
write it purely as requirements on a measurement protocols.