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

["Gorry (erg)" <[e-mail]>]

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

> On 26 Sep 2017, at 20:41, Mirja Kühlewind <[e-mail]> wrote:
> 
> 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."

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.

> 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.
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
> 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.
> 
I think reserving ECT(1) for this RFC could make sense.

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

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

Gorry