Re: [tsvwg] path forward on L4S issue #16

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Wed, 17 June 2020 16:27 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 DA40E3A0A04 for <tsvwg@ietfa.amsl.com>; Wed, 17 Jun 2020 09:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-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=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 o96P6Lct_nV9 for <tsvwg@ietfa.amsl.com>; Wed, 17 Jun 2020 09:27:24 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60043.outbound.protection.outlook.com [40.107.6.43]) (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 788C73A0A03 for <tsvwg@ietf.org>; Wed, 17 Jun 2020 09:27:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mZ7vp9Rjxut/GQJfQduHePRxMNHgDwvBAWq0nUT8VJ2Co/5G2PEJKeyDGtKsNOLSyschCGBi1H6osBEjr6VW6YA5LlTHIW3282w1Zf0hz3pXpmzCYpD+huVQyvdRwdiKFeH/+5QGSeu/58oP9klSjXs5RWXrRRPYzNJ1UUpx72LqG8c1nzxXKOh0RL6VaTsryu6oNwN3gyyihJJbPdmOltfUTIqaGle8Grh1qArd1vFBmoL2XGYQgnEYPDUl6mRMJfTe+rE6B24cBDc6MX0M64LdyR1I+2cHKQR+bD/CGFQFn6Px+20r0aKxzuhgvuKz8ArI4OStYY7O2nDff3CScw==
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=jsydmp+PamRDS8pBVuUdUAen5oodKM0rAA9ats6JdVg=; b=hltYtF2PQBMTXrFwO1Qq+FDqE2IjcdYTS51tQk4UcXWA5NDGaHjdW4G/RgeEclQqiVKpxTEFH/BGMJBGM1PC+U8yulnYPxq0EhrMouOzCAnu/Y6sFcpaUF3RqUXJVebHvJmehMBNGzOe4NEF55FyG2+O/P5dYmfiREPlfg//IQ4yWwUOuXq0TfaubwhDT3d6lhabK1XBX1BTW60CTqWsXm3yiySX3jAgMpf8aNhakiF8iSJhZyNB+Of8NnltFN8IB11n+oFLzv5kY3ijtNQF+zTE3cLxln9OfIdEVsjqXnff/zRh5Gx1EI7XZO29H+IHM8ZVtiHi9SEmU5/HCNHJvA==
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=jsydmp+PamRDS8pBVuUdUAen5oodKM0rAA9ats6JdVg=; b=JtF5OOMZ72TxkT/No3/mZFr4tl1NNQ06cH8uEfsRRCgTZW7CxT2Pb4fK7fnt370RG4jOafoSaY1D9Nb+5RUnuF+mbcz6X2tmrZ9vBje/gVC2Qu8i8bafsG3OmW3bNBAOQmx06ehr1oID6+ARQKcU0g5j6FMGoI6jhOpU9539OK4=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR07MB3388.eurprd07.prod.outlook.com (2603:10a6:7:30::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10; Wed, 17 Jun 2020 16:27:21 +0000
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::f411:8f72:4035:41d1]) by HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::f411:8f72:4035:41d1%8]) with mapi id 15.20.3109.018; Wed, 17 Jun 2020 16:27:21 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>, Jonathan Morton <chromatix99@gmail.com>, Sebastian Moeller <moeller0@gmx.de>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWPkYZyJNg6cgsQkOoRWoF9Fsxh6jQUFNQgAAFjoCAAAT/IIAABjQAgAAXTICAACKkgIAAFF2AgACvbJCAABzFAIAAByHAgABOV4CAAA2VUIAILGgAgALBbRCAABXrAIAABaAAgAAQBmA=
Date: Wed, 17 Jun 2020 16:27:21 +0000
Message-ID: <HE1PR0701MB287641121218FC0AA72F56B0C29A0@HE1PR0701MB2876.eurprd07.prod.outlook.com>
References: <2DC5C89B-C979-4354-98D7-BBDBC78A42B1@gmail.com> <202006171419.05HEJClG085550@gndrsh.dnsmgr.net>
In-Reply-To: <202006171419.05HEJClG085550@gndrsh.dnsmgr.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gndrsh.dnsmgr.net; dkim=none (message not signed) header.d=none;gndrsh.dnsmgr.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b3d5d288-957a-4508-4534-08d812db4fc2
x-ms-traffictypediagnostic: HE1PR07MB3388:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB3388E547AA13606345CC4A81C29A0@HE1PR07MB3388.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: H61QrWfTkfUKAjXWLcJJUe2w2x/bpaJpGrP3HwcADzuQg+dQADpt98ToywRf1nT+oslLaxPe/qYPwe//MSvIoNfgz096lZnG7gFlxiJfz09yZUMn9c9DX76g7ecZiHvM5Xwg6P5M8cQFjoTZBo9Dprw3yoRnyOZPb2O81mKabwqmlLapi2sveXcXAmb1Vv5METZSTTYwsRZKoN62AUo/kPdGxDVjgHrE6uQji4LqKAzyM6yf8MeAGGi6IttIcgTZZKjCNxZ7CDnhl4QNZyq8W0xyrUX/CNKEaxj5Tr8tV0R+sMn7xQ50XsM82tkDlHL05DjGwQWI1ighv/wYQpWe8w==
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; SFTY:; SFS:(4636009)(39860400002)(396003)(366004)(346002)(136003)(376002)(110136005)(186003)(66446008)(6506007)(54906003)(8936002)(53546011)(66556008)(66946007)(86362001)(33656002)(64756008)(66476007)(66616009)(2906002)(9686003)(478600001)(55016002)(107886003)(99936003)(66574015)(26005)(316002)(76116006)(8676002)(7696005)(5660300002)(4326008)(71200400001)(52536014)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: R1jwMKMK5Jn+jxH+S8fscdytZKqLj6dxEm1gXjAxE3+ZW4nE5I4HDJWarZAzhpxMvIz1TTLCi5HXgfv255L5RJQM9U4Qdn+DOOwNN01ZHZihFm6GuDElB7p/evm/TEO4Df15xrQoYnON+RowNY2HxkaHQQ4DF5QEYcg4UyUcYJ/19khu3FamN6KCM81xK8ojbunYvbOSInmVuSlzcN210eQRC9bXY1//nWFZP1cRK1T72t+0ao4z+7YPluPYvgPjoX7yCd5ZVbUDi2xkm9LujNpfNQJDQqtCaOtK8SPXIL0GzrTzoX6f6MG1L2CVmPKB9wO0zM1w0HpqcvZ/jLvPUuoSNgEDiSJgnpp+F9OwNnIkDVBaBas1jSeS9a4e0zX9qZHuTpIf5UrY3bh9l3d5NtdpIZ+Ypbt1fFYYUUpYhS3lwsNXaBtNwSAWeeIowl0+jFUEfwFi4ByCco+/BI2A68ONnnTxgmsz91xiTc2eFQo=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AA_01D644D4.EFD50940"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b3d5d288-957a-4508-4534-08d812db4fc2
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 16:27:21.6945 (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: duDN+mu28EPcY8hmNbpS1k5nO/Gfs4mQGYfphEZrFzv5lFlDKnYUxLzP6ze71Bx78doK0uLtOVgwSWjmVHfZrSloWDKFcyh6HmAXGmfXXAqvpl1qEyTCYiT011bb39yj
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3388
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/RiMNPL_i5nzVbMxhuDSu99JgZgE>
Subject: Re: [tsvwg] path forward on L4S issue #16
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, 17 Jun 2020 16:27:27 -0000

Hi

OK, I see that this discussion is only going in circles, nearly giving up on
this.
So far I see only one firm evidence that RFC3168 AQMs are deployed and
enabled and these are related to the OpenWrt project, manifested in a few
upgradeable devices (and some not upgradeable) that can be bought in retail
stores. The rest is unconfirmed.

This leads me to a look at the time line for L4S and how it correlates with
the fq-codel work and as a consequence the OpenWrt project.

1) L4S was first brought up late 2013-early 2014 in TSVWG. The ECN
experimentation draft (now RFC8311) was a draft -00 in sept 2016 and I know
that this draft was preceeded by a discussion in TSVWG before that 

