Subject: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-dctcp-07: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 21 Jun 2017 11:52:49 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tcpm-dctcp-07: 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-tcpm-dctcp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

- General: The purpose of this draft is not clear to me. Is the point to
document the Microsoft implementation just for people's information? Do you
have hopes other people will implement this? As written, this seems like a case
of an informational draft defining protocol. That's not necessarily a problem,
but it's helpful to put a paragraph near the beginning to describe why this is
being published and what expectations people have of the outcome. (If the
answer is along the lines of "We'd like people to implement this so we can get
more operational experience", then I will wonder why the status was not
"experimental".)

-1, last paragraph: I assume this means that all participants need to live in
the datacenter, right? That is, no flows where only one end lives in the
datacenter? (I think you clarify that later, but it would be helpful to state
it here.)

- 3.3: first paragraph: Why not MUST?
-- "The congestion estimator on the sender SHOULD process acceptable ACKs
   as follows:" Why not MUST?

Nits:

- 1: Can you offer a citation for MapReduce?

- 2: The additional text assumes the usage of 2119 keywords here do not quite
map to the 2119 definitions. -- "but even compliant implementations without the
measures in sections 4-6 would still only be safe to deploy in controlled
environments.":  That seems too important of a statement to be buried in the
terminology section.

- 4.1: Citation for NewReno?

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 22 Jun 2017 07:15:21 +0000

Hi,

> more operational experience", then I will wonder why the status was not

This doesn't describe "the Microsoft implementation". It describes a TCP variant that originated with Microsoft but has also been shipping as part of Linux and FreeBSD for at least a few years now. The purpose of describing it is so that others can produce interoperable implementations without need to resort to reading (licensed) code.

> datacenter? (I think you clarify that later, but it would be helpful to state

Yes.

>   as follows:" Why not MUST?

I think because it's not needed for interoperability, but I'll Praveen should chime in here.

> - 1: Can you offer a citation for MapReduce?

Sure, we'll add a pointer to https://research.google.com/archive/mapreduce.html

> environments.":  That seems too important of a statement to be buried in the

This is probably the wrong section for this statement, will revise.

> - 4.1: Citation for NewReno?

We can point to RFC6582.

Lars

---

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

> On Jun 22, 2017, at 2:15 AM, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
> 

That really seems to be a case of defining a standard in an informational RFC. Why is it appropriate to publish this as informational?

[The rest of your response look good.]

Thanks!

Ben.

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 22 Jun 2017 14:13:00 +0000

> That really seems to be a case of defining a standard in an informational RFC. Why is it appropriate to publish this as informational?

Because TCPM didn't want to recommend the currently implemented DCTCP as a PS. For a PS, the WG would have liked to make changes. And those changes would be unlikely to see implementation for at least a while.

So the options were: (1) document what current implementations do, but as Informational or (2) have the WG do a PS, but one without an implementation. We picked (1).

If the IESG felt that the current doc should be PS, none of the authors would (I believe) object, but the WG probably would.

Lars

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 22 Jun 2017 14:33:48 +0000

> >> This doesn't describe "the Microsoft implementation". It describes a TCP
> variant that originated with Microsoft but has also been shipping as part of
> Linux and FreeBSD for at least a few years now. The purpose of describing it
> is so that others can produce interoperable implementations without need
> to resort to reading (licensed) code.
> >
> > That really seems to be a case of defining a standard in an informational
> RFC. Why is it appropriate to publish this as informational?
> 
> Because TCPM didn't want to recommend the currently implemented DCTCP
> as a PS. For a PS, the WG would have liked to make changes. And those
> changes would be unlikely to see implementation for at least a while.
> 
> So the options were: (1) document what current implementations do, but as
> Informational or (2) have the WG do a PS, but one without an
> implementation. We picked (1).
> 
> If the IESG felt that the current doc should be PS, none of the authors would
> (I believe) object, but the WG probably would.

Publishing this doc on standards track would IMHO at least require another working group last call.

Michael

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Jun 2017 09:37:50 -0500

> On Jun 22, 2017, at 9:33 AM, Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]> wrote:
> 

