Subject: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 13 Mar 2017 09:51:47 +0000

I think this document looks in good shape. I have two sets of WG 
comments relating to the language used in the current draft:

(1) I think the language surrounding loss treatment needs to be still 
strengthened.
(2) I would like to see the contradition with RFC3168 reworked to avoid 
this INFO docuemnt attempting to over-ride that PS.

Best wishes,

Gorry

---
In section 1:

" This protocol is not meant for uncontrolled deployment in the global 
Internet. "

- To me this statement seems far too opn, and the draft has alreday 
found a clearer recommendations that I would agree to, as cited in the 
abstract:

"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"

- Is it possible to re-use this statement in place of the one quoted 
above at the end of the conclusion?

---

I'd also really like to see a statement about loss-treatment in the 
introduction. (see my comemt on section 5, but calling-out from the 
start that loss triggers standard TCP congestion control measures is I 
think a very important thing to make the reader aware about. Especially 
when the introduction (quite correctly) points to the merits of ECN 
reacting faster than loss-based methods.

---
In section 3:

"A DCTCP sender MUST deal with loss episodes in the same way as
    conventional TCP."

- I agree. Could we replace "deal with" perhaps with something like 
"react to"

---

3.4.  Handling of SYN, SYN-ACK, RST Packets

   " The switching fabric can drop TCP packets that do not have the ECT
    set in the IP header.  If SYN and SYN-ACK packets for DCTCP
    connections do not have ECT set, they will be dropped with high
    probability.  For DCTCP connections, the sender SHOULD set ECT for
    SYN, SYN-ACK and RST packets."

- I'd take the position that the fabric can and will drop any packets
under overload, as per RFC7567. I'd prefer to explicitly state that
to avoid a misconception that ECT eliminates all drop (rather than
nearly all drops).

---

Section 4:

   "It is RECOMMENDED
    that an implementation provide a configuration knob that will cause
    ECT to be set on such control packes"
- please correct typo /packes"

- I'm not a fan of an informational document over-riding a PS. I do not 
think
this is appropriate.

- I suggest once way to help, could be to say that
   "future versions of this protocol provide a configuration knob that 
will cause
    ECT to be set on such control packets [xx]."

and then  cite "draft-ietf-tsvwg-ecn-experimentation".

- The present text is clearly at odds with the RFC series.

---

In section 5:

The following statement is correct, in as much as SCTP needs to go back 
loss-based CC, but I'd prefer personally to see this expressed as 
"reverts to loss-based congestion control" - to make this a little more 
clear, and I'd much rather it said when it encounters loss, rather than 
perhaps suggesting this is only drop-tail:

"DCTCP will degrade to loss-based congestion control when transiting a 
congested drop-tail link."

- e.g. something like this:

"DCTCP will revert to loss-based congestion control when packet loss is 
experienced (e.g. when
transiting a congested drop-tail link, or a link with an AQM drop 
behaviour).

---

In section 6:

This statement could be better written:

"If the estimation gain is small relative to the packet loss rate, the 
estimate may not be too inaccurate."

- First, I think the loss rate noted, may be the loss rate for the 
return path (i.e., the opposite
direction to the packets bing CE-marked?)
- Second, may not be too inacurrate sounds odd - do you think the 
accuracy is acceptable for normal use?

If this relates to ACK loss, the following statement isn't necessarily 
true. And especially wculd be far from true for an internet with 
asymmetric routing:

"o  If packet loss mostly occurs under heavy congestion, most drops
       will occur during an unbroken string of CE packets, and the
       estimate will be unaffected.
"

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 16 Mar 2017 02:52:52 +0000

Inline prefixed by >>

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Monday, March 13, 2017 2:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: WGLC comments for draft-ietf-tcpm-dctcp-04

I think this document looks in good shape. I have two sets of WG comments relating to the language used in the current draft:

(1) I think the language surrounding loss treatment needs to be still strengthened.
>> This is fixed in the next update per the other comments in the mailing list.

(2) I would like to see the contradition with RFC3168 reworked to avoid this INFO docuemnt attempting to over-ride that PS.
>> Sure

Best wishes,

Gorry

---
In section 1:

" This protocol is not meant for uncontrolled deployment in the global Internet. "

- To me this statement seems far too opn, and the draft has alreday found a clearer recommendations that I would agree to, as cited in the
abstract:

- Is it possible to re-use this statement in place of the one quoted above at the end of the conclusion?

>> Fixed

---

I'd also really like to see a statement about loss-treatment in the introduction. (see my comemt on section 5, but calling-out from the start that loss triggers standard TCP congestion control measures is I think a very important thing to make the reader aware about. Especially when the introduction (quite correctly) points to the merits of ECN reacting faster than loss-based methods.

>> Fair enough. Added a statement: " DCTCP is a modification to the processing of ECN by a conventional TCP and requires that standard TCP congestion control be used for handling packet loss."

---
In section 3:

- I agree. Could we replace "deal with" perhaps with something like "react to"

>> Yes, replaced. Much better choice of words thanks.

---

- I'd take the position that the fabric can and will drop any packets under overload, as per RFC7567. I'd prefer to explicitly state that to avoid a misconception that ECT eliminates all drop (rather than nearly all drops).

>> Change this to : " If SYN and SYN-ACK packets for DCTCP connections do not have ECT set in the IP header, they will likely be dropped by the switching fabric under load. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets."

---

Section 4:

   "It is RECOMMENDED

>> Fixed

- I'm not a fan of an informational document over-riding a PS. I do not think this is appropriate.
- I suggest once way to help, could be to say that
   "future versions of this protocol provide a configuration knob that will cause
    ECT to be set on such control packets [xx]."
and then  cite "draft-ietf-tsvwg-ecn-experimentation".

>> Adding the citation to the "draft-ietf-tsvwg-ecn-experimentation" draft in the next update. Given that the document clearly limits the scope of deployment, I don't think this is at odds with the PS. Referencing the draft will provide enough context.

---

In section 5:

The following statement is correct, in as much as SCTP needs to go back loss-based CC, but I'd prefer personally to see this expressed as "reverts to loss-based congestion control" - to make this a little more clear, and I'd much rather it said when it encounters loss, rather than perhaps suggesting this is only drop-tail:

"DCTCP will degrade to loss-based congestion control when transiting a congested drop-tail link."

"DCTCP will revert to loss-based congestion control when packet loss is experienced (e.g. when transiting a congested drop-tail link, or a link with an AQM drop behaviour).

>> Yes the intention is better captured with your suggested text. Fixed.

---

In section 6:

"If the estimation gain is small relative to the packet loss rate, the estimate may not be too inaccurate."

- First, I think the loss rate noted, may be the loss rate for the return path (i.e., the opposite direction to the packets bing CE-marked?)
- Second, may not be too inacurrate sounds odd - do you think the accuracy is acceptable for normal use?

If this relates to ACK loss, the following statement isn't necessarily true. And especially wculd be far from true for an internet with asymmetric routing:

>> Yes these considerations are for the case where ACKs are lost reducing the accuracy of Alpha. The further sentence says that the impact of such loss has not been measured so its hard for me to say whether it will be "acceptable for normal use". Also, none of this applies to the internet and AFAIK routing is symmetric in the datacenter. I propose that we leave this text as is.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 16 Mar 2017 09:26:05 +0100

Hi,

>>> Change this to : " If SYN and SYN-ACK packets for DCTCP connections do not have ECT set in the IP header, they will likely be dropped by the switching fabric under load. For DCTCP connections, th…

To me, "will likely be dropped by the switching fabric under load" doesn't sound quite right - as if they would most probably be dropped whenever there is any form of load (no matter how much). I would suggest to change this to "...they are more likely to be dropped by the switching fabric under load."

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Mar 2017 08:52:18 +0000

> To me, "will likely be dropped by the switching fabric under load" doesn't sound quite right - as if they would most probably be dropped whenever there is any form of load (no matter how much). I w…
I agree with Michael, but also I don't see it is correct for transport 
protocolsto need a very specific network behaviour. The choice of which 
packets are dropped is a design choice of the AQM: If we were to see 
FQ-Codel or FQ-PIE (for exmaple) deployed, then a common behaviour would 
be to separately queue new flows (even if non-ECT) - Switch design can 
change - I therefore think we should not be assuming a specific switch 
behaviour, but also I do think the ID does not need to go there ....  
because I suspect the clause could perhaps be written differently...

- I'd suggest to change to:
"SYN and SYN-ACK packets for DCTCP connections set the ECT(0) codepoint 
in the IP header, this ensures they receive the same treatment as other 
DCTP packets when forwarded by a switching fabric under load. For DCTCP 
connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets."

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Thu, 16 Mar 2017 09:57:56 +0100

> On 16 Mar 2017, at 09:52, Gorry Fairhurst <[email-masked]> wrote:
> 
> I agree with Michael, but also I don't see it is correct for transport protocolsto need a very specific network behaviour. The choice of which packets are dropped is a design choice of the AQM: If we were to see FQ-Codel or FQ-PIE (for exmaple) deployed, then a common behaviour would be to separately queue new flows (even if non-ECT) - Switch design can change - I therefore think we should not be assuming a specific switch behaviour, but also I do think the ID does not need to go there ....  because I suspect the clause could perhaps be written differently...
> 
> "SYN and SYN-ACK packets for DCTCP connections set the ECT(0) codepoint in the IP header, this ensures they receive the same treatment as other DCTP packets when forwarded by a switching fabric under load. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets."

This is just an ACK to say that I agree.

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Mar 2017 09:01:21 +0000

I wonder if the following could be easily also resolved, see suggestion 
below.

>>> >>  Yes these considerations are for the case where ACKs are lost reducing the accuracy of Alpha. The further sentence says that the impact of such loss has not been measured so its hard for me t…
- Is it worth inserting "ACK" in the following, to disambiguate packet 
loss from ACK loss.

    "o  If ACK packet loss mostly occurs under heavy congestion, most drops
        will occur during an unbroken string of CE packets, and the
        estimate will be unaffected.

Gorry

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 16 Mar 2017 18:30:15 +0000

It is pretty clear that all the considerations are for ACK packet loss:

" However, if one or more ACK packets are dropped, it is possible that a subsequent ACK will cumulatively acknowledge
      a mix of CE and non-CE segments. This will, of course, result in a less accurate congestion estimate. There are some potential considerations:"

The fact that CE is being set also implies this is a response packet. 

"If packet loss mostly occurs under heavy congestion, most drops will occur during an unbroken string of CE packets,
          and the estimate will be unaffected."

I wasn't sure this needed further qualification but I don't see the harm adding ACK to qualify the packet loss, so fixed.

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Thursday, March 16, 2017 2:01 AM
To: Praveen Balasubramanian <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: WGLC comments for draft-ietf-tcpm-dctcp-04

I wonder if the following could be easily also resolved, see suggestion below.

On 16/03/2017, 02:52, Praveen Balasubramanian wrote:
> return path (i.e., the opposite direction to the packets bing 
> CE-marked?)
- Is it worth inserting "ACK" in the following, to disambiguate packet loss from ACK loss.

Gorry

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 16 Mar 2017 18:37:11 +0000

Changed to : " If SYN , SYN-ACK and RST packets for DCTCP connections have ECT set in the IP header, they will receive the same treatment as other DCTCP packets when forwarded by a switching fabric under load. Lack of ECT in these packets may result in a higher drop rate depending on the switching fabric configuration. Hence for DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets."

-----Original Message-----
From: Michael Welzl [mailto:[email-masked]] 
Sent: Thursday, March 16, 2017 1:58 AM
To: <[email-masked]> Fairhurst <[email-masked]>
Cc: Praveen Balasubramanian <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04

Cheers,
Michael

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 16 Mar 2017 18:45:37 +0000

We are way past the deadline for WGLC which was March 3rd :). Since the comments can be never ending and I have limited time, henceforth I will only fix feedback that is critical in nature - i.e. something blatantly wrong or very unclear language. Thanks for all the feedback so far, I think the document is in great shape now. You can expect to see the 05 revision being posted soon. 

-----Original Message-----
From: Michael Welzl [mailto:[email-masked]] 
Sent: Thursday, March 16, 2017 1:58 AM
To: <[email-masked]> Fairhurst <[email-masked]>
Cc: Praveen Balasubramanian <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Mar 2017 19:06:59 +0000

Thanks,

Gorry