Subject: [tsvwg] Mirja Kühlewind's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 26 Sep 2017 12:41:51 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tsvwg-ecn-experimentation-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) section 2 actually seems a bit redundant to me but I guess that not a
problem. I guess I would also be okay with the doc if section 2 would not be
there, but maybe this overview actually helps others who are less familiar with
ECN.

2) I guess it could actually be helpful to include a tiny bit of reasoning why
the ECN Nonce experiment is concluded instead of just saying that it was never
deployed and further point to an appendix of a draft (which is actually
appendix C and not B.1 I believe). I know this was discussed, but having one
sentence saying something in the lines like this is probably not to hard: "The
experiment is concludes with the result that ECN Nonce does not provide a
reliable integrity protection as the other end can always pretend to not
support this optional feature."

3) This sentence is a bit unclear:
"In addition, until the conclusion of the L4S experiment, use of
   ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to
   allocate ECT(1) exclusively for L4S usage if the L4S experiment is
   successful."
I guess the L4S exp RFC would use ECT(1), so the sentence to not really make
sense to me. Also given that there is no RFC for L4S yet, we actually don't
know if there is finally community/group consensus to publish that RFC. I guess
it actually to early to say something like this. I know why you want to have
this sentence in there, but from the processing point of view that does not
seems to be the correct thing to do and it might be better to just remove it.
Otherwise, if you want to  keep it or something similar but maybe less
specific, following up on the feedback provided by IANA, the TCP flag should
probably be just marked as reserved with reference to this RFC.

4) I'm not certain about this part:
"An exception to this requirement occurs in
      responding to an ongoing attack.  For example, as part of the
      response, it may be appropriate to drop more ECT-marked TCP SYN
      packets than TCP SYN packets marked with not-ECT. "
Maybe it's to late here and that's the reason I don't get it, but what would be
the reason to rather drop ETC marked SYNs? Can you explain? I do understand
that there is no reason to not drop ECT-marked SYNs in an attack situation
(meaning don't try to mark, drop immediately) but I don't understand why you
should drop ECT-marked SYNs preferentially? If the assumption is that attacker
would more likely use ECN than non-attackers because the will usually not be
dropped but marked, I'm uncertain if that is true and still not sure if the
above recommendation is appropriate. In any case I think this needs at least
more explanation in the document.

5) As a side note on this sentence:
"Random ECT values MUST NOT be used, as that may expose RTP to
      differences in network treatment of traffic marked with ECT(1) and
      ECT(0) and differences in associated endpoint congestion
      responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]."
I think random marking is anyway not a good idea because this is sometimes used
(incorrectly) as input for ECMP. Therefore I actually think the reference to
the l4s draft is actually not needed here.

---

From: "Gorry (erg)" <[email-masked]>
Date: Wed, 27 Sep 2017 08:13:40 +0100

Mirja, thanks for the review. I was document shepherd and have some observations.

> On 26 Sep 2017, at 20:41, Mirja Kühlewind <[email-masked]> wrote:
> 

That argument was presented along with others - although I suggest this is not really a new argument. 

There is value in a protection mechanism in a transport protocol, and had the nonce mechanism been deployed, senders could require this when using ECN - or could alternatively have opted for some other fallback method, knowing the receiver would not honour the nonce. I do not think this extra sentence is correct, nor important - the unusuability was a consequence of non deployment.

> sense to me.
I see this issue. The bashed text does seem too contorted!

 I suggest we say something simpler like ECT(1) is reserved for use by TSVWG. (This will be used by L4S, until this experiment is concluded or this allocation is made permanent). 

> Also given that there is no RFC for L4S yet, we actually don't
I think reserving ECT(1) for this RFC could make sense.

> more explanation in the document.
I suggest SYN attacks need to be considered - and I would like to see that noted here - however, stating what reaction is needed in this case, should be the subject of the TCPM ID.

> the l4s draft is actually not needed here.

Gorry