Re: [tsvwg] L4S vs SCE

Sebastian Moeller <moeller0@gmx.de> Wed, 20 November 2019 11:23 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 9B39F1208BA; Wed, 20 Nov 2019 03:23:45 -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 orCwk7te87nD; Wed, 20 Nov 2019 03:23:42 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 2D50A1208B1; Wed, 20 Nov 2019 03:23:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574249019; bh=fDfLvTjA5PtrzB+zKiSBQoYsZc51PUsnuwIyRMUtGYk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ZKoymR7t4QnrcYAxFbQHQ+E2BUvFZFouxzOf2FagsYhqx0nlQzc+G6OEkg+nAidNn 7MiOGFcg9drS9c1nPJXL7ljoSx0TyxGVC7FYrWMb67o2vBfb2Wtm4KQ/NNSTdjBql5 H7pHRWR8BZenizfrhJkmGvDXnLGXlf39p9YASNAo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mjj8D-1i9ZpI20Nf-00lHVO; Wed, 20 Nov 2019 12:18:19 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com>
Date: Wed, 20 Nov 2019 12:18:16 +0100
Cc: G Fairhurst <gorry@erg.abdn.ac.uk>, "Holland, Jake" <jholland@akamai.com>, "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FDF803BA-83A6-433D-8BE6-5FFF430881DA@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>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:qxrRXaBII5Cb/XKp1lPFy0CdMYW6wm47ALdJNbMpHwEhU5BJJ82 lmXPacVD4o5uQSWDr6XqcJAEHx6YdQ2YiJ/FDy8H7TatxSDetFwQXMKQKK8OpORtkAivGWo s3UQNvO7IbCVPkgA+ghKq+TwodiJWvsNbs/ukMxRuQT2Znhk4EiZZkJfm446ar4Qe/FKDQN /ZDWHklkmk5w1VZUK5miQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ovLgw7Cs5yw=:P5HA5We+9yt1Y/Rca/VyRY 80WrBRFCUNXUIgiU3yzwp4Wqjo4bws2XqUsPzak+tqJ2Cbw1vlOPNg0dm83S9dOFTkgGnHxPy uIWpKCGvarcWJxBWqL1AqvRO6fYak0p0G80mQK9yAWLuAa/IscHcpIYZ0LXNAPceLLYYpf7Fw q3FurcVbF2xDKgWssqQn9tkUXdH8QJOjC8FBbbpNluZveAF5wa7gWgsZDvJYGHHpunToJy1B7 Nz5+ryN7OalErwHsFmq53RONlLrjKbNU9SkmQ56/BZ2j6Qy6IK9tBIsjQXRcLwlyONGGcP9ML nJB8gIczBFDuU7+LXAfs3vbv0jIX7IJJ5MQFw3rUutHDb4TJI8A95C3T+wdixhGg8xfcL660a HuM34qxHEHC2Z1XJp1MOoI7sWKio19FDnIKr8Vuj7R+EfViozF0p14fjlnHSWolZ3CQAkAidW UqFv5F67aLzIxNea/JXC2zhUNWqshFCLDupydI84PFnKgA9gEVMWjslyCT13NlUjM12AHxOpT C+2tcnFCWw4+LaoGODmmqXnl+PzaoQUKM07vZOqog4eZlq3K2C15s6Ewr5UycCKMWhXA51NNr BrFWitAV14OZtw4YvJ0t6wj1BGZOmBGbMp6/LazT4T1r1HVQ995Ww4noU3xlGzzIOZV+vcMpK 28qYoO1xYaEOgWd9e1Dvtu0PXMIo/4/vn4+2fbvhOVlpERubTOgzVrRjonOZY3XFdvsjU4AWz IqSsr4o6xmXp+qqlUME8KYPCSsaCcvZnltsp8wU5KrOAdjiByYPI89CutUbTqZOG8B5063yKx fXb6VM1BkyolHHpzAX+KSlIJe9VqukgLuHWKxIJ7YUo4dONWncbwGbTV+rwFjDrE4QiygnayR yIEl0XnTBlgtMU0KQtH74A/92cyFTt5KGI1c+NcoxrJw7fIlP91Hlk5mEIqwvMcqmJARvwfSI euWrsSFKMNMnyotWbubNuLwFaAl172QH3ZZtxdSECEntD3yZsGsShU8kikdkCEkvgfNpCvki+ xz8x9AgofWZiYvhxcxk6RwAnleOBLJ9i30FuCCEZzpq6PHhXf5Dsv9tGVfk95r5OT0AsPu++N +cNL3MAnBMEsPKipZYtCeCloS6r8MiGSssVF2Mx7XH0A5FDfonHvKHOAn5tXjZAuv6qxw+yIt A/CgJp5Vl9T1cU8NKmzBDHxXxpNhMsHwBX5UA8e8SA4TZdP0Q51ux9ejeY0p+18Ql4BF5rMET 1kdwqTKt/unF/AG93WGP/+yD0NRkvn0+fQZzvXqmZ3o3d0B+eB/az39Xa8NA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2Cx-h_de-WCWZhDz2_xKep2lClA>
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 11:23:46 -0000

