Re: [tsvwg] start of WGLC on L4S drafts

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

Hi Pete

You are right, what I describe below is not really the same cellular access 
related feature that you described.
Perhaps one can add some wording around this (unless there already is, I need 
to take an extra look).

I don't however think that we should try to quantify the impact on peak 
throughput at this stage as there are so many variables to tune here. Perhaps 
one will have some decent figures to present in the course of the L4S 
experiment.

/Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Pete Heist
> Sent: den 24 september 2021 09:20
> To: [e-mail]
> Subject: Re: [tsvwg] start of WGLC on L4S drafts
>
> In my Prague/BBR tests with airMAX, the underutilization was caused by link
> layer burstiness rather than rate changes or application bursts, so we seem
> to be looking at different causes.
>
> The first issue I have is with the goal as stated in the drafts and the 
> results we
> see. There are various possible remedies to that which may lead to different
> discussions, but IMO that should be fixed in some way, and we can also
> revisit this after any draft changes.
>
> Thanks for the explanations...
>
> Pete
>
> On Wed, 2021-09-22 at 19:28 +0000, Ingemar Johansson S wrote:
> > Perhaps we delve off topic here but I'll try with the answer with the
> > hope that I don't mess up this thread
> >
> > The reason why SCReAM with L4S gives a lower throughput is two-fold
> >
> > 1) Fast fading : Even though the average link throughput is 10Mbps,
> > the instantaneous throughput may vary up and down, as L4S strives for
> > low queue delay it will mark packets until the queue delay target is
> > reached also when the link throughput is below the average link
> > throughput.
> > 2) Varying video frame sizes. Video coders don't produce equal sized
> > frames.
> > It is not only occasional I-frames that deviate in size, also P-
> > frames vary in size. Larger frames will hit the queue more and
> > therefore cause more packet marking, with the result that the target
> > bitrate goes down. This the larger the variations in frame size, the
> > more the target bitrate is reduced.
> >
> > Of the two above , I'd say that #1 is a cellular access specific
> > feature (not only 5G), it merely says that you cannot get both full
> > link utilization and low queue delay. I don't however really see that
> > as a flaw in L4S, rather that L4S is a good tool to find a good
> > working spot that gives low queue delay but still high link
> > utilization (albeit not full ditto).
> >
> > /Ingemar
> >
> >
> > > -----Original Message-----
> > > From: tsvwg <[e-mail]> On Behalf Of Pete Heist
> > > Sent: den 22 september 2021 17:25
> > > To: Ingemar Johansson S
> > > <ingemar.s.johansson=[e-mail]>; Jonathan
> Morton
> > > <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: Re: [tsvwg] start of WGLC on L4S drafts
> > >
> > > Hi Ingemar,
> > >
> > > The stated goal of L4S as I understand it from the second paragraph
> > > of the l4s-arch Abstract, is that _both_ latency and throughput
> > > should be better than a "classic" congestion controller, but these
> > > results would seem to show that only one of the two has been
> > > improved. This is similar to what we've seen with TCP Prague and BBR
> > > tests over wireless links, or other sources of bursty arrivals in L.
> > > Both of our test results have shown a mismatch between this goal and
> > > what we see over WiFi, airMAX and 5G networks, which seems like it
> > > should be addressed somehow. I've not done any testing on 5G so far,
> > > but I would think that if any wireless technology had a chance of
> > > achieving this goal, 5G would be it.
> > >
> > > IMO, we should do better than just mentioning somewhere deeper in
> > > the draft that this goal may not be achieved. One possibility is
> > > that the implementation could be changed to achieve these goals with
> > > current technologies. Another is that it's made clear up front how
> > > existing link/wireless technologies must change before the
> > > experiment will run successfully on them. In that case though, I
> > > think we're right to be cautious before starting an experiment that
> > > hasn't been shown to achieve its stated goal on any currently known
> > > wireless technologies.
> > >
> > > Regards,
> > > Pete
> > >
> > > On Wed, 2021-09-22 at 13:30 +0000, Ingemar Johansson S wrote:
> > > > Hi
> > > >
> > > > For the sake of completeness.
> > > > Attached are three graphs that depict simulated results with
> > > > SCReAM
> > > > congestion control, the scenario is 5G UL real time video
> > > > streaming
> > > > (e.g AR or remote control) where the channel is degraded due to
> > > > shadow
> > > > fading. Note that results can vary dependent on system
> > > > configuration
> > > > and overall radio conditions so see this as only examples.
> > > >
> > > > SCReAM-5G-noECNorL4S.png : Classic ECN and L4S disabled, SCReAM
> > > > operates only based on estimated queue delay
> > > >
> > > > SCReAM-5G-CoDel-ECN.png : SCReAM is ECN capable and 5G
> bottleneck
> > > > implements CoDel ECN marking
> > > >
> > > > SCReAM-5G-L4S.png : SCReaM is L4S capable and 5G bottleneck
> > > implements
> > > > L4S marking
> > > >
> > > > These graphs show that CoDel does not achieve the same
> > > > performance as
> > > > L4S.
> > > > One can of course argue that this almost 30ms less delay jitter
> > > > with
> > > > L4S is not important, but then again nobody is forced to use L4S.
> > > > I anyway see substantial results that L4S can improve performance
> > > > in
> > > > 5G for services like XR, cloud gaming or remote control and
> > > > therefore
> > > > look forward to have L4S ID published as experimental RFC.
> > > >
> > > > /Ingemar
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Morton <[e-mail]>
> > > > > Sent: den 22 september 2021 13:52
> > > > > To: Ingemar Johansson S <[e-mail]>
> > > > > Cc: [e-mail]; [e-mail]
> > > > > Subject: Re: [tsvwg] start of WGLC on L4S drafts
> > > > >
> > > > > > On 22 Sep, 2021, at 2:36 pm, Ingemar Johansson S
> > > > > <[e-mail]> wrote:
> > > > > >
> > > > > > I think that we have discussed this particular topic (isn't
> > > > > > CoDel
> > > > > > good
> > > > > > enough?) inside and out over the last two years. I posted
> > > > > > some
> > > > > > comparisons of CoDel-ECN vs L4S on this list (can be found
> > > > > > with
> > > > > > some search in the mail archive).
> > > > >
> > > > > There is one key advantage that CoDel-ECN has over L4S: it is
> > > > > deployable
> > > > on
> > > > > the existing Internet.
> > > > >
> > > > > > That said.. It is apparent that there will be no agreement
> > > > > > around
> > > > > > this but that is not necessary for the L4S experiment, and as
> > > > > > I
> > > > > > see it, not the scope of the present discussion either.
> > > > >
> > > > > He asked, I answered.  That's all there is to it.
> > > > >
> > > > >  - Jonathan Morton