Re: [tsvwg] L4S vs SCE

"Scheffenegger, Richard" <rs.ietf@gmx.at> Wed, 20 November 2019 21:36 UTC

Return-Path: <rs.ietf@gmx.at>
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 3B1AE12021D; Wed, 20 Nov 2019 13:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (1024-bit key) header.d=gmx.net
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 3tgl7x4zUiCc; Wed, 20 Nov 2019 13:36:10 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 ED790120227; Wed, 20 Nov 2019 13:36:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574285720; bh=SubxDv6GO4XtCxrroZm4SVNkqlM0gWcBau02HKlqIpA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=bSuk59SPurtzSPwE0aw+tsvLwlzUi1Wl0T5uwrJl2YmCZo0zS49F3LBkgGtoZkEwL jJCfmIonlbuGVsc9chKc9DNFn+8onXJHIwvR4tbV/JKJjsWRrJ7mPAbTbZQy1/TIhV T+VwKyVNkizpRwdcTdSxjrwzUEDrfj6S9fTw1s8k=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.20.8.66] ([203.127.152.4]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1McH5Q-1hzJo400Im-00chc1; Wed, 20 Nov 2019 22:35:20 +0100
To: Pete Heist <pete@heistp.net>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, Roland Bless <roland.bless@kit.edu>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <2AFFF85C-E66F-4CF4-AA62-6F7249A16959@heistp.net> <357abfd2-2d93-b4cf-355a-71a2def32b15@gmx.at> <E175102C-CD01-40B3-9807-3DE0C2DB8277@heistp.net>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <9d6c1ce4-d192-d016-8418-c26a09e25517@gmx.at>
Date: Thu, 21 Nov 2019 05:35:18 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <E175102C-CD01-40B3-9807-3DE0C2DB8277@heistp.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:xRoOSJlMBB7/8m77+GSbVo6ZEFlVrgICVPGbqWpjVBFNhqhEaXR ieWPhUHmmNwZIsawBqvYu1JlCSHrnmCjWHhyWFmn3BseWCf2XHWfZdsNj3qf1VOvkTSbB4W uFWKC0Q+uNEpNroRLd8rJftIWcSgLkrDoiYwUrTMjE9LgT+mWrcKrVuHhraDuH5loM+tUss gvF9IHhSYBQT0e6FLTdiw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:AqNLW94bCG4=:965d7zsSHW/qW8nAgN5jZQ w8/i2oPdzq3ERCuag75V4fXt5NOhl5aTr0xtDA2Ux6s5HxrHTKZngbWpIILPrKB33pCzZZeA5 libQXmSqa8JhfPMoL/d94F9WbcD+ocYSkDs7IW6HAQj4ioYAHmXd3E1W4AQHYLxTbvf24wEhJ 6ca4k1zZBVreMcurbiboSNcmFjxegAW2jwGDEmv8z3wypPfKPAu1bADkloV1aoyQTu2/awcxM QGcwfs+xaAu0t26WK9ZBMgurG0LP5zHofz2RPQrKB7n4dInuDRWw4xFRJ2FsDsT+IOVdNE3Yt /u0U/NHThDyMG0CgSqOPK6Jv8VB1siFDi/qUGBTdBf3YHbRmPn/2yjvlHA1Qwko3gEVz+ghYb 1HVfss0CYMUwz1Bwg8joq6C+mQMexGFIexanBsOlMSK5ScdfFfPAl9PZwpdyQTy35HnK5uIsu N2juMRCaTv3JCAp+gx/p5e2v2US9HSbTJ7cfXjuUv6gdAtgM7zkA5ESmJSd2zqfms67TnJ4eJ 13xDy8zp/aiaT/W3r2vgPnzPFcy5HhOPMw922oEtDXdVgmcUN2fnWDNPPxFcbNR47BSq0qdOz 7DaLvU72Z1p5ijcbdMKXvYFdL61BTdPgn95i8IsG4fUzZGC8mSjjJa6vOsExQhWKOUnNkd0iu NfneHPcpt7MfbrEyQFwaFjl1THdi8xS8HN8lH+I6PiwKDR35SRn0Ubh3+krHu3LHqv+k/MW2i bii0xDNoR9+h9IrF28Zlpfwbt8B41gM0dPEGyWhtdBr9/f/x/zwVkvITS/5eqDaCZEE218dbg 8VnbTBtvyfhToAgqpi4JfKGN7wlL//FEJQ83RAmp4VYXGNttSlba8oanCuXWnIgszFCQp3odC w1kWzmoMls3G+tp5j/QXp8CSJAigGYnPZeKGYkIH4gDulvAOnyGsB+Qo6YEnCrsLb47sO2KiJ tsJcX+pZRO/MNPZCM7IoXX4RH42Pn+DPDHnly1uXaSZVZyOVvp6FpxMaJFUeP5fR78fFp2cAH U+HVfwS8D8kQjqNBgnSHsZaXp2ZSqPkn8VIHuqpQG+Djq3jYQajjmUCcR8vhKwN1jYCa35XFP sNwTzlQFMBFaqHKv0+nq4h/pFRsvM20VAeAONQf0yN3FwiyCz48Gq+WYjUuxUit9ZY13bpMz6 ezihWmSS2TNJFt4LGW8rfwjr+3qB5/jQif6nPN1aZJRnUR10cezmgWXk1FXaX85i6q7KYZkbj 6pHrPMf3T9QQ7TNQyJgTkKto6ziC46xFK1gFccA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/tJBovbrbehgMKWGqBqJBL51sdBo>
Subject: Re: [tsvwg] L4S vs SCE
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: Wed, 20 Nov 2019 21:36:13 -0000


Am 20.11.2019 um 21:53 schrieb Pete Heist:
>
>> On Nov 21, 2019, at 4:28 AM, Scheffenegger, Richard <rs.ietf@gmx.at> wrote:
>>
>> Hi Pete,
>>
>> Am 20.11.2019 um 21:20 schrieb Pete Heist:
>>> allowing alternatives to be explored without a risk-benefit analysis.
>>
>> A basic risk-benefit analysis should always be done. Even benign
>> optimizations can change the dynamics of a CC.
>
> Good point, but the additional risks that a second congestion signal adds should only be reduced performance that doesn’t impact other flows.
>
> :)
>

