Re: [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: 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 9849E3A173F for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 21:19:13 -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 yis-XaqzoFpV for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 21:19:11 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 B132A3A173D for <tsvwg@ietf.org>; Mon, 16 Mar 2020 21:19:10 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id f3so5732745lfc.1 for <tsvwg@ietf.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=OL4+7xRgpO9aWd2DAneFo8c+JRnOKFZxuk25bWn45vMAD6Z4b14CeVqzS4FYBGXPoG RSEOp/WvIKmln6nDZG1TLkzrOgPrN6Ok0DffaKBgnhahQ6nNKbdVAWc4pERDnk9Gu4OH xkfZukBGcDchH9YiN8rMuEdVDKaUIFFUaXbH/JhQXrMD7yh0P9t2NJs6FChzRn4qXvbl JHdhNa295R9171cQYoE05P4TukOJVXu9fMhXXy7q0sY8MWwP9ubTqotfRf96L+O3ot+T 69kUiTjPeBrLsGMYSn7HXKoSjUNtc6rtQgLVaEJTWPucxl4zIiE/+0gD7Pp8EGNGzZOH BmPQ==
X-Gm-Message-State: ANhLgQ1sRp+T3FTEnrdZJ4H3fqAx7b2eBiClmQOGDYJ80zejG2rqZWNJ wYFrjPiMfhzoUkyo/GNwAs2y3p+O
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuKyKDalvwrZJBa8c90MNrin28lQnmFpc9b9URH?= =?utf-8?q?IvlvraD5F1SHFjP63jD3pf0kJoS+FubVDA=3D=3D?=
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: =?utf-8?q?=3CHE1PR07MB4425AA2A7976C1CCF594D3B2C2FF0=40HE1PR07MB?= =?utf-8?q?4425=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
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: =?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?=
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/tsvwg/qwdVuH_q-T4ClP5U9wauQz7e1MY>
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 04:19:14 -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