Re: [tsvwg] Reasons for WGLC/RFC asap

[Ingemar Johansson S <[e-mail]>]

Hi Lars

Please see inline marked [IJ]
/Ingemar

> -----Original Message-----
> From: Lars Eggert <[e-mail]>
> Sent: den 19 november 2020 11:13
> To: Ingemar Johansson S <[e-mail]>
> Cc: Steven Blake <[e-mail]>; tsvwg IETF list
<[e-mail]>
> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
> 
> 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.
[IJ] There was an interim (March / April ?) where L4S was described quite a
lot. Then I was happy to see that now we can move forward, unfortunately I
was wrong. As I see if (after following all the threads in this list) the
L4S drafts have move forward but the overall heated discussion on this
mailing list continues like before. The only way is see is that the L4S
drafts are moved to WGLC, then people will hopefully read the drafts and
come with requests for clarifications where needed. Until then you can only
expect more of the same long incomprehensible discussion threads until
March, when we will repeat the same process again.

> 
> > 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.
[IJ] You are right, sorry for this, it was not my intention to put you and
Steve in that camp.

> 
> 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.
[IJ] The only pain point I see now is the RTT bias in cases where long RTT
Prague flows compete with short RTT ditto. This is being addressed by the
developers and it is not only an L4S problem. Besides this, Prague will be
presented at ICCRG tomorrow as I understand it. 
Besides this there is discussion around all sorts of cases with RFC3168
style AQMs, additional discussion before a WGLC will definitely not make us
more wise.
As regards to investment, already today there is investment in this,
examples that are disclosed in the open are Broadcom and Nokia. I can
imagine that there is some expectation that L4S will materialize in RFCs 

> 
> > 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?
[IJ] This was in reference to the " try and delay WGLC/RFC " with the hope
that something better will emerge, it may as well be 5 years and we still
have only 2 bits. 

> 
> 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.
[IJ] If this would only be a IETF matter, then you are right. We however try
to address this also in 3GPP standards to make the whole thing work in
products, and that is of course hard to do if L4S is not even an RFC.

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