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

Sebastian Moeller <moeller0@gmx.de> Tue, 17 March 2020 14:40 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 5B3AE3A085C; Tue, 17 Mar 2020 07:40:45 -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 cej9wbdbBuL6; Tue, 17 Mar 2020 07:40:43 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B753A085A; Tue, 17 Mar 2020 07:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584455991; bh=9ZLq6OiPZRGWF3/XDg4EAWQZ0ori+m/zw6jxjDu3fPs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=XkBGIsbZDJwoXlPb9nEVWC95MnUyaNtDCcWUCFpbmPe85Jie7SF431+SNCsUY9Vqf VqEwDBF9SPh1Nxf2zdCWQ5yBVf6YNKXS7iSoI52OreVZT2ELRRwpVbPobs76/AskKU Wrx3wWatB7GwoLLlYy4aLx066j9u+gwOY/3bEJZk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.22] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mq2jC-1jabxM3q8A-00nBlU; Tue, 17 Mar 2020 15:39:50 +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?=3CHE1PR07MB4425459CBC6C816443661A65C2F60=40HE1PR07MB?= =?utf-8?q?4425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Tue, 17 Mar 2020 15:39:48 +0100
Cc: Bob Briscoe <in@bobbriscoe.net>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <58D1892C-8430-445B-9C8A-6ADD11181347@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?= <1C969A05-A4B7-43E9-B694-3195A2FC086A@gmx.de> =?utf-8?q?=3CHE1PR07MB44255CED94938F9C38515FD6C2FF0=40HE1PR07MB4425=2Eeurpr?= =?utf-8?q?d07=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CAC10E219-46C2-4345-B98F-71689F788B13=40gmx=2Ede=3E_=3CHE1PR07M?= =?utf-8?q?B4425AA2A7976C1CCF594D3B2C2FF0=40HE1PR07MB4425=2Eeurprd07=2Eprod?= =?utf-8?q?=2Eoutlook=2Ecom=3E?= <efb20cca-ccee-1d74-3f95-a287e53049b8@bobbriscoe.net> =?utf-8?q?=3C444DC935-62CF-4646-9F4B-269D861EE85A=40gmx=2Ede=3E_=3CHE1PR07M?= =?utf-8?q?B4425459CBC6C816443661A65C2F60=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:k8hXctC6QocJWBp/YtDlbIaiyAxBw7qJYJQvzOR2MIXCQRoNVgn 69/eQMXt4zdjFO7KT/wblNFW9wH0xu31SX2oyGVA7d8a2OsZxO+PaZibYjWxBm9R6CyriB5 3grqBsmNGD1k9nth+AKPRnUibYvBAv30nMFVh8iONaGmSH2W9CGgxFShSKRAELGnnzlBCaI /epelLBH4nmAJgk7uv9Kw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:KXu6ncOg0RE=:vbIjTvTS1m5/AQ1Xm8/Yyk AGHSdsW0SPpiMA1Egc+r+rzujuRc/ng8RXtuOfIwJV4FVdwNSWl98NIKwqnim334RjRy7dmgn f9my9FmoCUr4FVGoHjLaDPLpcfzy9A8WXZ7W63A4dZGBuSpKmxwxWr6t4lWcBc49LWyIXzLBu IMUeU55poPNO+2PERGxjzbZyt+VkSkZ8ZNm5WyM7oKj7xkAx2DRzGIrQe56/uBhRl1VW053v9 CydBDzzzsPkmnQT6w3dm2X/KjxNnnQ8AmmUU4FVwfbvJ29DmbHNdQ3vh2qwHuGy6BuKz16f2v +P9fVOxlxP6t94r/vnYV0AS9DoZ3PNuL8xWk/Mlx7HBo0y0sglkwc4PtvCo3P/aK6maeRemGF i3u/ncvQBU52u/fWjuHCNjwXSwkzB51dhkDl0F4u6gi+gMELbdYN1CRkHPyH3LYQEW0zvAPg1 UkfKpZyJd4qPLKRQAafH5X4bMzt4fEiLn+XSZdtRhqJXWpaoPvGYnJKPeQ8OCmoanXv6jpvqH LV/j93AQa1bRQhGhn9rIaqfTHJvNKZtpCGVlgALZtA7/BchiTnOvxno5HfixA9qpnkg20Z/t4 tyl0zdrdchYn4cD+kfpDoNkqz4ZNkV1ndW1lHZH5K8nYJzqGB4M5aThBYrGrrycwVC2jPnKKS Zh90k/nT1mTbxLvAwbJb4k450nfP3A8cojbnTsCl97DnV1BoftEiBQ04V/4OlEZQkMxnIt/+Q eqkRJeCLMvNUmcYLoAoym0lDZzUtAI9J1DpC+tAImJJ/fyLpukfsJitbAsRQcgQub9sFvSmbi m6+lHje718L97GAUlOF+lKtNWVrFVm83pjvlv1HyY6ma7Brx870m3jeMOF4zSVLmN0TOrqZQX Pqr5HPl6BeWVuk2FevNDTbjfGKK5yZyQ0RlNobiFSX8DaefPEUOb89Opac2PTci0u+MLsENSL OV+8e3Z1C4jNAM9+c3pJaNC2/966aJeG0VBjGI3J1VCVPiroIyhsJP9FSAg5F0k0n2fCr/5Ba SWX7AkfUE6xs8LCA9uJPiLBO8PTXynERGwmp55t3aSRjd21k2MQU/oNd+YDchfRpj/yOzBiVG Z1hvpO41W+adAZMlZVgltkVyalwIobMR/Xxvod7K4GCdI/3OTe0g0pK3qASCiFfYLYltxbzwG RKU5616MSKbphTlXUC69ZhAd8fVrCDOn0pkY227Dq4jVJprui9hjKDWfKc1YF/D9bSj5kqZIZ r7xXD0bSxFDVtYGOGI2wWKV91KRJBGg1nWFRNbMgqj7DPCsGfFuvzhCDK/3uTHLNtx7b7gvhz 2FKeb74JVhBSBFfd1OV2ppJ3ML/bPZr3Pmm/8fICSW9ObNc1/n+yCstbDmuJsx3DmZZ1Z8KN
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CofNclBqEhIeqDufAnuaIHvtJeM>
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, 17 Mar 2020 14:40:46 -0000

