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

Sebastian Moeller <> Tue, 17 March 2020 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DAD33A0897; Tue, 17 Mar 2020 07:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M_6UvtwcZLSK; Tue, 17 Mar 2020 07:55:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 781413A08A3; Tue, 17 Mar 2020 07:55:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1584456891; bh=N9PXq3FXGOvPEUzWFwDxWIQuQxbMI2eDgGU+Lphv70Y=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=WjY73vUtBNfPYz6yFnAm88W4k3bqZpi2t7KO7flvvRoED3y+GBl6hxk61hUGcO0XM umiujJcqUW6I2S+YClv3dUSHfBY377ct1yP0tikBBD3e4JzzCGdLj0FJ1ZlHaTvE6P qw7+L/V8GNu8ROrB24rt2u5On5JPLHrh/xYO40eo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MN5if-1ixvHq2qAP-00IzlK; Tue, 17 Mar 2020 15:54:51 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Tue, 17 Mar 2020 15:54:49 +0100
Cc: Ingemar Johansson S <>, Ingemar Johansson S <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <><> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:0CpqIfElDz1DaTfEuLeQEVieSGLyePjMZPLZ5OrKyv3VvSIwMyQ 7KRkI7jwuSuSakJ93kurwdwhPHc0bVo0KoeC701E36quPiPCTaP5BZfMqU1wI3bJSvGelaI YrBUh9V+5vV1hSgdQTBPmKr38xmPjq3wI9pEHMXtN2mX97T5N9DBecbo8q/sWGSrZSf09ck 8AGFrGUh1QE/NVWwvMJBQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7RVSyPmPIGE=:dyBKf7vcxfydrCDH2u95KS 1UNYMcP33yQqrCDIbOeQOoETKwutYavR88YcENdvC91Z5pc6qw+5bgFujQOBTdVl8wy8H25Ux hlhBM9PGjsFGmEiK4y1UQYm/zsf9JK7GWscXFhYSCkGYqeoacYcSlgKj2VduhPDOtyXY68rir tecXZ33MIo9dfFy2ekwJqJu1I8a675WmjhCk4GQnrps7mY6yoEYliwj9wvAFET0a73RnsqixE FaubSINJYrKHXtr3ULRRewJfSttE4Xa+u7u6l5Y/vc+rgzkWdkoVrs/gfXe0HOby0tN3q7ihf 2DXOEDgvCibkQdnoVEi5La7Le9qrZqbXfymn8A1em+limMt3OM75VuprAN0ToGlQvpiRNYYu8 xl0YhVLgWR4uxrWD+u5LuANXh5Q6SIRWLZtysh6teFPnjZ9BgmSYVuaJNmfwzW85J2aftIq7/ ZkGoTUFhPLXB8E5xrGoMCCrEoSK1RJlIncgCYB3gKhVL9YRmdU+rZX5TbmY7m4F4lBkZKhojg mLhqqOv4wMVUAQH4K6Ww0ZSm9WeAtWJ1Rt7RdWdb4qg4ONcRII4WVmjeuRDOmSbtoeaNiv9A2 HHAluzv1svb/5qY14TTN9Wnw1BmPaYrd7lj+4UI1/CVU4j9RVR9S9gW8VUhDAVVA7sUtbUK21 TErh0NANlu2VaJL/ar+yut1/Oqo6PZGsxpliAXU3V+2aFLp5pEub8xMdPX6OrUExkTXDROMFq Aipyc/pJVNdj3J62Qc3qATE8KDsH64PW60HviqXPcpKaH0LD5cGYwo5BtizOTwhcPBp155ACU Hm7KmGC/Sjg6XumFrzCASsfaLOXKlCWeZxWrd7VGkOwLBD9tehW9oGneHIAuG9G7j4Jp2pPaf 3xjaoCu3+SF3vasbfh/E7wP3+gsldgjHLILjoB1EXxtwt7MP+cVKsD0Aom4WGcUDjiBh2NCm1 nW7Wt5ELj4KdgKxtE1YyFe7mmb355nsV/5+j1WODao/DUVf31d0hy8mwOjhiNGopG63XCjZs9 /fpn46kNHUJM9TlprwOiHvPmGRqpatL95hFV6vC0TeHAEeidihWzOuZ1a7JL2FZxGK7RbV3MC RYAYHuoyqxJZ8t0dhhP1iDsjYjIMcwv+P+W7oggrHPiv3UJ9+n7Dgjo4PKLI04D0fENj9gz/x XgJU1mdp3JsQTIwyjI8dEnzsspsc+739GLpJjYnZ+8NVRTQmlFzuLk27bh9uF2WQ3Wd2LbOFo m5a9X992CnbXubJjGQaOmD/lU8BGvHOV3oYY1iEr9D+K4o9eXD2uTrv7IIGJsolidtDLKentZ 4Eo1FwYl40RfveOLtqQ32zin4KxA2txLWf91QlRFDhjsdzxmoraGjAUwePJ5A4bnY9f0YfRO
Archived-At: <>
Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Mar 2020 14:55:48 -0000

