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

[Lucien <[e-mail]>]

Hi Ben!

Please see inline!

Also fixed the Alvaro comment as well.

Please let us know if you are okay with the change approve?

Thanks!
Lucien

On Wed, Jun 21, 2017 at 12:36 PM, Ben Campbell <[e-mail]> wrote:

> Thanks for the response. Comments inline:
>
> Ben.
>
> > On Jun 21, 2017, at 2:17 PM, Lucien <[e-mail]> wrote:
> >
> > 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 <[e-mail]> 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
>
> For the record, I think BMWG has adopted interpretations of both
> informational RFC and 2119 keywords that are at best unconventional, and at
> worst tortured. But I also recognize the precedent has been set, and don’t
> mean to hold this draft hostage to it. Thus it was a non-blocking comment
> which you can feel free to ignore :-)
>
>
> >
> > 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
>
> Works for me, thanks.
>
>
> >
> > - 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.
>
> Apologies, I missed the earlier citation to 1242, which was specifically
> in regard to these terms.
>
> >
> >
> >
> > - 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).
> >
>
> As written, it’s not clear to me if “Incast” means “one to
> many/many-to-many” communication in general, or the patterns of
> synchronization that result from that. The first paragraph seems to say the
> former but the second paragraph seems to say the latter.
>
>
Clarified the paragraph and re-wrote it, take a look. incast is either
many-to-one (simpler scenario), or many-to-many.