Re: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-capacity-metric-method-06: (with COMMENT)

"MORTON, ALFRED C (AL)" <acm@research.att.com> Sat, 27 February 2021 21:27 UTC

Return-Path: <acm@research.att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F303A14A5; Sat, 27 Feb 2021 13:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNhyRmQ31955; Sat, 27 Feb 2021 13:27:40 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08333A14A3; Sat, 27 Feb 2021 13:27:39 -0800 (PST)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 11RLOpHv004448; Sat, 27 Feb 2021 16:27:34 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049458.ppops.net-00191d01. with ESMTP id 36yjdmxunk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Feb 2021 16:27:34 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 11RLRX1b111144; Sat, 27 Feb 2021 15:27:34 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 11RLRVQX111105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Feb 2021 15:27:31 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id 028BE4009E78; Sat, 27 Feb 2021 21:27:31 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30494.vci.att.com (Service) with ESMTP id CB7604009E77; Sat, 27 Feb 2021 21:27:30 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 11RLRUZv094901; Sat, 27 Feb 2021 15:27:30 -0600
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 11RLRPp4094531; Sat, 27 Feb 2021 15:27:25 -0600
Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-blue.research.att.com (Postfix) with ESMTP id E856F10A18D8; Sat, 27 Feb 2021 16:27:24 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0487.000; Sat, 27 Feb 2021 16:27:42 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Murray Kucherawy <superuser@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-capacity-metric-method@ietf.org" <draft-ietf-ippm-capacity-metric-method@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, Ian Swett <ianswett@google.com>, "tpauly@apple.com" <tpauly@apple.com>
Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-ippm-capacity-metric-method-06: (with COMMENT)
Thread-Index: AQHXC4nxBVc8bVjRIEG0L+qbBEEkzapsdkBQ
Date: Sat, 27 Feb 2021 21:27:42 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF01476A1087@njmtexg5.research.att.com>
References: <161426647584.14166.5269938969946072865@ietfa.amsl.com>
In-Reply-To: <161426647584.14166.5269938969946072865@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.148.42.167]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-27_16:2021-02-26, 2021-02-27 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 clxscore=1011 priorityscore=1501 adultscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102270182
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/g0Q2SY_src_YB0jKBkICnwtBITE>
Subject: Re: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-capacity-metric-method-06: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Sat, 27 Feb 2021 21:27:42 -0000

> -----Original Message-----
> From: Murray Kucherawy via Datatracker [mailto:noreply@ietf.org]
> Sent: Thursday, February 25, 2021 10:21 AM
> 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
> Subject: Murray Kucherawy's No Objection on draft-ietf-ippm-capacity-
> metric-method-06: (with COMMENT)
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-ippm-capacity-metric-method-06: No Objection
> 
...
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Since a SHOULD leaves an implementer with a choice, it's preferable to see
> prose explaining why one might deviate from the SHOULD advice.  Thus, the
> SHOULDs in Sections 5.3 and 6.3 leave me wondering under what circumstances an
> implementer might legitimately choose to do something else.  If there are
> none, should it be a MUST?
> 
> 
Hi Murray,

Thanks for your review, and re-casting your ballot as a COMMENT. I listened to 
the telechat and heard it happen. It was my first chance to take advantage of 
the opportunity to listen-in, and I'm glad I did.

S 5.3

OLD + Ben's comments fixed:
Anticipating a Sample of Singletons, the number of sub-intervals with duration dt 
SHOULD be set to a natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt 
for 1 <= n <= m.

I cannot for the life of me conjure-up why a practical value of m would not be
a natural number. Thus, I'll make this a MUST unless someone produces a 
reasonable deviation (which we would add to the text).

NEW
Anticipating a Sample of Singletons, the number of sub-intervals with duration dt 
MUST be set to a natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt 
for 1 <= n <= m.

S 6.3

It's basically the same requirement in this section, so the same rationale and fix 
applies:

OLD + Ben's comments fixed:
The number of sub-intervals with duration dt SHOULD be set to a natural number m, 
so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= m.

NEW
The number of sub-intervals with duration dt MUST be set to a natural number m, 
so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= m.

These are the only SHOULDs in 5.3 and 6.3.

Going a bit further, I found a SHOULD in 7.3 that we could explain better:
 
OLD
st SHOULD be much smaller than the sub-interval dt. 
The st parameter does not have relevance when the Source is transmitting at 
a fixed rate throughout S.

NEW
st SHOULD be much smaller than the sub-interval dt and on the same order as FT, 
otherwise the rate measurement will include many rate adjustments and include
more time smoothing, thus missing the maximum rate. The st parameter does not 
have relevance when the Source is transmitting at a fixed rate throughout S.


And 7.4 has an unexplained SHOULD:
OLD
Both the Sender and Receiver or (source and destination) bit rates SHOULD 
be assessed as part of an IP-layer Capacity measurement. 
NEW
Both the Sender and Receiver or (source and destination) bit rates SHOULD 
be assessed as part of an IP-layer Capacity measurement. Otherwise, an 
unexpected sending rate limitation could produce an erroneous Maximum 
IP-Layer Capacity measurement.

We have some other SHOULDs, mostly associated with reporting results. These,
and others in S 10 are aspects we really cannot mandate.

All these changes are in the working version of -07 to-be.

Thanks again!
Al