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

From: Ben Campbell <[email-masked]>
Date: Wed, 21 Jun 2017 12:06:06 -0700

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.)

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

- 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".

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

---

From: Lucien <[email-masked]>
Date: Wed, 21 Jun 2017 12:17:55 -0700

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

> https://datatracker.ietf.org/doc/draft-ietf-bmwg-dcbench-terminology/

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

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

> "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.

> 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).

---

From: Ben Campbell <[email-masked]>
Date: Wed, 21 Jun 2017 14:36:51 -0500

Thanks for the response. Comments inline:

Ben.

> On Jun 21, 2017, at 2:17 PM, Lucien <[email-masked]> wrote:
> 
> Hi Ben, 
> 
> Thanks for the comment! Please find my answers inline, and please acknowledge back!
> 
> 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 :-)

> 	•  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.

> 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.

> 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.

---

From: Lucien <[email-masked]>
Date: Wed, 21 Jun 2017 21:59:46 -0700

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 <[email-masked]> wrote:

> > 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
> 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 :-)
>
>
> >
> >       •  calling out specifically that this specifically applies to data
> >       • 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.
>
>
> >
> > 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.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Jun 2017 16:56:05 -0500

The latest version resolves all of my comments, except for the comment that it was confusing to find normative procedures in a “terminology” draft. I understand the authors have chosen not to address that. It was a non-blocking comment, so I will not pursue it further.

Thanks!

Ben.

> On Jun 21, 2017, at 11:59 PM, Lucien <[email-masked]> wrote:
> 
> Hi Ben!
> 
> Please see inline!
> 
> Clarified the paragraph and re-wrote it, take a look. incast is either many-to-one (simpler scenario), or many-to-many.  
>