Re: [tsvwg] L4S vs SCE (Evolvability)

Sebastian Moeller <> Tue, 07 January 2020 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A620A120089; Mon, 6 Jan 2020 23:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IUorLa_uDcDN; Mon, 6 Jan 2020 23:50:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4211B12004D; Mon, 6 Jan 2020 23:50:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1578383388; bh=xYBJLwutUR9yI+ss67/6cBC79yW8uY7rve49DKxG30g=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=UdaYJY9Ui1/C77tFZsJJZJBE/FlFFS4m/Gq9u4bldjAH9CvJW9sgdOF+gTt0+hePc QliYtxogFjkBZM02SLnde6N6Vd9tLs14bX9wmb0C+mV+YnVfvMzX1DgRT+up1cO/qK TnKIE0avUN53FYUhst2/Ew3xuI8yt0kSN9pCr5nI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1N17UW-1jrFNW223u-012Ukw; Tue, 07 Jan 2020 08:49:48 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Tue, 07 Jan 2020 08:49:47 +0100
Cc: "Black, David" <>, Bob Briscoe <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Greg White <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:3e1MkAWAvLRdXyMlnueVhAHgGlXSidhc9dwUoafYzIBVyBX2cK6 la+iRTkWC0COf1cTQETiJqmK6wgkG90Y9Q7WexQD5/zud+YPFAZ8DbxY/J8Wips7sxEOZ/6 LCpo155VebE/x4up+00jWUGXeGBYUY0hGiu7fiFV01ZaHN0o5yqCOmSWQLoB+sX+xgkXk/d zyDHEsoqJTzTtny5swATg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:TOdQQh8yKPY=:FSgwGOKg44dUvn2rtgVPCR g2ElisNK6KmozXz4ZzGmy99s+zKGMep90611P9jH1KC/9FSO2z0PLXjTa2+5Z/TUmnstGS0dx ve4ZOrVpyx3k5/CJksy7mR0eQuDqumib/6TjygdFvtDbfKS9orZ6ODjeFF79WWvcr99NqkIFh 9L2j7m7WNl5mpeFcSsQCAg/n0i7LedH0NmcXvB04eTNI9DvQsRAzo6sDW7lf6fOHqheqRw1Xf s+ApJCHIudS8gsIv9z/UqHXbcOKcP90a4hD0fH+4kDjSZXBOP2/xyHd5VigiCPE+uehd0Vy+Z TBaJxG3SX3HTX7lPoBgB6zMDtHQCiNV3l8NZM5vYRkJmKiWov9deL+cmJkdMergpBw8bB1tqF 9s0/YZogdnJCIojF1UbNFkyOm3tZuBvPwkVI/T6nbyHbWGPGOiza99SXWxvK0EbFq5IEUXywr wxo0f8CEFrcVGBrtVNy7eXgA/JKg0SD+H7/ySN1+E6uVkZWZDdl3l6gBwmutsRJlAGYzzeeMx 03GzyjC1ZtfLqqQTdUjzMz3Putsr84X7ElJjMbDojLQ2d7aK+27Mr2+HevWtYxPQ+zxn4xlmf bSK1JtkPafK0mMfoz5YhGRGoMVBnIPzSPTb5wgCyE061LdGwmqsbw9BmAsNJJzSsXVnVEXopo PYSXQupQA15zeKy/lWd8C6dlHYdlg5hYwBmiG4nxdL+H6+yUO0e12taPvltC0q96djz9EYQ5Y C4yExWAEeHWHz1toKCb2VxVMAKEZouggE2hgaM0hMihphBaWwi0ZyidhZPUCFr7qZQp9LyuG8 3gEj49m/AOVKD/iEb6sdrtmWi8B7GJaVHiW7aVsydQDobMDpN6EfjJJV729m2Q86tpS4JihP2 tJ+a0VFJhTRaSpPBzBjdKTB6ZFTZxMd08sj69XoJhZ4IjLdgpy921NrAPoXVUMot+jy+1CZMr LLS1QdfkqQg/8JUEwCt/7ldUtOjBu6/mFC4FkTYtzat3vVkifCzfFm04nmd35DXymu1BIuc3f 480rJNWz9u8XzxEaQqkC2QF97WIOqX2di+APvWT7AEuUktmVABmIjAIQhvx02GkD/lQLZnO9T tKGctU2I7CJPRUwIJCB8x4SiaT5wWcNAdRpVs3X+4L+TQc3iLOjpnMUIqTGhO85SaD9Hjj0jX e9dhH8neB+1JuTyCIZLo7edUO/OyWHezuhasEKbztplllYh3DJx7hmS6KyWxeGskaywyhJrVt 6Y7Cs23Oa/qLG7wnZud/iAJBLGlm8HKBXiEqa2CkNCOJ+VS7eOXClKUuUsaU=
Archived-At: <>
Subject: Re: [tsvwg] L4S vs SCE (Evolvability)
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: Tue, 07 Jan 2020 07:50:45 -0000

