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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 17 March 2020 13:45 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
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 22FB23A0772 for <tsvwg@ietfa.amsl.com>; Tue, 17 Mar 2020 06:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 KlLg8iJ1Zmlr for <tsvwg@ietfa.amsl.com>; Tue, 17 Mar 2020 06:44:59 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70073.outbound.protection.outlook.com [40.107.7.73]) (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 59D943A0770 for <tsvwg@ietf.org>; Tue, 17 Mar 2020 06:44:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DWUpXiUIklK889dj0fg28l3gx6t6PuK3JWyO86gx4FfJsLV1bzl3/T1PuJpHLq?= =?utf-8?q?5+YVCc2/EVqBEMwOrNMMYNaj1urUgH2ptCuM1RUUMpgzsgL++d4g9fQn7m5lpa+Q4?= =?utf-8?q?6tcMQEjsc5F9RXzKhGXhZPR2MLA2c5sk30MCOFk4A3JHcwugHFb76TPJHqvF/PZCW?= =?utf-8?q?fxulhKSr1X5C1QV5ro1vn6p2z1Xoa5oQo+eOHWv93qxxjEyRZ1FLiiWuxQ6BJqjUf?= =?utf-8?q?er1RngUPH5YkjIYmHijVtlyqyytFcvSMqZ4V+ialk1bF6SYKraiNyAgDbTlQWQeel?= =?utf-8?q?1f/L8Zn+tDtbEo0/nYdZw=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DGyLqQyX2Yir7jumfP4WWz3lOVC01vEGG4XoGRAIVveg=3D=3B_b=3DTwF2Ga?= =?utf-8?q?j9KZA8AakwhNxV54ZS1qchi6oSDMekR+asSgZAYC4lVqOcbloO+6IbKRrTaZ09KjC?= =?utf-8?q?lvWVCQJizGeBovBjE+3I0i4jHByGebxYShkk/588tEJcvPAX0/DM8w6cmfDJknaFK?= =?utf-8?q?VmvrKYr/qwZPcxJNpOBqDPANSvPG3dvIhwSHWxcYWVF+gVvnjmUeetRM22F37DebJ?= =?utf-8?q?XFRSQV4OpcMtw2ZqukGjg+s8Kz1idSexdiFBsvyUWmTv3c2zr/Psi1B80aBHD+FVG?= =?utf-8?q?WDb7KhFVBcgb4QCJ4GAsRbzkTz4aJZzr/Wusfw5s/xFJYvDsA3eoLMl+Gd8kK3w6z?= =?utf-8?q?ZgcPFP3eZFA=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DGyLqQyX2Yir7jumfP4WWz3lOVC01vEGG4XoGRAIVveg=3D=3B_b=3DojsffE?= =?utf-8?q?FaRZOb6urScQGY4qjsJ1LUomdcCxdgh/VTOXML06gDil+/MiaxHNaoZaCxpmKtWAn?= =?utf-8?q?S65H11WlFLR9YGtsLUdVpy5DvNy5nFJNwDHxKs1wb8ZeDgb0H8rGrBUzZCqlFmGm7?= =?utf-8?q?OaQyKlepHAaQcXf01Zl99ZrnoT4E4BKYCCM=3D?=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB4316.eurprd07.prod.outlook.com (20.176.168.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.12; Tue, 17 Mar 2020 13:44:56 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::e80a:dc35:1cef:7cb9]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::e80a:dc35:1cef:7cb9%7]) with mapi id 15.20.2835.013; Tue, 17 Mar 2020 13:44:56 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Sebastian Moeller <moeller0@gmx.de>, Bob Briscoe <in@bobbriscoe.net>
CC: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
Thread-Index: =?utf-8?q?AdX2sUQTt8TR64exRw6bAaEpFrsNEgAD11cAAACWSIAAAOWNgAAD?= =?utf-8?q?4iVQAAalBwAACxURwAE3vTiAABiNKgAAAOm+YA=3D=3D?=
Date: Tue, 17 Mar 2020 13:44:56 +0000
Message-ID: =?utf-8?q?=3CHE1PR07MB4425459CBC6C816443661A65C2F60=40HE1PR07MB4?= =?utf-8?q?425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
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> <444DC935-62CF-4646-9F4B-269D861EE85A@gmx.de>
In-Reply-To: <444DC935-62CF-4646-9F4B-269D861EE85A@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 08aaaa92-9ade-40d4-f48b-08d7ca79611a
x-ms-traffictypediagnostic: HE1PR07MB4316:|HE1PR07MB4316:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CHE1PR07MB431691E7D3559C2C034FBB50C2F?= =?utf-8?q?60=40HE1PR07MB4316=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:3383;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=286029?= =?utf-8?b?MDAxKSg0NjM2MDA5KSgzOTg2MDQwMDAwMikoMzQ2MDAyKSgzOTYwMDMpKDM2?= =?utf-8?b?NjAwNCkoMTM2MDAzKSgzNzYwMDIpKDE5OTAwNCkoODExNTYwMTQpKDMwODY0?= =?utf-8?b?MDAzKSg1NTAxNjAwMikoODY3NjAwMikoODExNjYwMDYpKDg2MzYyMDAxKSgz?= =?utf-8?q?16002=29=28107886003=29=2826005=29=2871200400001=29=288936002=29?= =?utf-8?q?=28966005=29=28478600001=29=289686003=29=282906002=29=28566030000?= =?utf-8?b?MikoNDMyNjAwOCkoNTI1MzYwMTQpKDE4NjAwMykoNzY5NjAwNSkoNjY0NDYwMDgp?= =?utf-8?q?=2864756008=29=28110136005=29=2815974865002=29=2866616009=29=2866?= =?utf-8?q?476007=29=2866556008=29=2866946007=29=2854906003=29=2866574012=29?= =?utf-8?q?=2853546011=29=286506007=29=2833656002=29=2876116006=29=283367550?= =?utf-8?q?03=29=2818886065003=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4316; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?btouAHlU4v51b4Wmwi6oVn+t4+zafqp?= =?utf-8?q?ksP5Axu8malc2yF6S8n3EXMuo+ojjoKC3AaVFhW2xlaThMcafnKsSFRLEA0NUaVMZ?= =?utf-8?q?jIHGB5zbo8oTo7SB+NEFx7g6Rw8d3ptdJeUZCitWXnMXSqT/4CpykKIs/qjGs3eKK?= =?utf-8?q?MgYh/w2xbSNsqWLf+FcXGw9J/UqrdxOzLQOs7nMTBU+BjZKiM/y6MJW4XKjL6oMD/?= =?utf-8?q?yr8TivoONNqlteYJA+hjAYPCJHaj9PZj2Q+TuyPD+ekBf4gs5EqjW7R5LoReLMZgL?= =?utf-8?q?rFOqM4WaekYCF99evw+NKcCJZKbObfiVouKpJoocIPGRDFya1hPsmz6qznA8HS1oc?= =?utf-8?q?0agVlGCavcCk10iC/GJQ8AERmj1vUuEcbdCT5c6Onlt2fkIfdlPIDeoj8YREPTmEz?= =?utf-8?q?fib0utopbgJsrbgg9L5E1pMGz70XXP97wGdePdJFeap7XyflXKKy1zQtXImFeMLNk?= =?utf-8?q?0Dq8kMJEC0USZbVmbg87BeynbYEXJaIWxUoK5mhBRIOH5YytJQY9xcSkipHNSKAVQ?= =?utf-8?q?TP7k7kasfCvuGdv8e4WAhrpcW4YpBzJ+fMBpcte+kzAaSge7sEijL/eTXJVUXnEaI?= =?utf-8?q?u8A=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?fmOTqYZApCuBTUPpftRuxNsRpd93nx?= =?utf-8?q?p9lEXdyeJhVsQb2GI6PA8AxakYjJT/YiUITy5eRoE0GvyzLkrPiY5wehYNdliWKe+?= =?utf-8?q?P2zAbdIvD8Fs3Fb6h/2yzoY3KU1xJcRvnWmzUCK2Otm5/PXus+BPvqg=3D=3D?=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0672_01D5FC6A.9F4BDE20"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 08aaaa92-9ade-40d4-f48b-08d7ca79611a
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 13:44:56.3955 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?dOtqCP06TlaDwg71792R9?= =?utf-8?q?G01SSyhaZxja6rchL4xhr+V8nOFeMOq9m5SSeOEd2VPgRyq80xAxJaeVhQNszS46D?= =?utf-8?q?wyKmNiEnri0TPDIAvK0VFWHMiHPe8ZC+No0KdS6prx?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4316
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/oRJFvfXWeZDTtP8CVVfoM8yNFgw>
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 13:45:06 -0000

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

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