Re: [tsvwg] path forward on L4S issue #16

[Jonathan Morton <[e-mail]>]

> On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S <[e-mail]> wrote:
> 
> Given all the input sofar my impression is that It is difficult to say how serious issue 16 really is. 
> Surely there is a possibility that L4S flows can get an potentially unfair advantage over a congested node that is  RFC3168 capable (and ECN enabled). The question is here when things are deemed as unfair and when starvation is a fact, opinions differ. 
> Another question is to how large extent there will be legacy RFC3168 ECN capable (and ECN enabled ) bottlenecks that will "never" be updated or replaced. This question is currently difficult to answer. 

When questions such as these are "difficult to answer", the correct design choice is to assume pessimistically, unless and until the question can be answered more definitively.  Therefore, the L4S design must account for the possibility of RFC-3168 AQMs in the network, and actively avoid unfairness in that case.

> Yet another aspect is how successful it will be to implement RFC3168 bottleneck detection e.g. in TCP Prague, I am quite confident that these will not always be successful.

I think we can safely say that the detection mechanism currently in TCP Prague is not successful.  David Black also pointed out that this would always be a fragile mechanism, difficult to implement correctly, and thus likely to be implemented wrongly by other transports even if a workable version was somehow developed.

With these facts established, I do not see how L4S can proceed without changing the signalling mechanism it uses.  This is something we intuitively realised more than a year ago, when the SCE project was started, but now we have actual evidence to back up that intuition.

 - Jonathan Morton