Hi Ingemar,

> On Mar 17, 2020, at 14:44, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> Hi
> 
> It is true that the "CoDel" implementation in the test code is a botched version. The CoDel algorithm implemented in our system simulator that was used to produce these examples is however _the_ CoDel

	[SM] Great! See, I was missing something ;)

Best Regards
	Sebastian


> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Sent: den 17 mars 2020 14:16
>> To: Bob Briscoe <in@bobbriscoe.net>
>> Cc: Ingemar Johansson S
>> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; Ingemar Johansson S
>> <ingemar.s.johansson@ericsson.com>; iccrg@irtf.org; tsvwg@ietf.org
>> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
>> 
>> Hi Bob,
>> 
>> 
>>> On Mar 17, 2020, at 02:32, Bob Briscoe <in@bobbriscoe.net> wrote:
>>> 
>>> Sebastian,
>>> 
>>> I suspect it is the 20ms interval that is the main cause the extra queuing delay
>> with CoDel.
>> 
>> 	[SM] That and the fact that rfc3168 asserts ECE until it receives the CWR
>> from the sender and that on Ingemar's test path takes 20ms, so the temporal
>> fifelity of rfc3168 ECN is simply too low for SCReAM's feed-back fidelity
>> requirements.
>> 
>> 
>>> 
>>> The 20:1 ratio between interval and target was really designed around loss.
>> 
>> 	[SM] I do not think that this actually makes a big difference for rfc3168
>> ECN, CE will be asserted just as a drop would be for NON-ECN packets, and it
>> will take a while for a drop being registered by the receiver and send back to the
>> sender as well. Note how the 5% rule has no bearing on that.
>> 
>>> The need to filter out brief excursions in the queue is only necessary when
>> you're using impairments (losses) as signals.
>> 
>> 	[SM] I disagree, (limited) burst tolerance is not only helpful if loss is
>> involved.
>> 
>> 
>>> If you're using explicit signals, you can signal unfiltered queue variations,
>> because there is no harm having higher ECN marking levels.
>> 
>> 	[SM] Sure, but I strongly believe the bigger issue here is that L4S CE
>> feedback simply has higher temporal fidelity not being limited by the 1RTT ECE-
>>> CWR dance.
>> 
>> 
>>> For that matter, you might as well use Eric Dumazet's simple patch to CoDel
>> that adds immediate ECN marking at a shallow threshold, bypassing all the
>> CoDel machinery, which is really tailored for loss.
>> 
>> 	[SM] Note how I asked Ingemar about whether he tested codel's
>> ce_threshold... But I am still wondering whether Ingemar's test where done with
>> SCReAM's own limited Codel implementation or with a full fledged Linux AQM
>> node in the path (looking at the SCReAM repository makes me believe its own
>> Codel being very vrudimentary and not implementing ce_threshold and as it
>> appears not even the square law drop interval calculation, @Ingemar, I am sure
>> I am reading something wrong here, so please help me see what I am missing*).
>> 
>> 
>> *) I am 99.999% sure I am missing something ;)
>> 
>>> 
>>> Of course, unless you have FQ (which you can't at the RLC layer)
>> 
>> 	[SM] Then use feedback the queueing information from the RLC layer
>> back up to where at least IP packets are handled/seen, akin to say the wifi
>> airtime fairness approach?
>> 
>>> , you would have to work out some other way to ensure coexistence with
>> existing congestion controls. That is left as an exercise for the reader - I
>> wouldn't want to be seen to be pushing any particular solution. But hopefully,
>> through scenarios like this, you might start to understand the set of
>> requirements that led to one solution rather than another.
>> 
>> 	[SM] Well, I believe that neither 1/p type signaling, nor higer temporal
>> feed-back fidelity are really under discussion, we all want those, the question is
>> more what is the best and safest/backward compatiblest way of using those, but
>> I digress (this is not the thread for that discussion ;) )
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>>> 
>>> 
>>> Bob
>>> 
>>> On 10/03/2020 21:04, Ingemar Johansson S wrote:
>>>> Hi
>>>> Attached is a simulation of the same simple bottleneck case with target=1ms
>> and interval=20ms.
>>>> Two ECN beta values : 0.8 and 0.6. A larger backoff (0.6) does actually not
>> improve things as the CWND reduction leads to that packets from the video
>> coder are queued up in the RTP queue.
>>>> As you can see there is still a way to go to reach the L4S delays.
>>>> 
>>>> Perhaps the SCReAM's response to CoDel - ECN marks can be optimized
>> further, don't know, but I already spent a considerable time to try and get where
>> the code is now, and I spent a lot more time on this than I spent on the response
>> to the L4S signal.
>>>> My impression is that it is the fractional congestion signal with L4S
>>>> that makes it easier to get a good algorithm behavior (and I
>>>> definitely believe that there is room for improvement)
>>>> 
>>>> And as said earlier, the SCReAM code is freely available to experiment with
>> and occasionally it is quite fun
>> (https://www.youtube.com/watch?v=eU1crtEvMv4 ).
>>>> 
>>>> 
>>>> /Ingemar
>>>> 
>>>>> -----Original Message-----
>>>>> From: Sebastian Moeller <moeller0@gmx.de>
>>>>> Sent: den 10 mars 2020 16:29
>>>>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
>>>>> Cc: Ingemar Johansson S
>>>>> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; tsvwg@ietf.org;
>>>>> iccrg@irtf.org
>>>>> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
>>>>> 
>>>>> Hi Ingemar,
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Mar 10, 2020, at 13:37, Ingemar Johansson S
>>>>> <ingemar.s.johansson@ericsson.com> wrote:
>>>>>> Hi
>>>>>> 
>>>>>> The SCReAM code is freely available on
>>>>> https://protect2.fireeye.com/v1/url?k=3fa4aff0-6370a99d-3fa4ef6b-
>>>>> 867011091b6c-c4d35656f5c9b268&q=1&e=16e2b451-36c7-4814-af9d-
>>>>> 
>> 4acb21ac792b&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream
>>>>> for anybody interested to run their own experiment with whatever
>>>>> AQM/ECN configuration.
>>>>> 
>>>>> 	[SM] Well, if you are not interested in figuring out what is
>>>>> happening with with rfc3168 ECN ans SCReAM that is your prerogative...
>>>>> 
>>>>> 
>>>>>> Please note that SCReAM is configured in an L4S mode when the
>>>>>> network AQM does L4S marking (mimicking ECT(1)). For CoDel-ECN
>>>>>> however, SCReAM runs in normal ECN mode with a beta of 0.8 (=20%
>>>>>> reduction on CWND for each congestion event)
>>>>> 	[SM] Okay, that is a far cry from Reno's 50% though, have you
>>>>> tested different reduction percentages or how did you arrive at 20%?
>>>>> But is it really 0.8? ScreamTx.h has the following:
>>>>> 
>>>>> // CWND scale factor upon ECN-CE event static const float kEcnCeBeta
>>>>> = 0.9f;
>>>>> 
>>>>> I am probably missing something somewhere...
>>>>> 
>>>>>> I tried also with other different ramp markers (1ms/10ms),
>>>>> (2ms/10ms),(5ms/15ms).
>>>>> 
>>>>> 	[SM] That means for L4S, or do you mean you tried different values
>>>>> for Codel's target ans ce_threshold parameters?
>>>>> 
>>>>> 
>>>>>> There are slight variations  in throughput and latency but not dramatic.
>>>>> 	[SM] Well, these are also pretty slight variations in numerical
>>>>> values, at least if compared to codel's default interval of 100ms...
>>>>> 
>>>>>> And truth to be told, the ECN behavior is better tuned in the code
>>>>>> than the L4S
>>>>> behavior.
>>>>> 
>>>>> 	[SM] For a defintion of better that ignores that you seem to be
>>>>> much happier with the results L4S gives you.
>>>>> 
>>>>>> There is room for improvement as regards to the L4S behavior (for
>>>>>> instance
>>>>> faster ramp-up) and it may well be the case that SCReAM is
>>>>> completely scrapped in favor of new designs.
>>>>>> But the bottomline, the L4S thresholds and L4S code is not
>>>>>> carefully picked to
>>>>> show a good performance.
>>>>> 
>>>>> 	[SM] So, you tried different L4S parameters (and found the to have
>>>>> similar performance) but for rfc3168 ECN and Codel you only tried
>>>>> the default parameters?
>>>>> 
>>>>> Best Regards
>>>>> 	Sebastian
>>>>> 
>>>>>> /Ingemar
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Sebastian Moeller <moeller0@gmx.de>
>>>>>>> Sent: den 10 mars 2020 11:28
>>>>>>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
>>>>>>> Cc: Ingemar Johansson S
>>>>>>> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>;
>>>>>>> tsvwg@ietf.org; iccrg@irtf.org
>>>>>>> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
>>>>>>> 
>>>>>>> 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>; 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-6301ddb
>>>>>>>>>> c-0
>>>>>>>>>> cc
>>>>>>>>>> 47
>>>>>>>>>> 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
>>>>>>>>>> =================================
>>> 
>>> --
>>> 
>> ________________________________________________________________
>>> Bob Briscoe                               http://bobbriscoe.net/
>