Subject: Re: [tcpm] Some comments on draft-ietf-tcpm-dctcp

From: Praveen Balasubramanian <[email-masked]>
Date: Sun, 17 Jul 2016 20:27:03 +0000

Sorry for the late response. Inline prefixed with <Praveen>. The next update to the draft will include these changes.

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Monday, May 9, 2016 8:25 PM
To: [email-masked]
Cc: [email-masked] Extensions <[email-masked]>
Subject: [tcpm] Some comments on draft-ietf-tcpm-dctcp

Dear authors,

As individual contributor to TCPM, I have read -01 of the DCTCP draft and I've run into some minor issues:

* Section 1: I think the following wording was discussed already in the past:

   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 protocol is not meant for uncontrolled
   deployment in the global Internet.

  Reading the document again, I'd prefer a wording that would not generally recommend DCTCP to all single domain datacenter environments. The smallest change I could think of would be to add the word "only":
   
   It is recommended that DCTCP be only deployed in a datacenter environment
   where the endpoints and the switching fabric are under a single
   administrative domain.  This protocol is not meant for uncontrolled
   deployment in the global Internet.

<Praveen> fixed

* Section 2+3: This is an informative document so RFC 2119 should be used with care, if at all. My impression is that at least some use of RFC 2119 language could be avoided. Examples:

    Section 3.1: "Therefore, sender and receiver MUST NOT assume that a particular marking algorithm is implemented by the switching fabric."

    => I think an implementation of DCTCP inherently follows this and this does not require RFC 2119 statements.

<Praveen> Fair enough. I will rephrase this to say lowercase should not.

    Section 3.3: "The congestion estimator on the sender MUST process acceptable ACKs as follows:"

    => This is a sender-side algorithm that relies on internal TCP state variables. I am not sure if an implementation really has to implement the algorithm exactly in this way or if slight variations could yield the same result. A "MUST" on the exact algorithm seems a bit restrictive in that case.  

<Praveen> As Lars pointed out this is already violated in the Linux implementation. I am changing this to SHOULD.

    (... possibly more ...)

* Section 4: This section discusses both discusses implementation issues for DCTCP as well as further TCP tuning that may be used in combination with DCTCP (lower MinRTO, cwnd idle, ...) but that is not tightly related to the actual DCTCP protocol mechanisms. Also, partly related to this, Section 4 is a relatively long text without subsections. I think that Section 4 could be better structured, e.g., by adding two or three subsection distinguishing DCTCP implementation from other (related) implementation guidance. The actual content may not require rewording, except possibly some reordering of paragraphs.

<Praveen> Yes the discussion of minrto, delack timeout and cwnd restart is confusing and not strictly needed in a RFC focused on DCTCP. I am removing these 2 paragraphs and after this the section is shorter and I think does not need sub-sections. 

* Section 5: I am not sure if the following comment on UDP is compatible with draft-ietf-tsvwg-rfc5405bis-12:

   If the datacenter traffic consists
   of such traffic (including UDP), one possible mitigation would be to
   mark IP packets as ECT even when there is no transport that is
   reacting to the marking.

  Also, I don't fully understand the contect, e.g., what marking/drop profiles are here referred to. Maybe some additional explanation could help. As far as I know, this can be quite device-specific, e.g., many routers would allow separate queues for non-TCP/non-IP traffic. In any case, the handling of UDP seems to me rather unrelated to DCTCP, right? If this is considered useful information for potential implementers, Section 5 should also be better structured into DCTCP deployment issues and other related deployment experiences in environments running DCTCP.

<Praveen> I am changing this text to suggest that deployments must take into account segregation of non-TCP traffic and use schemes to ensure such traffic does not suffer by being on the same queue as DCTCP traffic.

Thanks

Michael

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Jul 2016 08:59:30 -0700

>    deployment in the global Internet.
FWIW, the word "only should be relocated. In its location above, it
implies that DCTCP should be only deployed, not something else (e.g.,
not operated, talked about, etc.).

