Subject: [tsvwg] Support for ECT(1) as input signal

From: <[email-masked]>
Date: Mon, 27 Apr 2020 19:38:52 +0000

Hi all,
In terms of the question almost asked at the end of today's meeting - should we define ECT(1) as a new input signal, a new output signal, or wait before making a decision? - I support making ECT(1) an input signal.

I don't see that much value in a new output signal indicating a lower level of congestion. I think it is OK to achieve something similar by signalling CE at a lower rate, and perhaps earlier at a lower rate.

A new input signal allows a different AQM at the bottleneck and should allow much lower latency for some services. I agree with the sentiment that it would be ideal to signal this through something other than the ECN field, such as DSCP, but in practice that is no good outside a controlled environment.

I don't think we need to wait further to make a decision. The discussion between the two options has been going on for a long time and often seems quite repetitive.  Not all the work is done, but I think it would be help advance the work for the WG to make a decision so it can focus its efforts on remaining issues.

Best wishes,
phil

---

From: Roland Bless <[email-masked]>
Date: Tue, 28 Apr 2020 00:11:18 +0200

Hi Philip,

On 27.04.20 at 21:38 [email-masked] wrote:
> I don’t see that much value in a new output signal indicating a lower
> level of congestion. I think it is OK to achieve something similar by
> signalling CE at a lower rate, and perhaps earlier at a lower rate.

I see more value in an additional output signal to get
better feedback about the level of congestion. That's currently
missing and could be utilized by better congestion control algorithms.
DCTCP is just one example. The advantage is that it is an unambiguous
signal, whereas your proposal (signaling CE at lower rate or earlier)
cannot be easily distinguished from legacy CE use.
Using DCSP as classifier for L4S and using ECT(1) as congestion mark
at the same time would allow for using ECT(1) as earlier congestion
signal for other evolving/future congestion controls, too.

> A new input signal allows a different AQM at the bottleneck and should
> allow much lower latency for some services. I agree with the sentiment
> that it would be ideal to signal this through something other than the
> ECN field, such as DSCP, but in practice that is no good outside a
> controlled environment.

We went through this with the LE PHB DSCP search.
Probably DSCP 5 would be a useful choice.

> I don’t think we need to wait further to make a decision. The discussion
> between the two options has been going on for a long time and often
> seems quite repetitive.  Not all the work is done, but I think it would
> be help advance the work for the WG to make a decision so it can focus
> its efforts on remaining issues.

I have the impression that much of the discussion focused around
L4S vs. SCE, which one is the better approach. I find it much more
useful to decouple the question of ECT(1) use from the "better
approach"/"more advanced approach" discussion.

Regards,
 Roland

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Mon, 27 Apr 2020 18:33:58 -0700 (PDT)

Hello Roland, and Philip,

Some comments inline marked {rwg}

> > I don?t see that much value in a new output signal indicating a lower
> > I don?t think we need to wait further to make a decision. The discussion
> > seems quite repetitive. ?Not all the work is done, but I think it would

{rwg} I am actually very upset about how this meeting was handled by the
chairs.  It was framed to us (SCE and L4S teams) a month ago as
NOT about L4S vs SCE, but about the long term decision of how
ECT(1) should be used.  Yet when it came time closer to the meeting
an outline of the slides was handed to each team that clearly framed
it as an L4S vs SCE discussion, and as expect that is exactly how
the meeting went.

Hopefully we can get some serious engineering discussion about the
real tradeoffs of using ECT(1) as an input or an output or to reserve
that decision until much more data is in hand.

-- 
Rod Grimes                                                 [email-masked]

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 28 Apr 2020 09:28:51 +0200

Hi Rodney,

I do not think that the chairs are to be blamed for how the debate developed, it is rather that the room decided to lead a different conversation and the chairs did not intervene (it is also unclear to me whether they should have).

But I agree that this is not really what I expected from the prepared slides*, if you allow me an allegory here:

We set out to decide on the relative merits of caffeinated versus decaffeinated beverages as a refreshment, but we actually ended up debating/reciting our subjective preferences for Coke versus Pepsi. This is all fine and well, and I have a much better feeling about the brand preferences now, but in regards to the initial question we are not one iota further along the path to making a decision.

Honestly, I also had the feeling we were rather discussing a platonic ideal version of ECT(1) as input/L4S instead of the implementation that currently sits before us. 
The was a clear disconnect in engagement of the people in the room yesterday and in the in the email discussions on the differences between what L4S promises and what it delivers over the last year(s). I really wish everybody with a clear opinion would also engage further in getting the L4S RFC in better shape (there still is a noticeable amount of over-promising/hype in there, as well as too much spin (like the whole RTT-independence topic)).

Best Regards
	Sebastian

*) Although as my too unfriendly mail to the list  a few days earlier indicates, I had already realized that that meeting material was not an ideal objective representation of the facts on which to base the input/output decision, which in retrospect probably was a mistake. The presentation of clearly subjective assessments naturally  steered the discussion into the Coke versus Pepsi direction.

> On Apr 28, 2020, at 03:33, Rodney W. Grimes <[email-masked]> wrote:
>