[tsvwg] Review of draft-bagnulo-tsvwg-generalized-ecn-01

[Mirja Kühlewind <[e-mail]>]

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