Re: [tcpm] [tsvwg] Review of draft-bagnulo-tsvwg-generalized-ecn-01

["Black, David" <[e-mail]>]

Hi Mirja
[+tcpm WG]

The datatracker records draft-bagnulo-tsvwg-generalized-ecn as replaced
by draft-bagnulo-tcpm-generalized-ecn - the latter draft is expected to move
this work forward in the tcpm WG.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Mirja Kühlewind
> Sent: Friday, December 09, 2016 11:56 AM
> To: [e-mail]; marcelo bagnulo braun; Bob Briscoe
> Subject: [tsvwg] Review of draft-bagnulo-tsvwg-generalized-ecn-01
> 
> Hi all,
> 
> find below review comments for draft-bagnulo-tsvwg-generalized-ecn-01 as an
> individual contributor (classified in different categories):
> 
> Comments on Argumentation:
> Please note that I do support the document and marking of control packets
> given the otherwise negative impact on performance especially if we would aim
> for an all-ECN Internet in future. These additional arguments are provided to
> be added for discussion in the doc for completeness.
> 
> Section 2 (the reliability argument)
> -----
> Even though this is not spelled out like this in RFC3168, I would like to
> extend the argument here a little:
> 
> 1) I'm okay to say that if loss is not detected reliably for this kind of
> packet, you may as well not require to detect CE marks. However, receiving a
> CE mark, detecting it, and just no reacting to it, is a different thing. I
> clearly see the trade-off here for TCP but I don't want this to be a
> statement where other protocols say it's okay to not react to CE because TCP
> is doing this as well for ACKs. Note sure yet how to solve this problem and
> I'm not comfortable with recommending to mark control packets whiteout at the
> same time defining standard mechanisms for TCP how to react to it.
> 
> 2) If a packet is dropped, it's gone and cannot further congest the link.
> This is the mechanism of the network to protect itself. However, if you mark
> a packet as ECN capable, it keeps sitting in the queue and another non-ECT
> packet might be dropped instead. This is a well-known general problem of ECN,
> however, if the ECT-marked is then also unresponsive to CE marking, this
> might make the situation worse.
> 
> Section 3 (TCP SYNs): Argument 3 (DoS attacks)
> ---
> Having ECT marked attack traffic makes it worse because this might leads to a
> even higher loss rate for non-ECT traffic while ECT packets keep sitting in
> the queue.
> 
> Section 4 (Pure ACKs): second argument
> ---
> The difference it that an CE marking on a ACK can be detected by the receiver
> (even though it not fully clear how to react to it or just ignore
> it...hopefully not) but you can't detect ACK loss because you don't know how
> many ACKs have been send initially. I don't think this is an issue but you say:
> "If the pure ACK carrying the
>     ECT and the CE bits set is later dropped by the network, it will be
>     essentially falling back to the use of drop as congestion signal."
> which seems wrong.
> 
> However, this is on the other had a pro argument because while loss cannot be
> detected at all, there is at least a chance to detect CE marked ACKs.
> 
> 
> Comments on the more editorial side:
> 1) One more argument to make in the intro, especially as you mention l4s, is
> that in this case, having the packets not marked as ECT could even lead to
> differential network treatment, which might influence performance even more.
> 2) I would recommend to move the discussion on data centers in section 3 to a
> separate section at the end of the doc because that's the only time you talk
> about data centers.
> 3) In section 3 regarding [ecn-pam], you are assuming that the packets were
> dropped the the endpoint/receiver, however, there could also be middleboxes
> doing this. I don't think we looked at RST but that would be interesting.
> 3) section 3 "The responder may drop the SYN (either silently or by sending a
> RST) or may reply with a non ECT marked SYN/ACK.  If it is the latter,
>     then this is a non-issue" -> I wouldn't call it a non-issue because at
> least the congestion signal got lost.
> 4) I think you need security considerations.
> 
> Nit:
> section 3, 1. sentence: s/We next describe he arguments exhibited/We next
> describe the arguments exhibited/
> 
> And the important bit at the end:
> 
> One high-level comment:
> This document is a good read, however, it is not clear what an implementor
> should actually do if he/she want to enable ECN on control packets. Instead
> of only have an informational discussion, I would rather see an experiment
> where you proposed concrete things/machanims that should/must be done
> when
> ECN is used on control packets.
> 
> Further, at the end of section 3, you not only discuss potential
> fallbacks/safety guards on how to use ECN on control packets but you actually
> propose changes to the ECN protocol as specified in RFC3168. This part really
> doesn't seem to be appropriate for an informational doc and also would need
> further discussion as an experiment. As you have to rely for these mechanism
> on changes on both the sender and receiver side, I would simply just use
> AccECN instead. This would mean there should maybe be a recommendation that
> if the initiator wants to set ECT on control packets incl. the SYN it
> should/must also try to negotiate AccECN in the handshake (which anyway as an
> implict fallback to calssic ECN if AccECN is not supported by the receiver).
> 
> Thanks for writing the doc. I think this is a very good starting point!
> 
> Mirja