2) The FQ-codel work was finalized early 2016, not quite a perfect overlap
with the 00 version of the ECN experimentation work but definitely an
overlap with the preceeding L4S and dualQ discussions and references to the
RITE project which happened around 2014-2015.

With that in mind, shouldn't it have been on the table to consider the
possible future existence of L4S in the different realizations of fq-codel
(and OpenWrt) development? 

Issue #16 is pretty much a consequence of the above timeline, I see that
there was ample time to react but that reaction did not come until 2019 (or
late 2018?), was any assessment done as regards to how L4S could coexist
with fq-codel before the debate started in TSVWG?.

/Ingemar
 
 
 

> -----Original Message-----
> From: Rodney W. Grimes <ietf@gndrsh.dnsmgr.net>
> Sent: den 17 juni 2020 16:19
> To: Jonathan Morton <chromatix99@gmail.com>
> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; Ingemar
> Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>;
> tsvwg@ietf.org
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> > > On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com> wrote:
> > >
> > > Given all the input sofar my impression is that It is difficult to say
how
> serious issue 16 really is.
> > > Surely there is a possibility that L4S flows can get an potentially
unfair
> advantage over a congested node that is  RFC3168 capable (and ECN
> enabled). The question is here when things are deemed as unfair and when
> starvation is a fact, opinions differ.
> > > Another question is to how large extent there will be legacy RFC3168
ECN
> capable (and ECN enabled ) bottlenecks that will "never" be updated or
> replaced. This question is currently difficult to answer.
> >
> > When questions such as these are "difficult to answer", the correct
design
> choice is to assume pessimistically, unless and until the question can be
> answered more definitively.  Therefore, the L4S design must account for
the
> possibility of RFC-3168 AQMs in the network, and actively avoid unfairness
in
> that case.
> >
> > > Yet another aspect is how successful it will be to implement RFC3168
> bottleneck detection e.g. in TCP Prague, I am quite confident that these
will
> not always be successful.
> >
> > I think we can safely say that the detection mechanism currently in TCP
> Prague is not successful.  David Black also pointed out that this would
always
> be a fragile mechanism, difficult to implement correctly, and thus likely
to be
> implemented wrongly by other transports even if a workable version was
> somehow developed.
> >
> > With these facts established, I do not see how L4S can proceed without
> changing the signalling mechanism it uses.  This is something we
intuitively
> realised more than a year ago, when the SCE project was started, but now
> we have actual evidence to back up that intuition.
> 
> And I would like to add to that, this is evidence the L4S team itself
should of
> identified, characterized and docuemented years ago.  I see no reason that
it
> took team SCE to disect the failure modes of L4S so that they could be
> addressed.
> 
> IMHO the fact that L4S is years into the process and only done positive
test
> results presentations leads one to believe it is simply being pushed
through
> the process with little to no care about the actual internet community.
> 
> The proponents seem to genuily be a) unwilling to acknowledge that there a
> problems they should be working on, and b) presenting that L4S is ready
for
> internet deployment inlight of the fact that data showing clear and
present
> problems exist.
> 
> >  - Jonathan Morton
> --
> Rod Grimes
rgrimes@freebsd.org