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

Jonathan Morton <chromatix99@gmail.com> Tue, 17 March 2020 08:12 UTC

Return-Path: <chromatix99@gmail.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 6E1E93A1A8B for <tsvwg@ietfa.amsl.com>; Tue, 17 Mar 2020 01:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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=gmail.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 Gn3gBWuN-Gdc for <tsvwg@ietfa.amsl.com>; Tue, 17 Mar 2020 01:12:20 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 3AC6E3A1A87 for <tsvwg@ietf.org>; Tue, 17 Mar 2020 01:12:20 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id f10so21706386ljn.6 for <tsvwg@ietf.org>; Tue, 17 Mar 2020 01:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u31twwClSyf9/7DR/wQZB2npUkROnmcYZHAXHTgT2ik=; b=ETA+eyCI9VFy9AQo+1hdfG+X0TIk0IE9Y6tSRpngPFTTJya3UeMI5MfF8lEo47gHfm UxxvmaD3/M/MYa+ewuzJR81LZnAcaQzOgrMQHhCjiB+kb6+scfRCpeioTTLzbMk1EnBt uJe5oqoOFHwWcgXBjc8WQoA6ho/gZWVwXET45xJ5gbnRWck8acCKa3hYpPq10sgKK0RY 3x0g2m0m1k/seIh1rQIm7l6b1wF8MOK+Jpq8xH4TDg/P7vkPx2PmSNA1AmOde0YkzGVG i21vbwUu18SFvKxtI2StiMxaPn91VaCYO6MRkfhYJi53tBRXsobDlLmFi/7pnTz+vswf uAWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u31twwClSyf9/7DR/wQZB2npUkROnmcYZHAXHTgT2ik=; b=RlE20qVfyovJbJE2djwudwETrSaV39qMkf1Fp1D1D5lxD7UY3++jK7CvKgzrRJpEUx ij23s7gFSBqhP5VtG6WD8FJuLbkafi7IMkWb9mX7hOpJdH7itz8tHnFRNPZtPW8PRjIf 0Vje5tDgW1BPQjovi++eHa/2gonJ6/LKW7FoMzRp+sBItDK4w/bJfMauy0quM6K9pHRF RFyRRB2tQGsdTtgEh44cYCb8cD5xZbj+hMGVPGJjObRFQMQxfKLsU3VrW9X8oWfYgqh3 q1MFWsACUf5sU4FCWS2KOuamvV1bWJVu+3SebjAUPp+D2yIeGLMF12EoNs4lPq+TpdOx hN2g==
X-Gm-Message-State: ANhLgQ24LYdW/nb6vz2WjQucin5CbXwSit3PB90AeIll3Ul4kjdvoEcI /SoSVkK4AQ/9B8ys2rusNpI=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuMAPWaacG0w98O1H5d9XTVUUd1cZ/lRrtmbtGX?= =?utf-8?q?ENiF0JRPuBtsI861hwAVNDraCKKdBGCQMA=3D=3D?=
X-Received: by 2002:a2e:8994:: with SMTP id c20mr1919843lji.263.1584432738162; Tue, 17 Mar 2020 01:12:18 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-250-250-nat-p.elisa-mobile.fi. [83.245.250.250]) by smtp.gmail.com with ESMTPSA id e8sm1684725ljj.67.2020.03.17.01.12.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2020 01:12:17 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: =?utf-8?q?=3CHE1PR07MB44253C9941C7E6F1011615F5C2F60=40HE1PR07MB?= =?utf-8?q?4425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Tue, 17 Mar 2020 10:12:16 +0200
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <03AAF752-ADA9-44CC-9DAD-CE59F3AFC453@gmail.com>
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?= =?utf-8?q?=3C9C8E93A1-1C72-4CD4-8EB5-438AB2F2FF8D=40gmail=2Ecom=3E_=3CHE1PR?= =?utf-8?q?07MB44253C9941C7E6F1011615F5C2F60=40HE1PR07MB4425=2Eeurprd07=2Epr?= =?utf-8?q?od=2Eoutlook=2Ecom=3E?=
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-IJnBjVDtAPZ-4IQerZHVKPK-JU>
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 08:12:23 -0000

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

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

 - Jonathan Morton