Re: [tsvwg] Reasons for WGLC/RFC asap

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Thu, 19 November 2020 09:43 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 0BC163A12E1 for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 01:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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 tLqd4ubIXp5t for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 01:43:41 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on061f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::61f]) (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 A39903A12DE for <tsvwg@ietf.org>; Thu, 19 Nov 2020 01:43:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hq6FDSzvZacTp1Udri3n2nSQkoRDP0Z3laFtsohnSiBOpRbv99vgWG+l2qzR1ZtWAlOiLo1ranf73eXx2cziVja/sixKeEdLtSieqZwek6p2H2/u/AFjCGu3MM5crT/U6oHK3AMphZM7jzcA/b8x0beYPi1WMlRkCpWIWkmqxROLiFtBZAjKRik2DSK0vS+A/ukN9PV1oCgniU52RxLrbqUH/H9T8cytPHquj9EBAr0kbq5UMIt5hVeqtVltLslslQk8w9jtie/07HLtAwskYWTc6qgP3G2dgWGWrbZb09NtFZoc/7VNLVbkDRe/PUttminEk90SJ0ewvE7+zCXTqA==
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=Y/Hukj+7llLp/hFEIOWYnRzMwYTUkR1n9UbRSxRmDP8=; b=S2GEY++R0xzvyd8aEfJ9iqi+ODoj8wtf9m3F8lxkGkAFPzV2DQ0Vg5yilrXxMZ0Q9AN4mVdrB34RgkqDkxAUOEbGKPKQMF7LvLoXrIPAxcWok9QIybuVYJbpkTF/TkUUTqUTjK/DWxhseahZvJryvUk3EYYKjUAN0hZvJE4ItS6zaonvtLMYkyOPldqjz0DJZzv2V6SG3PJveEC4lQq2gkej4C5qnw4o287YQ9Dalw5smwH/X6vRC9VXAjpsjJSjyUuIYzx88xhKZpWOwIhL5azx0WhdbLXjFNIzY0xNFaeAbNXiJr9PTnbnLdN8IxNapfMlcoyDD9wkOfWzvclQHw==
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=Y/Hukj+7llLp/hFEIOWYnRzMwYTUkR1n9UbRSxRmDP8=; b=HKScv3f6J14asAM/hXLCurbLitJ3EYpMUf/LRLyVGyYQIjkyWT0CDAWE499JqhsD/YWHJpdfYvbtwyczdPrRpSZGwAzWI+NUd3WGVeI1P8Q3QF7Lqy4aC+yn5nWyMhnFvmbcAjVTKEh1RqJELPPyfk6F97Ty5zObcJKEhGTpUQ0=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.11; Thu, 19 Nov 2020 09:43:37 +0000
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::50c8:a7da:1a:48a3]) by HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::50c8:a7da:1a:48a3%11]) with mapi id 15.20.3589.016; Thu, 19 Nov 2020 09:43:37 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Lars Eggert <lars@eggert.org>, Steven Blake <slblake@petri-meat.com>
CC: tsvwg IETF list <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] Reasons for WGLC/RFC asap
Thread-Index: Ada9kaHRGNO57vIZSgq7zPn1SuIYhAAQZ1iAABevuwAACIsIYA==
Date: Thu, 19 Nov 2020 09:43:37 +0000
Message-ID: <HE1PR0701MB2876C4FDA655284D4E563042C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com>
References: <AM8PR07MB747626CB7622CB89209018A8B9E10@AM8PR07MB7476.eurprd07.prod.outlook.com> <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com> <4FF8800F-B618-4818-AF5E-1E997EA9FBF3@eggert.org>
In-Reply-To: <4FF8800F-B618-4818-AF5E-1E997EA9FBF3@eggert.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: eggert.org; dkim=none (message not signed) header.d=none;eggert.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fcfdb108-2326-4fc3-15b4-08d88c6f96e8
x-ms-traffictypediagnostic: HE1PR07MB3386:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB33861E8B8EC8339C423C2A7FC2E00@HE1PR07MB3386.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: y6zboIAPeuMu+MJAPLe56iMpb9UPh4FwVkXlBFXQk/U+0YkrgZzNJLp1axQXo4vVlkTMe+q0dqJRPhjvm9qhWHyJTVUMz73trOCcdCmjC8vLLGtssvwdKuouUq9KuAlGwgPSZnxlgrk+ewvDjCgLNE1X4qVFYL9K/cGmwIG9ZOPpH7cv4KUFqDBtBuxTLMZFoh9GHuoGaV3F0nG6IixnRgB6Ak1aqCT+PXqJpdNuZgLvlyf3E4t0CDfXQoXfqKtRiOhh7eB75gSKvcg9YCYR5pVzmikYQ/GozWd1RMd3Z4HprZk98EKEu/o8vdrvBqq1NjlDB9guyDoLsHSm9p09OQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2876.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(66556008)(52536014)(9686003)(8676002)(8936002)(5660300002)(54906003)(83380400001)(110136005)(2906002)(66476007)(316002)(99936003)(4001150100001)(66616009)(478600001)(66946007)(76116006)(33656002)(86362001)(64756008)(7696005)(55016002)(4326008)(107886003)(26005)(53546011)(6506007)(186003)(71200400001)(66446008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: EOBZxNPHlI4Kbu4rrlC8zDoX3ERfGl5JMEO6IUU/0Pk7iTchsqL6o6ZSyGuhoKtFgBYiyVm/IdJi+AbaW9m+2CkqaZKwTtQXzWR27BqxvE5aSkUaUwlqz8xWzHcVa92fZ9PnphPIHcE8J58nIWuNyJEdIqu8+S6ows1OOHpyDcBddmfQQsm2gaKGOY9W+HIV1XzXMJZI5hOE8MPVUSw2XvlyPdYMAL4iHsoT4MNM7L1wPrCb3jCQwJiQOcgiOHylJeCWKIMq54F9UrAjz12jRZ1VL0i67IgGwJJ0zFUPvZ4c1uVb6qQfxDbra82W8c4Sz6cO9Kkb5uh5Y2uVpZeQQF+Uaa6j21o3jM5iu41t+iGAA8rzGYjAH4WM9kTGSgEYWvjV0kNNROHNhOCZi0hDCW5VSfCwvo/GMP6w+5SVsp23WgOlX5qqKG9s+5r/DLEx0F/wa2jwZ7nsFr2oraQXDb531ZJs0wxORJNovi4hNVLHJ64pxcJQNVt5jcUzL8R++J8m3YTFnlTy350sYSlr3mj1vUO6ANuzbQWTexb0KNnU3wTZMUgOBfXXxarZv1YZHZ3GRdTZNwt0/Aq+fEuNJjutMDNkGFid17WyGW5dsH4F7kWQJ+AHfj3iVxLfgJvnk8SVpvHrQ/7nmWaCsFubpA==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0057_01D6BE60.D5C9D340"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2876.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fcfdb108-2326-4fc3-15b4-08d88c6f96e8
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 09:43:37.2006 (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: CPS8tSy5wUZQmsYHtsM8epefjAJqhieCw2uou92KDqXEiL6cNH+nYKjJCTPdD2iJ4cCW6l4vCgGyQKvJQt9D6QKRoLh4eGDwx0jFjeFr99pqt/5zEVgvxrT9+jKnNaUU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3386
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ctQTO-8F2w78uTBVAYAGYZlGqC8>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
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: Thu, 19 Nov 2020 09:43:43 -0000

Lars, Steven

My opinion is that this work has stalled due to an endless discussion on the severity of the listed issues. Do you foresee that a year or so more of equally endless discussion will make anybody more wise ?, between meetings there are only a few people engaged in this debate that floods the TSVWG list, it is a safe bet that most outsiders hit the delete button.
 
I can understand the incentives to try and delay WGLC/RFC, perhaps some hopes that there will by some magic emerge a much better high-fidelity congestion marking in some form. In short, tear the whole thing apart and come up with something much better. 
The problem is that we are talking at least 2 years extra work to get into the state that the L4S drafts are today. 
The use of the ECT(1) code point tend to often lead to questions like "what do we do when L4S fails?". Well the nonce has been declared historic so the process for this is in place, but besides this it is perhaps good to consider that L4S can actually fly ?. 

I really think that it is high time to move this to WGLC, this has dragged on for too long. 

/Ingemar



> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Lars Eggert
> Sent: den 19 november 2020 06:08
> To: Steven Blake <slblake@petri-meat.com>
> Cc: tsvwg IETF list <tsvwg@ietf.org>
> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
> 
> Hi,
> 
> just wanted to say that Steven's email below raises many of the points I tried
> to make - and expresses them better - so +1.
> 
> Thanks,
> Lars
> 
> On 2020-11-18, at 19:50, Steven Blake <slblake@petri-meat.com> wrote:
> >
> > On Wed, 2020-11-18 at 10:31 +0000, De Schepper, Koen (Nokia -
> BE/Antwerp) wrote:
> >> Hi all,
> >>
> >> To continue on the discussions in the meeting, a recap and some extra
> thoughts. Did I miss some arguments?
> >>
> >> Benefits to go for WGLC/RFC asap:
> >> 	• There is NOW a big need for solutions that can support Low Latency
> for new Interactive applications
> >> 	• The big L4S benefits were a good reason to justify the extra network
> effort to finally implement ECN in general and AQMs in network equipment
> >> 	• Timing is optimal now: implementations in NW equipment are
> coming and deployment can start now
> >> 	• Deployment of L4S support will include deployment of Classic ECN
> too! So even for the skeptics among us, that consider that the experiment can
> fail due to CCs not performing to expectations, we will fall back to having
> Classic ECN support
> >> 	• Current drafts are about the network part, and are ready and stable
> for a very long time now.
> >> 	• Only dependency to CCs in the drafts are the mandatory Prague
> requirements (only required input/review from future CC developers: are
> they feasible for you)
> >> 	• We have a good baseline for a CC (upstreaming to Linux is blocked
> by the non-RFC status)
> >
> > These are arguments to deploy a scheme that has been demonstrated to
> work. Not arguments to conduct an *experiment* to determine whether a
> scheme is capable of working (and under what conditions?).
> >
> > Do you completely ignore the simulation results that show that L4S currently
> does not live up to it's own hype? How are you going to conduct the
> *experiment* without at least one CC that seems to work in simulation?
> >
> >> 	• Larger scale (outside the lab) experiments are blocked by non-RFCs
> status
> >
> > Why? What is preventing an interested network operator from conducting
> L4S *experiments* now, using an experimental DSCP to signal L4S packets?
> What is preventing two interested directly peering operators? What is
> preventing two interested but non-peering operators from running tunnels
> between themselves?
> >
> >
> >> 	• It will create the required traction within the CC community to come
> up with improvements (if needed at all for the applications that would benefit
> from it; applications that don’t benefit from it yet, can/will not use it)
> >> 	• NW operators have benefits now (classic ECN and good AQMs) and
> in the future can offer their customers better Low Latency experience for the
> popular interactive applications
> >> 	• When more L4S CCs are developed, the real independent
> evaluation of those can start
> >
> >
> >>
> >> Disadvantages to wait for WGLC/RFC:
> >> 	• We’ll gets stuck in an analysis paralysis (aren’t we already?)
> >> 	• Trust in L4S will vanish
> >> 	• No signs that we can expect more traction in CC development; trust
> and expectations of continuous delays will not attract people working on it, as
> there will be plenty of time before deployments are materializing
> >> 	• Product development of L4S will stall and die due to uncertainty on
> if L4S will finally materialize
> >> 	• Product development of Classic ECN will stall and die due to
> uncertainty on how L4S will finally materialize
> >>
> >> What are the advantages to wait? Do they overcome these disadvantages?
> >>
> >> Regards,
> >> Koen.
> >>
> >
> > As I have said before, the only thing blocking the L4S *experiement* from
> getting IETF blessing IMHO is the wholly unnecessary insistence on consuming
> an IP header bit *now* with no plan to relinquish it if the *experiment* fails.
> Every objection raised to my statement has been an argument predicated on
> ease of deployment. Ease of deployment as a standard is something to be
> considered, yes. The allocation of an IP header bit can be considered *after*
> evaluating the results of the *experiment*, especially when there are
> practical work-arounds (e.g., experimental DSCP) to enable the *experiment*
> to proceed.
> >
> > I see the same style of argument from particle physicists who want to spend
> $40B to build a 150-km circumference particle collider, to find what exactly?
> (Especially considering that all current beyond-Standard Model theories have
> totally bombed).
> >
> >
> > Regards,
> >
> > // Steve