Re: [ippm] Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-capacity-metric-method-10: (with COMMENT)

"MORTON JR., AL" <acmorton@att.com> Sun, 30 May 2021 02:00 UTC

Return-Path: <acmorton@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 4D4183A28C9; Sat, 29 May 2021 19:00:43 -0700 (PDT)
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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=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 t_MW5W6jPSmr; Sat, 29 May 2021 19:00:36 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 865C13A28C5; Sat, 29 May 2021 19:00:36 -0700 (PDT)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14U1rpMV001621; Sat, 29 May 2021 22:00:27 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 38ufp1bag1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 29 May 2021 22:00:27 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14U20Qul006799; Sat, 29 May 2021 22:00:26 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14U20OW0006694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 May 2021 22:00:24 -0400
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 2F1224009E73; Sun, 30 May 2021 02:00:24 +0000 (GMT)
Received: from GAALPA1MSGEX1DC.ITServices.sbc.com (unknown [135.50.89.116]) by zlp30485.vci.att.com (Service) with ESMTP id E21284009E70; Sun, 30 May 2021 02:00:23 +0000 (GMT)
Received: from GAALPA1MSGEX1DB.ITServices.sbc.com (135.50.89.115) by GAALPA1MSGEX1DC.ITServices.sbc.com (135.50.89.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Sat, 29 May 2021 22:00:01 -0400
Received: from GAALPA1MSGEX1DB.ITServices.sbc.com ([135.50.89.115]) by GAALPA1MSGEX1DB.ITServices.sbc.com ([135.50.89.115]) with mapi id 15.01.2242.010; Sat, 29 May 2021 21:59:55 -0400
From: "MORTON JR., AL" <acmorton@att.com>
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.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: Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-capacity-metric-method-10: (with COMMENT)
Thread-Index: AQHXU8E5DrkdX1i0cUCjU6i/7U6Trar7EAXQ
Date: Sun, 30 May 2021 01:59:55 +0000
Message-ID: <5a07cf8b71d44b8cb54dcccd84592bbb@att.com>
References: <162220671966.6728.1925413023818681484@ietfa.amsl.com>
In-Reply-To: <162220671966.6728.1925413023818681484@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.204.195]
x-tm-snts-smtp: 4636D368EC1306C567DEE4DDE13FF6700DE760D18B8F4866D3977F6002CAE5382
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-GUID: vnsuyruyKSpP-YxYfr1haovWBWKMWi2q
X-Proofpoint-ORIG-GUID: vnsuyruyKSpP-YxYfr1haovWBWKMWi2q
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-29_11:2021-05-27, 2021-05-29 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 bulkscore=0 mlxscore=0 spamscore=0 malwarescore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105300011
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/SbStmc3hJDz6Q9sajX_0_1vdrQA>
Subject: Re: [ippm] Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-capacity-metric-method-10: (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: Sun, 30 May 2021 02:00:44 -0000

Hi Zahed,

Thanks for your review, please see replies below, [acm].

Al

> -----Original Message-----
> From: Zaheduzzaman Sarker via Datatracker <noreply@ietf.org>
> Sent: Friday, May 28, 2021 8:59 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;
> tpauly@apple.com
> Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-capacity-
> metric-method-10: (with COMMENT)
> 
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-ippm-capacity-metric-method-10: No Objection
> 
...
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the work on the document. I consider this document to be an
> important one when it comes to IP layer capacity for access networks.
> 
> After my review and observing the IPPM working group discussions, I consider
> the valid discuss points raised by Magnus Westerlund is now addressed in the
> -10 version of this document.
> 
> please find my comments and observations below -
> 
> * Major Issue: I didn't find any restriction imposed by the memo on the number
> of allowed concurrent tests between same Source and Destination. My
> understanding is this memo should either strictly prohibit the concurrent tests
> between same Source and Destination or provide a maximum limit of concurrent
> tests where the algorithm has been tested to provide valid results. I am not
> going to hold a discuss on this but I would like to be corrected if I am wrong
> in the understanding.
[acm] 
I'm trying to understand your comment in order to address it properly.
Let's consider the existing requirements:

We have text to restrict concurrent non-measurement traffic, in the Scope:

	It is RECOMMENDED to discontinue non-measurement traffic that shares a 
	subscriber's dedicated resources while testing: measurements may not be 
	accurate and throughput of competing elastic traffic may be greatly reduced.

We allow a single test to use concurrent flows, and the default is one flow
(text below is near the end of section 8.3):

	In general, results depend on the sending stream characteristics; 
	the measurement community has known this for a long time, and needs to keep 
	it front of mind. Although the default is a single flow (F=1) for testing, 
	use of multiple flows may be advantageous for the following reasons:
	...

We don't use the term "concurrent" in the draft, and it is obviously
counter-productive to run more than one test independently attempting to 
measure the *maximum* capacity between the same Source and Destination.
The number of concurrent tests between same Source and Destination
that we have tested is one.

The maximum limit on concurrent tests *at an on-net server* is a function
of the server host characteristics: CPU power, network interface speed, and
the external Internet access capacity the host can expect to use.
None of these characteristics are the subject of standardization 
in the form of numerical limits. However, in Section 10 we already specified:

- Hosts MUST limit the number of simultaneous tests to avoid resource 
  exhaustion and inaccurate results.

Perhaps you have a better view of the current text now, and limits on testing 
that makes sense in the context of Maximum capacity measurement.
Was it your intent that we mandate what seems to be obvious (one test only)?
Or something else?

> 
> * Minor Issues , nits:
> 
>    ** I found it a bit odd to not find Magnus Westerlund's name in the
>    acknowledgement section as his review and comments has improved the
>    algorithms and the document a lot. I would encourage the author's to include
>    names of the individuals who has provided any sort of review (including the
>    directorate reviews) that improved this document.
[acm] 
OK
> 
>    ** Section 2:
> 
>       *** I am not getting the context of "local goal", what does it
>       really mean?
[acm] 
Lars questioned this word choice too. We changed it to "secondary goal".

> 
>       *** I kind of feel that the paragraph 2 and 3 should swap their order to
>       focus the goal of "defining efficient test procedure" and then
>       "harmonizing the metric and method across the industry" becomes "another
>       goal". This is based on the current text which makes me feel there are
>       number of goals and the ranks (if there is any) of the goals are not
>       clear. If there is not rank among the goals then simply putting them in a
>       bullet list would help the readability.
[acm] 
The section reads differently with the wording changes related to replacement
of "local goal".
> 
>    ** Section 8.1:
> 
>       *** paragraph 1: s/ agressiveness / aggressiveness .
[acm] 
OK

> 
>       *** paragraph 2: It will be helpful if it is mentioned who pre- builts the
>       table and  who (and where) it will be used.
[acm] 
... (by the test initiator)...

> 
>    ** Section 10 : I find 4, 5, 6 of the new security considerations
> introduced
>    in this section not entirely security related rather general
> considerations
>    on how to run the tests. I think those mentioned considerations are
> more
>    suitable to put it in section 8 (in section 8.3). I understand the
> feeling
>    the everyone should read the security considerations but there is no
>    guarantee that it is the case specially while implementing the tests.
> Hence,
>    putting then in section 8 likely will bring these to attention early.
[acm] 
We already make reference to these requirements much earlier than Section 8.3, 
in the text of Section 2, Scope:

- MUST only be used in circumstances consistent with Section 10, 
  Security Considerations

We can't make the reference much earlier than that!

Changes above have been implemented in the working text for version 11.

> 
>