Re: [tsvwg] ECT(1): Plan for Vancouver

Jonathan Morton <> Sun, 08 March 2020 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55A243A073D for <>; Sun, 8 Mar 2020 01:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pKoPUxGwDxYZ for <>; Sun, 8 Mar 2020 01:27:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92C813A05AA for <>; Sun, 8 Mar 2020 01:27:20 -0800 (PST)
Received: by with SMTP id q10so4455245lfo.8 for <>; Sun, 08 Mar 2020 01:27:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PO50yVIICfkNMxlmFQ/0QVoLgb+aLTGMl5tMBhVk6Cc=; b=PJtEAXeuqcjiVHeSe4qvTo3e9LLDOUB0Fwr/fTLinDcXt5rz3U0dWVSfJJzFA7Cv3W NelFnAKpvMMlTWVF/YV9cv08uo8ZkAvOSRBecQst9ANxZi6jK11wyV8/YWsg+vY4GFC8 pi62/Lj4wqeSMTeLV83xUXBczvTz0ulunrbTfUAXHvcW+mjddcXImnLPBevWA3trBjea ZNXZPB8qjMbIjf9dWMIUM54FxNU43kyudS7yT+iWUOqH53i80B4sqvOCY3odJILRX1bw +E4emwzreN30qNggxkRyb1C3BvkaX+BYUJi1hcQBjil1mpzPD/Uiz8NXZV/yK1alFWyE qDfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PO50yVIICfkNMxlmFQ/0QVoLgb+aLTGMl5tMBhVk6Cc=; b=MSF3SSqlF2TBGd29AcUhiMy6QztYmVpJPwDls2zFjrjnGmCBCHr5v9T2cPrjmZHdME CCxvwrflgUX7Zu1XocJDT7u63gVKhGiiKSr+e29tA0HpBfwRL67iFqx3ww4zw7h5Fp1I 30Viy4SE9YgupmjL3ReFfLwJ5ROQeZ9B/m4QSAA+SmbGq7DNac7ty4oBKsjZd717N50T 5b1YZYb3mMxsmi6SvQKLyJkHGzH/m8ZEYySJG0SkeX2bUOipeKKR1m5tieRRYfbLPnBL 1AZzbLZ3uoJTI16OV0a2sOAu0uKzdhFRiwL8vhxSt/VDnwKQPYoN2OIsugzwHSzVrgCI ++oA==
X-Gm-Message-State: ANhLgQ3wLtdw48NwsXnFiN4vwxCrFzYyp4y8ZhfPXc78jjFbSlTShPIM 8y25mvbi6XHsp01tc8tE3RU=
X-Google-Smtp-Source: ADFU+vs3PlaggDzxjvmDjLyrz5JF2H9rIHnxOqSBfdsh8RVS+ArxXiLht6nTF0A+zMXKzFQTo8qekA==
X-Received: by 2002:ac2:5473:: with SMTP id e19mr3425660lfn.24.1583659638732; Sun, 08 Mar 2020 01:27:18 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id e2sm18661635ljp.55.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2020 01:27:18 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Sun, 08 Mar 2020 11:27:16 +0200
Cc: Ingemar Johansson S <>, Ingemar Johansson S <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Greg White <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] ECT(1): Plan for Vancouver
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Mar 2020 09:27:23 -0000

