Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S

Sebastian Moeller <moeller0@gmx.de> Tue, 10 March 2020 10:28 UTC

Return-Path: <moeller0@gmx.de>
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 F13043A0FEF; Tue, 10 Mar 2020 03:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 WIX40lOIF2fE; Tue, 10 Mar 2020 03:28:08 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8426C3A0FFF; Tue, 10 Mar 2020 03:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583836080; bh=4STwlZ63drN5z9PT5rNTNaL4bQ5wy07f5187BYBpVOo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=jupIdq8ucekCRPwD9CEAbrTPr3BkE01rsdyKC3i7/HJTOX/JnCQNGshtqTVCq4zMx rikvpFIKkAxtoC8jVbUHEiVMAWQnSuNTLl9AfuXvJy9/mgn6eI1W4ClPUPi/8wimne r+OdiZfTQza3UKrbrd0s7uI3lM05zY7E0y2wXL5Y=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.22] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvK0X-1jT0NN1MQb-00rHZK; Tue, 10 Mar 2020 11:28:00 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: =?utf-8?q?=3CHE1PR07MB4425B105AFF56D1566164900C2FF0=40HE1PR07MB?= =?utf-8?q?4425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Tue, 10 Mar 2020 11:27:57 +0100
Cc: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "iccrg@irtf.org" <iccrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C969A05-A4B7-43E9-B694-3195A2FC086A@gmx.de>
References: =?utf-8?q?=3CHE1PR07MB44251B019947CDB6602B30B2C2FF0=40HE1PR07MB4?= =?utf-8?q?425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CA2300F8D-5F87-461E-AD94-8D7B22A6CDF3=40gmx=2Ede=3E_=3CHE1PR07M?= =?utf-8?q?B4425B105AFF56D1566164900C2FF0=40HE1PR07MB4425=2Eeurprd07=2Eprod?= =?utf-8?q?=2Eoutlook=2Ecom=3E?=
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:eiNnSTvHromxTgs5FM1v1UlMOW3yzwyfusLW6qkU2FGiyBue7XM BYiXyfRfzWsGhSgFsIMn2pBksKE8+2rPHl+JZ94jgN+BWkKke9f14V8NBfbfdTJuxeFMHmr ka9bRyU89LWBI9MIL4UU7+ctfHA+qdElaeDlZASqnwdxQOSeNae+om5HOm7EeuWD5Fkxfmo C2Wc3qk74/cVVr7TfVHmA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:3f8/K3UgVLU=:ZiA2w9MnTnyjxlBuPfZbO1 42byT9vldACAtx2xcKU1KRrKhNTqkIlhcnvtCKmJLGkscWZ/VpmSkOVyd+WSqxxp5anAOEHQ9 UZtGwEk406HFt2wz2tU4YlXJ6Fi2YjIMAQkIz5TRs6J4Y3enUB9nmyG/OR/RDZlmbhZpoQ5bM 931+UBngCBa7vQONqzlJHVuj4f4J5S32aLqbz9sk/z9T3Q7tOl0Wv6pg+30GgvthlWFKUKpWE aZDuzHiODkceY6hURf5inXVtqhHFVdLkk5aVmPpj3szvGA68KZ3hFH5+S7zqxmI2C5gBrpNL5 rMA6rjyC1TCVsI9CzAQHW/2O/Air+iR0AD6Cazit/UQ3UueFgOna4sQNNZb1igX6nYwE76vhS ZlXgtElQ/mIsQhXxKX42QpRsQp9ucxOoj2bG77z+OfOqavAoDlvq54JW6sNnVOKKeLbIS/YCG XToaZepOyJwQcb+jPqba0xD22JJX1cnuIQI9uToP0zduv6VSUPx8OeSFIk7xQk7QMzIRx9lJ8 xnHISMEAc24FsKiEuDAwnJRSEDb0q25KzfoQEGK7c8/jg2vTkp2hSrGnH86gLrl5cnDkNmcil gofb7WfWeV8MTC8c2iu3YyZt+pGVp9PdrT8whbSLBzZjQKb6wWAcQS79tJWFVTCj5HN8I5bcF /AxM79It+a0d3az07Vee28mzBqcOOnkL30RkGBjaLmXi7X7tYDtzA80M1eaRywEmcPPHDXQAO +LSqshDM1KgGe7prapy7m70PvHuTnw5hvmpCASSN7wz6snBhlF1/mFtzD8vLM99b2EZqYTFeY TYjJdNAIhIOmOaJcZIrkLuuIiDMW+NCJEr2XEc3IjxI5DOzYZkBqbSFz7MFkqzFODmHwDWN4z NxoWxzfYUMq31rysRuAoUI41hbvLaEw8ek+gsfHuUFiXSV+/eXADxSzM0BAg5u+b/eLHaPVWx YhHYZH05aQj/CensprvRBgph2OGGlqor3aWuzgbJt3wrsAg60bTYLxZFOxJNVBlDTK5cmEG2N d5rKb9MH10Ol1jKkqO0upkGYALiMCilUa4U5GbJcm+tvDxh4/gPaxYandLnKrUFotbLJNFeRm bR5PjlKmy3Migwo8sLfdBnXRKYyOiQKKDsHwJd1OFWgf3An0azaS66IH6MWtRKhI2/AqRrFG6 X/Mwuq9Sopo21oq74e5LfIlNIzBLZYjVuCF+bON51XmPI78YZstD9Dw6eB853+FEj/PvGzG/y SmetYl0qSoIqVxArekYwNUnDhB8fPkEsdKI+p9KV2D9SMDj5mHOyFCQYryAK/2WZr1Ieg2BKl bAcru/p3gMyDXShRsKQeDhHiCilUUnpGhxRMJutuzTObKmTFinUKUbCffP/ZSZvMveV6RG+n
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FsH87245xexp8hoEW3lg2OCI5Nc>
Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
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, 10 Mar 2020 10:28:12 -0000

