Re: [tsvwg] Reasons for WGLC/RFC asap

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

Hi

Please see inline [IJ]

/Ingemar

> -----Original Message-----
> From: Lars Eggert <[e-mail]>
> Sent: den 19 november 2020 14:10
> 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 14:36, Ingemar Johansson S
> <[e-mail]> wrote:
> > 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.
> 
> to clarify: I don't have opinions about the L4S drafts. I haven't read
them in a
> while, I agree that I should.
> 
> One point I am trying to make is that since the set of documents we are
> discussing seems incomplete, in that it doesn't seem to contain a TCP
variant
> that intends to delivers benefits over L4S paths w/o regressions.
> 
> My main point though is that there seem to be questions raised about the
> performance and behavior of L4S with various TCP variants. This is not an
> issue with the content of the L4S drafts. It's a remaining uncertainty
related to
> the experimental evaluation and analysis that the L4S mechanisms have seen
> so far. Going forward with a LC is not going to bring further clarity
here.
> 
> > [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.
> 
> That is one point. I think interactions with tunnels was another.
[IJ] My take is that this is something for L4S ops that I see as a product
of the L4S experiment. It is not something that needs to be answered on its
own as it is mainly the RFC3168 AQM issue in another shape, we don't know
how widely spread this problem is or to how large extent this equipment can
be updated, earlier discussions on fq-codel implementations in home gateways
was not conclusive I guess but it appears that many of these have automatic
upgrade features, I guess the reason here is to be able to upgrade to combat
security threats but this is admittedly speculation.

> 
> I'm actually looking forward to the presentation on TCP Prague - is there
a
> draft?
[IJ] Not that I know of, code is found at https://github.com/L4STeam/  
> 
> > 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.
> 
> Discussion won't, but experimentation would.
[IJ] Yes, but we need to get past the discussion on all possible things that
can happen. Recall from the discussion yesterday that Stuart Cheshire and
his team has not need evidence of ECN marking AQMs. So I fear that we spend
a lot of time discussing problems that are very rare.

> 
> > 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
> 
> Sorry I was unclear. You are right that there is investment by vendors.
But I
> think the key question if there will be an investment by operators, since
they
> need to eventually buy L4S kit and deploy it. And that investment will
only pay
> off if end systems actually have deployed a CC scheme that takes advantage
of
> L4S. So the ready availability of such a scheme is IMO a key requirement.
[IJ] I would say that we already have CC algos that can be used. Surely they
do not meet all the requirements today but I don't see why it will not be
possible. It is definitely the case that we will be discussing what typical
RTTs are like forever but that is not something that should delay the L4S
drafts I think.  

> 
> > [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.
> 
> Is L4S currently a requirement for a future 3GPP release?
[IJ] L4S is not currently pushed for in 3GPP, there is however work on the
support for extended reality that requires low latency. L4S will definitely
fit there. I would expect that L4S support can be proposed ~ mid next year.

> 
> Thanks,
> Lars