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

Bob Briscoe <in@bobbriscoe.net> Tue, 17 March 2020 01:12 UTC

Return-Path: <in@bobbriscoe.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 9753E3A14D2 for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 18:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 UZpPFyZqaAYk for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 18:12:16 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 431DD3A14CF for <tsvwg@ietf.org>; Mon, 16 Mar 2020 18:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0LyGI292ow6YK89dJP4/PlZOG/OZURoeGdPw/SgBq4Y=; b=5oduoyjS9W6pzV7WDi08h96o8y zmCkG2i1jL1AdgG18SMiK1X2MCb//oR4affKBpYOTQvNCN4m8Bja4KXbJMbMq8wyE7KaZA5LVROfP lizADNnQChe6vfLzRPMVpgnkqcdO7pi2eC5iBELXn1EBy/O1So8HwQMqlHk6elnq4DyyNEIohCdKr utw9tRYKbHZ7+1U5mzs4yiy5k8LlmYcs1YADgETkot5jH/+hLJX2zdxY+jMlP5F5kqKS8N6Du4laX OtfnD2Xcqi6w9KpKfkAAzwDs5Vf1Xg1+8Jzc4g5uHQPZ2adZ99bzYKBUIifScKugleDrxbR4XS2Mn MoB79EGw==;
Received: from host-79-78-166-168.static.as9105.net ([79.78.166.168]:35388 helo=[192.168.2.5]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <in@bobbriscoe.net>) id 1jE0mD-008jie-P7; Tue, 17 Mar 2020 01:12:14 +0000
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, Sebastian Moeller <moeller0@gmx.de>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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?=
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <9e5ea80f-d709-e204-f08d-93d3479668aa@bobbriscoe.net>
Date: Tue, 17 Mar 2020 01:12:12 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: =?utf-8?q?=3CHE1PR07MB4425B105AFF56D1566164900C2FF0=40HE1PR07MB?= =?utf-8?q?4425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/fRlMVwhencS63HvYnoFnwRl7G1s>
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 01:12:20 -0000

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 <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!

[BB] Yes, thanks, @Ingemar...

>>
>>> 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-congestion-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?

[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.

In the list of SCE issues,
https://github.com/heistp/sce-l4s-bakeoff/blob/master/README.md#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?


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
>>> 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/