If you intend to use "only" to constrain location, it has to precede the
location clause as follows:

     It is recommended that DCTCP be deployed only in a ...

Joe

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 19 Jul 2016 19:26:06 +0000

Thanks for addressing my review. In general, I believe my concerns are sufficiently sorted out.

I am not a native speaker and thus I cannot really comment on Joe's remark regarding the location of the word "only".

<chair hat on>
>From a procedural perspective, I want to note that the new Terminology section contains new some wording:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  Normative
   language is used to describe how necessary the various aspects of the
   Microsoft implementation are for interoperability, but even compliant
   implementations without the measures in sections 4-6 would still only
   be safe to deploy in controlled environments.

I have no particular suggestion how to change that wording but I want to ensure the WG is aware of this use of RFC 2199.
</chair hat on>

Michael

> From: Praveen Balasubramanian [mailto:[email-masked]]
> Sent: Sunday, July 17, 2016 10:27 PM
> To: Scharf, Michael (Nokia - DE); [email-masked]
> Cc: [email-masked] Extensions; [email-masked]
> Subject: RE: [tcpm] Some comments on draft-ietf-tcpm-dctcp
> 
> Sorry for the late response. Inline prefixed with <Praveen>. The next
> update to the draft will include these changes.
> 
>   Reading the document again, I'd prefer a wording that would not
> generally recommend DCTCP to all single domain datacenter environments.
> The smallest change I could think of would be to add the word "only":
> 
> * Section 2+3: This is an informative document so RFC 2119 should be
> used with care, if at all. My impression is that at least some use of
> RFC 2119 language could be avoided. Examples:
> 
>     Section 3.1: "Therefore, sender and receiver MUST NOT assume that a
> particular marking algorithm is implemented by the switching fabric."
> 
>     => I think an implementation of DCTCP inherently follows this and
> this does not require RFC 2119 statements.
> 
>     => This is a sender-side algorithm that relies on internal TCP
> state variables. I am not sure if an implementation really has to
> implement the algorithm exactly in this way or if slight variations
> could yield the same result. A "MUST" on the exact algorithm seems a
> bit restrictive in that case.
> 
> <Praveen> As Lars pointed out this is already violated in the Linux
> implementation. I am changing this to SHOULD.
> 
> 
>     (... possibly more ...)
> 
> * Section 4: This section discusses both discusses implementation
> issues for DCTCP as well as further TCP tuning that may be used in
> combination with DCTCP (lower MinRTO, cwnd idle, ...) but that is not
> tightly related to the actual DCTCP protocol mechanisms. Also, partly
> related to this, Section 4 is a relatively long text without
> subsections. I think that Section 4 could be better structured, e.g.,
> by adding two or three subsection distinguishing DCTCP implementation
> from other (related) implementation guidance. The actual content may
> not require rewording, except possibly some reordering of paragraphs.
> 
> <Praveen> Yes the discussion of minrto, delack timeout and cwnd restart
> is confusing and not strictly needed in a RFC focused on DCTCP. I am
> removing these 2 paragraphs and after this the section is shorter and I
> think does not need sub-sections.
> 
> 
> * Section 5: I am not sure if the following comment on UDP is
> compatible with draft-ietf-tsvwg-rfc5405bis-12:
> 
>   Also, I don't fully understand the contect, e.g., what marking/drop
> profiles are here referred to. Maybe some additional explanation could
> help. As far as I know, this can be quite device-specific, e.g., many
> routers would allow separate queues for non-TCP/non-IP traffic. In any
> case, the handling of UDP seems to me rather unrelated to DCTCP, right?
> If this is considered useful information for potential implementers,
> Section 5 should also be better structured into DCTCP deployment issues
> and other related deployment experiences in environments running DCTCP.
> 
> <Praveen> I am changing this text to suggest that deployments must take
> into account segregation of non-TCP traffic and use schemes to ensure
> such traffic does not suffer by being on the same queue as DCTCP
> traffic.
> 
> Thanks
> 
> Michael
>