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

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

Return-Path: <chromatix99@gmail.com>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F2F3A173E for <iccrg@ietfa.amsl.com>; Mon, 16 Mar 2020 21:19:12 -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=ham 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 njw-Ba10QA5Y for <iccrg@ietfa.amsl.com>; Mon, 16 Mar 2020 21:19:11 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 CD2713A1740 for <iccrg@irtf.org>; Mon, 16 Mar 2020 21:19:10 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id t21so15977424lfe.9 for <iccrg@irtf.org>; Mon, 16 Mar 2020 21:19:10 -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=Fs6CprG80WyQFQj0zCP1kZGEgZNEuaY2AwhRcdkUOyo=; b=JQgyjjS/pibI3kR4Qj2ZkrnlOIT2LTpz+0E+NH0iQGkWn6pAJKA4XWSLkRuGA6yDn/ yX9912UUJgQxE65KLiAqyolPMk+OHwGVxrBxRSxxU4fA1z+FnXpHy8SnRTZxxczuYY2V jGJZIGe42ZRz+qpIIJ04iRQMJ9cXajC0x6nWtmYzgdihCGFohku2FvZOYI91IRnorWjq u2UJHgmaVji4zbdNKGfEiUfq8szwqQ3aDX3Sa4AVshZGbw/XNqm6v9DXEonYE5MTkgzR tbBAYxn+d9CIuHI5gxwb97aQwo8+8w4J075SXcgYAaBuQFd48SytcpK9s6t8C2zcDFCh /oRQ==
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=Fs6CprG80WyQFQj0zCP1kZGEgZNEuaY2AwhRcdkUOyo=; b=YwhuoEkxpZEDcFGbS6m3n+7BzXHyM87WtjVOmny4JR5+O7ECV/zr9+5WE/f3Gz3zl4 YLvr8OoPdfUQrFhH5HRbIOHe+AeuG3S50Hl2DPP/PxKImYmWW5iFzWIxQAE2DkVGyc0g ClC265HWax/Jqn608bLDfM+UJEByf8TmMKhPnpI/fwMMyOpCs95Tr1+cI7wL9dEQJp8A UXuvrFMbBIyVoQ0YgASL9+5QiUxsvAjExNH3PIuM06PiwJpjVdRB9ZXLr8wJkLRiMHJX PJj6LiWiCTHH31xbrDMElBlak7Yol8i/p3oPJJdXf+SaK1xfaEwg+JcjmvRJ0zUpGfSH jWzA==
X-Gm-Message-State: ANhLgQ2ndyVY0qSh+dVFOsG4+33G8JLSAGNsjHTchkKQGWnEiXGqTY4C sVEUb3ttzdg12Nqi4c8tTvU=
X-Google-Smtp-Source: ADFU+vuKyKDalvwrZJBa8c90MNrin28lQnmFpc9b9URHIvlvraD5F1SHFjP63jD3pf0kJoS+FubVDA==
X-Received: by 2002:a19:6716:: with SMTP id b22mr1586060lfc.46.1584418748865; Mon, 16 Mar 2020 21:19:08 -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 w9sm1375192lfk.4.2020.03.16.21.19.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2020 21:19:08 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <HE1PR07MB4425AA2A7976C1CCF594D3B2C2FF0@HE1PR07MB4425.eurprd07.prod.outlook.com>
Date: Tue, 17 Mar 2020 06:19:06 +0200
Cc: Sebastian Moeller <moeller0@gmx.de>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C8E93A1-1C72-4CD4-8EB5-438AB2F2FF8D@gmail.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>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/YnJi2S6PgGwIJ1mw3rRfR-TQqpI>
Subject: Re: [iccrg] [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2020 04:19:13 -0000

> On 10 Mar, 2020, at 11:04 pm, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> 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)

I had a look through this thread again, and I remembered something which may be very relevant to put these results into context.  I think you are making at least some of these tests with a 50fps video stream from a typical PAL-format camcorder, in which case the interval between frames is already 20ms.  The top of the delay graph in the tightened Codel traces is only 50ms, and in the originals is 100ms.

I estimate the queue delay in the tightened Codel traces is approximately 10ms most of the time - only half a frame.  Is this actually noticeable to the user?  Perhaps this performance is already good enough.

I think this level of delay mostly results from the behaviour of your pacing algorithm under bursty demand.  Codel deliberately tolerates a degree of burstiness, in the name of maintaining reasonable throughput on the networks and traffic patterns found in the real world.  As long as the queue empties below the target delay within the interval, Codel will not intervene - and at the tightened settings, the interval is approximately the same as the video framerate, which seems entirely appropriate.

Something you could try is to partially simulate an SCE deployment, by setting SCReAM into L4S mode and employing a Codel AQM set to, say, 25ms interval, 2.5ms target.  I think that might have interesting results.  This actually represents the SCE portion of an AQM optimised for a 100ms path, but it's a configuration that's quite well tested and should cope well with a bursty traffic load.  There are some differences between the L4S response algorithm and the ones we use in SCE, but I think you should get good results with this combination.

I've looked briefly at the code, and I think true SCE support could also be implemented without difficulty; you already have sufficient ECN codepoint feedback from the receiver.  You would need to apply the L4S response (or something broadly equivalent) when noting ECT(1) codepoints, and the conventional Multiplicative Decrease response when noting CE codepoints.  Obviously, this also means ECT(0) must be emitted at origin, not ECT(1).

I'd be happy to advise further on work in this direction, if you think it's promising.

 - Jonathan Morton