Subject: [tcpm] draft-ietf-tcpm-dctcp-03 and cwnd increase

From: Neal Cardwell <[email-masked]>
Date: Sun, 20 Nov 2016 17:23:59 -0500

In reading https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-03 I
noticed the passage:

   A DCTCP sender MUST deal with loss episodes in the same way as
   conventional TCP.  In case of a timeout or fast retransmit or any
   change in delay (for delay based congestion control), the cwnd and
   other state variables like ssthresh must be changed in the same way
   that a conventional TCP would have changed them.

However, I couldn't find a corresponding 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 standard 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. Apologies if I just missed it.

cheers,
neal