Hi Ingemar,

more in-line.

> On Nov 20, 2019, at 11:04, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> Hi
> Please see inline , an answer to the question that is to some extent to directed me personally 

	[SM] I want to apologize to you, I did not intend to offend with this question, nor did I want to drag you and Koen into this. I merely cited you as I assume that both of you have a better feel about your respective fields/industries interest in L4S than I do.


> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Sent: den 20 november 2019 09:32
>> To: G Fairhurst <gorry@erg.abdn.ac.uk>
>> Cc: Holland, Jake <jholland@akamai.com>om>; 4bone@gndrsh.dnsmgr.net;
>> Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; tsvwg-
>> chairs@ietf.org; De Schepper, Koen (Koen)
>> <koen.de_schepper@nokia.com>om>; tsvwg@ietf.org
>> Subject: Re: [tsvwg] L4S vs SCE
>> 
>> Hi Gory,
>> 
>> new question below.
>> 
>>> On Nov 20, 2019, at 05:03, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>>> 
>>> Helpful, see in-line.
>>> 
>>> On 20/11/2019, 11:46, Holland, Jake wrote:
>>>> From: Wesley Eddy<wes@mti-systems.com>
>>>> Date: 2019-11-20 at 01:24
>>>>> • concern that there can only be one of L4S or SCE happening
>>>> There was a side discussion about this I think is worth mentioning:
>>>> 
>>>> It might not be hard to consider the consequences of
>>>> mis-classification that could occur in the "both experiments"
>>>> scenario.  If the concern about co-existence is primarily technical,
>>>> at first glance it doesn't seem too dire:
>>>> 
>>>> (PS: I acknowledge that there may be legitimate non-technical
>>>> concerns with running both experiments simultaneously, but have
>>>> nothing else to add to that discussion right now--if your concerns
>>>> are only non- technical feel free to skip this section.)
>>>> 
>>>> 1. If a SCE connection runs across a chained SCE-L4S link, then
>>>> there's a risk that the SCE node would mark ECT(1), which would then
>>>> be mis-classified as an L4S packet by the L4S box box.  This makes
>>>> the marked packet likely to be re-ordered, plus gives it a higher
>>>> probability of being marked CE, which would cause a higher backoff
>>>> than necessary for the SCE sender.
>>>> 
>>>> This seems like not a disaster, since at least it fails safely with a
>>>> MD backoff.  The cost is some performance penalty to SCE, but only
>>>> when both aqms were lightly congested, and the sender responds as if
>>>> at least one was heavily congested.
>>>> 
>>>> (In the reverse direction, ECT(0) would already be classic traffic
>>>> for the L4S queue, so there's no impact.)
>>>> 
>>>> 2. If an L4S connection runs across a chained SCE-L4S link, the
>>>> ECT(1) packets from the L4S sender would be mis-classified in the SCE
>>>> node as already-marked SCE by upstream.
>>>> 
>>>> If I understand the SCE versions of CNQ and CAKE correctly, this
>>>> would have no impact--the ECT(1) packets would be marked CE when the
>>>> congestion level is high enough (and won't get any SCE marks since
>>>> they already appear to be SCE-marked), but this is no different from
>>>> the behavior of any other 3168 aqm.
>>> Since the chief aim of L4S was towards low latency, I'm also interested in
>> queuing properties of the traffic, some initial questions:
>>> 
>>> Would an SCE router likely preserve or change the queueing of ECT(1) L4S
>> traffic? - is this behvaiour different to any existing ECN-marking router?
>>> 
>>> And would SCE traffic arriving at the L4S queue meet L4S expectations in
>> terms of responsiveness?
>>> 
>>>> 
>>>> Are there other scenarios that need consideration?
>>>> 
>>>> As far as technical concerns go, these 2 situations don't seem like a
>>>> high barrier to running both experiments simultaneously, but of
>>>> course I'd welcome comments about other considerations this brief
>>>> analysis misses.
>>>> 
>>>> 
>>>>> • maybe lack of understanding about how and where people are hoping
>>>>> to use/deploy L4S?  (like as an operator, what else would be there
>>>>> that mitigates some of the concerns people have, and that supports
>>>>> gathering experimental results, etc)
>>>> +1, these suggestions sound very helpful to me.  Mitigation
>>>> +strategies,
>>>> expectations, end conditions for the experiments, monitoring and
>>>> evaluation plans, any restrictions on scope of intended deployment;
>>>> all these would be valuable additions to the docs IMO, and it would
>>>> strongly mitigate my safety concerns if there were reasonable guard
>>>> rails described.
>>> From what I recall when we discuused the EXP deployment of L4S: If this
>> concludes at some time, I guess we can expect ECT(0) behaviour to continue
>> as-is, and we can expect use of ECT(1) for L4S to terminate, or be filtered to
>> avoid L4S.
>> 
>> 	[SM] According to Koen:
>> "I don't expect many large real world service/application providers to use the
>> basic reference Prague implementation anyway. They will have their own
>> version ready, eager to deploy low latency applications and to test and check
>> if they are sufficiently complying to the Prague requirements."
>> 
>> And according to Ingemar:
>> "I have argued (rightly or wrongly) about the connection to work in 3GPP,
>> admittedly so far only proposed work. Others have pointed out work related
>> to WiFi and DOCSIS, how much should this weight in here ?"
>> 
>> It seems like the industry is ready to adopt L4S rather quickly.
>> 
>> 
>> 	How do you expect an industry/commercial roll-out of L4S
>> technology to behave, if the L4S experiment should terminated without
>> adoption as a standard track RFC? Are they supposed to phase-out using
>> ECT(1) as well, or is it understood that deployed L4S instances continue using
>> L4S methods?
> 
> [IJ] The premise would be that L4S is declared a failure.

	[SM] Well, I am trying to discuss "contingency planing" here, by necessity that includes potential retraction of the experiment, no? I am also happy to talk about the opposite contingency here unconditional success; where should I send the bottle of Champagne to for the deserved celebrations? ;)

