Re: [tsvwg] L4S vs SCE

Sebastian Moeller <moeller0@gmx.de> Wed, 20 November 2019 08:37 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 A8E581208CB; Wed, 20 Nov 2019 00:37:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 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_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 kv3SfSetW6zQ; Wed, 20 Nov 2019 00:37:29 -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 E7EBA120A90; Wed, 20 Nov 2019 00:37:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574239044; bh=WtfOy7pKZGPavYiKcSLvMbp/HzXTdQS/nMWbekB2YRI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Vo99rlXcz42jtd2+qnV4QxyjwQvM5RSc4+YXLfN4/DLmdvSUQM1H8ZBDnBh+YLd87 DuJmiNeNtigm+5TxmcauHW5DQjSPkQJThPg68TjrBWbTTbvWomDBjVofvvjAx8T8sW RFObq9a2b/eL+Dyjb+KNH9OrPwzSrOpawb3XyiJo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MzQgC-1hbvK93Lu4-00vSy5; Wed, 20 Nov 2019 09:31:57 +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: <5DD4BB25.3060700@erg.abdn.ac.uk>
Date: Wed, 20 Nov 2019 09:31:56 +0100
Cc: "Holland, Jake" <jholland@akamai.com>, "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "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: <5658232C-07D5-4C89-B16A-58A928332FC6@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>
To: G Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:SmqSzuhPMxNECQMVeY+XPKRMaLChzURX2SfzKIvJK6Jx4HpK5bY bujgjr+I3ts6TMfuRmsTot2TYflC8zTe8Z+AXlG4Xt7voi3JzI2MfXWddwg8bnIaKjt0ONB M5O6rdPD3flnP3l7WwHlwddlahNAY0d2EkL3iA9wNMxlyC1raJIzZrFGnn/Um9MYTMjwe96 3OzjFXb8O0cPVV09ATp9A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:nSD5xX/EZN4=:FOeWAX7gFVo4Mel5Xil4Gw 7vIlr+xS+n+5wJTZGSBoGIQCd6TIqdWbe5/VMgy0p/kOMwSKRDrrMi97lOzREzjSACJ1ucd/L tSwYU8dDCREnPmRJhSw9LSyrwgD5ODHjYs70lRV2cNuaTa47mebnZ6SaL3TZ0IRJL1O+wqfZw pLVM8Qjip0krrv/XV451otkBAGyePJNjdMkDQ+ZiBgnOQAuSb+R4uJ5CE0Gv4vM/MBxxsyVOB fy4hsmrlRqH2XagD1QPpBAjFZGGDrIWUVAnd0dywZqNtqOX5Ckqclq4xKX+UOk1klb66DVDkp 079x7B1FF4RyEGJrxF9lzUlZFbX0FYZ9RwW5jjwwDtyTqlfq/IPisFYlsxiZYUC2PGsXiWQM1 d0pR4gKz58aKemCSXrmMbx7ByoluFeKlguX3qrMpsa41lKAhJg+n0YSHu5p5JFQVNmTwGVrSQ 2+Uw7fzOqG8J+AHoUCLi1eO6u4AhY5KzDOBQCLBioe6oijbsWipb99p7VGaQQWgO5KXe9xX2q ig9ocsJsoFaVOnRWkJ79a35x7MfIN22j2C134MRh6Q3b7V0vXK3zMK4azthelaKkPBpMLNQbH lB+MK9rjIg9sKJcDPKqWkkYdEUlJrM6YpyH/CYFI68fpU8o2vgO/McO0bec9abGHRT+am+Tbs mABCmVJ7nSTnsZ8MA4EacGxK0xTCSxtPDzcuRbuNPaDiLe1vSe8oE1cIF7M5pOgUfHhFacml+ KpaLFqa28UVycNnuXFHYKZmagNV9PDxgVHoNs0hSDuR45Qqk8M9HMURQ5DNPEMqZFSIjavRyD 3ygi0jtL9t268najX9+SmCqNEdU072w1WGLFaEY/CSAFn5obGBkrqUhgXymS6ioqYXA9yirkv /54JrYXhMXWrvV/4skQo3OIZBYZuj7twEO36mU3RumDjVGV4Tbf1shTlqHzLArubyGXMrrRNa +FMWr79W9BKVUQTGAdKeL2b0FHqy9LeG5wvUVfWBCQa4HEzPyixP2f8H18cKRgvnyfcEdOcfn QyLgE/xh81Tcf2dX9q0YNcOQ62Buq4o1oAFoBwncBlyVz1HZwjyzOGgazUVHz7cbCtn+Pns5p J1NgaH1X20tmXmRak528LSQXO+iVqpajoNWN1yXkqLn1fP78bG1wWRIb0KYdCs6MlZ3FhdHa4 hPctGEhOWiOP9JERd3E/fgws9Ptn4hI41EBF40IPH7T7V7qPrVBZSws+XooR9FAKOJLeNkPPQ M+/x5UQDpfKW0YPOP3Oo2ZiiFlED+4AGIJySQQ+DSP436PEpH9i17OevUBSE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ueb28Vv50eLS682pwE7hXRNyxD8>
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 08:37:32 -0000

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? 



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