Re: [tsvwg] path forward on L4S issue #16

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

Hi

Yes, RFC8298 will eventually be updated, it is still an experimental RFC and
the target is to make it standards track in the end. 
There is already an implementation of L4S support in running code
(https://github.com/EricssonResearch/scream) but I don't really see that as
up to the task. More work is needed, it is perhaps possible that one can do
away with the split between the network congestion control part and the rate
control part. One problem that we currently see is that it may back off a
little too easy when we run it in our proprietary 5G network simulator with
L4S support.

The SCReAM BW test tool can be run on both RFC3168 style mode with the -ect
0 option, in which case it does something that resembles ABE. It runs in L4S
mode with the -ect 1 option.


/Ingemar
 
> -----Original Message-----
> From: Rodney W. Grimes <[e-mail]>
> Sent: den 9 juni 2020 17:25
> To: Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>
> Cc: Sebastian Moeller <[e-mail]>; Ingemar Johansson S
> <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> > Hi
> > Why don't you run the testing yourself to get the answers you look for?.
> >
> > You can download and build the SCReAM BW test tool (follow the steps
> below).
> > I can guarantee that you'll find cases where it does not work In a
> > satisfactory way. But as with most other congestion control work it is
> > work in progress, sometimes that progress is good, sometimes not so
> > good due to other projects that are more important.
> 
> Is there any plan to update RFC8298 to include using L4S w/Scream?
> 
> > /Ingemar
> > ==============================
> > How to get and build the SCReAM BW test tool on Linux PC's
> >
> > cd ~/somewhere
> > git clone
> > https://protect2.fireeye.com/v1/url?k=70acc563-2e0c7f0d-70ac85f8-861d4
> > 1abace8-e225af5cf515fe3e&q=1&e=20992ad0-7a3c-4843-b436-
> e719baf77c27&u=
> > https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream.git
> > cd code/bw-test-tool
> > cmake .
> > make
> 
> Does this code include the modifications that use ECT(1) marking?
> Is it possible to turn on/off that marking so that useful comparision
tests can
> easily be created?
> 
> For the benifit of the others in this thread, SCReAM is an experiment as
> documented by RFC8298, with the following in section 5 Discussion, a list
of
> items:
> o  Support for alternate ECN semantics: This specification adopts the
>       proposal in [ALT-BACKOFF] to reduce the congestion window less
>       when ECN-based congestion events are detected.  Future work on Low
>       Loss, Low Latency for Scalable throughput (L4S) may lead to
>       updates in a future document that describes SCReAM support for
>       L4S.
> 
> 
> >
> > What needs to be installed in advance is git cmake make gcc (or g++ ?)
> > I install both
> >
> > Read the SCReAM-BW-test-tool.pptx
> > ==============================
> >
> > > -----Original Message-----
> > > From: Sebastian Moeller <[e-mail]>
> > > Sent: den 9 juni 2020 16:21
> > > To: Ingemar Johansson S
> > > <ingemar.s.johansson=[e-mail]>
> > > Cc: Jonathan Morton <[e-mail]>; Ingemar Johansson S
> > > <[e-mail]>; [e-mail]
> > > Subject: Re: [tsvwg] path forward on L4S issue #16
> > >
> > > Ingemar,
> > >
> > > I have a feeling that this discussion thread is based on a
> > > disconnect. I
> > believe
> > > that most here agree that Scream is a nice and interesting project
> > > worth pursuing. The only contentious point is whether scream working
> > > well with current L4S AQM behavior over a single simulated hop, can
> > > make up for the apparent lack of testing under even mildly
> > > adversarial conditions (aka
> > real
> > > internet conditions) of the core L4S implementation and design. If
> > > you
> > have
> > > made such measurements in the context of scream's development,
> > > please do not hesitate to present them here.
> > >
> > > incomplete listing of mildly adversarial conditions:
> > > 1) bi-directionally saturating traffic
> > > 2) asymmetric links
> > > 3) long networks paths, >>5 hops
> > > 4) paths with parallel segments
> > > 5) unfriendly greedy traffic with less than expected yielding behavior
...
> > >
> > > Data demonstrating L4S immunity against negative behaviour under any
> > > of these conditions, is IMHO quite helpful for the continuing
discussion.
> > >
> > > Best Regards
> > > 	Sebastian
> > >
> > >
> > >
> > > > On Jun 9, 2020, at 16:11, Ingemar Johansson S
> > > <ingemar.s.johansson=[e-mail]> wrote:
> > > >
> > > > Jonathan, you kick in open doors..
> > > >
> > > > I urge interested people (if any?) to follow the discussion thread
> > > > instead to get an understanding what causes the lower throughput
> > > > with
> > > L4S.
> > > > https://mailarchive.ietf.org/arch/msg/tsvwg/FFQH_XG0-
> > > wbLIt7JRJ33dH8Fyf
> > > > c/
> > > >
> > > > /Ingemar
> > > >
> > > >> -----Original Message-----
> > > >> From: Jonathan Morton <[e-mail]>
> > > >> Sent: den 9 juni 2020 12:10
> > > >> To: Ingemar Johansson S <[e-mail]>
> > > >> Cc: [e-mail]
> > > >> Subject: Re: path forward on L4S issue #16
> > > >>
> > > >>> On 9 Jun, 2020, at 10:33 am, Ingemar Johansson S
> > > >> <[e-mail]> wrote:
> > > >>>
> > > >>> "Even though it is more than a magnitude difference in queue
> > > >>> delay between CoDel-ECN and L4S, it is fair to say that these
> > > >>> simple simulations should of course be seen as just a snapshot."
> > > >>
> > > >> Not to mention a magnitude difference in throughput.
> > > >>
> > > >> - Jonathan Morton
> >
> 
> --
> Rod Grimes
[e-mail]