Re: [tsvwg] L4S vs SCE

"Scheffenegger, Richard" <rs.ietf@gmx.at> Wed, 20 November 2019 20:29 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 622E8120113; Wed, 20 Nov 2019 12:29:00 -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 WeWtFZVSTeq1; Wed, 20 Nov 2019 12:28:57 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5F3EC120112; Wed, 20 Nov 2019 12:28:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574281687; bh=M8jC8bGsHhRweW1GxecuY1M1E+j6odScuBza81iTsDA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ZBfTn6jy3fqCNcTi5ToaJ3pOjNEoDXKMdROX/Qct2AXTwEVDoUnkN8ujFba3zs4Cx XlytEkB7QeRayqm0wlcJtDxZjdXJMS74cucixUd+0xIatHkgjS2aEj8o7pSO5n/hEq ZXH3KQY7KRRbm9FVgYmCvxL1JXRnCYOsbUxQNYsM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.20.8.66] ([203.127.152.4]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTABT-1iQ9FZ35IN-00UZCi; Wed, 20 Nov 2019 21:28:07 +0100
To: Pete Heist <pete@heistp.net>, Bob Briscoe <ietf@bobbriscoe.net>
Cc: 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>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <357abfd2-2d93-b4cf-355a-71a2def32b15@gmx.at>
Date: Thu, 21 Nov 2019 04:28:06 +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: <2AFFF85C-E66F-4CF4-AA62-6F7249A16959@heistp.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:gifV3N/L42ShlIcMATJ/2vz1gzQsLiEP6IU/4F9NUDm3oQ/+IUc 55oqXjybqNRiJgV3+XPTRcoEqzxR5PuNNF+mmg5g131uXRmDWu6ZW5WenB69ql5s2JW0QA8 clOOcu4qt8d7fAvnX15mTrItKRc315+s2qcNFH2EyiTTKPKCJTDjky0mMWeqW/YnqDxcHSb UlTI5OUKvTEqifKaVkqMQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mY2M9Rz5QRQ=:bWjUkmRNECPk2dXgITktue wC+K3NcytohtCZTLmLVx9umQyfl0LRmk8ZeR9PFo7wfAr21sA3l+igdBfwDKR0zibUDsWx1O4 STgoMhcUvf7W/ydVSiQe5kNHG61mu0BGUWaXKkuBZPmWDl6cC6abs57vRTEDK3i2rcCWZXptN bJbkwil8YlAn71Lbqqe3Q/smz0c6RFk5f7r+e+Ve0U5YZKnhn5RCKcq1ulxuoCUdE/jipWRK5 5sfIKZBbMXHUSNFFBspKrVfyd7Iwb9prSOMHpTYYFJcCmH5Rp4SkNwg+8dJ67Gr1UYCjpy4ep rubnqo7bYSpFG+aC6EAZzMz3Y5gsIJ57eASgQf8kuysUiXU6mOqZaZc3f+SqtMsG0kbI4wknd DrQnRxEycNHgoD+AJoXP74U98Dkm1TbSm25nrkaOFw3ZMqFcV/mPL/FR1ETraeAAQC9dQ0wPf LRBf+mqvBCUIiHG69Gy12uT8Ypej/XyDD01Yz7f6DKdi9bIi0ehZtpK2aMIiyqKZOUojagvk5 CeeBsCfLDnpw3v6JOR15BUggU/jNlEPsNCPF/DuqsAtAzPS1S3ufyiInC30XKKlGKS97sWUjC d0aegA1thg+CGlkxphOhzHm/0COvhbqsDMoWmSEbYix3kCTU4Szy8uGNqej4ppxsfG8jxcGpP NZ7I7SnUwQF4BFQi//P+X/6uumlGW1twmRKIWOLMlVz9E84YE0c9KUeuqxyZriHcmKNsqeQIc e/1syL5kLusQbFEPydgKeYVmLymRyk3NeCdzo1TSTC3f+TDVMGYmmlSMZ+Q0JE5atmzXk6V0k IQchZt6AUz+TxykPsLD7d2IQK0VaQ5OKawvFom6WI5D3XAnh08vqsEsELg4v5TVv+YcOUkQDs A/8rjBYvA9Vjj8bf67zi2AOjpJvBp9+cCa3cHu002iV94M5hUnspYUF1prdRDg05CJoybrcgE Q3GINZJI2WELmVV8PO9Ds57355IXRmELyDXQIPckC17ZZSGn5/Y1xw+CS5vltrGcQnd8CoYMO Cd8gXvGbuLpz7xBY08Tiof/lvXhyw+b4u1Fz7cEv9AqhDIwkH+sqjp7qcD96Y4tZtdGFcesM+ xoG+Ha3YkS6lEPAHzqHIZ1FtugiXRNJ7uYCwCgUEBZb5AxlGxaxxt/M39OhhMzJ1Rvm08iduR T3l1hdKyFoU1gUe4vu7+Yfum/VJkhedYFjBR3QkDO+CxvavRXcKJ4X/eUdKT7oztG3JyJoN72 /g+FjE3JWSJUkZDaUhnXW5vQFM+98UxKxkT80VA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/pIE64_qnTineDHAmYZ9HW9TvFHw>
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:29:00 -0000

Hi Pete,


Am 20.11.2019 um 21:20 schrieb Pete Heist:
>
>> 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,

Is this a plug for AccECN? ;) (I just looked and found that we started
that work back in 2011...)

> without the need for protection mechanisms,

Are you referring to secondary signals like loss, CE or in a different
context?

> 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.

Richard