Re: [bmwg] Benoit Claise's No Objection on draft-ietf-bmwg-dcbench-methodology-15: (with COMMENT)

Lucien <lucien.avramov@gmail.com> Wed, 21 June 2017 17:17 UTC

Return-Path: <lucien.avramov@gmail.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71275127876; Wed, 21 Jun 2017 10:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4ociLgxpFIhm; Wed, 21 Jun 2017 10:17:26 -0700 (PDT)
Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1140A128B38; Wed, 21 Jun 2017 10:17:25 -0700 (PDT)
Received: by mail-yb0-x232.google.com with SMTP id 84so48520492ybe.0; Wed, 21 Jun 2017 10:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jhcG3KxRPjUuDIde11J8il63q5i27XX6vGVTu7kT2iw=; b=SIhOc6MC+yWGJI8uoS7V7TtTqH7dQHSj2qYuYD5icpia0OH0J+mAiN6GYFhHcI8yYq K80etZVWTS35220ix9RLSh7FypN0E0mNyASBwG79na8lQQml6IvRWPUn2NgzOMZmKf2P Ug0MkYb11XZwfWl44nVpwORXbBjOsHLJFR5oRpVfNuT95SXoMrczGs7MIBEYExeh43nZ G+WMSsDzOhalqqgo3J+h5Tpm5mkGe/ByRm4gDAnGmECl41GbGauxttrhrjRgOEPoNzCP dgQze1H7DLKHDwHl7bcNfMecSu9ul1mX6MaHMIIWnM6KOA+GHUgwWpQsvsF1xWZQmzhB Hi0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jhcG3KxRPjUuDIde11J8il63q5i27XX6vGVTu7kT2iw=; b=Km7EBCLFCKQGwGmdAs5FxyL94XWHHDEAPX+qgkRcRIWWO0fABHwTmFABjSFVQgdUgd jUBK66R/uAH5nO5N7Y6t+7lB/4oWxPm7cjou+dfJhre8xfFZPD3n6L9sSxXtX7ahNRK9 uZcydnbeGvZyTH/vcMVQsT3UtoUGvyYF2TZ572dZX9z7pxV6FBeQKM2y49iS294z3RiU 7t2YR9iWpUFrb4x5esBKFmUUll3AZAlJIFN/Y6b49xrlLv/jZrSJjQG29xK4kGY+2I0t rMlpIgtp12evqaavdIRRBOVUeZmtztmi3aQ3DNlaCqyq+g3n9/df/T3a663XvDhwhLHc JtMw==
X-Gm-Message-State: AKS2vOx6cFE445zvR/ybgBdRteiwKuMS4tHpIkNBDD7mZ6h20YTOwynL nWimjvvdCyBLKMltcTBUBpPwMb6V/Q==
X-Received: by 10.37.51.67 with SMTP id z64mr27961890ybz.145.1498065444157; Wed, 21 Jun 2017 10:17:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.145.2 with HTTP; Wed, 21 Jun 2017 10:17:23 -0700 (PDT)
In-Reply-To: <149806019382.15579.8882065223122169054.idtracker@ietfa.amsl.com>
References: <149806019382.15579.8882065223122169054.idtracker@ietfa.amsl.com>
From: Lucien <lucien.avramov@gmail.com>
Date: Wed, 21 Jun 2017 10:17:23 -0700
Message-ID: <CAArZqeU-kLzgLWoSsrMAjgZ8rmmAFB=N0MXW_wFNFV2ta2Dnag@mail.gmail.com>
To: Benoit Claise <bclaise@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-bmwg-dcbench-methodology@ietf.org, Sarah Banks <sbanks@encrypted.net>, bmwg-chairs@ietf.org, bmwg@ietf.org, Tim Chown <tim.chown@jisc.ac.uk>
Content-Type: multipart/alternative; boundary="001a1148af24a6575405527b8acb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/SjlKO7-mpVoW6fdnFMcgNUDHeic>
Subject: Re: [bmwg] Benoit Claise's No Objection on draft-ietf-bmwg-dcbench-methodology-15: (with COMMENT)
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jun 2017 17:17:29 -0000

Hi Benoit,

Thank you for the comment! ( I did address also Tim's comment by updating
the draft and answering his email)

Please see inline for your comments:

On Wed, Jun 21, 2017 at 8:49 AM, Benoit Claise <bclaise@cisco.com> wrote:

> Benoit Claise has entered the following ballot position for
> draft-ietf-bmwg-dcbench-methodology-15: No Objection
>
> 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-bmwg-dcbench-methodology/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> At some point in time, I was wondering if this document was about
> (benchmarking) terminology or about (benchmarking) performance metric
> definition? And I was wondering what the connection was with the RFC 6390
> PMOL
> template and with
> https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-11? When I
> look at
> the section 3 "jitter", there are obvious elements from the PMOL template.
> Thinking about it, whether a performance metric is used for benchmark or
> not,
> we need a formal definition. Is it time for: 1. IPPM to finish up
> draft-ietf-ippm-metric-registry 2. start populating the registry 3. BMWG
> to
> start using/specifying those performance metrics
>
> Thoughts?
>

Initially when we started this over 4 years ago i wanted to do 1 document
for both terminology and method of benchmarking. It became a very long and
intense publication, and I believe back then when you were also our AD, the
feedback we kept getting was to make this easier and break it down in two
publications wich we did. Now looking back, I am glad we did because it
provides a much better structure and it's more digestable and succinct.

The document terminology is about defining the terms specific for data
center benchmarking. It's not about the performance per say. But it's
related to the implication of performance testing.

The document methodology (on the same last call), is about how and what to
benchmark (using the terminologies defined in the other document).

I think it would be a great idea to harmonize all performance metrics
accross WGs, but that's really beyond the scope of what our goal is in
those two publications. I am happy to help participate in such incentive /
project if there is critical mass willing to do it.





>
> Below is Tim Chown's OPS DIR review:
> verall, the document is well written, and I believe it to be Ready with
> minor
> nits.
>
> General comment:
>
> It would be interesting to see an Appendix with an example of a recorded
> test
> using the language defined here.
>
> Specific comments:
>
> Section 1:
>
> “- Low amount of buffer (in the Mb range)”
> Change to MB?  (given later you refer to KB/MB/GB as the measurement unit
> for
> buffers)
>
> Section 2.1
>
> Expand DUT on first use.
>
> Section 3.1
>
> Perhaps clarify relationship of Delay and Latency, since you focus on
> Latency
> in the document and not Delay?
>
> Last para, you say “If” here, but for Latency the FILO timestamp was a
> MUST in
> Section 2?  This doesn’t seem consistent?
>
> Expand PDV on first use.
>
> Section 6.1.1
>
> “1518 bytes frames” -> “1518 byte frames”
>
> Section 7.1,
>
> Why is ‘and’ in quotes here?  Not sure you can say the balance is defined
> by
> goodput?  Do you mean that goodput is an indication of the balance?  For
> standard TCP, a very small loss can have a dramatic effect on application
> throughput.
>
> The second para should follow the first, change “[RFC2647].  Goodput…” to
> “[RFC2647], i.e., goodput…”
>
> Section 7.3
>
> I don’t understand how the example given correlates to G = S/Ft ?
>
> There’s a few typos in this section; please re-check.
>
>
>