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

[Praveen Balasubramanian <[e-mail]>]

Inline prefixed by >>

-----Original Message-----
From: Gorry Fairhurst [mailto:[e-mail]] 
Sent: Monday, March 13, 2017 2:52 AM
To: [e-mail]
Cc: [e-mail]
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:

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

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

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



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

---

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).


>> 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
    that an implementation provide a configuration knob that will cause
    ECT to be set on such control packes"
- please correct typo /packes"


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


- 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).


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

---

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

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