Subject: [tcpm] Wording on enabling DCTCP in draft-ietf-tcpm-dctcp

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 11 Oct 2015 18:18:20 +0000

Hi,

During IETF 93 we had a quick discussion on how to negotiate DCTCP (see http://www.ietf.org/proceedings/93/minutes/minutes-93-tcpm). Given that the WG aims for a very fast publication of this I-D, I'd like to trigger a follow-up discussion on what the document should state regarding enabling DCTCP. 

As an individual contributor to TCPM, I believe that it would be good if the document addresses the enablement (and perhaps also the implicit negotiation) in a dedicated section; right now this issue is spread across different parts of the document.

Specifically, my personal view would be:

* Abstract

  => I think the abstract should better explain the focus on controlled domains. Also, it could mention coexistence with standard TCP as an issue. For the IESG processing, it could also help to stress the status as informational (e.g., by "This informational memo...").

* Section 1 Introduction

   It is recommended that DCTCP be deployed in a datacenter environment
   where the endpoints and the switching fabric are under a single
   administrative domain.  This memo also discusses deployment issues
   related to the coexistence of DCTCP and conventional TCP, the lack of
   a negotiating mechanism between sender and receiver, and presents
   some possible mitigations.  

 => I wonder whether to add a more explicit warning sign such as "The protocol is not meant for uncontrolled deployment in the global Internet", or a wording like the statement in Section 4.

* Section 4 Implementation Issues

   The implementation must also decide when to use DCTCP.  Datacenter
   servers may need to communicate with endpoints outside the
   datacenter, where DCTCP is unsuitable or unsupported.  Thus, a global
   configuration setting to enable DCTCP will generally not suffice.
   DCTCP may be configured based on the IP address of the remote
   endpoint.  Microsoft Windows Server 2012 (and later) also supports
   automatic selection of DCTCP if the estimated RTT is less than 10
   msec and ECN is successfully negotiated, under the assumption that if
   the RTT is low, then the two endpoints are likely on the same
   datacenter network.

  => To me, whether to enable DCTCP or not is not an "implementation issue" only. I think this warrants a dedicated section. I'd also suggest to split the problem statement and *possible* solutions from the actual heuristic in Windows Server 2012 into two paragraphs. This could probably be achieved by a purely editorial change only.

* Section 6 Known Issues

   DCTCP provides no mechanism for negotiating its use.  Thus, there is
   additional management and configuration overhead required to ensure
   that DCTCP is not used with non-DCTCP endpoints.  The affect of using
   DCTCP with a standard ECN endpoint has been analyzed in
   [ODCTCP][BSDCAN].  Furthermore, it is possible that other
   implementations may also modify [RFC3168] behavior without
   negotiation, causing further interoperability issues.

  => The requirement to detect DCTCP endpoints seems related to the enabling discussion above. At least, I think it would be valuable to have an internal cross-reference between the sections discussing the two aspects.

Thanks

Michael

---

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 19 Oct 2015 18:15:59 +0000

Thanks for the feedback Michael.
Comments inline prefixed with >>. We will publish a draft version with the updates.

Thanks!

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Scharf, Michael (Michael)
Sent: Sunday, October 11, 2015 11:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: [tcpm] Wording on enabling DCTCP in draft-ietf-tcpm-dctcp

Hi,

During IETF 93 we had a quick discussion on how to negotiate DCTCP (see https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fproceedings%2f93%2fminutes%2fminutes-93-tcpm&data=01%7c01%7cpravb%40microsoft.com%7c9a254a41ea8343c339bc08d2d2685e39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9OkF4LWSSiAuVwPWQz3XTLKyrwgO39Fl1Xyk4iuWZmI%3d). Given that the WG aims for a very fast publication of this I-D, I'd like to trigger a follow-up discussion on what the document should state regarding enabling DCTCP. 

* Abstract

>> Moving some text from introduction to abstract to reflect this. Adding "informational" edit.

* Section 1 Introduction

>> Adding this text explicitly in the introduction section where the recommendation for datacenter deployment is also given.

>> I think when and how to enable DCTCP belongs to implementation issues section. Agreed about splitting the problem and potential solutions into separate paragraphs, making these editorial changes.

* Section 6 Known Issues

>> Moving some of this text to the implementation issues section. 

Thanks

Michael

_______________________________________________
tcpm mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftcpm&data=01%7c01%7cpravb%40microsoft.com%7c9a254a41ea8343c339bc08d2d2685e39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=N0T2SP1SrK%2bgwFcWZI37MPsL6vtMgEC2N3kcnuPzApY%3d