Hi Ingemar,


> On Mar 10, 2020, at 11:07, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> Hi
> 
> For the future studies we will only focus on L4S as the scope is to study the performance gain that L4S give for instance for AR/VR, gaming and remote control applications.

	[SM] How are you going to "study the performance gain that L4S give[s]" if you do not compare it with the best of class alternatives? I am truly puzzled.

> Flow aware AQMs with RTT estimates as metadata in the packets is outside the scope as it would require packet inspection, which is not feasible if queues build up on the RLC layer in the 3GPP stack.

	[SM] Fair enough. What is this comparison intended to show us then?

As far as I can see you paired an application designed for 1/p-type congestion feed-back with an 1/sqrt(p)-type AQM that was also set for sub-optimal RTT and latency target for the test path. And lo and behold, the application does "better*" for the 1/p-type AQM (with lower latency target; I assume that  L4S ramp-marker (Th_low=2ms, Th_high=10ms) was carefully selected to match what SCReAM expects). IMHO that simply demonstrates, that in communication it pays if sender and receiver of a symbol (CE here) assign the same meaning to it.

But that can not be it, sohat am I missing here?

Best Regards
	Sebastian


*) Assuming one buys into your definition of better, in which (instantaneous) queueing delay is valued over video quality. From a network operators perspective that seems a valid position




> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Sent: den 10 mars 2020 10:45
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
>> Cc: tsvwg@ietf.org; Ingemar Johansson S
>> <ingemar.s.johansson@ericsson.com>om>; iccrg@irtf.org
>> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
>> 
>> Hi Ingemar,
>> 
>> thanks for posting this interesting piece of data!
>> 
>>> On Mar 10, 2020, at 09:02, Ingemar Johansson S
>> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
>>> 
>>> Hi
>>> 
>>> I recently updated the readme on the SCReAM github with a comparison with
>> SCReAM in three different settings
>>> 	• No ECN
>>> 	• CoDel ECN
>>> 	• L4S
>>> https://protect2.fireeye.com/v1/url?k=63019d27-3f884737-6301ddbc-0cc47
>>> ad93e2a-489fa99c3277fb8a&q=1&e=5aab95a7-4aab-4a64-99a5-
>> 5b55606e303b&u=
>>> https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%23ecn-explicit-
>> co
>>> ngestion-notification
>>> 
>>> Even though it is more than a magnitude difference in queue delay
>>> between CoDel-ECN and L4S,
>> 
>> 
>> 	[SM] So, in this simulations of a 20ms path, SCReAM over L4S gives ~10
>> times less queueing delay, but also only ~2 less bandwidth compared to SCReAM
>> over codel. You describe this as "L4S reduces the delay considerably more" and
>> "L4S gives a somewhat lower media rate". I wonder how many end-users would
>> tradeoff these 25ms in queueing delay against the decrease in video quality from
>> halving the bitrate?
>> Could you repeat the Codel test with interval set to 20 and target to 1ms,
>> please?
>> 
>> If that improves things considerably it would argue for embedding the current
>> best RTT estimate into SCReAM packets, so an AQM could tailor its signaling
>> better to individual flow properties (and yes, that will require a flow-aware
>> AQM).
>> 
>> 
>> 
>>> it is fair to say that these simple simulations should of course be seen as just a
>> snapshot.
>> 
>> 	[SM] Fair enough.
>> 
>>> We hope to present some more simulations with 5G access, and not just
>> simple bottlenecks with one flow, after the summer.
>> 
>> 	[Looking] forward to that.
>> 
>>> 
>>> Meanwhile, the SCReAM code on github is freely available for anyone who
>> wish to make more experiments.
>>> 
>>> /Ingemar
>>> ================================
>>> Ingemar Johansson  M.Sc.
>>> Master Researcher
>>> 
>>> Ericsson Research
>>> RESEARCHER
>>> GFTL ER NAP NCM Netw Proto & E2E Perf
>>> Labratoriegränd 11
>>> 971 28, Luleå, Sweden
>>> Phone +46-1071 43042
>>> SMS/MMS +46-73 078 3289
>>> ingemar.s.johansson@ericsson.com
>>> www.ericsson.com
>>> 
>>>  Reality, is the only thing… That’s real!
>>>      James Halliday, Ready Player One
>>> =================================