Re: [tsvwg] L4S vs SCE

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Wed, 20 November 2019 10:04 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
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 BD60A1208C6; Wed, 20 Nov 2019 02:04:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.com
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 6LUZQ-EJ4795; Wed, 20 Nov 2019 02:04:46 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130054.outbound.protection.outlook.com [40.107.13.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4882A120827; Wed, 20 Nov 2019 02:04:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mU6BzeZX7yZzIOSYW1O04gZnzFGi5dAIV5BCFYHuu+P9tiXhfXyXnvl5mO0OgS+gzpPlqhhKYVh+OIDa3EgbK7qDiJYQzIKF+ycIeXC5h2vSjOSAb8rCeU+VtrBQppWXfX0bTbqTIsRddqx8fdCpH4xLNAJpk4LL8z6IOZOLbNRsASYJaawGL3aOIISzSY/GqsPea4ECdnUJAXVtGmGj4JUb1wjSeI1H37yhdqzSJLsFVP7TjUM2Q73CvLbJwS2JsfcUqzZitqe0+NQbXqvP99jt3UDZ1TTO0IEa5vJvGnjpz1Yf1bYPORlnPJE73F0fn1iojTHhGlok0mSyJUTNEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7/YZaehmRU6acHfOa6L/E+nlMJghwuqLAPdc3C6pXhU=; b=G6TE1VcCGBD4KJC5Dy2hv2MprYWVWYx8zjQd767MWqnfocbkDZVyP5rYJMoT/gdyChS8d25Cqlw/qr2Tkh7GEbUjvOc3k2Y9Y2GrMM/gefEArh4Zj7FRrG0p5nlc5rgpD7LRk4uH88eWnRHC7nUDevavbsPKaOO88eL7DbF7N/Q2Fck2MDqQ6clNzUeNY5akum6xIySAheLdXZ9qg6IjMREH3HquOFcHQHvpq8szpshk5fG9Uk3fFGU12TCJqYOOvPUGSS8p86fC83tAlSj699LNDvnGYKpJjfd0Lf0rC7WKdVizPhYJTNn4l3Rk9iIAVn4GKjTseVLe5dWCAPCsVQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7/YZaehmRU6acHfOa6L/E+nlMJghwuqLAPdc3C6pXhU=; b=N3WEG81SPVjuXmK/gbDPW5e3S7tla0cOBM8oajUyJVhnXdN/VN6OjWNJYKKzQ2m+x4SEr94nalU98hFUveAptPh3ftxItS0Ct1ML84hWkhsd/PHVQYPcm+1TNQx+EYIb6KHSZaANikIRsnOTNnZL7fYaR449rI5NrPDNsYRz32g=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3276.eurprd07.prod.outlook.com (10.170.244.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.12; Wed, 20 Nov 2019 10:04:43 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2495.009; Wed, 20 Nov 2019 10:04:43 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Sebastian Moeller <moeller0@gmx.de>, G Fairhurst <gorry@erg.abdn.ac.uk>
CC: "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>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] L4S vs SCE
Thread-Index: AdWe0nrRkrzku9jhQamw6kS06HsgqgAK7DuAABW78QAAAJnugAAJXScAAAJlnjA=
Date: Wed, 20 Nov 2019 10:04:43 +0000
Message-ID: <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com>
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>
In-Reply-To: <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [192.176.1.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 270b1656-4dbf-4e76-4539-08d76da110f2
x-ms-traffictypediagnostic: HE1PR07MB3276:|HE1PR07MB3276:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB32760DD4E9FC4BE4147571D4C24F0@HE1PR07MB3276.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(376002)(396003)(366004)(346002)(199004)(189003)(51914003)(13464003)(305945005)(5660300002)(99286004)(14444005)(74316002)(256004)(66446008)(14454004)(316002)(76116006)(66946007)(52536014)(110136005)(7736002)(54906003)(11346002)(33656002)(66616009)(64756008)(66476007)(446003)(81166006)(81156014)(476003)(8676002)(7696005)(486006)(6506007)(53546011)(26005)(102836004)(76176011)(66066001)(186003)(25786009)(66574012)(478600001)(66556008)(8936002)(71190400001)(71200400001)(6246003)(4001150100001)(55016002)(229853002)(2906002)(107886003)(86362001)(4326008)(6116002)(3846002)(9686003)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3276; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rqgcRunZ7+MvCbLkUe4yzEQM9B3K0sXSaYK0hErglhMzo6+AwFCzcMpW7st6ZrJGESMC75gJIgRY8G/te0ma3zYivTX5kSazsktJuE19LIR9KWnN53FDYUxoSWxorSldk83Cw/czLsEKyOszDq+4G6IyELVYiKR0A9jXh0g2LglxYUfZLoED1dhXOveA8sfaRyqw7Za3awMBssVELB8B+7ubeT1tPQdglG9PQIxfjZiTNPWkgeoGqx564jrNvfnxevGe1wzNw0FCsXES9pt7ugvoehLCeTbB5b93pZxsOwrwSdZ04Zl/9Ezrhny8i2MKNt5j7KoERIGokRXZWyAUM/MxqjxEAg/9mvdwQperas2CCw9i4vd1htbkxBpYDfNqqIWnxNYMIAsfsk23hlv1NxMsn0+DZNz41VCJsI4AmUM1b2W4bvOjLus30Pkp71XU
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0762_01D59F92.4F3E1D10"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 270b1656-4dbf-4e76-4539-08d76da110f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 10:04:43.5580 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WhHFeKPuVjkFTTQXnnL35Gj+NSVy90NSmwq/0N8azOsJzfYAxbNsXml8W7sTN/0Op8+ktNmA0PRX204HNfHDbb2Lqnm+xQeAKWON2l2x63CUKqMUwA9Kbz9UZbwFhfAW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3276
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hDrOWr77alONqRSZOywGB1pjtHc>
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 10:04:50 -0000

Hi
Please see inline , an answer to the question that is to some extent to directed me personally 

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


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