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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 17 March 2020 10:38 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 580DC3A1C91 for <tsvwg@ietfa.amsl.com>; Tue, 17 Mar 2020 03:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.564
X-Spam-Level:
X-Spam-Status: No, score=-3.564 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, RCVD_IN_MSPIKE_H2=-1.463, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 hcQwjlqF_rLh for <tsvwg@ietfa.amsl.com>; Tue, 17 Mar 2020 03:38:42 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70047.outbound.protection.outlook.com [40.107.7.47]) (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 1571D3A1C8D for <tsvwg@ietf.org>; Tue, 17 Mar 2020 03:38:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqOBoK1SZLX8fdJdh3ZXUhpIo1oeO/Yk7fi4rI9+UHz+ZCQYcTqFSfpHIYje/i4QbGfdZSWP4tByzWFXzWGHJcPuBqxErS+kaDNqWJy7x6r6s0jSkJ1QIP0osgnn8MUEe/gmzYNygBGtzTJbeQ0tIHaOqFCjBWvnzX8qETVQRkYOt9bJBg/A8aYo9X3AKLpB9H5mwrpxF1nyluIgS8oI46tZhUW5hJO5nysJWudyV3mlm0nwKw5Xx8AUr14F5AlmV5QXsWe6UtNUL9g1lo+oVn3VfKr3wEXlZj7p+z6XbVtJBhJjr8EFf6iucYUXZzECGdvM2D+F/TW3pdUGkM/1lg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=/GLgoY5IrwPK99Sv/OZBVq+72HYH7aqOkQoqLuv//ow=; b=nvumF5ZsH1vGvcLCe0k/yk8W+t4CIRJAMWwwzwI+7o+fFJ3tYa+NdJlHUQuxAvxi68oJBzyul5tpj2/2yRMCOs4zylJAqsLn39aMChhV1nkWTuchMNzr6SY7On4PJQB+l/vpbDKWdhBnL+OJ67rsMWrtRKk9++ZvTgFbnScAI/8vvBpeetXEVHL1EHxjYKQIrKz5CI1cl3JzOFvqi4NiydUn8HSLTveVCqWrVNKsr6IuZRaRtMvyNVvJcdBkxRgaYmOnf12l/YLVUvWS+CJFhW7BlFls7KwXLSdxp/iSMTR+/MkQEEFTK/qh9pCpJOfpqfp2b4Zl74QIoIG4H58Heg==
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; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=/GLgoY5IrwPK99Sv/OZBVq+72HYH7aqOkQoqLuv//ow=; b=elwJI6N7aQBKsEK0yGNb0HrqEGH/djqqAakQ7O7At1UNQU/71bTdd00Y54TiGWUPAazEesNLUNiOiuN3NNhS9Rs75225V4IH/vslq6DgNwoq6EPNmwLi6lyYltkfjvNvt+CX4dApB7jsJBO+K4VIfTVAE5vUuIAJyj5FHNLtAwI=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.11; Tue, 17 Mar 2020 10:38:39 +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 10:38:39 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Jonathan Morton <chromatix99@gmail.com>
CC: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, Sebastian Moeller <moeller0@gmx.de>, "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: AdX2sUQTt8TR64exRw6bAaEpFrsNEgAD11cAAACWSIAAAOWNgAAD4iVQAAalBwAACxURwAE9jDUAAAUUToAAAxBeAAAFA2wQ
Date: Tue, 17 Mar 2020 10:38:39 +0000
Message-ID: <HE1PR07MB44257FE612E53D99CEF3D2BCC2F60@HE1PR07MB4425.eurprd07.prod.outlook.com>
References: <HE1PR07MB44251B019947CDB6602B30B2C2FF0@HE1PR07MB4425.eurprd07.prod.outlook.com><A2300F8D-5F87-461E-AD94-8D7B22A6CDF3@gmx.de> <HE1PR07MB4425B105AFF56D1566164900C2FF0@HE1PR07MB4425.eurprd07.prod.outlook.com> <1C969A05-A4B7-43E9-B694-3195A2FC086A@gmx.de> <HE1PR07MB44255CED94938F9C38515FD6C2FF0@HE1PR07MB4425.eurprd07.prod.outlook.com><AC10E219-46C2-4345-B98F-71689F788B13@gmx.de> <HE1PR07MB4425AA2A7976C1CCF594D3B2C2FF0@HE1PR07MB4425.eurprd07.prod.outlook.com><9C8E93A1-1C72-4CD4-8EB5-438AB2F2FF8D@gmail.com> <HE1PR07MB44253C9941C7E6F1011615F5C2F60@HE1PR07MB4425.eurprd07.prod.outlook.com> <03AAF752-ADA9-44CC-9DAD-CE59F3AFC453@gmail.com>
In-Reply-To: <03AAF752-ADA9-44CC-9DAD-CE59F3AFC453@gmail.com>
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: 569bb412-b536-47dc-136d-08d7ca5f5af2
x-ms-traffictypediagnostic: HE1PR07MB3242:|HE1PR07MB3242:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB3242399F4DCA2FDDCB619326C2F60@HE1PR07MB3242.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2089;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6029001)(4636009)(366004)(39860400002)(376002)(396003)(136003)(346002)(199004)(81166006)(81156014)(86362001)(6916009)(5660300002)(4326008)(8936002)(55016002)(8676002)(107886003)(9686003)(7696005)(316002)(71200400001)(52536014)(54906003)(66574012)(478600001)(186003)(2906002)(66946007)(53546011)(66556008)(66616009)(66446008)(76116006)(6506007)(26005)(33656002)(64756008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3242; 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: bghSwo1yFWDZGurJDDSKR5WLQiXi89F/o3uWGdYT4iBc/f88dQCOS1Y/rDSGO9mCxoPQrq7QDppM6uwoWI4tf9R/P2c+a28CIzFC6TFnNR+pZeyy5ziCjkSkJkpbd407QQnPBuP36tEu1sG06XXSmIM9zLVPGy/wKuULNKeswjbdBX2wnAFAZ5J7syzEWWGnfErpAqJeCBvGEclqxxkJQxnq/oWnJlOVwkWZZFtIjPozOtvszCSK4U3d5T82cLrxWrjW+QRmQ2UmojOniF5q9cK5b8dmHgA+liZWQ/QIWtnvhs9SaVeU3ubtMCSCDbCWwDYAL+J4SoiRs8Y/WzryUs8UIe40VNeHlIt9pJcLAetVVWvx5jUAES2VEa7/BYdeMGvoSHmGKC3FfvPbI2DycsZU68Npdq28XGgBS5mhM1SJApcpb0w01jCiRwak4QRH
x-ms-exchange-antispam-messagedata: 3qkJUngKQL9XVbJT4MtFm19/72bUe2t6+IS/TCeqAty0D3l5QKCKGUGikS9Qk4j+KlpfSeFVBORKgNZ4i40y+H0/XeG619xN9Jfh8rFVdptmrQFkoBbb2FsjuHMnZUSp9+Jt7q3tMR2X3L15/R8NqQ==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_053C_01D5FC50.992527F0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 569bb412-b536-47dc-136d-08d7ca5f5af2
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 10:38:39.0933 (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: xnl7dkEyg5MZZyIpZMEk9pWLcmweK1tpMFGpayrPO0VAvwzD4v1zccpxSCzFWt3szsvgpudO/G8UWWEvf4i0ELx1JUDc+GNBVKlXEk5ubta6MBg9tUSfMrTO8ctP+MLU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3242
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CzgjqA0Q2rjPLoYmftrCBe4_wSc>
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 10:38:45 -0000

Hi
Inline..
Ingemar

> -----Original Message-----
> From: Jonathan Morton <chromatix99@gmail.com>
> Sent: den 17 mars 2020 09:12
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> Cc: Ingemar Johansson S
> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; Sebastian Moeller
> <moeller0@gmx.de>; iccrg@irtf.org; tsvwg@ietf.org
> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
> 
> > On 17 Mar, 2020, at 9:02 am, Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com> wrote:
> >
> > The frame rate in this example is 60fps, which means a 16.6ms frame
> > interval. I am not convinced though that the frame rate plays so much
> > role here as the packet pacing make these 16.6ms frames become
> > transmitted in ~10ms or so (depends in the computed pacing rate in
> > SCReAM)
> 
> Hmm, takes 10ms to transmit the frame, results in 10ms peak queuing latency,
> on a 20ms baseline path.  Seems like an awfully big coincidence to me.  All joking
> aside…
[IJ] ~10ms means roughly 10ms, could be 11.23342344354654667ms or 13.23423434423ms or 9.23423432434234ms ......

> 
> > Yes, possible that it may be as you say, but doesn't this reveal a
> > flaw in CoDel if you need to adapt thresholds based on assumptions on
> > application layer behavior?
> 
> No, because that's not what we're making assumptions about when choosing
> Codel parameters.  It just so happens that your baseline path RTT and framerate
> are conveniently similar, but the typical path RTT is what Codel is supposed to be
> tuned for.  The default parameters, with a 100ms interval, are intended for use
> on general Internet paths with conventional AIMD traffic.
> 
> The 25/2.5ms parameters are what we are already using for high-fidelity
> congestion control in much of our SCE testing.  They are not tuned for your
> particular application.  I'm just curious how it would react, with the L4S-type
> response, if given that style of signalling.  No code changes are needed to try
> this out.
> 
> > I cannot for instance rule out that somebody in the future (or perhaps
> > already now?) implements a gaming engine that updates part of the view
> > with 240fps and other, less important parts with 30fps. QUIC would
> > allow all that media over one connection but in different streams. For
> > the network it would just be a bunch of packets passing through.
> 
> I imagine such a stream would have more frequent cycling and relatively smaller
> peaks of traffic.  This would make the problem slightly easier, not harder, from a
> queuing point of view.
> 
> > I don't see that it is worth spending effort on this as it should be apparent by
> now that SCE would not give better performance than L4S.
> 
> 
> When the traffic is not bursty and does not exhibit a significant sawtooth
> structure, the difference between controlling the peak or the trough of the
> traffic is minor.  However, SCReAM presently does not fit that description.
> 
> To a great extent, L4S' aggressive marking strategy ends up controlling the
> peaks of the traffic, while Codel tends to control the troughs.  When applied to
> SCReAM traffic, the latter results in noticeably higher throughput - which I
> presume corresponds to better image quality - than the former.  It does do while
> still controlling the added delay to less than one frame time, except during the
> exceptional event of the sharp reduction in capacity.
> 
> SCE is designed to be safe to use over existing Internet paths.  L4S, as presently
> implemented, is not.  That's a point which might not show up on a raw
> performance comparison, in which traffic is run only through nodes which fully
> implement the new specification.  It is of course possible to employ L4S'
> aggressive signalling schedule using the SCE method.  This gets you the same
> performance as L4S on a conforming network, but also keeps you compatible
> with conventional networks by retaining the standard meaning of a CE mark.
> 
> So I'm not certain what metrics you're using which say L4S outperforms SCE
> here, but since we are using Codel for SCE marking, I'd say the above
> characteristics are at least worthy of further study.  Of course I can't insist on it,
> but I think it would save some time and effort in the long run.
> 
> Separately, I also think that if you were to make the pacing rate and target
> encoding rate more similar (as the encoder seems to track the latter pretty
> closely), that would improve SCReAM's performance on both L4S and SCE - for
> different reasons.  Both stem from the fact that your data-in-flight number
> currently fluctuates a lot on short timescales, and on average is much less than
> the cwnd.
> 
> In the case of L4S, you would get a straightforward increase in throughput and
> thus image quality from what you presently have.
> 
> In the case of Codel-based marking, there would be less noise in the queue-
> depth signal, resulting in a better estimate of the true BDP being represented in
> the cwnd, and better control of the network side of the delay equation. As I
> understand it, SCReAM is designed so that data still in the application-side buffer
> can be discarded to accelerate recovery when network conditions abruptly
> change, and this would facilitate that.  The result should be roughly equal
> throughput but improved delay characteristics.
> 
> But until it's tested, those are just my educated guesses.  I think SCReAM-like
> traffic would be a valuable addition to our test suite, but it will take time to
> figure out how to integrate it - since it's written in a different language than we
> normally use.
[IJ] Please go ahead and experiment with SCReAM and SCE if you feel it's worth it. Personally I will not waste my precious brain cycles on SCE.

> 
>  - Jonathan Morton