Re: [bmwg] Ben Campbell's No Objection on draft-ietf-bmwg-dcbench-terminology-17: (with COMMENT)

Lucien <lucien.avramov@gmail.com> Wed, 21 June 2017 19:18 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 235EE12946E; Wed, 21 Jun 2017 12:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 NPCziw3HFMYI; Wed, 21 Jun 2017 12:17:56 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 5881212943A; Wed, 21 Jun 2017 12:17:56 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id e142so68256028ywa.1; Wed, 21 Jun 2017 12:17:56 -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=BAymDwym53Y0kIFsg7H0G1M6k8Abqs6YRt7Qy8ccq+A=; b=gyEroCGd2juq5+wq0yjH7/nxE9gwrqV0mn2bFU3SVyccO1Vitz2YNkHRI/FVwOzL2y ijjaGIRXmLcgaTYldvKvOFskI2ywIJCpFTmamUIcZ5fYIFPkJPWWNSTKQ/bzIwbwDNOH sc6N0YpTbK0yxTUDCnveh0efL7SMWifcXt+OKcEYcaLzXiuk1xfo0bE/u4jlG2wrhA6P rI//quUMJ3ktrwVGASkjIhHnmI1xmtWLnHAisNRseZGf0F6hqaBxaC4BWo1GTSmv+88M tgKTuoltdXKbiA6V3WoX9dF5WWODEp5XgAwl4z3SrPXm6zOO8sFjg80iNNduKOCyofBj erBg==
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=BAymDwym53Y0kIFsg7H0G1M6k8Abqs6YRt7Qy8ccq+A=; b=M6aoEtXr7HhLAIdD1oxIemDBiELtXtKaxswd+L4LpupmnPZhDWjIhRDTRdUVuqmoXS jzVJtAbRtVG18iZ56GsSm1RUQHGdgYwmuNVEiUfQXzDGZDC+J3/rZkwRExwIGJdvbIfL +fr9ZtAh5hzFyDY0utdGS4/Zar7xZzFln43H1thgczFZ13dniNf8MVIbCO6KcYXjDqcg kE0atOm7yued33imp3YDut8u0Azf4REWIz8QrEzMqqQVq5IEb3PfHvxiFT+k+aEaXzHk Boyz7EsdHq6cLZLcMypHhK3WhKJuW7HFypvoiddySs+JhRMDwQv6OOmbgDVYVIbNqMt1 qw4g==
X-Gm-Message-State: AKS2vOyiBxoFtO4M2JfCcVGcYUaOMJYSaaiwOyQTQCCOauNm1Lh2E85z cAiCyj2sEcgWpL9UWT8nwDLywxVXzQ==
X-Received: by 10.129.89.9 with SMTP id n9mr3554900ywb.302.1498072675595; Wed, 21 Jun 2017 12:17:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.145.2 with HTTP; Wed, 21 Jun 2017 12:17:55 -0700 (PDT)
In-Reply-To: <149807196602.15838.8048520689148705215.idtracker@ietfa.amsl.com>
References: <149807196602.15838.8048520689148705215.idtracker@ietfa.amsl.com>
From: Lucien <lucien.avramov@gmail.com>
Date: Wed, 21 Jun 2017 12:17:55 -0700
Message-ID: <CAArZqeX2_1XJhuqhMdHYRELrERgMzu+AV9zQAFLQUdpMbh7PcA@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-bmwg-dcbench-terminology@ietf.org, Sarah Banks <sbanks@encrypted.net>, bmwg-chairs@ietf.org, bmwg@ietf.org
Content-Type: multipart/alternative; boundary="001a11471a1ead3c1005527d3972"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/NYPVGpgWGva8q4vXLdDdWU4OuzU>
Subject: Re: [bmwg] Ben Campbell's No Objection on draft-ietf-bmwg-dcbench-terminology-17: (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 19:18:29 -0000

Hi Ben,

Thanks for the comment! Please find my answers inline, and please
acknowledge back!

Appreciate you taking the time to look at our work.

Lucien

On Wed, Jun 21, 2017 at 12:06 PM, Ben Campbell <ben@nostrum.com> wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-bmwg-dcbench-terminology-17: 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-terminology/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I find the naming of the draft fairly confusing. It goes way beyond
> "terminology"; it makes a number of normative (using 2119 language)
> statements
> about benchmarking procedures. I wonder why the sections about procedure
> did
> not go into the methodology draft instead. In general, I don't think
> putting
> normative language in an informational terminology draft is a good idea.
> (This
> would have been a DISCUSS, except that I am aware the bmwg has decided to
> make
> all its drafts informational and to still use 2119 language. For the
> record, I
> think that policy falls down with this draft.)
>

That's how we have decided it makes sense at BMWG to proceed with these two
drafts. We have been hashing this out for 4+ years now and the current
state is the consensus.  As author, I have no intention nor desire to
change this

>
> I agree with the comment from others that this does not seem to be
> specific to
> datacenters.
>

Great, so did we, this is why we already worked on addressing this by:

   -  calling out specifically that this specifically applies to data
   center switches (defining what those are today)
   - stating clearly that it can be applied to switches out of the data
   center, but that's not the specific scope of this


> - 2.2: Definitions of "store-and-forward" and "cut-through" when used in
> this
> context would be helpful. The first may be obvious, but the best I can do
> with
> "cut-through" is assume it means the opposite of "store-and-forward".
>

Those are cleary defined in RFC 1242, which we reference. We don't want to
duplicate definitions here.



>
> - 6.2: After reading the definition of "Incast" several times, I'm still
> not
> sure what it means or what is being measured.
>

It's many to one type of network traffic patterns. Its very commonly found
in cloud data centers implementing distributed storage/compute frameworks
(big data for example).