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

[Uma Chunduri <[e-mail]>]

Support Option-1 i.e.,  ECT(1) as an input signal to the network and
remaining issues need to be worked out here.

FWIW:
There is real need for this work and it can ease things from best-effort
queues. While I don't claim to understand all other implications of various
CC stuff on this, IMO  this is better than mapping it to DSCP code points
(which has only limited options when its mapped to TC bits in some
environments).

--
Uma C.



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