Re: [tsvwg] Reasons for WGLC/RFC asap

[Lars Eggert <[e-mail]>]

Hi,

On 2020-11-19, at 11:43, Ingemar Johansson S <[e-mail]> wrote:
> My opinion is that this work has stalled due to an endless discussion on the severity of the listed issues. Do you foresee that a year or so more of equally endless discussion will make anybody more wise ?

I'd hope so. But maybe I am optimistic.

One problem is that there have been two camps that are mostly talking to (or shouting at) each other. That makes it quite unappealing to join the discussion for someone who isn't part of those camps. I agree that more of that kind of "discussion" is not going to be helpful. I think the two camps need to realize that they need to convince the *rest of the WG* of their respective views, not each other.

> , between meetings there are only a few people engaged in this debate that floods the TSVWG list, it is a safe bet that most outsiders hit the delete button.

Yes. Because mostly, as I wrote above, the discussion is very inwardly focused, highly detailed, very fast-paced, references email threads that go back years (without pointers) and so makes it very, very hard for someone who has not participated to engage and stay engaged.

> I can understand the incentives to try and delay WGLC/RFC, perhaps some hopes that there will by some magic emerge a much better high-fidelity congestion marking in some form. In short, tear the whole thing apart and come up with something much better.

That's certainly not what I tried to say, and I didn't get that from Steven's email either.

My point (don't want to speak for Steven) was that without a TCP scheme that delivers some benefits when operating over a path with some new-style queuing while at the same time not suffering from serious regressions, it's kinda hard to argue that that new-style queueing is performing as desired. (And we can certainly debate what counts as a serious regression and what doesn't.) Basically, a strawman that satisfies (some of) the Prague requirements without regressions.

Maybe we have that TCP scheme already, but at least the recent results that Pete shared show that there are maybe still some question marks.

And we don't need the perfect scheme. But we need something that delivers enough benefit that the entities that are required to deploy this feel motivated to do so. Deploying this is a pretty big investment, after all.

> The problem is that we are talking at least 2 years extra work to get into the state that the L4S drafts are today.

I can't quite parse that sentence. Are you saying this would delay L4S for two years before we can LC it?

Like Steven, I don't understand where this extreme pressure comes from to LC something. Experimentation is not contingent on the LC, even large-scale experimentation.

> The use of the ECT(1) code point tend to often lead to questions like "what do we do when L4S fails?". Well the nonce has been declared historic so the process for this is in place, but besides this it is perhaps good to consider that L4S can actually fly ?.

I don't actually care at all that L4S uses ECT(1). I'm still unconvinced - at the moment - that L4S delivers on its promises. *That* is why I am questioning whether we're ready for a LC.

> I really think that it is high time to move this to WGLC, this has dragged on for too long.

"Time spent in WG" is not a useful criteria for determining whether something is ready for a LC.

Thanks,
Lars