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

["Eggert, Lars" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Mon, Jul 17, 2017 at 1:23 AM,  <[e-mail]> wrote:
>> 
>> 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
> ...
>> There are also htmlized versions available at:
>> 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