> I doubt that anybody has a good enough crystal ball to predict what happens. First it is necessary to come to the conclusion that L4S is a failure and I would argue that we are not yet there and I don't currently see that coming. Before that possible event I don't see it meaningful to speculate.
> This reminds me of a question the late Ingvar Kamprad, the founder of IKEA, got when an IKEA warehouse was opened in northern Sweden, something that he was very engaged in personally : "How long are you going to support it financially?" was the question. His answer was "Well.. let us open the warehouse first..".. I can add that the parking lot outside IKEA in Haparanda, Sweden is most often jam-packed.
> And.. as regards to 3GPP adoption, it must be understood that 3GPP has not yet adopted L4S, I certainly hope that it will go that way and I try to do all that I can to make that happen, but alike IETF, 3GPP is a collection of minds with differing preferences and goals.

	[SM] I duly note that 3GPP is not committed yet, but is it fair to claim that inside 3GPP thee is an interest in L4S' goals and/or techniques? My question is about the feasibility to roll-back L4S (under the pessimistic assumption that this is deemed required) in the light of potential uptake into industry standards and roll-out into a potentially high number of network elements (think base stations, CMTSs, ...). 

Best Regards
	Sebastian


> 
> 
>> 
>> 
>> 
>> --
>> 	Sebastian
>> 
>>> 
>>> Have we thoughts on what would happen with SCE?
>>>> 
>>>>> • entangled evaluation of L4S with TCP Prague (I see this badly in
>>>>> the threads ... From what I can tell, the public test Prague code
>>>>> doesn't yet meet all the Prague requirements in the L4S draft, and
>>>>> that's caused some explosion of emails.)
>>>> Yes, sorry about my contributions to this problem.  I wasn't sure how
>>>> to make the point about the level of confidence we can have in the
>>>> safety properties of an L4S rollout (and how it relates to the likely
>>>> impact of wg adoption decisions on external SDOs) without bringing up
>>>> the examples from the TCP Prague testing.
>>>> 
>>>> Maybe it would have been better just to point out that we don't yet
>>>> know whether the safety requirements of L4S can be achieved, since we
>>>> haven't yet seen running code that meets them, rather than
>>>> introducing confusion by pointing to example tests of something that
>>>> doesn't yet try to implement those requirements.
>>>> 
>>>> The point is well-taken, both from you and from Greg's earlier
>>>> message to that effect, and I'll try to be more clear on this
>>>> distinction in the future.
>>>> 
>>>> Best regards,
>>>> Jake
>>>> 
>>>> 
>>> Thanks for these thoughts,
>>> 
>>> Gorry