> On 8 Mar, 2020, at 9:35 am, Greg White <> wrote:
> On 3/5/20, 3:47 AM, "tsvwg on behalf of Jonathan Morton" < on behalf of> wrote:
> [snip]
>    In that sense, even if a precise threshold for unfairness cannot be agreed upon, there is clearly a qualitative difference between a system which imposes a 15-fold reduction of available throughput on existing traffic, versus one which accepts a 2-fold reduction of throughput to itself, when deployed in a shared environment without FQ.  I think when shown that way, consensus that one is acceptable but the other is not would be straightforward to achieve.
>     - Jonathan Morton
> [GW] I hope that there isn't anyone reading this mailing list who believes that the above is an accurate characterization of the debate between L4S and SCE.   To provide some balance to the above, here is (in my opinion) a more accurate characterization.  
> The SCE proposal penalizes any sender that adopts it (2-fold reduction in throughput with no improvement in latency) in many cases, and gives a benefit that is nearly on par with the L4S benefit (this is still to be shown, but it is theoretically possible) when FQ is used in the bottleneck.  Based on this, why would a sender ever adopt SCE?  Why would the IETF ever want to consider using this last codepoint for that purpose?
> In comparison, L4S provides a benefit to the adopter (better throughput and lower latency) and no significant penalty to others in the majority of cases (including FQ) and only results in the significant penalty to older systems in some (highly?) unlikely cases if RFC3168 fallback is not implemented.

Funny, I thought single-queue AQMs were supposed to be rare on today's Internet?  Or at least that's what the L4S team has repeatedly claimed in the past.  Now, suddenly, they are a big problem for SCE but somehow still rare and thus insignificant for L4S traffic?  Isn't that strange, when the SCE team are the big advocates for FQ!

What is perhaps less obvious about the CodelAF system is that the 2:1 ratio is mostly independent of the relative RTT of the two flow types, even though the underlying window-based congestion control remains dependent on RTT.  That's because the flows are signalled to independently, and thus have independent control loops, coupled only by the single queue their packets travel through.

The 2:1 ratio is simply the ratio of queue occupancy (and thus relative throughput) needed to balance out the 2:1 ratio in target sojourn time between the CE-marking and SCE-marking portions of the AQM, via the very simple AF weighting scheme we are demonstrating.  I'm sure a more sophisticated weighting scheme, perhaps involving an integrating term, would be able to eliminate this too, but we have decided to prioritise other matters for now.  I think it's on the todo list for Madrid.

Now, as it happens, that is exactly how the TSVWG Chairs have now framed the debate.  Run both types of traffic through a conventional, RFC-3168 compliant, single AQM and evaluate the resulting behaviour.  SCE flows, in that case, will behave like conventional ones and there is no problem.  L4S flows, as far as the currently available codebase are concerned, will squash out any competing conventional traffic - which is a problem.  If your classic-detection code actually works as advertised, then there will be a period at the start of the flow in which you still squash out all conventional traffic, but then you will revert to conventional behaviour.  That's my prediction based on an educated reading of the proposed algorithm.

That is one of the major bases on which the decision about using ECT(1) as an input or an output will be taken.  It is a basis on which SCE has an undeniable advantage.

And there is also the situation of low-cost or high-speed network hardware which requires a simplified implementation of queuing and AQM to meet its other market goals.  I think it's fair to characterise DualQ as being in this category.  SCE has LFQ for low-cost hardware and CodelAF for high-speed hardware.  LFQ clearly achieves the best results here, as it is mathematically equivalent to DRR++, an FQ technique.  CodelAF achieves reasonable results, consistently, with very little complexity, and is capable of further development.

DualQ has so far not proved to be very robust, as Sebastian Moeller is keen to point out; the public implementation fails to integrate the queue protection logic and also fails to avoid (as advertised) giving a major throughput advantage to L4S traffic, at the expense of conventional traffic.  This latter effect is now the subject of one of the workarounds to be added to L4S endpoints, but which we have not yet seen in a testable form (only a demo video).

There are other points to consider, such as the overall robustness of the system and the potential for future innovation, which the workarounds presently being applied to L4S appear to belie in the former case, and close off in the latter by making some algorithms dependent on internal details or configuration of the others.  SCE's design space remains open for further innovation along many dimensions, and is straightforward to implement in its current form with relatively little chance of serious error.  Not bad for one year's work, I think.

I think it is time for L4S to demonstrate and publish a fully integrated solution to all its problems, or just go away and stop wasting everyone's time.  But that's just my opinion.

 - Jonathan Morton