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

[Gorry Fairhurst <[e-mail]>]

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