Hi Bob,

> On Mar 17, 2020, at 02:12, Bob Briscoe <> wrote:
> Sebastian
> On 10/03/2020 10:07, Ingemar Johansson S 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.
>> 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.
>> /Ingemar
>>> -----Original Message-----
>>> From: Sebastian Moeller <>
>>> Sent: den 10 mars 2020 10:45
>>> To: Ingemar Johansson S
>>> <>
>>> Cc:; Ingemar Johansson S
>>> <>;
>>> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
>>> Hi Ingemar,
>>> thanks for posting this interesting piece of data!
> [BB] Yes, thanks, @Ingemar...
>>>> On Mar 10, 2020, at 09:02, Ingemar Johansson S
>>> <> 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
>>>> ad93e2a-489fa99c3277fb8a&q=1&e=5aab95a7-4aab-4a64-99a5-
>>> 5b55606e303b&u=
>>>> 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?
> [BB] This does seem more harsh than I would have imagined - so a useful data point; thx Ingemar. Nonetheless, this is the end-system taking bandwidth away from itself in order to give itself lower latency in the presence of varying network capacity. Nothing to stop other applications making different tradeoffs.
> It is worth thinking about the complexity of the policy control and signalling system needed for Ingemar's video to express the tradeoffs it is making here;... if it had to get an FQ scheduler to allow these tradeoffs instead. The scheduler would not necessarily have to make all the tradeoffs itself - for instance the app could underutilize it's 'fair' share, but it would need to be able to take more than its 'fair' share during periods of lower capacity.

	[SM] I fail to see it that way, in Codel for example, it is the burst tolerance that allows exactly that kind of bandwidth trading with one self (send more now, make up for it a bit later by sending less). In fq_codel it is the FQ component that decides when a flow/bucket/tin is eligible to send something, and inside each flow/bucket/tin is a codel instance that decides what/when to mark/drop. But as Ingemar's example shows, his application gets significantly more bandwidth with Codel than with L4S, it would be interesting to see a plot of video quality (measured at the receiver). Any thing longer than a "burst" will get into tricky accounting territory if one wants to actually enforce long-term adherence to a set bandwidth share.

> In the list of SCE issues,
> it says "Another argument is the perception that FQ can do harm to periodic bursty flows, however we have not yet shown this to be the case with hard evidence". I don't recognize that argument, but I would if it had said "...can do harm to flows needing variable throughput or smooth throughput in the presence of variable available capacity". If Ingemar had run a TCP flow in parallel here, I think that would go some way towards the hard evidence sought here?

	[SM] Only if we assume that the video stream would be more important to the link's user, what if the TCP flow's speedy completion would actually be more important to the user? 
	That is, to be blunt, where I believe you fail to see the forrest for the trees, the AQM has no chance of being able to optimally split bandwidth between eligible flows without additional information to base its optimization upon. So either you supply that information (say explicit DSCP marking within a well-managed DSCP-domain) or you ned to accept that all you can do is aim for good enough and "do no harm". 
IMHO FQ strikes a decent balance here, it might rarely be optimal, but it also is equally rarely pessimal (while any unequal sharing mechanism will result in optimal and pessimal sharing, depending on whom you ask). In addition FQ allows much simpler prediction of what to expect from a link und saturating load. 
Of course this is just an opinion, and everybody here is entitled to their own opinion on this matter...

Best Regards

> Bob
>>> 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
>>>> 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
>>>>   Reality, is the only thing… That’s real!
>>>>       James Halliday, Ready Player One
>>>> =================================
> -- 
> ________________________________________________________________
> Bob Briscoe