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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Tue, 09 June 2020 15:24 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE63A0900 for <tsvwg@ietfa.amsl.com>; Tue, 9 Jun 2020 08:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFiROz_Cy7gF for <tsvwg@ietfa.amsl.com>; Tue, 9 Jun 2020 08:24:48 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B360B3A085C for <tsvwg@ietf.org>; Tue, 9 Jun 2020 08:24:48 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 059FOcDh051420; Tue, 9 Jun 2020 08:24:38 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 059FOatj051419; Tue, 9 Jun 2020 08:24:36 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202006091524.059FOatj051419@gndrsh.dnsmgr.net>
In-Reply-To: <VI1PR0701MB287768D465C37DC46A459C12C2820@VI1PR0701MB2877.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
Date: Tue, 9 Jun 2020 08:24:36 -0700 (PDT)
CC: Sebastian Moeller <moeller0@gmx.de>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/NUhi5y4R-oBfbuGcuXExicAeZgs>
Subject: Re: [tsvwg] path forward on L4S issue #16
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 15:24:50 -0000

> 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://github.com/EricssonResearch/scream.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 <moeller0@gmx.de>
> > Sent: den 9 juni 2020 16:21
> > To: Ingemar Johansson S
> > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
> > Cc: Jonathan Morton <chromatix99@gmail.com>om>; Ingemar Johansson S
> > <ingemar.s.johansson@ericsson.com>om>; tsvwg@ietf.org
> > 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=40ericsson.com@dmarc.ietf.org> 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 <chromatix99@gmail.com>
> > >> Sent: den 9 juni 2020 12:10
> > >> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> > >> Cc: tsvwg@ietf.org
> > >> Subject: Re: path forward on L4S issue #16
> > >>
> > >>> On 9 Jun, 2020, at 10:33 am, Ingemar Johansson S
> > >> <ingemar.s.johansson@ericsson.com> 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                                                 rgrimes@freebsd.org