Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-09.txt

From: [email-masked]
Date: Sun, 16 Jul 2017 22:23:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF.

        Title           : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters
        Authors         : Stephen Bensley
                          Dave Thaler
                          Praveen Balasubramanian
                          Lars Eggert
                          Glenn Judd
	Filename        : draft-ietf-tcpm-dctcp-09.txt
	Pages           : 16
	Date            : 2017-07-16

Abstract:
   This informational memo describes Datacenter TCP (DCTCP), a TCP
   congestion control scheme for datacenter traffic.  DCTCP extends the
   Explicit Congestion Notification (ECN) processing to estimate the
   fraction of bytes that encounter congestion, rather than simply
   detecting that some congestion has occurred.  DCTCP then scales the
   TCP congestion window based on this estimate.  This method achieves
   high burst tolerance, low latency, and high throughput with shallow-
   buffered switches.  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.  This memo documents DCTCP as currently
   implemented by several major operating systems.  DCTCP as described
   in this draft is applicable to deployments in controlled environments
   like datacenters but it must not be deployed over the public Internet
   without additional measures.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-09
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-dctcp-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-dctcp-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 20 Jul 2017 11:36:54 -0400

>         Filename        : draft-ietf-tcpm-dctcp-09.txt
...
> https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-09

I would like to re-raise an issue I raised in Nov 2016:
 https://www.ietf.org/mail-archive/web/tcpm/current/msg10632.html
There I did not get a response, but I think it's an issue worth
at least a sentence in the draft...

This is a nice draft. One quick thought on a minor point:
I couldn't find a passage in the draft about how cwnd is increased.
I didn't see a mention of the word "increase",
or slow start, or congestion avoidance, or a reference to DCTCP
inheriting RFC5681 behavior for cwnd increase.

The SIGCOMM 2010 paper is clear on this point: "The only difference
between a DCTCP sender and a TCP sender is in how each reacts to
receiving an ACK with the ECN-Echo flag set. Other features of TCP
such as slow start, additive increase in congestion avoidance, or
recovery from packet lost are left unchanged."

And the Linux DCTCP code is clear as well, since it uses
tcp_reno_cong_avoid(), meaning it inherits the standard Reno behavior
of slow start and congestion avoidance.

So I presume the intent of the IETF DCTCP would be the same
as the SIGCOMM 2010 DCTCP paper and Linux DCTCP code,
which is to say cwnd increase would be like Reno/RFC5681.

But IMHO it would be useful for the draft to have explicit language to
this effect as well. Particularly since now there are IETF documents
for both Reno and CUBIC, and the details of the DCTCP cwnd
decrease algorithm may or may not depend on the
Reno-style increase.

Apologies if I just missed this discussion.

cheers,
neal

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 24 Jul 2017 07:48:28 +0000

Hi Neal,

it looks indeed like we dropped the ball on your earlier comment. Will discuss!

Lars

> On 2017-7-20, at 17:36, Neal Cardwell <[email-masked]> wrote:
>