Re: [tsvwg] L4S vs SCE

Sebastian Moeller <moeller0@gmx.de> Wed, 20 November 2019 20:34 UTC

Return-Path: <moeller0@gmx.de>
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 411B6120120; Wed, 20 Nov 2019 12:34:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 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, URIBL_BLOCKED=0.001] autolearn=no 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 TAJWP-N54Mx2; Wed, 20 Nov 2019 12:34:24 -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 DF48B120113; Wed, 20 Nov 2019 12:34:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574282013; bh=l15R/xQphlJv/bw7kM6UPmZnrkQhQZv2EJS7Mo3NSOU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=jeoKOJyuGBi8LEX3j2pc026c0MRMhkw+iSR/pfBX2vOTRCrQFehTftEPmtC9d2MN/ mSbzT68q69Fm2kalzK7n2cgIY0nrnFDWM8XN1v77qp9aq04ApxOfxzDPTFDogi47H+ hXvK1h1cMiVZWMbrgLmRw5N6KYXuXEoo8QOHi/js=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.1.154.19]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJmKh-1iHvca1JCT-00K7cD; Wed, 20 Nov 2019 21:33:33 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <2AFFF85C-E66F-4CF4-AA62-6F7249A16959@heistp.net>
Date: Wed, 20 Nov 2019 21:33:31 +0100
Cc: Bob Briscoe <ietf@bobbriscoe.net>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Roland Bless <roland.bless@kit.edu>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <23E514FB-F8AA-43A7-AEFE-62830DA0F4F2@gmx.de>
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>
To: Pete Heist <pete@heistp.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:vv9p2qYen3zkKEy+c/kVJ8/GkGupf2X6SpWIRq5dgeKIlRkfYDz 5Maf++I5ase3u7K3CSQ4HIDW4HSN80+xHBae8S0h8rNRyCvo6cK+Fy7rrWBv9lrue5YvghI CquHw1NWuuMPs9so9aypjU3uqXriaKqXhh1wKD1Ursqh3fdYQ/9bUvpUXHzTW5l8QAnZ9rh 0rfCYGLt+MyFEDylZBQ0Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:F1zX66F2aKU=:eoc2v+LprLR4o2B0J0AkY+ TBUOhTCyMHm/V+ArrnTyehjhjz9uXYpEl2Jfz0jNpOB+sPXQkoW2pychTdygsOrbiNDprmI4a YnJj6XHC32Dv3TZkW0c/dTslivVIkjmNx1LP8wFsgUy7Jc0iMub98CISIjPmbJm3A3VPd8q8A 26VdT3wPJRD+WH2NBEaNGoeQMRHc7G6H1Dv1gKa0dmF8US0Sf9yZdEYJKsqegRUMHFz5XDC30 UEZoFbKELxVCmQ9HZZSEmP/qRg0fkwZJ1VaW8puUdfqy3RWEZ5aj2EwUMgaSyVbspIyz6Zf4i xDoNry5ueBPO/Am+x6we/yJ0SfNjg2kMyICunPLhOweKkymulTSRtK3zg2qsqKqXWMQlej6jY Tg9OjUtNyPj3M6dm/6u06bDbMYFiVdD4ue2WJI1PWjTYC3Ctyub119ZXDlWZ/ilQ/hUyusDDv JcSBnrqZ5pxjWbrEqQbhiMafD/o4UXDxKWXpiwyG8gO3kPNP1yFWf+XQdnQKVXChpU1ZhQ9g4 R27StH1qg6/Zrxy2qOTZI1LN69qeYkp3nNFtN0pV3pl0rGjORJIPBg3C+ALW0X/qFuI4hKyNR HSM6SMapgT+CsT3tLVVx/v9LbePWOpsWOKzqcSAUUv4AUA4CGM6AJymRhwJVGvqUElxG6TSF2 TvowX5sYjTkc18i/1Fq63ZgjomJER7BcYkPJiBfZ60daSpWiUhWUrATcV9Eb+K69ScX9LEtRf 4IWRLJsZA4ZQ0knBtSNyrWKSGXiOk/aTuM1c2jaEQ5ysQwe2YunRT0CHthHr0PS8kUtR1mo0C ZXmlhtOipGZkGOrK3PjedXEZBXqcB/Tor6Bmsptv/Tn5DJCAooxtdFdO5f/1THAjqs3p9Xp2g mCxpCVTrM+kziIVhwfoTcTKF5JvMTwyXOSeoyLeWZG7OtD4jGrlWOaO/yE2ZZNMhN7j3rR8AA tzT0PAsaL/lf8q9FWBJWUFwscrkx/Cf0vkS6PWbK8m3UuIbJq3oEmjxF0Xq5lMePxWJUhSyP/ NsUs8O0BBQLy46ezRdNUGEFwsAJQygyH/5NisF+8LvBDq061yEmloNIZGWJIVtaor+bfNuXD3 vydjey69lmZR41ku/sn4QKXxxqJnB58GC/pZijHCR+7tVh7V5v9cgc3UFKrlNKNwEJSqE9VH3 pzbnuAGHlpp3ZcZjvOgAj8uucV1zzsNHPDdvTxPss3JtzXuaeLGoeoZd4XIHXImAvCroBKPmt /oerjmEDQ8mgu+j+M7haj0+ynuTp2DhGXSVcNLQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/xNpBmabVyI6aWbfp-LBQE0OzCaA>
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 20:34:26 -0000


> On Nov 20, 2019, at 21:20, Pete Heist <pete@heistp.net> wrote:
> 
> 
>> On Nov 21, 2019, at 2:34 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>> 
>> Roland,
>> 
>> On 20/11/2019 21:22, Roland Bless wrote:
>>> Yes, but as I also expressed my concerns w.r.t. the L4S codepoint earlier, at the cost of binding this to a quite fixed set of L4S 
>>> behaviors and "burning" the last ECT codepoint. Personally, I like concepts with a little bit more potential to be useful for future 
>>> development (evolvability) of congestion controls, e.g., BBRv2 and LoLa could also benefit from an SCE-like marking...
>> 
>> My whole purpose in solving the problem of deploying scalable CCs over the Internet was to re-juvenate evolution (to widen the range of applications that could be supported by different transport behaviours, particularly for real-time with low latency and high throughput at the same time). One of the main things that has stopped CCs evolving so far is the need for friendliness with the Reno behaviour that was not scaling over the years. 
>> 
>> If SCE is primarily supported in FQ AQMs, that will constrain flows to be capped at the rate that FQ gives them. How is that doing anything other than massively constraining future evolution of CCs, especially real-time ones? See Per-Flow Scheduling and the End-to-End Argument. I don't need to tell you that the e2e argument is all about giving end systems the power to innovate without permission.
> 
> In my opinion, what would enable future innovation in CCs is a signaling mechanism that is completely safe by design, without the need for protection mechanisms, allowing alternatives to be explored without a risk-benefit analysis.

	[SM] At the very least if protection mechanisms are employed, they need to to be robust and reliable, without nasty corner-cases... if the rest of the internet's safe operation is contingent on protection/isolation, it seems prudent to put time and effort to make sure isolation is as strict as technical possible...


Sebastian