Sure, and I think some of the documented issues might prevent publication on standards track anyway. But that still does not necessarily make “informational” appropriate.

But to be clear, I am not asking for the status to be changed. I am asking for a paragraph to describe the reasoning and expectations behind making it informational.

Thanks,

Ben.

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 22 Jun 2017 14:43:16 +0000

> >> variant that originated with Microsoft but has also been shipping as
> >> part of Linux and FreeBSD for at least a few years now. The purpose
> >> of describing it is so that others can produce interoperable
> >> implementations without need to resort to reading (licensed) code.
> >>>
> >> So the options were: (1) document what current implementations do,
> >> but as Informational or (2) have the WG do a PS, but one without an
> >> If the IESG felt that the current doc should be PS, none of the
> >> authors would (I believe) object, but the WG probably would.
> >
> Sure, and I think some of the documented issues might prevent publication
> on standards track anyway. But that still does not necessarily make
> “informational” appropriate.
> 
> But to be clear, I am not asking for the status to be changed. I am asking for a
> paragraph to describe the reasoning and expectations behind making it
> informational.

For what it is worth, from https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/shepherdwriteup/

"The objective of this informational memo is to document an alternative TCP congestion control algorithm that is known to be widely deployed. It is consensus in the TCPM working group that a DCTCP standard would require further work. A precise documentation of running code enables follow-up experimental or standards track RFCs."

Michael

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Jun 2017 09:47:42 -0500

> On Jun 22, 2017, at 9:13 AM, Eggert, Lars <[email-masked]> wrote:
> 

As I mentioned to Michael, I am not asking for a status change, just an explanation in the text. Would it make sense to add a paragraph to the effect of “This documents existing implementations but is not mature enough to be considered a standard. Use at your own risk”?  (With some wordsmithing, of course.)

Thanks,

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Jun 2017 10:00:49 -0500

> On Jun 22, 2017, at 9:57 AM, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
> 
> On 2017-6-22, at 16:47, Ben Campbell <[email-masked]> wrote:
> I don't think documenting the reasons why an RFC is not a Standards Track document is current practice. At least I don't see text related to this in other Informational RFCs.

Well, technically, I am asking to document why it is informational. There have been repeated discussions over time about whether it’s appropriate to put 2119 language in an informational at all. Opinions are mixed. My personal opinion is that it is okay to do so as long as the reasons for doing so are clear. I do not believe they are clear in the existing text.

Ben.

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 22 Jun 2017 14:57:01 +0000

Hi,

Lars

---

From: Mark Allman <[email-masked]>
Date: Thu, 22 Jun 2017 11:07:20 -0400

Hi Lars!

> I don't think documenting the reasons why an RFC is not a
> Standards Track document is current practice. At least I don't see
> text related to this in other Informational RFCs. 

What's the harm?  Michael wrote it in the shepherd writeup.  Why not
just chuck it in the doc to provide context?  How to take a spec
that is an informational is an obvious question.  Why not just say
what we're doing?  Is there a downside I am missing here?  Is there
some disagreement to why we're doing this?

allman, going back into my hole now ...

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Jun 2017 12:51:25 -0500

> On Jun 22, 2017, at 9:43 AM, Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]> wrote:
> 
> "The objective of this informational memo is to document an alternative TCP congestion control algorithm that is known to be widely deployed. It is consensus in the TCPM working group that a DCTCP standard would require further work. A precise documentation of running code enables follow-up experimental or standards track RFCs.”

Those exact words or something to their effect in the document would resolve my comment. I don’t think we can expect readers to look at the shepherd writeup.

Thanks!

Ben.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 23 Jun 2017 17:31:34 +0100

Lars,

>> - 4.1: Citation for NewReno?
In the context of the DCTCP draft:

    It is useful to implement DCTCP as additional actions on top of an
    existing congestion control algorithm like NewReno.

So the text should probably say Reno, rather than NewReno, and the 
citation should be to Reno congestion control [RFC5681], not the NewReno 
addition, which is solely about responding to partial ACKs.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/