Re: [tsvwg] Consensus call on ECT(1)

["C. M. Heard" <[e-mail]>]

On Mon, May 4, 2020 at 11:15 AM Wesley Eddy <[e-mail]> wrote:

> *In this email thread, please state, concisely, which of the following
> viewpoints on ECT(1) you prefer. Please have extended discussion in a
> different thread. If you are uncomfortable sharing your opinion on the
> list, you may email the tsvwg chairs directly ([e-mail]
> <[e-mail]>). *
>
>
>
>
>
> * If you did not attend the 27 April interim, please watch the meeting
> video [https://www.youtube.com/watch?v=dw3YKyeFxQU
> <https://www.youtube.com/watch?v=dw3YKyeFxQU>] for context on this
> question. 1. I support using ECT(1) as an input signal to the network. This
> is the approach consistent with the current L4S drafts. This position does
> not mean that there are no remaining issues with L4S, but that the
> remaining issues can be resolved by continued WG effort on the current
> drafts. 2. I support using ECT(1) as an output signal from the network.
> This is consistent with SCE. If you believe L4S will not be safe for the
> internet without significant architectural changes, you are in this group.
> 3. There is a specific test or tests I need to see before making a decision
> about ECT(1). Please be specific about the tests in your response. Please
> submit your opinion by 5/18/2020.*
>

After an examination of the evidence, I am not convinced that L4S can be
made safe for the Internet without significant architectural changes, so
that puts me squarely in group 2: use ECT(1) as an output signal from the
network.

What drives me to this conclusion is the need for L4S endpoints to
implement heuristics to detect classic ECN bottlenecks and fall-back to
using the RFC 3168 interpretation of CE markings. The evidence that I have
seen does not give me confidence that it is possible to make this reliable.

Mike Heard