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>
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tsvwg/FsH87245xexp8hoEW3lg2OCI5Nc>
Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
Precedence: list

Hi Ingemar,


> On Mar 10, 2020, at 11:07, Ingemar Johansson S =
<ingemar.s.johansson@ericsson.com> wrote:
>=20
> Hi
>=20
> 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=3D2ms, Th_high=3D10ms) =
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. =46rom a =
network operators perspective that seems a valid position




>=20
> /Ingemar
>=20
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Sent: den 10 mars 2020 10:45
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=3D40ericsson.com@dmarc.ietf.org>
>> Cc: tsvwg@ietf.org; Ingemar Johansson S
>> <ingemar.s.johansson@ericsson.com>; iccrg@irtf.org
>> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
>>=20
>> Hi Ingemar,
>>=20
>> thanks for posting this interesting piece of data!
>>=20
>>> On Mar 10, 2020, at 09:02, Ingemar Johansson S
>> <ingemar.s.johansson=3D40ericsson.com@dmarc.ietf.org> wrote:
>>>=20
>>> Hi
>>>=20
>>> I recently updated the readme on the SCReAM github with a comparison =
with
>> SCReAM in three different settings
>>> 	=E2=80=A2 No ECN
>>> 	=E2=80=A2 CoDel ECN
>>> 	=E2=80=A2 L4S
>>> =
https://protect2.fireeye.com/v1/url?k=3D63019d27-3f884737-6301ddbc-0cc47
>>> ad93e2a-489fa99c3277fb8a&q=3D1&e=3D5aab95a7-4aab-4a64-99a5-
>> 5b55606e303b&u=3D
>>> https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%23ecn-explicit-
>> co
>>> ngestion-notification
>>>=20
>>> Even though it is more than a magnitude difference in queue delay
>>> between CoDel-ECN and L4S,
>>=20
>>=20
>> 	[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?
>>=20
>> 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).
>>=20
>>=20
>>=20
>>> it is fair to say that these simple simulations should of course be =
seen as just a
>> snapshot.
>>=20
>> 	[SM] Fair enough.
>>=20
>>> We hope to present some more simulations with 5G access, and not =
just
>> simple bottlenecks with one flow, after the summer.
>>=20
>> 	[Looking] forward to that.
>>=20
>>>=20
>>> Meanwhile, the SCReAM code on github is freely available for anyone =
who
>> wish to make more experiments.
>>>=20
>>> /Ingemar
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>>> Ingemar Johansson  M.Sc.
>>> Master Researcher
>>>=20
>>> Ericsson Research
>>> RESEARCHER
>>> GFTL ER NAP NCM Netw Proto & E2E Perf
>>> Labratoriegr=C3=A4nd 11
>>> 971 28, Lule=C3=A5, Sweden
>>> Phone +46-1071 43042
>>> SMS/MMS +46-73 078 3289
>>> ingemar.s.johansson@ericsson.com
>>> www.ericsson.com
>>>=20
>>>  Reality, is the only thing=E2=80=A6 That=E2=80=99s real!
>>>      James Halliday, Ready Player One
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D