Re: [tsvwg] start of WGLC on L4S drafts

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

Hi

I believe that we can discuss around this for a long while. But I'd suggest
that this is something up to evaluation during the L4S experiment.

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 22 september 2021 15:51
> To: Ingemar Johansson S <[e-mail]>
> Cc: Jonathan Morton <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] start of WGLC on L4S drafts
> 
> Hi Ingemar,
> 
> the issue with L4S-SCReAM I see is that it clearly trades in utilization
for more
> robustness against unexpected rate drops... it it not clear how much of
its
> lower packet delay it actually gains from responding quicker to capacity
> changes (so L4S signaling) and to what degree it is giving itself more
time by
> essentially aiming at only filling the link to 80% or so. Because if all
senders
> would/could do that (aim well below their estimate of true capacity), we
> would not considerable less queuing delay... The real teats is how will
> SCReAM behave if the same link also carries a TCP Prague File up- or
> download that makes sure the ink is running at capacity...
> I mean no disrespect to SCReAM here, it might be well suited for its
intended
> purpose, but as a generalizable model for "internet traffic" it seems to
fall
> short a bit.
> 
> 
> Best Regards
> 	Sebastian
> 
> 
> > On Sep 22, 2021, at 15:42, Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]> wrote:
> >
> > Jonathan
> >
> > Thing is that you can still be using CoDel if you prefer to do so and
> > prefer the higher throughput (peak throughput is not always top
priority) .
> >
> >
> > /Ingemar
> >
> >
> >
> >> -----Original Message-----
> >> From: Jonathan Morton <[e-mail]>
> >> Sent: den 22 september 2021 15:37
> >> 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 4:30 pm, Ingemar Johansson S
> >> <[e-mail]> wrote:
> >>>
> >>> 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.
> >>
> >> These charts also show that Codel-ECN gives a significant improvement
> >> over having a dumb FIFO at the bottleneck, even with a congestion
> >> control that acts on delay information rather than only losses or
explicit
> marking.
> > That
> >> was the point I was making for Herr Geib.
> >>
> >> Codel-ECN also shows significantly higher and more consistent goodput
> >> than the L4S solution, which may be important in many applications.
> >>
> >> - Jonathan Morton