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

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

Hi David,

yes, I already realized that I reviewed the wrong doc. The right review on the tcpm list will follow soon. I set the ‚replaces‘ relation yesterday after noticing. 

@all: Please make sure you set this correctly if you upload a draft with a new name!

Mirja


> Am 10.12.2016 um 03:36 schrieb 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
>