Hi Greg,

please note that I am not a member of the SCE development team, but I have looked at the L4S/SCE comparisons in detail and hence believe I can add (other people's) data to this discussion thread.

More below in-line.

> On Jan 7, 2020, at 01:09, Greg White <> wrote:
> David,
> See [GW] below.
> Greg
> On 1/1/20, 4:33 PM, "tsvwg on behalf of Black, David" < on behalf of> wrote:
>    Bob,
>    (posting as an individual)
>    The assertion that SCE traffic will "starve" is just plain wrong in the following ...
>>> The SCE markings can be used independently whether you have multiple
>>> queues or just a single queue.
>> [BB] This seems to be the opposite of reality. Perhaps you've used the
>> word 'can' because you think it might be possible. But there's good
>> reason to doubt that. As follows...
>> Packets from non-SCE and from SCE senders are indistinguishable by just
>> looking at them. So, if there's a single queue, they have to be mixed
>> together in it {Note 1}. But a single queue can only have one length.
>> Any transports that don't understand SCE drive the single queue to a
>> deeper operating point (defined by CE or drop).
>    The reasoning appears to be sound up to this point, but the next sentence does not follow from the above:
>> This overruns the SCE
>> operating point, and causes SCE marking to approach 100% {Note 2}. Then
>> those transports that do understand SCE will starve.
>    Actually, it causes both SCE and non-SCE senders to operate at that "deeper operating point (defined by CE or drop)" because SCE traffic has an RFC-3168-like response to CE marks, and the usual reaction to drops.  The result is a deeper queue than would have resulted in the absence of non-SCE traffic, but the result is definitely *not* starvation.
> [GW] Is that true?  Setting aside Bob's "Note 2" implementation, it seems your statement would only be true if the SCE sender had /no/ cwnd response to SCE-marks (i.e. ECT(1)) at all (which I guess would make it a non-SCE sender). I know the SCE congestion controller is still under development, but I seem to remember Jonathan indicating that it would aim to reduce its congestion window until the SCE-mark rate was 50% (don't quote me on that being the precise behavior currently).   If the non-SCE senders continue to drive the SCE-mark rate to 100% in order to experience occasional CE-marks, then the SCE senders would continue to reduce their congestion window on every RTT.   I suppose one way to (somewhat) get the behavior you are describing would be for an SCE sender to, upon receiving a single CE-mark, revert to an RFC3168 compliant mode and stop responding to SCE-marks.  I don’t believe that is the behavior today.

	[SM] I believe we could just look at the data collected for scenario 1 at, especially,, and, which show the "degenerate" single queue SCE-AQM case. 

	And your intuition seems to be right, the tested naive SCE AQM will, in single queue configuration, unduly slow down SCE-enabled flows (just like a single queue L4S AQM would unduly slow down flows with a 1/sqrt(p) response).
IMHO this seems to indicate that for single queue operation (or operation at similar computational cost to a single queue?) the SCE AQM needs refinements, and it is not clear yet how well this can be made to work but there is work on-going in that regard. It certainly seems safe behavior from the perspective of throughput of the standard non-SCE traffic though, and it also seems relatively easy to simply avoid instantiating single queue SCE AQMs until this issue is remedied.

	This issue is also explicitly acknowledged by SCE's developers at

"SCE Single Queue Non-SCE Unfairness

Because SCE is marked at lower queue depths than CE, non-SCE flows will outcompete SCE flows in a single queue without a change to the SCE marking ramp, as presented at IETF 105. This is effective, however it trades off some of the benefits of SCE, and requires tuning, which may be dependent on the link or traffic conditions.

Another solution is fair queueing. One of the arguments against this is the resource requirements for fair queueing, which led to the proposed Lightweight Fair Queueing and Cheap Nasty Queueing. Another argument is the perception that FQ can do harm to periodic bursty flows, however we have not yet shown this to be the case with hard evidence, and the SCE team is in general in favor of FQ.

We continue to explore alternative solutions to this challenge, and will seek to quantify any potential side effects of FQ, however this is a decades old debate that may not be resolved any time soon." (slide 13) shows that e.g. modification to the marking ramp-function can help ameliorate that issue.

>    Thanks, --David