Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

"Scheffenegger, Richard" <rs.ietf@gmx.at> Mon, 18 November 2019 02:20 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 1A701120106; Sun, 17 Nov 2019 18:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Q2QvuSxY3la1; Sun, 17 Nov 2019 18:20:21 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 1974D120048; Sun, 17 Nov 2019 18:20:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574043561; bh=R9soMrwU03Q7lrWFQjPoLYV2a0ENMyHsEfktdEo2aug=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fEqTJWJp3eGY2anXAd4SoEHrgsfcJ6abyHHLQgOneHfwcPI2FIE6ebCIaUuDs6qpD yNyTvJBnE5Otq3y85b86UtXCW/CanT+BybIjVBX2MARKUJilIZ9uZ4tsFyE/7PB6no AipCws4MjQFwbsmoNarvro9kT7kx1eKW/AxzaAmw=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [31.133.155.213] ([31.133.155.213]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MBlxW-1iiZqW3Cw8-00CEZ6; Mon, 18 Nov 2019 03:19:21 +0100
To: Jonathan Morton <chromatix99@gmail.com>
Cc: "Roni Even (A)" <roni.even@huawei.com>, Bob Briscoe <in@bobbriscoe.net>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <201911141350.xAEDo99J048928@gndrsh.dnsmgr.net> <39d0435d-e22b-7b4b-bba7-3988a67aba76@bobbriscoe.net> <6E58094ECC8D8344914996DAD28F1CCD23DC49BC@dggemm526-mbx.china.huawei.com> <3e40dfe2-f2c0-eeb3-c68e-79e1b2cb9d25@gmx.at> <97022649-EB9D-4467-9640-314C6A3916F8@gmail.com>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <ac9e7e3b-d046-e2ee-e529-6ca8ba965873@gmx.at>
Date: Mon, 18 Nov 2019 10:19:15 +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: <97022649-EB9D-4467-9640-314C6A3916F8@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:2yvU7kGUgTXxf3n5JhCLUxKNgEzmjNOBIalHdMbt3a0XPdAzO1p zRBZtSzxYBqMXAnrtFs9lc/wsIz9cUk3fObBbqjjDW7qZW3yh2Pu7ZmTEBaSaUmYQ4cSRCR vgR81HinRBcyfiY9g7KyLUZDT9tb5GHsACbKCYmqr1bAnTQ0ULCR8O5oDzC9re3RGyIF4pa 7J9jlbn/qukLrslq/QuHQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Xc01Thgo8+s=:0pmCJVUZBzIUE+BWxyAoNU eNogz5zhP/ik7xF/CaBeWn+nkc6ED7AfJsNewCNmEkMAUO5pFx+7SuRPjyMlO5fLWt1hl+PEW bnasmC0OKPhIB/LspvwHU06eV18iLctppJ+hVT/HjGm/XUltXtdxJb+l7SW9xFSuxSaYlRKVc r6qczl3VpxecL/6HpU2RK5m8x8G/HOkcDluW3Tg6w1SOY+T2wt4FF0mb5d7kGquW4Sq6VoGx9 hbyPBEJwPJV2MjWtyeaR6wLX3GwcQgKhJG03i8pqMqHOoPp8KTopN63vVuSwxrGaNCNzWD9jZ fzo71U1fOOoLOYps7XRl8v5xGfqWTSLu9+eNbdbiaGgaezhh6AJcaM4f6jr9fuJx2SIfQnD0e AAM6rvSsyLV4Grt9jN3zuc9J7zbvBwT1TJs3XAaZocoCBgsZwO8PETMOfV6tH1bvt8Mi99Dpp KUAgQB8Gt9ZS1Naoku2MlyzUpdfHdLQ5AnDmCPII4Xf7SAV3NP9xa9/hIYY7Kwg5xGRumj5qA rFH4HS3Ws804SoYB5wTL7sCTEt89ZdoPqMXmIl2mCdtIFDsdl3WenBptMNAiMBlL1AadzMPYB Vysqkgf40ocCMxQyEvou/nJmU8vFOPwBEr1IQiEJoW1g+eQDXqP5rOTrSDHlsjcaoDdMlHgkp LNSPmtr/KUnm20tZsQOt4LcIZeLIon8KaUv7BH+k1A/n1DOTRFh9x0ZDJQB81GLA12FRjwhSo pQ2/nhPe+ZGFZEFq6nj9qp0FyK+J2DXnZMQLf9gEka7TIuYRjvLpYYD6aGQgdOJuU6EjzESKf MiZBWUrT34WgLLUwFJ3lhO+SlNQlien90trghFVjEyb3kLjV2flMAe7AfEaTlRvFK166t2znC +sZzDF5W/MqR1wXlWHme1pUW5bjAobWTUQrp6C0oR3TQAb6y92OEVW32h18soX2Zo49L5VXCv 9IXFpsEBlwmoNfyZIjG54XOynTxGXFVfObdIMnRSYFOwKct3qZt5BijvTEx5DoSfsgJEwCUJ5 1xspBD22obRSisJzNCzI4qWhGQ3/g388eIMvFYpGtdud6Y+UNU2b4cz1V7anKZJEn3sweF1Tc vKsM0PZDjXCqlR3DHMFOFwX+0DuMF71u9aOJ2EUoGOqb71iKOIDb5vv2600r+QS1uA7kgfxk7 Zq1TMT2RwIfEaADSBpliznLnPZxwS2cumHYQhFnB5ZNTyCvd1uhk/BKSReNtz7XBgVXl5gUsn ZNRf30Wk9fomIdn3Ez6Y5hDSvpF5Rg3LFaymxjA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/7f-jfCuqcyP2To2HGnhJ6AtRmPw>
Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-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: Mon, 18 Nov 2019 02:20:24 -0000

Hi Jonathan,

 > I believe DCTCP made a fundamental error in deciding to redefine CE,
and that's the problem that L4S is presently running into.  We do have
(since IETF-104 @ Prague) an alternative version of DCTCP using SCE
signalling, and that could illustrate a starting point for merging the
two experiments.  I believe that would solve an awful lot of problems at
a stroke.


Being in a position of having no immediate control over the ECN marking
strategy, and having to reuse existing silicon's RED implementation,
that choice of DCTCP was IMHO reasonable. (Also, IMHO it is not
realistic to see a timely implementation of more modern AQMs in very
high speed chipsets - but others would be in a better position to
discuss, if the SCE codepoint transitions could be implemented with
little effort in those asics).

I agree that this was not a choice that lends itself to good, backwards
compatible interoperability. As such, a clean slate approach (such as
SCE) is more free in using "proper" codepoints. However, that allowed
the immediate deployment using existing RED AQM (and an additonal
classifier so that non-DCTCP is not using the queue with the aggressive
marking).



However, because of the different reaction of the CC (1/cwnd vs
1/sqrt(cwnd) ), these two will not coexist with each other in the same
(non-FQ) queue, correct?



Best regards,
    Richard


Am 18.11.2019 um 02:22 schrieb Jonathan Morton:
>> On 18 Nov, 2019, at 8:52 am, Scheffenegger, Richard <rs.ietf@gmx.at> wrote:
>>
>> While on the surface, the AQM marking strategy (abstract from what
>> actual signal is used to convey this) seems to be quite similar between
>> DCTCP (L4S) and SCE, what I am still missing would be a detailed
>> mathematical model of the SCE congestion control loop.
>
> [snip]
>
>> I would love to discuss the three pieces of SCE (AQM marking strategy,
>> Congestion Control loop, and signaling) separate from each other first,
>> before we wade into certain implementation details - like how to convey
>> the signal back and forth.
>
> On the contrary, I consider the signalling method to be the most important aspect of SCE.  The marking strategies and congestion control algorithms applied using this signalling are interesting and potentially useful, but the critical aspect is providing an extra congestion signal without breaking RFC-3168 compatibility.
>
> There's no fundamental reason why the same marking strategies and congestion control algorithms as L4S can't be applied with SCE signalling, with equivalent performance - *except* that the backwards compatibility problems with existing Internet traffic and infrastructure (as Jake just helpfully outlined) would be solved.
>
> I believe DCTCP made a fundamental error in deciding to redefine CE, and that's the problem that L4S is presently running into.  We do have (since IETF-104 @ Prague) an alternative version of DCTCP using SCE signalling, and that could illustrate a starting point for merging the two experiments.  I believe that would solve an awful lot of problems at a stroke.
>
>   - Jonathan Morton
>