There have been proposals over the years, to utilize the absence of a
congestion signal as another signal, to speed up with session-start.

I know that Bob has also been looking into this as a thought, to use the
absence (or lower than expected steady-state) feedback of a low-impact
congestion signal as a new mechanism to speed up slow-start or adjust
maximum burst sizes. and there are similar approaches in the literature
(but most were never brought in front of the IETF).

The addition of a secondary congestion signal also introduces the signal
"absence of secondary congestion signal" (provided you can affirm
yourself, that this secondary mechanism is actually working on the
bottleneck). Misuse of such a "1-x" signal could impact other flows.

But don't get me wrong - I am very much in favor to a new signal; in my
opinion, there are valid point in favor and against both of the two
current proposals, which can not be easily combined.

However, perhaps a more in-depth analysis would show, that linking SCE
and L4S queues behind each other (in any order, and any number of
queues, only some of which become the bottleneck at a time), is not
catastrophically problematic. I haven't run any numbers on this though.


 From a 20km view, the marking strategies between both - broken down on
an individual flow - seem to be fairly similar. Both appear to be using
instantaneous queue depth (sojorn time) without any smoothing of that
signal at the bottleneck. One stated of with a step function profile,
while the other with a slope. Form my understanding, both marking
strategies have found that some aspects of the other are beneficial
(deadband when the queue is fairly empty, and a more or less steep
slope, ramping up to 1 well ahead of a full Q). One crucial difference
is that one does lend itself to easily cope with 100G+ link speeds and
very tight time and memory budget on silicon, while the other one lends
itself ideally more towards the edge of the current internet.

The main contention - from my observation - is the question if a DualQ
can be implemented without infringing certain IPR, and if it actually
meets the cited design goals. Or if classification and bandwidth
allocation need to be an orthogonal means to prevent starvation of one
or the other type of flow. Similar questions remain on the other side -
is it possible to build an AQM that can be put on 200G / 400G switching
chipsets and maintain the properties of (FQ_)Cake - especially when the
Q never holds more than one packet of a flow at any time.

The L4 feedback signal should be the least concern when designing a new
CC mechanism (and AccECN would in principle support all the use cases of
SCE - not necessarily particularly efficient per the latest draft where
the TCP options need to be used; but we have had designs over the years
to match up with SCE needs much better, and could still tweak things
there. Remember that when we started, we did think that ECT1 may become
an additional congestion signal in its own right - but that design fell
through in the WG. But there is nothing stopping the WG to revisit this
decision now, in light of new data.

Remains the CC reaction, where I believe the base CC mechanism in L4S
has had more in-depth reviews (dctcp) than SCE over the last ~9 years.

Best regards,
    Richard